Epigraf:
Jednou se v lese setkali Ježek a Medvídek.
— Ahoj, Ježku!
— Ahoj, Medvídku!
Tak, slovo za slovem, vtip za vtipem, a Ježek dostal od Medvídka pěstí …
Níže jsou úvahy našeho týmového lídra a také ředitele pro rozvoj produktu RAS — Igora Marnata o specifikách pracovních konfliktů a možných metodách jejich řízení.
Většina konfliktů, se kterými se na práci setkáváme, se vyvíjí podle scénáře podobného tomu, který je uveden výše v epigrafu. Existuje několik účastníků, kteří jsou zpočátku k sobě poměrně přátelští, snaží se vyřešit nějakou otázku, ale nakonec problém zůstává nevyřešený a vztahy mezi účastníky diskuze se nějak zhoršují.
Život je rozmanitý, ve výše popsaném scénáři se vyskytují variace. Někdy jsou vztahy mezi účastníky zpočátku horší, někdy není ani otázka, která by vyžadovala okamžité řešení (jako v epigrafu), někdy po diskuzi zůstávají vztahy stejné, jaké byly před jejím zahájením, ale otázka nakonec zůstává nevyřešená.
Co mají společného všechny situace, které lze označit za situaci pracovního konfliktu?
Za prvé, je to přítomnost dvou nebo více stran. Tyto strany mohou zaujímat různé pozice v organizaci, být v rovnostářských vztazích (kolegové v týmu), nebo na různých úrovních hierarchie (nadřízený — podřízený), mohou být individuální (zaměstnanec) nebo skupinové (v případech konfliktu mezi zaměstnancem a týmem nebo mezi dvěma týmy) atd. Na pravděpodobnost konfliktu a jednoduchost jeho vyřešení má velký vliv úroveň důvěry mezi účastníky. Čím lépe se strany znají, čím vyšší je úroveň důvěry, tím vyšší je šance, že se dohodnou. Například zaměstnanci rozptýleného týmu, kteří se nikdy osobně nesetkali, pravděpodobněji vstoupí do situace konfliktu při řešení jednoduché pracovní otázky než lidé, kteří se alespoň několikrát osobně setkali. Proto je při práci v rozptýlených týmech velmi důležité zajistit pravidelné osobní schůzky všech členů týmu navzájem.
Za druhé, v situaci pracovního konfliktu se strany nacházejí v situaci, kdy je potřeba vyřešit nějakou otázku, která je důležitá pro jednu stranu, obě strany nebo pro organizaci jako celek. Vzhledem ke specifikům situace mají strany obvykle dostatek času a různorodých způsobů, jak danou otázku řešit (formálních, neformálních, schůzek, dopisů, rozhodnutí vedení, existující cíle a plány týmu, hierarchická struktura atd.). To je rozdíl oproti situaci, kdy se řeší pracovně (či nepracovně) zaměřená otázka v organizaci, například důležitá otázka: “Hele, kámo, ze který čtvrti jsi?!” na ulici, nebo konflikt podle epigrafu. Při řešení pracovního problému hraje roli kvalita pracovního procesu a kultura řešení otázek v týmu.
Za třetí, rozhodujícím faktorem konfliktu (z pohledu naší diskuse) je skutečnost, že strany procesu nemohou samy dojít k řešení, které by vyhovovalo všem. Situace si žádá zásah třetí strany, vnějšího rozhodčího. Tento bod se může zdát sporný, ale v podstatě, pokud se konfliktní situace úspěšně vyřešila bez zásahu vnějšího rozhodčího, otázka byla úspěšně vyřešena a vztahy mezi stranami se nezhoršily, je to situace, k níž bychom měli směřovat. O takovém konfliktu se dozvíme jen zřídka nebo náhodně po jeho vyřešení. Čím více otázek může tým vyřešit sám, tím efektivněji bude pracovat.
Dalším charakteristickým rysem konfliktu, který stojí za zmínku, je míra emocionálního napětí při řešení. Konflikt nemusí být nutně spojen s vysokou emocionální intenzitou. Účastníci nemusí křičet a mávat rukama, aby situace byla v podstatě konfliktní. Pokud se problém neřeší a určité emocionální napětí je přitom přítomno (možná není zjevně vyjádřeno navenek), znamená to, že se jedná o situaci konfliktu.
Je třeba se vůbec angažovat do konfliktních situací, nebo je lepší nechat jejich řešení na volném průběhu a čekat, až se problém vyřeší sám? Je třeba. Ne vždy je ve vaší moci nebo kompetenci vyřešit konflikt zcela, ale v jakékoli situaci, v konfliktu jakékoli velikosti, se můžete postavit dospělým způsobem a tím na něj přitáhnout další lidi kolem sebe, zmírnit negativní důsledky konfliktu a přispět k jeho řešení.
Než se podíváme na několik příkladů konfliktních situací, zaměřme se na několik důležitých bodů, které platí pro všechny konflikty.
Při řešení konfliktu je důležité být nad situací, a ne uvnitř ní (tomu se také říká „zaujmout meta pozici“), to znamená, že se nemůžete ocitnout v procesu řešení jako jeden z účastníků. Jinak místo toho, abyste byli externím rozhodčím, pomáhajícím s řešením, pouze posílíte postavení jedné ze stran na úkor druhé strany. Při přijímání rozhodnutí je důležité, aby bylo morálně akceptováno všemi stranami, jak se říká, „koupeno“. Aby, i když strany nebyly z přijatého rozhodnutí nadšené, alespoň byly upřímně ochotny ho dodržovat. Jak se říká, být v pozici disagree and commit. Jinak se konflikt jednoduše změní na jiný, doutnající oheň zůstane pod rašelinou a v určitém okamžiku se nevyhnutelně znovu rozhoří.
Druhý moment, částečně spojený s prvním – pokud se chystáte účastnit se řešení konfliktu, přistupujte k tomu co nejvážněji z hlediska komunikace a studia kontextu. Promluvte si osobně s každou stranou. Nejdříve samostatně s každou. Nespokojte se pouze s e-mailem. V případě rozptýleného týmu promluvte alespoň prostřednictvím videohovoru. Nespokojte se s drby a výpověďmi svědků. Pochopte příběh, co si každá strana přeje, proč to chce, co očekává, zda se již pokusili danou záležitost vyřešit dříve, co se stane, pokud nebude vyřešena, jaké možnosti řešení vidí, jak vidí pozici druhé strany, co považují za správné nebo špatné atd. Načtěte si do své hlavy veškerý možný kontext, nestranně, předpokládajíce, že mají všichni pravdu. Nejsou uvnitř konfliktu, jsou zvenčí, v meta pozici. Pokud je kontext dostupný pouze v e-mailovém vlákně – přečtěte si alespoň celé toto vlákno a související diskuse a dokumenty. Poté, co si to přečtete – stejně si promluvte osobně. Téměř s jistotou uslyšíte něco důležitého, co v e-mailu není.
Třetí důležitý moment – celkový přístup k komunikaci. To jsou běžné věci, nic vesmírného, ale mají velmi velký význam. Nepokoušejte se šetřit čas, komunikujte se všemi účastníky, nekritizujte osobu, ale zvažujte důsledky jejích činů (ne „jsi hrubý“, ale „možná se mohou kluci cítit uraženě”), dejte možnost zachovat důstojnost, diskuze provádějte osobně, nikoli před celou skupinou.
Konflikty obvykle vznikají z jedné ze dvou příčin. První je spojena s tím, zda se člověk v době konfliktu nachází v pozici dospělého nebo v pozici dítěte (o tom níže). To souvisí s jeho emocionální zralostí a schopností řídit své emoce (což, mimochodem, není vždy spojeno s jeho věkem). Druhá běžná příčina – nedokonalost pracovního procesu, která vytváří situace šedých zón, kde je odpovědnost rozložena mezi účastníky, očekávání stran si navzájem nejsou průhledná, role v procesu jsou nejasné.
V řešení konfliktu (jakož i jakéhokoli jiného problému) by měl manažer mít na paměti tři perspektivy: krátkodobou – vyřešit problém / konflikt tady a teď, střednědobou – minimalizovat pravděpodobnost vzniku dalšího konfliktu ze stejného důvodu, a dlouhodobou – budování kultury zralého člověka v týmu.
V každém z nás je vnitřní dítě, přibližně tří- čtyřleté. Většinu času v práci spí, ale občas se probudí a převezme kontrolu. Dítě má své vlastní priority. Je pro něj důležité trvat na tom, že to je jeho pískoviště, máma ho miluje víc, jeho autíčko je nejlepší (design je nejlepší, programuje nejlépe, …). V situaci konfliktu může dítě mačkat hračky, dupat nohama a třískat lopatkou, ale nemůže řešit dospělé otázky (architekturu řešení, přístupy k automatickému testování, termíny vydání atd.), nemyslí v termínech prospěchu pro tým. Dítě v konfliktu můžeme povzbudit, utěšit a poslat spát, požádat ho, aby zavolalo svého dospělého. Před zahájením diskuse v podmínkách konfliktu se ujistěte, že nyní hovoříte s dospělým, nikoli s dítětem, a že i vy stojíte na pozici dospělého. Pokud je vaším upřímným cílem nyní vyřešit vážnou záležitost, jste na pozici dospělého člověka. Pokud je vaším cílem dupat nohama a třískat lopatkou, to je dětská pozice. Pošlete své vnitřní dítě spát a zavolejte dospělého, nebo odložte diskusi. Člověk přijímá emocionální rozhodnutí a poté k němu hledá racionální opodstatnění. Rozhodnutí přijaté dítětem na základě dětských priorit nebude optimální.
Kromě chování během konfliktu je dětská nebo dospělá pozice charakterizována také úrovní odpovědnosti, kterou je člověk ochoten na sebe vzít. V krajních projevech se dětská pozice programátora, se kterou jsem se opakovaně setkával, projevuje takto: napsal jsem kód, odeslal ho na recenzi – má práce skončila. Recenzenti by ho měli zkontrolovat a sloučit, QA by ho měl otestovat, pokud budou problémy – dají mi vědět. Jak podivné, i poměrně dospělí a zkušení lidé se někdy chovají tímto způsobem. Druhý konec stupnice – člověk se považuje za odpovědného za to, aby jeho kód fungoval, byl pokryt testy, osobně ho zkontroloval, úspěšně prošel recenzí (pokud je to potřeba, není problém oslovit recenzenty, probrat otázky hlasem atd.) a byl sloučen, QA při potřebě dostane podporu, jsou popsány testovací scénáře atd. V normálních případech programátor buď zpočátku leží blíže ke dospělému konci stupnice, nebo se tam posune s narůstajícími zkušenostmi (za předpokladu, že v týmu se kultivuje správná kultura). V extrémních případech však pokračuje v práci, obvykle zaujímá dětskou pozici, a pak má on i jeho tým periodicky problémy a konflikty.
Vypěstování správné, dospělé kultury v týmu je důležitý úkol každého manažera. Vyžaduje dlouhý čas a každodenní úsilí, ale výsledek stojí za to. Existují dva způsoby, jak ovlivnit kulturu týmu – osobní příklad (kterým se tým určitě bude řídit, tým vždy hledí na vedoucího) a diskuse a povzbuzení správného chování. Ani zde není nic složitého nebo příliš formálního, stačí při řešení problémů poznamenat, co by zde šlo udělat lépe, zdůraznit, že jste si všimli, když bylo řešení správné, pochválit, zmínit na rozboru vydání atd.
Podívejme se na několik typických konfliktních situací, od jednoduchých po složitější:
Konflikty nesouvisející s pracovními otázkami
Poměrně často se v práci objevují konflikty, které nesouvisí s pracovními otázkami. Jejich vznik a snadné vyřešení obvykle přímo souvisí s úrovní emocionální inteligence účastníků, úrovní jejich dospělosti a nesouvisí s dokonalostí či nedokonalostí pracovního procesu.
Typické příklady – někdo nedostatečně často používá pračku nebo sprchu, což se nelíbí okolí; někomu je dusno, jinému fouká, když otevře okno; někdo je příliš hlučný, zatímco ostatním je potřeba ticho na práci, a tak dále. S řešením konfliktů tohoto druhu je lepší nezapomínat a nenechat je plavat. Samy se nevyřeší a budou nás denně vyrušovat od práce a otravovat atmosféru v týmu. Naštěstí jejich řešení obvykle nečiní velké problémy – stačí klidně si promluvit (samozřejmě jeden na jednoho) s kolegou, který zanedbává hygienu, zajistit pohodlné usazení lidí, kteří preferují ticho/chlazení, koupit zvukově izolující sluchátka nebo postavit příčky, atd.
Další příklad, který jsem za dobu své práce potkal několikrát – psychologická neslučitelnost členů týmu. Z nějakých důvodů spolu lidé prostě nemohou pracovat, každá komunikace končí skandálem. Někdy to souvisí s tím, že lidé mají polarizované názory na nějakou citlivou otázku (obvykle politickou) a neumí je nechat mimo pracovní prostředí. Přesvědčovat je, aby snesli jednoho druhého nebo změnili své chování – je to relativně beznadějné. Jedinou výjimkou, kterou jsem potkal, byli mladí kolegové s otevřeným myšlením, jejich chování je ještě možné postupně měnit periodickými rozhovory. Obvykle se problém úspěšně řeší rozdělením do různých týmů, nebo alespoň zajištěním příležitosti, aby se vzájemně střetávali co nejméně.
Ve všech uvedených situacích je třeba si promluvit s jednotlivými účastníky, prodiskutovat situaci, zeptat se, zda vůbec vidí problém v tomto případě, a zjistit, jaké, podle jejich názoru, existují cesty k řešení, a zajistit jejich účast na rozhodování.
Z hlediska optimalizace pracovního procesu (střednědobá perspektiva, o které jsem mluvil) zde není mnoho možností, jediným bodem pro optimalizaci je brát v úvahu faktor kompatibility při sestavování týmu a dopředu neklást spolu lidi, kteří budou konfliktní.
Z hlediska týmové kultury se tyto situace vyskytují mnohem méně často v týmech s dospělou kulturou, kde si lidé váží týmu a kolegů a dokážou si problémy řešit sami. Kromě toho se takové konflikty v týmech, kde je vysoká úroveň důvěry, lidé dlouho pracují spolu a/nebo často komunikují mimo práci, řeší mnohem jednodušeji (často automaticky).
Konflikty týkající se pracovních otázek:
Takové konflikty bývají obvykle způsobeny oběma příčinami najednou, a to emocionální (kdy někdo z účastníků není na pozici dospělého) a nedokonalostí samotného pracovního procesu. Nejčastější typ konfliktů, se kterými jsem se setkal, jsou konflikty v procesu revize kódu nebo diskuse o architektuře mezi vývojáři.
Vyzdvihl bych zde dva typické případy:
1) V prvním případě vývojář nedokáže získat revizi kódu od kolegy. Patch byl poslán na revizi a nic se neděje. Na první pohled není mezi oběma stranami jasný konflikt, ale pokud se nad tím zamyslíme, je to rozhodně konflikt. Pracovní otázka se neřeší, jedna strana (očekávající revizi) pociťuje jasný diskomfort. Extrémní podtyp tohoto případu vzniká při vývoji v komunitě nebo v různých týmech, přičemž revizor se nemusí o tento konkrétní kód zajímat, a kvůli vytížení nebo jiným okolnostem si nemusí vůbec všímat žádosti o revizi, přičemž externí arbitr (společný pro obě strany) nemusí existovat.
Přístup k řešení, který pomáhá v takové situaci, se týká dlouhodobé perspektivy a kultury dospělého člověka. Za prvé, funguje rozumná aktivita. Není rozumné očekávat, že kód čekající na revizi si sám získá pozornost recenzenta. Je třeba pomoci recenzentům, aby si ho všimli. Pingněte pár lidí, položte otázku na zpětné vazbě, zapojte se do diskuzí. Je zřejmé, že dotěrnost spíše uškodí, než pomůže, je třeba zapojit zdravý rozum. Za druhé, dobře funguje předběžná příprava. Pokud tým chápe, co a proč se děje, proč je tento kód vůbec potřeba, design byl předem projednán a schválen všemi, lidé spíše zaměří pozornost na takový kód a přijmou ho do práce. Za třetí, funguje autorita. Pokud chcete, aby vás někdo recenzoval, sám dělejte spoustu recenzí. Dělejte kvalitní recenze, s reálnými kontrolami, skutečnými testy, užitečnými komentáři. Pokud je vaše přezdívka v týmu známá v dobrém světle, je větší šance, že si někdo všimne vašeho kódu.
Z pohledu pracovního procesu jsou zde možné zlepšení — správné stanovení priorit, zaměřené na to, aby pomohlo vývojáři dosáhnout svých cílů a cílů týmu (recenzovat ostatní, psát dopisy do komunity, doprovázet kód popisem architektury, dokumentací, testy, zapojit se do diskuzí s komunitou atd.), nenechat patche příliš dlouho viset ve frontě, a tak dále.
2) Druhým běžným případem konfliktů při revizi kódu nebo designu jsou odlišné názory na technické otázky, styl kódování, výběr nástrojů. Obrovský význam má úroveň důvěry mezi účastníky, příslušnost do jednoho týmu a zkušenost s týmovou prací. Zablokování nastává tehdy, když se někdo z účastníků postaví do dětské pozice a nesnaží se slyšet, co mu chce jeho protějšek sdělit. Často může jak přístup, který navrhuje druhá strana, tak i přístup, který byl původně navržen, úspěšně fungovat a není zcela zásadní, který z nich vybrat.
Jednou programátor z mého týmu (nazvěme ho Paša) připravil záplatu se změnami v systému nasazování balíčků, které vyvinuli a udržovali kolegové z vedlejšího oddělení. Jeden z nich (Igor) měl silný názor na to, jak by měly být služby Linuxu nastavovány při nasazování balíčků. Tento názor se lišil od přístupu navrženého v záplatě, a tak se jim nedařilo se dohodnout. Jak to bývá, termíny se krátily a bylo třeba dospět k nějakému rozhodnutí, někdo z nich musel zaujmout dospělý postoj. Paša uznával, že obě přístupy mají své místo, ale chtěl, aby jeho varianta prošla, protože žádné výrazné technické výhody nebyly ani u jednoho z variant.
Naše diskuse vypadala přibližně takto (samozřejmě dost schema-ticky, rozhovor trval půl hodiny):
— Paša, za pár dní máme feature freeze. Je důležité, abychom všechno sesbírali a začali testování co nejdříve. Jak to uděláme přes Igora?
— Chce nastavovat služby jinak, nalepil mi tam svoje komentáře …
— A co tam, velké předělávky, hodně práce?
— Ne, práce tam na pár hodin, ale v konečném důsledku je to jedno, obě varianty budou fungovat, proč to potřebujeme? Udělal jsem funkční věc, tak ji prostě schválíme.
— Hele, jak dlouho už to všechno prodiskutováváte?
— Už tak asi týden a půl se v tom motáme.
— Em … můžeme za pár hodin vyřešit otázku, co už zabírá týden a půl a neděláme to?
— No, ano, ale nechci, aby si Igor myslel, že jsem ustoupil …
— Poslouchej, co je pro tebe důležitější, vydat release se svým řešením uvnitř, nebo porazit Igora? Můžeme porazit, ale pak je dobrá šance, že zmeškáme release.
— No … bylo by fajn Igorovi ukázat, že jsem lepší, ale okay, release je důležitější, souhlasím.
— Je ti opravdu tak důležité, co si Igor myslí? Upřímně, jemu je to docela jedno, chce jen jednotný přístup v různých místech toho, za co odpovídá.
— Tak dobře, udělám to, jak si přeje v komentářích, a začneme testování.
— Děkuji, Paša! Byl jsem si jistý, že z vás dvou budeš dospější, i když je Igor starší než ty :)
Problém se vyřešil, vydání bylo uvedeno na trh včas, Paša nebyl zvlášť nespokojen, protože sám navrhl řešení a zrealizoval ho. Igor byl obecně spokojen, protože jeho názor byl zohledněn a udělali to, jak navrhl.
Další typ podobného konfliktu — volba mezi technickými řešeními/knihovnami/přístupy v projektu, zejména v distribuovaném týmu. V jednom z projektů, který byl prezentován jako používající C/C++, se nakonec ukázalo, že technický management projektu je kategoricky proti použití STL (Standard Template Library). To je standardní knihovna jazyka, která usnadňuje vývoj, náš tým si na ni velmi zvykl. Ukázalo se, že projekt je mnohem bližší C než C++, což tým příliš nenadchlo, protože management se snažil a najal opravdu skvělé programátory C++. Přitom americká část týmu, jak inženýři, tak manažeři, pracovala ve firmě dlouho, zvykli si na stávající stav, vše jim vyhovovalo. Ruská část týmu byla shromážděna teprve nedávno, během několika týdnů (včetně mě). Ruská část týmu kategorie odmítla vzdát se obvyklého přístupu k vývoji.
Začaly nekonečné písemné diskuse mezi dvěma kontinenty, e-maily o třech až čtyřech obrazovkách létaly sem a tam, jak v hromadné korespondenci, tak osobně, od programátorů – programátorům a manažerům. Jak to obvykle bývá, e-maily takového rozsahu nikdo, kromě autorů a jejich horlivých zastánců, nečetl. Chaty skřípěly napětím, předávaly na různé strany mnohonásobné úvahy o technických výhodách STL, jak dobře je testována, jak je bezpečná a jak báječný je život s ní a jak hrozný bez ní.
Tento proces trval poměrně dlouho, než jsem si konečně uvědomil, že diskutujeme o technických aspektech, zatímco problém ve skutečnosti není technický. Problém není v přednostech nebo nedostatcích STL či složitosti práce bez něj. Problém je spíše organizační. Potřebovali jsme jen pochopit, jak je strukturována společnost, ve které jsme pracovali. Nikdo z nás předtím neměl zkušenosti s takovou společností. Bylo to tak, že po vývoji kódu a jeho uvedení do produkce se o zabezpečení starali zcela jiní lidé z jiných týmů a z jiných zemí. Tento obrovský inženýrský tým o několika desítkách tisíc inženýrů (v souhrnu) si mohl dovolit pouze zcela základní minimum technických prostředků, abych tak řekl, minimum minimorum. Všechno, co překračovalo inženýrský standard zavedený ve společnosti, fyzicky nemohlo být dále podporováno. Úroveň týmu je určována úrovní jeho nejslabších členů. Po tom, co jsme pochopili skutečnou motivaci činů americké části týmu, byl tento problém stažen z programu, a společně jsme úspěšně vyvinuli a uvedli produkt, přičemž jsme používali standardy platné v společnosti. V tomto případě e-maily a chaty nefungovaly dobře, k dosažení společného porozumění bylo zapotřebí několika cest a mnoha osobních setkání.
Z pohledu pracovního procesu by v tomto konkrétním případě pomohlo mít popis používaných prostředků, požadavků na ně, omezení na přidávání nových, odůvodnění těchto omezení. Tyto dokumenty přibližně odpovídají těm popsaným v bodech Reuse Strategy a Development Environment příručky „Manager’s Handbook for Software Development“, vyvinuté v . I přes svůj věk vynikajícím způsobem popisuje všechny hlavní aktivity a fáze plánování vývoje softwaru tohoto druhu. Přítomnost takových dokumentů velmi usnadňuje proces diskuse o tom, které komponenty a přístupy mohou být v produktu použity a proč.
Z pohledu kultury je zřejmé, že v případě zralejšího postoje, kdy se strany snaží slyšet a pochopit skutečnou motivaci činností kolegů a jednají na základě priorit projektu a týmu, nikoli osobního ega, by se konflikt vyřešil jednodušeji a rychleji.
V jiném konfliktu, který vznikl kvůli výběru technického řešení, mi také zabralo dost času pochopit motivaci jedné ze stran (byl to opravdu neobvyklý případ), ale jakmile byla motivace jasná, řešení se stalo očividným.
Situace je taková: v týmu o asi 20 lidech se objevuje nový vývojář, řekněme, že se jmenuje Stas. Naším standardním komunikačním nástrojem v týmu byl v té době Skype. Jak se později ukázalo, Stas byl velkým fanouškem otevřených standardů a open-source softwaru a používal pouze nástroje a operační systémy, jejichž zdrojové kódy jsou veřejně dostupné a používají veřejně popsané protokoly. Skype mezi takové nástroje nepatří. Strávili jsme spoustu času diskusemi o výhodách a nevýhodách tohoto přístupu, pokusy spustit alternativy Skype na různých operačních systémech, pokusy Stase přesvědčit tým, aby přešel na jiné standardy, psát mu osobně e-mailem, volat mu osobně telefonem, koupit mu druhý počítač speciálně pro Skype atd. Nakonec jsem pochopil, že problém není vlastně technický ani organizační, ale spíše názorový, dokonce by se dalo říct náboženský (pro Stase). I kdybychom nakonec Stasa a Skype spojili (což už zabralo několik měsíců), u jakéhokoli dalšího nástroje by problém vznikl znovu. Neměl jsem žádné skutečné prostředky, jak změnit Stasovo myšlení, a neměl jsem důvod se snažit změnit myšlení týmu, který v tomto prostředí skvěle fungoval. Člověk a společnost prostě měly ortogonální myšlení. V podobných situacích je dobrým řešením organizační přístup. Převedli jsme Stasa do jiného týmu, kde byl více v souladu.
Příčina tohoto konfliktu, podle mého názoru, spočívá v nesouladu osobní kultury konkrétní osoby (která má silný názor, který jí brání jít na kompromisy) s kulturou společnosti. V tomto případě je to samozřejmě chyba manažera. Bylo zpočátku špatné brát ho na projekt tohoto druhu. Stas nakonec přešel na projekt vývoje open-source softwaru a skvěle tam vynikl.
Dobrá ukázka konfliktu, který vznikl současně kvůli dětskému postoji vývojáře a nedostatkům pracovního procesu — situace, kdy v nepřítomnosti definition of done měl vývojář a QA tým různé očekávání ohledně připravenosti funkce předané do QA. Vývojář považoval za dostatečné napsat kód a hodit funkci přes plot do QA — tam se s tím vyrovnají. Docela dospělý a zkušený, mimochodem, programátor, ale měl takový vnitřní práh kvality. QA s tím nebyli spokojení a požadovali, aby mu ukázali a popsali, co sám zkontroloval, a požadovali od něj testovací scénář. Již v minulosti měli s funkcionalitou od tohoto vývojáře problémy a nechtěli zbytečně trávit svůj čas. Mimochodem, měli pravdu — funkce skutečně nefungovala, kód před předáním do QA nezkontroloval.
Abych situaci vyřešil, požádal jsem ho, aby mi ukázal, že všechno opravdu funguje (nefungovalo, a musel to opravit), probrali jsme s týmem a QA definition of done (udělat ho písemným jsme se rozhodli, protože jsme nechtěli proces příliš byrokratizovat), no a s tímto specialistou jsme se brzy rozloučili (k obecnému ulehčení).
Z pohledu pracovního procesu by možná zlepšení v tomto případě mohlo spočívat v existenci definition of done, požadavcích na doprovod každé funkce unit a integračními testy, popisu testování, které provedl vývojář. V jednom z projektů jsme měřili úroveň pokrytí kódu testy během CI, a pokud úroveň pokrytí po přidání patche klesla, testy byly označovány jako neúspěšné, tj. jakýkoli nový kód mohl být přidán pouze při přítomnosti nových testů pro něj.
Další typický příklad konfliktu, úzce souvisejícího s organizací pracovního procesu. Máme produkt, tým vyvíjející tento produkt, tým podpory a zákazníka. Zákazník má problémy s produktem a obrací se na podporu. Podpora analyzuje problém a zjistí, že problém se nachází v produktu, přenáší problém na produktový tým. Produktový tým má rušné období, blíží se vydání, proto tiket s problémem od zákazníka, ztracený mezi ostatními tikety u vývojáře, jemuž byl přidělen, visí několik týdnů bez pozornosti. Podpora si myslí, že vývojář pracuje na problému zákazníka. Zákazník čeká a doufá, že se na jeho problému pracuje. Ve skutečnosti se zatím nic neděje. Po několika týdnech se zákazník konečně rozhodne zeptat se na pokrok a ptá se podpory, jak to vypadá. Podpora se ptá vývoje. Vývojář se lekne, prohlédne si seznam tiketů a objeví tam tiket od zákazníka. Čtečíc tiket od zákazníka, si uvědomuje, že informace pro vyřešení problému nestačí, a potřebuje další logy a dumpy. Podpora žádá zákazníka o další informace. A zde si zákazník uvědomuje, že se na jeho problému celou dobu nikdo nepracoval. A přijde bouře …
V této situaci je řešení samotného konfliktu docela zřejmé a lineární (opravit produkt, aktualizovat dokumentaci a testy, uklidnit zákazníka, vydat hotfix atd.). Je důležité analyzovat pracovní proces a pochopit, kdo nese odpovědnost za organizaci interakce mezi dvěma týmy, proč se taková situace vůbec mohla stát. Je jasné, že je třeba opravit proces - někdo by měl monitorovat celkový obraz bez připomínek od zákazníků proaktivně. Tikety od zákazníka by měly být viditelné mezi ostatními tikety u vývojářů. Podpora by měla vidět, zda vývoj pracuje na jejích tiketech v daném okamžiku, pokud ne - kdy může začít pracovat, kdy lze očekávat výsledek. Podpora a vývoj by měly pravidelně komunikovat a diskutovat o stavu tiketů, shromažďování potřebných informací pro ladění by mělo být co nejvíce automatizováno atd.
Stejně jako se protivník ve válce snaží udeřit na spojení mezi dvěma jednotkami, tak i v práci bývá tím nejcitlivějším a nejzranitelnějším místem obvykle interakce mezi týmy. Pokud jsou manažeři podpory a vývoje dostatečně zralí, dokážou proces opravit sami; pokud ne, proces bude i nadále generovat konflikty a problémy, dokud nezasáhne manažer, který dokáže situaci napravit.
Dalším typickým příkladem, se kterým jsem se opakovaně setkal v různých firmách, je situace, kdy produkt vyvíjí jeden tým, automatizované integrační testy provádí druhý tým a infrastrukturu, na které to vše běží, spravuje třetí tým. Problémy při běhu testů vznikají neustále a příčinou problémů může být jak produkt, tak testy a infrastruktura. Problematické bývá obvykle dohodnout se, kdo by měl provádět prvotní analýzu problémů, hlásit chyby, zpracovávat logy produktu, testů a infrastruktury atd. Konflikty zde jsou velmi časté a zároveň jednotné. V případě vysokého emocionálního napětí se účastníci často vracejí do dětské pozice a zahajují diskuse typu: „proč bych se tím měl zabývat“, „u nich se to víc kazí“ atd.
Z pohledu pracovního procesu konkrétní kroky k vyřešení otázky závisí na složení týmů, druhu testů a produktu atd. V jednom z projektů jsme zavedli periodické služby, při nichž týmy sledovaly testy na střídavém principu, po týdnu. V jiném projektu prováděli prvotní analýzu vždy vývojáři testů, avšak tato analýza byla dost základní a produkt byl dost stabilní, takže to fungovalo dobře. Hlavní je zajistit transparentnost procesu, jasnost očekávání pro všechny strany a pocit spravedlnosti situace pro všechny.
Je konflikt v organizaci skutečně problém? Je to špatné znamení, když se ve vašem týmu často (nebo alespoň příležitostně) vyskytují konflikty? Obecně ne. Pokud dochází k růstu, rozvoji a nějaké dynamice, objevují se otázky, které dosud nebyly řešeny, a tyto otázky mohou vyvolat konflikty. To je indikátor, že je třeba se zaměřit na určité oblasti a že existují prostor pro zlepšení. Je špatné, pokud konflikty vznikají velmi často a obtížně se řeší nebo trvá dlouho, než se vyřeší. To je pravděpodobně známka nedostatečně nastavených pracovních procesů a nízké zralosti týmu.
Zdroj: habr.com
