Otázka:
Jak se mám učit, aniž bych byl otravný pro lidi kolem mě?
Jonathan Stanton
2014-08-06 23:11:53 UTC
view on stackexchange narkive permalink

Nejsem nový v tom, co dělám, ale stále se musím hodně učit. Když mě lidé požádají o pomoc, jsem obecně rád, že se mohu podělit o svůj pohled. Když lidé kritizují moji práci, je pro mě těžké spolknout, ale bránit se lidem, že poukazují na mé nedostatky, ze mě nedělá lepšího člověka ani si nevyhraje přátele, takže je to něco, na čem pracuji s grácií. právě jsem se připojil k novému týmu a stále si zvykám na to, jak lidé dělají věci. Naučil jsem se, že poslech může být moje tajná zbraň, a měl bych to používat hojně. Ale když najdu něco, o čem se cítím opravdu špatně, a chtěl bych o tom mluvit s lidmi v mém týmu, jsou obecně velmi defenzivní a bylo těžké udržet se na jejich dobré straně.

Se vším tím řekl, jak mám přistupovat k ostatním a žádat o pomoc / kritiku, aby ostatní pracovali, aniž by je bránili?

Už jste někdy uvažovali o tom, kolik z příběhu víte, ve srovnání s tím, jaké předpoklady ve věci vytváříte?
Mírně jsem to upravil, aby to bylo více zaměřeno na téma webu, vítejte na pracovišti! [Tato otázka] (http://workplace.stackexchange.com/q/23220/2322) bude také užitečná, protože se týká poměrně významně.
Kromě vynikajících odpovědí, které již poskytli ostatní, se můžete sami trénovat v [kladení sokratovských otázek] (https://www.google.com/search?q=asking+the+socratic+questions)
možný duplikát [Jak se mohu bránit v překročení své autority se spolupracovníky?] (http://workplace.stackexchange.com/questions/23772/how-can-i-keep-myself-from-overstepping-my- orgán-se-spolupracovníky)
@JBKing: Přál bych si, abych mohl na tvůj komentář uvést obrovskou halo. Toto je první otázka, na kterou se ptám jednotlivců, které mentoruji, když mají problém, kterému se nezdá, že by se dostali kolem.
čtyři odpovědi:
Nevir
2014-08-06 23:36:43 UTC
view on stackexchange narkive permalink

Tady je opravdu několik otázek :) Pokusím se je rozebrat a každou z nich řešit:


Jak se vyhnout obraně, když lidé kritizují moji práci?

Na tuto otázku nemám skvělou odpověď; ale několik postřehů o případech, kdy se ve své práci cítím defenzivně:

  • Do projektu jste se dostali jen dny / hodiny / týdny / měsíce a někdo jej sestřelil většinu nebo celý .

    • Obvykle je to vaše chyba: Tuto myšlenku jste měli zkontrolovat se svým týmem velmi brzy v procesu.

    • Někdy týmy / klienti během procesu vývoje změní názor. Ach, dobře; alespoň jste s nimi často kontrolovali svou práci, že? Chápou, že vaše předchozí práce byla cenná, ale bylo nutné provést kompromisy.

  • Připnuli jste si na myšlenku a máte potíže s přijetím alternativ.

    • Zastavit. Nadechni se. Přijměte, že se můžete mýlit, a zkuste zjistit, jaké informace vám chybí.

Jak a kdy požádám o pomoc?

Často, ale ne příliš často.

  • Nepožádejte o pomoc pokaždé, když uvíznete: To má tendenci skončit v situaci, kdy jste závislí na týmu kamarád, abys dokončil svou práci. To je pro vás špatné (nenaučíte se řešit problémy) a špatné pro ně (časová ztráta).

  • Nehubujte však problém příliš dlouho, aniž byste se ptali o pomoc.

Obecné pravidlo: Strávte hodinu zkouškou zabývat se problémem; zkuste o tom shromáždit co nejvíce informací. Pokud stále uvíznete, zeptejte se špičatých otázek svých spoluhráčů.

Namísto „Nemůžu přijít na <thing>. Pomoc?“, Přejděte na „Kdokoli narazil na <thing> nebo podobné?". (žádost o pomoc při ladění je výjimkou z tohoto pravidla)

Jak vzbudím obavy ohledně technologie týmu?

Toto je opravdu jen druhý konec první otázky.

Musíte dávat velký pozor, abyste svým spoluhráčům nedovolili, aby při vznášení takových obav cítili potřebu bránit se. Několik rad:

  • Předpokládejme, že vám chybí důležitý kontext ( téměř vždy ).

  • Spíše než bez okolků navrhovat alternativní řešení, proberte se. Zeptejte se otázek, které vedou vaše týmové kolegy ke stejným závěrům jako vy.

  • Nechte své ego za sebou. Neobtěžujte se, když / pokud někdo krouží kolem, aby s vámi souhlasil, ale myslí si, že to byl jeho nápad (a nedává vám kredit). Místo toho se radujte, že se vaše technologie nyní ubírá směrem, který vám vyhovuje více!

Dobře formulovaná odpověď. Vítejte na pracovišti!
Dobré body. Pokud jde o žádost o pomoc: Začněte tím, že si přesně zapíšete, v čem je problém, a předvídejte, jaké budou jejich následné otázky. Tento proces vám velmi často dá odpověď, kterou potřebujete. Viz také Rubber ducking: http://en.wikipedia.org/wiki/Rubber_duck_debugging
user22432
2014-08-06 23:24:31 UTC
view on stackexchange narkive permalink

Když jsem narazil na situaci nebo nastavení, které se zdá divné, zeptám se někoho jiného slovy: „Můžete mi dát nějaké informace o tom, proč děláme X způsobem Y?“ To žádá o vysvětlení, proč se věci dějí tímto způsobem, a zároveň je třeba si uvědomit, že někdy (dobře, často, zvláště v podnikových situacích), si člověk musí vystačit s méně než optimální situací:

  • starší kód
  • „obchodní potřeby“, které se zdají divné, ale jsou některým projektem domácích mazlíčků vyšší úrovně
  • méně než dokonale efektivní plugin, který má některé funkce, na které se velmi spoléhá a tak to nelze nahradit
  • žádný čas / rozpočet na krok zpět a opravu věcí

Díky tomu vám členové vašeho týmu mohou poskytnout zázemí, aniž by se cítili jako oni musí ospravedlnit, proč osobně nepokročili a neopravili nějaký nepořádek. Zvláště pokud se jedná o tým, na který se pravidelně valí, nebo který má málo zdrojů a od kterého se pravidelně očekává, že bude dělat zázraky, pravděpodobně už má mentální mentalitu. Koncipování vašich otázek způsobem, který výslovně ukládá vinu mimo skupinu (nebo přinejmenším ne uvnitř ní), je z nich velmi pod tlakem, aby ospravedlnil extrémní standardy kódování preclík-logika nebo ne-nejlepší praxe.

Páni, moc děkuji! Cítím, že to musím každé ráno přezkoumat, dokud to nebude zakořeněné! Děkuji!
Dokonce i ti nejlepší vývojáři skončili chaotickým kódem z opotřebení a okolností. Všichni se snažíme začít s čistým kódem, ale krátké termíny a časté změny mohou změnit i ten nejčistší kód na něco, co stojí za to. „Nejlepší“ přístup příliš často není pro „právě teď“ dobrý. Stojí za zmínku, že mnoho jazyků podporuje značku #hack, aby označila tato obzvláště vhodná místa v kódu pro pozdější revizi, aby tyto gremlinky vyčistili, než se vrátí, aby vás pronásledovali.
A pamatujte si ve starších kódových základnách, že to, co teď vypadá špatně, nemusí být v době psaní špatnou volbou. Lidé nenahrazují pracovní kód jen proto, že přichází nový způsob, jak to udělat.
RualStorge
2014-08-06 23:37:20 UTC
view on stackexchange narkive permalink

Nejlepším způsobem, jak udělat kritiku něčí práce, je ujistit se, že si to o kódu ponecháte, rozvíjet porozumění, PROČ byste měli v situaci udělat X místo Y.

síla otázek

Nikdo vás nemá rád, když říkáte „to je špatné“, „nedělejte to tak“ atd. I když nabídnete vysvětlení, začali jste dotazem kvalitu své práce a pravděpodobně je postaví do defenzívy. (Jakmile se dostanou do defenzívy, celý proces se zastaví)

Lepší způsob je říci „Hej, uvažoval jsi (jiná možnost), obávám se, že bychom mohli (důvod, proč metoda zde se nedoporučuje) zde. “ Příklad, vložený CSS. „Hej, uvažoval jsi o jejich zařazení do třídy? Opravdu se obávám, jak se náš projekt rozšiřuje, může být těžké zachovat styly na všech těchto samostatných divech.“

Tímto způsobem neútočíte na jejich práci , místo toho diskutujete o možnostech a uvedete důvod zvážit druhou možnost. V některých případech může mít jedinec velmi platný důvod, proč je jeho přístup v tomto konkrétním případě vhodnější, otevřením této cesty mu dáte šanci to vysvětlit a oba máte potenciál se učit a rozšiřovat své znalosti.

NIKDY nepoužívejte slova jako Správné, Špatné, Lepší, Nejlepší, Horší, Nejhorší atd. Z toho okamžitě vyplývá, co někdo udělal, bylo nekvalitní, ať už je tomu tak nebo ne. Kromě toho existují případy, kdy je zaručeno to, co je obvykle považováno za špatný postup, a případy, kdy věci, které jsou považovány za nejlepší, jsou skutečně špatné nápady.

Dokud o tom budete diskutovat tým, který vylepší váš kód, bude obecně dobrý. (ve všech případech čas od času budou jejich vzplanutí, v takových případech nechte nálady vychladnout a vraťte konverzaci zpět na správnou cestu, abyste zjistili, co má smysl pro konkrétní případ)

(každý by měl zvážit to při kritice vysvětlete lidem, o kterých si myslíte, že útočí na váš kód)

Přál bych si, abych mohl hlasovat pro všechny tyto odpovědi, děkuji vám za přidání vašeho postřehu!
Kdykoli existuje řada vynikajících zdrojů, které vám poskytnou tento pohled na veterány v našem oboru. Velmi doporučuji provést vyhledávání, abyste našli hybatele a shakery ve vašich konkrétních vývojářských výklencích (.net, php, Java atd.). Často vám mohou poskytnout znalosti, které by jinak trvalo roky, než by se někdo naučil bouchnout hlavou o zeď. (nepřipojovat nikoho konkrétního, protože se to zde mračilo)
+1 zejména pro sílu otázek. I když nejsem fanouškem frázovacích otázek typu „uvažoval jste o tom“ nebo „mám obavy“. Ty stále staví lidi do defenzívy. Nejlepší způsob, jak přimět lidi, aby „viděli vaši cestu“, je přimět druhou osobu, aby si myslela, že to byl její nápad. V tomto ohledu nic nefunguje lépe než otázky „Co kdyby“ a „Jak bychom mohli“. Vaše otázky by samozřejmě vždy měly být úvodními otázkami, jejichž cílem je přimět osobu, aby dospěla ke stejnému závěru jako vy. Někdy ale přijdou s lepšími závěry.
@Dunk velmi dobrá poznámka, opravdu jsem neměl problémy s „zvážil jste“, ale myslím si, že „co kdyby“ a „jak bychom mohli“ jsou pravděpodobně efektivnější při dosahování konečného cíle zde.
user8365
2014-08-11 22:03:51 UTC
view on stackexchange narkive permalink

Respektujte čas ostatních lidí a nepřerušujte je, pokud to není kritické. Zkuste a zkuste nastavit čas na kladení otázek, protože jste noví. Může to být stanovený čas nebo možná mají členové týmu preferenční časy pro otázky (první věc ráno, hned po obědě atd.). U některých projektů může být pracovní zátěž cyklická. V Agile může být na konci sprintu špatná doba. Tímto způsobem můžete nashromáždit řadu otázek a zeptat se správné osoby.

Dělejte si poznámky. Nikdo vám nechce vysvětlovat stále stejné věci. Některé z těchto poznámek mohou být důležité, když je do týmu přidána další osoba. Není důvod, aby museli projít stejnými bolestmi učení, jaké jste vy, pokud se tomu lze vyhnout jednoduchou dokumentací.

Když pracujete s lidmi jeden na druhého, je méně pravděpodobné, že se stanou defenzivními. Mnoho lidí bude reagovat negativně, pokud je před skupinou zpochybníte. Dozvídáte se, kdo jsou tito jednotlivci ve vašem týmu. Ujistěte se, že chápou, že se učíte, a máte odlišný přístup k něčemu, co doporučili. Jakmile pochopíte rozhodnutí v kontextu a omezení, můžete zjistit, proč provedli určitá rozhodnutí.



Tyto otázky a odpovědi byly automaticky přeloženy z anglického jazyka.Původní obsah je k dispozici na webu stackexchange, za který děkujeme za licenci cc by-sa 3.0, pod kterou je distribuován.
Loading...