Epigraph:
Kdysi dávno se v lese potkali Ježek a Medvěd.
- Ahoj, Ježku!
- Ahoj, Medvídku!
Takže, slovo od slova, vtip od vtipu, Ježek dostal od Medvídka ránu do tváře...
Níže je diskuse od našeho vedoucího týmu a také ředitele vývoje produktů RAS Igora Marnata o specifikách pracovních konfliktů a možných metodách jejich zvládání.
Většina konfliktů, se kterými se v práci setkáváme, se vyvíjí podle scénáře podobného tomu, který je popsán v epigrafu výše. Existuje několik účastníků, kteří jsou k sobě zpočátku docela příznivě nakloněni, snaží se vyřešit nějaký problém, ale nakonec problém zůstává nevyřešen a vztahy mezi účastníky diskuse se z nějakého důvodu kazí.
Život je rozmanitý a ve výše popsaném scénáři se vyskytují variace. Někdy není vztah mezi účastníky zpočátku příliš dobrý, někdy dokonce neexistuje problém, který vyžaduje přímé řešení (jako například v epigrafu), někdy po diskusi zůstává vztah stejný jako před začátkem, ale problém nakonec není vyřešen.
Co je společné ve všech situacích, které lze definovat jako situace pracovního konfliktu?
Za prvé, existují dvě nebo více stran. Tyto strany mohou zaujímat různá místa v organizaci, být v rovnoprávném vztahu (kolegové v týmu), nebo na různých úrovních hierarchie (šéf - podřízený), být individuální (zaměstnanec) nebo skupinový (v případě konfliktu mezi zaměstnanec a tým nebo dva týmy) a tak dále. Pravděpodobnost konfliktu a snadnost jeho řešení jsou do značné míry ovlivněny mírou důvěry mezi účastníky. Čím lépe se strany znají, čím vyšší je míra důvěry, tím vyšší je šance, že se dohodnou. Například členové distribuovaného týmu, kteří nikdy nekomunikovali tváří v tvář, mají větší pravděpodobnost konfliktu kvůli jednoduchému pracovnímu problému než lidé, kteří měli alespoň pár osobních interakcí. Proto je při práci v distribuovaných týmech velmi důležité zajistit, aby se všichni členové týmu pravidelně osobně setkávali.
Za druhé, v situaci konfliktu v práci jsou strany v situaci, kdy řeší nějaký problém, který je důležitý pro jednu ze stran, pro obě strany nebo pro organizaci jako celek. Zároveň, vzhledem ke specifikům situace, mají strany obvykle dostatek času a různé způsoby, jak ji vyřešit (formální, neformální, schůzky, dopisy, rozhodnutí vedení, přítomnost cílů a plánů týmu, fakt hierarchie atd.). To se liší od situace řešení pracovního (nebo nepracovního) problému v organizaci, například od řešení důležité otázky: „Eh, chlapče, z jaké jsi? na ulici, nebo konflikt z epigrafu. V případě řešení pracovního problému záleží na kvalitě pracovního procesu a kultuře řešení problémů v týmu.
Za třetí, určujícím faktorem konfliktu (z hlediska naší diskuse) je skutečnost, že účastníci procesu nemohou samostatně dojít k řešení problému, které by vyhovovalo všem stranám. Situace vyžaduje zásah třetí strany, externího arbitra. Tento bod se může zdát kontroverzní, ale v podstatě, pokud byla konfliktní situace úspěšně vyřešena bez zásahu externího arbitra, problém byl úspěšně vyřešen a vztahy stran se nezhoršily, je to situace, o kterou bychom měli usilovat . S největší pravděpodobností se o takovém konfliktu ani nedozvíme, nebo se to dozvíme náhodou po jeho vyřešení. Čím více problémů může tým vyřešit sám, tím efektivnější bude.
Dalším charakteristickým rysem konfliktu, kterého se vyplatí dotknout, je míra emoční intenzity při rozhodování. Konflikt nemusí být nutně spojen s vysokou emoční úrovní. Účastníci nemusí křičet a mávat rukama, aby situace byla v podstatě konfliktní. Problém není vyřešen, je přítomno určité emocionální napětí (možná není navenek jasně vyjádřeno), což znamená, že jsme postaveni před konfliktní situaci.
Je nutné do konfliktních situací vůbec zasahovat, nebo je lepší nechat jejich řešení volný průběh a počkat, až se problém vyřeší sám? Potřebovat. Není vždy ve vaší moci nebo kompetenci konflikt zcela vyřešit, ale v jakékoli situaci, v konfliktu jakéhokoli rozsahu můžete zaujmout dospělou pozici, čímž do ní přivedete několik dalších lidí kolem sebe a zmírníte tak negativní důsledky konfliktu. konfliktu a přispět k jeho řešení.
Než se podíváme na několik příkladů konfliktních situací, podívejme se na několik důležitých bodů společných všem konfliktům.
Při řešení konfliktu je důležité být nad bojem, nikoli uvnitř něj (také se tomu říká „zaujmout metapozici“), tedy nebýt součástí jedné ze stran v procesu řešení. V opačném případě pomoc externího arbitra pouze posílí postavení jedné ze stran na úkor druhé strany. Při rozhodování je důležité, aby bylo morálně přijato všemi stranami, jak se říká „koupeno“. Takže, i když strany nebyly potěšeny přijatým rozhodnutím, alespoň upřímně souhlasily s jeho provedením. Jak se říká, umět nesouhlasit a zavázat se. V opačném případě konflikt jednoduše změní svou podobu, doutnající oheň zůstane pod rašeliništěm a v určité chvíli se nevyhnutelně znovu rozhoří.
Druhý bod, částečně související s prvním, je ten, že pokud jste se již rozhodli podílet na řešení konfliktu, berte to co nejvážněji z hlediska komunikace a studia souvislostí. Promluvte si osobně s každou ze stran. Pro začátek zvlášť s každým. Nespokojte se s poštou. V případě distribuovaného týmu mluvte alespoň přes video odkaz. Nespokojte se s doslechem a zprávami očitých svědků. Porozumět příběhu, co každá strana chce, proč to chtějí, co očekávají, zkoušeli tento problém vyřešit již dříve, co se stane, když se nevyřeší, jaká řešení vidí, jak si představují pozici druhá strana, co si myslí, správné nebo špatné atd. Nahrajte si do hlavy všechny možné souvislosti, s otevřenou myslí, za předpokladu, že každý má pravdu. Nejste uvnitř konfliktu, jste mimo něj, v metapozici. Pokud je kontext dostupný pouze ve vláknu příspěvku, přečtěte si jej alespoň celý a související vlákna a dokumenty. Po přečtení stále mluvte svým hlasem. Téměř zaručeně uslyšíte něco důležitého, co není v e-mailu.
Třetím důležitým bodem je obecný přístup ke komunikaci. Jsou to obyčejné věci, nic kosmického, ale jsou velmi důležité. Nesnažíme se šetřit čas, mluvíme se všemi zúčastněnými, nekritizujeme člověka, ale zvažujeme důsledky jeho jednání (ne „jsi drzý“, ale „možná by se chlapi mohli urazit tato věc“), dáváme možnost zachovat si tvář, diskutujeme osobně, ne před linkou.
Konflikty jsou obvykle způsobeny jedním ze dvou důvodů. První souvisí s tím, zda je člověk v době konfliktu v pozici dospělého nebo v pozici dítěte (více níže). Může za to jeho citová vyspělost, schopnost zvládat emoce (což mimochodem ne vždy souvisí s jeho věkem). Druhým častým důvodem je nedokonalost pracovního procesu, která vytváří situace šedých zón, ve kterých je odpovědnost rozložena mezi účastníky, očekávání stran nejsou vůči sobě transparentní a role v procesu jsou rozostřené.
V souladu s tím musí mít manažer při řešení konfliktu (stejně jako jakéhokoli jiného problému) na paměti tři perspektivy: krátkodobý - vyřešit problém/konflikt tady a teď, střednědobý - minimalizovat pravděpodobnost vzniku dalšího konfliktu ze stejného důvodu a dlouhodobě - pěstovat v týmovém člověku kulturu dospělých.
Každý z nás má vnitřní dítě, asi tříleté, čtyřleté. Většinu času v práci prospí, ale někdy se probudí a převezme kontrolu. Dítě má své priority. Je důležité, aby trval na tom, že je to jeho pískoviště, jeho matka ho miluje víc, jeho stroj je nejlepší (design je nejlepší, programuje nejlepší, ...). V konfliktní situaci může dítě mačkat hračky, dupat nohama a praskat špachtlí, ale neumí řešit problémy dospělých (architektura řešení, přístupy k automatizovanému testování, data vydání atd.), nepřemýšlí o výhodách pro tým. Dítě v konfliktu lze povzbudit, utěšit a poslat do postele tím, že ho požádáte, aby zavolalo svému dospělému. Před zahájením diskuse v konfliktní situaci se ujistěte, že mluvíte s dospělým, nikoli s dítětem, a že vy sami jste v pozici dospělého. Pokud je v tuto chvíli vaším upřímným cílem vyřešit závažný problém, jste v pozici dospělého. Pokud je vaším cílem dupat nohama a praskat lopatkou, je to dětská poloha. Pošlete své vnitřní dítě do postele a zavolejte dospělému nebo přeložte diskusi. Člověk udělá emocionální rozhodnutí, a pak pro to hledá racionální zdůvodnění. Rozhodnutí učiněné dítětem na základě dětských priorit nebude optimální.
Kromě chování v době konfliktu je postavení dítěte nebo dospělého charakterizováno také mírou odpovědnosti, kterou je člověk připraven na sebe vzít. Dětská pozice programátora, se kterou jsem se nejednou setkal, ve svých extrémních projevech vypadá takto: Napsal jsem kód, poslal na recenzi – moje práce je hotová. Recenzenti by to měli zkontrolovat a schválit, kontrola kvality by to měla zkontrolovat, pokud budou problémy, dají mi vědět. Kupodivu se tak někdy chovají i poměrně zralí a zkušení lidé. Na druhém konci stupnice je, že se člověk považuje za odpovědný za to, že jeho kód funguje, je pokryt testy, byl jím osobně zkontrolován, úspěšně prošel kontrolou (v případě potřeby není problém pingnout recenzenty, diskutovat o problémech hlasem atd.) a byla potlačena, QA v případě potřeby poskytne pomoc, budou popsány testovací scénáře atd. V normálních případech programátor buď začíná blíže konci škály pro dospělé, nebo se tam přesouvá, když získává zkušenosti (za předpokladu, že se v týmu pěstuje správná kultura). V extrémních případech pokračuje v práci, obvykle zaujímá dětinskou pozici, pak má on a tým periodicky problémy a konflikty.
Pěstování správné, vyspělé kultury v týmu je důležitým úkolem každého manažera. Trvá to dlouho a každodenní úsilí, ale výsledek stojí za to. Existují dva způsoby, jak ovlivnit týmovou kulturu – jít příkladem (který bude určitě následován; tým vždy vzhlíží k vedoucímu) a diskutovat a odměňovat správné chování. Ani zde není nic srozumitelného nebo příliš formálního, jen si při projednávání problémů všimněte, že se zde něco dalo udělat, zdůrazněte, že jste si všimli, kdy bylo rozhodnuto správně, pochvalte, poznamenejte při kontrole vydání atd.
Podívejme se na několik typických konfliktních situací, od jednoduchých po složité:
Konflikty nesouvisející s pracovními problémy
Dost často dochází v práci ke konfliktům, které nesouvisejí s pracovními záležitostmi. Jejich výskyt a snadnost řešení obvykle přímo souvisí s úrovní emoční inteligence účastníků, s jejich úrovní zralosti a nesouvisí s dokonalostí či nedokonalostí pracovního procesu.
Typické příklady: někdo nepoužívá pračku nebo sprchu dostatečně často, což se ostatním nelíbí, někdo je dusno, u jiného vítr, když otevře okno, někdo je příliš hlučný a další potřebuje k práci ticho a již brzy. Řešení konfliktů tohoto druhu je lepší neodkládat a nenechat jim volný průběh. Sami se nevyřeší a každý den vás budou rozptylovat od práce a otravovat atmosféru v týmu. Naštěstí jejich vyřešení nebývá velký problém – stačí si v klidu (samozřejmě jeden na jednoho) popovídat s kolegou, který zanedbává hygienu, zajistit pohodlné sezení lidem, kteří preferují ticho/chlad, koupit sluchátka pohlcující zvuk nebo nainstalovat přepážky , atd.
Dalším příkladem, se kterým jsem se během své práce několikrát setkal, je psychická inkompatibilita členů týmu. Z nějakého důvodu lidé prostě nemohou spolupracovat, každá interakce končí skandálem. Někdy je to způsobeno tím, že lidé zastávají polární názory na nějaké naléhavé téma (obvykle politické) a nevědí, jak je nechat mimo práci. Přesvědčit je, aby se navzájem tolerovali nebo změnili své chování, je docela marný úkol. Jedinou výjimkou, se kterou jsem se setkal, jsou mladí kolegové s otevřeným vnímáním, jejichž chování lze stále postupně měnit periodickými rozhovory. Obvykle je problém úspěšně vyřešen jejich rozdělením do různých týmů nebo alespoň poskytnutím příležitosti k překrývání v práci velmi zřídka.
Ve všech výše uvedených situacích stojí za to promluvit si se všemi účastníky osobně, situaci prodiskutovat, zeptat se, zda v tomto případě vůbec vidí problém, zeptat se, jaká jsou podle jejich názoru řešení, a zajistit jejich účast na jeho realizaci. rozhodnutí.
Z hlediska optimalizace pracovního procesu (střednědobá perspektiva, kterou jsem zmiňoval) se zde mnoho udělat nedá, pro optimalizaci je jediným bodem zohlednit faktor kompatibility při sestavování týmu a nedávat lidi spolu předem, kdo bude v konfliktu.
Z pohledu týmové kultury k takovým situacím dochází mnohem méně často v týmech s vyspělou kulturou, kde lidé respektují tým a kolegy a vědí, jak problémy řešit samostatně. Takové konflikty se navíc mnohem snadněji (často automaticky) řeší v týmech, kde panuje vysoká míra důvěry, lidé spolu dlouhodobě spolupracují a/nebo často komunikují mimo práci.
Konflikty související s pracovními problémy:
Takové konflikty jsou většinou způsobeny oběma důvody najednou, jak emocionálními (to, že jeden z účastníků není v pozici dospělého), tak nedokonalostí samotného pracovního procesu. Snad nejběžnějším typem konfliktů, se kterými jsem se setkal, jsou konflikty během kontrol kódu nebo diskusí o architektuře mezi vývojáři.
Zde bych zdůraznil dva typické případy:
1) V prvním případě nemůže vývojář získat kontrolu kódu od kolegy. Patch je odeslán ke kontrole a nic se neděje. Na první pohled mezi oběma stranami není žádný zjevný konflikt, ale když se nad tím zamyslíte, je to docela konflikt. Pracovní problém není vyřešen, jedna ze stran (čekající na posouzení) pociťuje zjevné nepohodlí. Extrémním podtypem tohoto případu je vývoj v komunitě nebo v různých týmech, přičemž recenzenta tento konkrétní kód nemusí zajímat z důvodu načítání nebo jiných okolností, nemusí žádosti o recenzi vůbec věnovat pozornost a externí arbitr (správce společný pro obě strany) ) nemusí vůbec existovat.
Přístup řešení, který v takové situaci pomáhá, se vztahuje právě k dlouhodobé perspektivě, kultuře dospělého. Za prvé, chytrá aktivita funguje. Neměli byste očekávat, že kód visící na recenzi přitáhne pozornost samotného recenzenta. Musíme pomoci recenzentům, aby si ho všimli. Pingani pár lidí, zeptejte se na syncape, zúčastněte se diskuzí. Je zřejmé, že důmyslnost spíše uškodí než pomůže, je třeba používat zdravý rozum. Za druhé, předpříprava funguje dobře. Pokud tým rozumí tomu, co se děje a proč, proč je tento kód vůbec potřeba, design byl projednán a odsouhlasen předem se všemi, lidé s větší pravděpodobností budou takovému kódu věnovat pozornost a přijmou ho pro práci. Za třetí, autorita funguje. Pokud chcete být recenzováni, udělejte si spoustu recenzí sami. Dělejte vysoce kvalitní recenze se skutečnými kontrolami, skutečnými testy a užitečnými komentáři. Pokud je vaše přezdívka v týmu dobře známá, je větší šance, že si vašeho kódu všimnou.
Z hlediska pracovního postupu jsou zde možná vylepšení správná prioritizace, jejímž cílem je pomoci vývojáři dosáhnout jeho cílů a cílů týmu (kontrolovat ostatní, psát dopisy komunitě, doprovázet kód popisem architektury, dokumentací, testy, účastnit se diskuzí s komunita atd.), zabránit tomu, aby záplaty visely příliš dlouho ve frontě atd.
2) Druhým častým případem konfliktů během kontroly kódu nebo návrhu jsou různé pohledy na technické problémy, styl kódování a výběr nástrojů. V tomto případě je velmi důležitá míra důvěry mezi účastníky, příslušnost ke stejnému týmu a zkušenost se společnou prací. Slepá ulička nastává, když jeden z účastníků zaujme dětinskou pozici a nesnaží se slyšet, co mu chce partner sdělit. Často může dobře fungovat jak přístup navržený druhou stranou, tak přístup navržený původně a v zásadě nezáleží na tom, který z nich zvolit.
Jednoho dne programátor z mého týmu (říkejme mu Pasha) připravil patch se změnami v systému nasazování balíčků, který vyvinuli a podpořili kolegové ze sousedního oddělení. Jeden z nich (Igor) měl svůj vlastní silný názor na to, jak přesně by měly být služby Linuxu konfigurovány při nasazování balíčků. Tento názor se lišil od přístupu navrženého v patchi a nemohli se shodnout. Jak už to tak bývá, termíny utíkaly a bylo potřeba se nějak rozhodnout, bylo třeba, aby jeden z nich zaujal pozici dospělého. Pasha uznal, že oba přístupy mají právo na život, ale chtěl, aby jeho volba prošla, protože Ani jedna, ani druhá možnost neměla žádné zjevné technické výhody.
Naše diskuse vypadala asi takto (samozřejmě velmi schematicky, rozhovor trval půl hodiny):
- Pašo, za pár dní zamrzneme. Je důležité, abychom si vše dali dohromady a začali testovat co nejdříve. Jak se dostaneme přes Igora?
— Chce to nastavit služby jinak, nalepil mi tam komentáře...
- A co je tam, velké změny, spousta povyku?
- Ne, je tu práce na pár hodin, ale nakonec v tom není žádný rozdíl, bude to fungovat tak či tak, proč je to nutné? Vytvořil jsem něco, co funguje, přijměme to.
- Poslouchej, jak dlouho jsi o tom všem diskutoval?
- Ano, už týden a půl určujeme čas.
- Um... můžeme vyřešit problém za pár hodin, který už zabral týden a půl, a neudělat to?
-No, ano, ale nechci, aby si Igor myslel, že jsem upadl...
- Poslouchej, co je pro tebe důležitější, vydat propuštění spolu s tvým rozhodnutím uvnitř, nebo zabít Igora? Můžeme to zablokovat, ale pak je velká šance proletět s uvolněním.
- No... samozřejmě by bylo skvělé Igorovi utřít nos, ale dobře, uvolnění je důležitější, souhlasím.
- Je pro tebe opravdu tak důležité, co si Igor myslí? Abych byl upřímný, je mu to úplně jedno, chce jen jednotný přístup na různých místech věci, za kterou je zodpovědný.
- Dobře, nech mě udělat, co žádá v komentářích, a můžeme začít testovat.
- Děkuji, Pašo! Byla jsem si jistá, že z vás dvou budete vy dospělejší, i když Igorek je starší než vy :)
Problém byl vyřešen, vydání bylo vydáno včas, Pasha necítil velkou nespokojenost, protože sám navrhl řešení a realizoval jej. Igor byl celkově spokojený, protože... Jeho názor byl vzat v úvahu a udělali, jak navrhl.
Dalším typem v podstatě stejného konfliktu je 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 umístěn jako používající C/C++, se ukázalo, že technické vedení projektu bylo kategoricky proti použití STL (Standard Template Library). Jedná se o standardní jazykovou knihovnu, která zjednodušuje vývoj, a náš tým je na ni velmi zvyklý. Ukázalo se, že projekt má mnohem blíže k C než k C++, což tým příliš nenadchlo, protože vedení se snažilo ze všech sil a naverbovalo opravdu skvělé plus hráče. Americká část týmu, inženýři i manažeři, přitom ve firmě pracovala delší dobu, byla zvyklá na stávající stav a byla se vším spokojená. Ruská část týmu se dala dohromady poměrně nedávno, během několika týdnů (včetně mě). Ruská část týmu kategoricky nechtěla opustit obvyklý přístup k vývoji.
Mezi dvěma kontinenty začaly nekonečné písemné diskuse, dopisy na třech nebo čtyřech obrazovkách létaly sem a tam, ve skupinových i osobních, od programátorů po programátory a manažery. Jak už to tak bývá, dopisy této délky nečetl nikdo kromě autorů a jejich zapálených příznivců. Chaty skřípaly napětím, přecházely myšlenky na různých obrazovkách různými směry o technických výhodách STL, o tom, jak dobře je testováno, jak je bezpečné a obecně, jak úžasný je život s ním a jak hrozný je bez něj .
To vše trvalo poměrně dlouho, až jsem si nakonec uvědomil, že jsme diskutovali o technických aspektech problému, ale problém ve skutečnosti nebyl technický. Problémem nejsou výhody či nevýhody STL nebo obtížnost práce bez něj. Problém je spíše organizační. Potřebovali jsme jen pochopit, jak funguje společnost, pro kterou jsme pracovali. Nikdo z nás předtím neměl zkušenosti s prací v takové společnosti. Šlo o to, že poté, co byl kód vyvinut a uvolněn do výroby, podporu řešili úplně jiní lidé z jiných týmů, z jiných zemí. Tento obrovský inženýrský tým čítající několik desítek tisíc inženýrů (celkem) si mohl dovolit jen zcela základní minimum technických prostředků, takříkajíc minimální minimum. Cokoli, co fyzicky přesahovalo strojírenský standard zavedený ve společnosti, nemohlo být v budoucnu podporováno. Úroveň týmu je dána úrovní jeho nejslabších členů. Poté, co jsme pochopili skutečnou motivaci akce americké části týmu byla tato záležitost odstraněna z agendy a společně jsme úspěšně vyvinuli a vydali produkt s využitím standardů přijatých společností. Dopisy a chaty v tomto případě nefungovaly dobře, trvalo několik cest a hodně osobní komunikace, než došlo ke společnému jmenovateli.
Z hlediska pracovního postupu by v tomto konkrétním případě pomohl popis používaných nástrojů, požadavky na ně, omezení přidávání nových a zdůvodnění těchto omezení. Takové dokumenty zhruba odpovídají těm, které jsou popsány v odstavcích Strategie opětovného použití a vývojové prostředí „Manažer's Handbook for Software Development“, vyvinuté v r. . Navzdory svému stáří dokonale popisuje všechny hlavní činnosti a fáze plánování vývoje softwaru tohoto druhu. S dokumenty, jako je tento, je velmi snadné diskutovat o tom, jaké komponenty a přístupy lze v produktu použít a proč.
Z kulturního hlediska samozřejmě s vyzrálejší pozicí, ve které se strany snaží slyšet a chápat skutečnou motivaci jednání svých kolegů a jednají na základě priorit projektu a týmu, nikoli osobního ega. , konflikt by se vyřešil snadněji a rychleji.
V dalším konfliktu o volbu technického řešení mi také trvalo znatelně dlouho pochopit motivaci jedné ze stran (byl to velmi neobvyklý případ), ale poté, co byla motivace jasná, bylo řešení zřejmé.
Situace je taková: v týmu asi 20 lidí se objeví nový vývojář, říkejme mu Stas. V té době byl naším standardním nástrojem pro komunikaci jako tým Skype. Jak se později ukázalo, Stas byl velkým fanouškem otevřených standardů a softwaru s otevřeným zdrojovým kódem a používal pouze nástroje a operační systémy, jejichž zdroje byly veřejně dostupné a které využívaly veřejně popsané protokoly. Skype mezi tyto nástroje nepatří. Strávili jsme spoustu času diskusí o výhodách a nevýhodách tohoto přístupu, pokusech o spuštění analogů Skype na různých operačních systémech, Stasových pokusech přesvědčit tým, aby přešel na jiné standardy, napsat mu osobně poštou, zavolat mu osobně na telefon, koupit mu druhý počítač speciálně pro Skype atd. Nakonec jsem si uvědomil, že tento problém v podstatě není technický ani organizační, je spíše ideologický, dokonce, dalo by se říci, náboženský (pro Staše). I kdybychom nakonec propojili Stas a Skype (což trvalo několik měsíců), problém by se znovu objevil na jakémkoli dalším nástroji. Neměl jsem k dispozici žádné skutečné prostředky, jak změnit Stasův pohled na svět, a nebyl důvod se pokoušet změnit pohled na svět týmu, který v tomto prostředí perfektně fungoval. Osoba a společnost byli ve svém pohledu na svět prostě ortogonální. V takových situacích je dobré řešení organizační. Stase jsme převedli do jiného týmu, kde byl více organický.
Důvodem tohoto konfliktu je podle mého názoru rozpor mezi osobní kulturou konkrétního člověka (který má vyhraněný názor, který mu nedovoluje dělat kompromisy) a kulturou firmy. V tomto případě je to samozřejmě chyba manažera. Zpočátku bylo špatné vzít ho na projekt tohoto druhu. Stas nakonec přešel na projekt vývoje softwaru s otevřeným zdrojovým kódem a tam exceloval.
Dobrým příkladem konfliktu způsobeného jak dětinským přístupem vývojáře, tak nedostatky pracovního procesu je situace, kdy při absenci definice hotovo mají vývojář a tým QA odlišná očekávání ohledně připravenosti funkce převedena do QA. Vývojář věřil, že stačí napsat kód a hodit funkci přes plot do QA – tam to vyřeší. Mimochodem docela vyzrálý a zkušený programátor, ale to byl jeho vnitřní práh kvality. QA s tím nesouhlasil a požadoval, aby jim ukázal a popsal, co sám zkontroloval, a požadoval pro ně testovací skript. Už v minulosti měli problémy s funkčností od tohoto vývojáře a nechtěli znovu ztrácet čas. Mimochodem, měli pravdu - funkce opravdu nefungovala, nezkontroloval kód před odesláním do QA.
Abych situaci vyřešil, požádal jsem ho, aby mi ukázal, že všechno opravdu funguje (nefungovalo to a on to musel napravit), mluvili jsme s týmem a s definicí QA hotovo (nestihli to v psaní, protože jsme nechtěli, aby byl proces příliš byrokratický, dobře, brzy jsme se s tímto specialistou rozešli (k všeobecné úlevě).
Z hlediska pracovního postupu jsou možnými vylepšeními v tomto případě přítomnost definice hotovo, požadavky na podporu každé vlastnosti jednotky a integračních testů a popis testování prováděného vývojářem. V jednom z projektů jsme měřili míru pokrytí kódu testy během CI a pokud po přidání patche úroveň pokrytí klesla, byly testy označeny jako neúspěšné, tzn. jakýkoli nový kód lze přidat pouze v případě, že pro něj existují nové testy.
Další typický příklad konfliktu úzce souvisejícího s organizací pracovního procesu. Máme produkt, tým vývoje produktu, tým podpory a zákazníka. Zákazník má problémy s produktem a kontaktuje podporu. Podpora analyzuje problém a chápe, že problém je v produktu, a předá problém produktovému týmu. Produktový tým je v rušné době, blíží se vydání, takže tiket s problémem od zákazníka, ztracený mezi ostatními tikety vývojáře, kterému je přidělen, visí několik týdnů bez pozornosti. Podpora se domnívá, že vývojář pracuje na problému zákazníka. Zákazník čeká a doufá, že se jeho problém řeší. Ve skutečnosti se zatím nic neděje. Po pár týdnech se zákazník konečně rozhodne zajímat o průběh a ptá se podpory, jak se věci mají. Podpora žádá o rozvoj. Vývojář se otřese, prohlédne seznam tiketů a najde tam tiket od zákazníka. Přečtením lístku od zákazníka pochopí, že k vyřešení problému není dostatek informací, a potřebuje více protokolů a výpisů. Podpora vyžaduje od zákazníka další informace. A pak si zákazník uvědomí, že celou dobu na jeho problému nikdo nepracoval. A udeří hrom...
V této situaci je řešení samotného konfliktu zcela 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 porozumět tomu, kdo je odpovědný za organizaci interakce mezi dvěma týmy a proč je tato situace vůbec možná. Je jasné, co je třeba v procesu opravit – někdo musí sledovat celkový obraz bez upomínek od zákazníků, proaktivně. Vstupenky od zákazníka by měly vyčnívat mezi ostatními vstupenkami od vývojářů. Podpora by měla vidět, zda vývojový tým aktuálně pracuje na svých lístcích, a pokud ne, kdy může začít pracovat a kdy lze očekávat výsledky. Podpora a vývoj by měly pravidelně komunikovat a diskutovat o stavu tiketů, shromažďování informací nezbytných pro ladění by mělo být co nejvíce automatizováno atd.
Stejně jako ve válce se nepřítel snaží zasáhnout spojnici mezi dvěma jednotkami, tak i v práci bývá nejcitlivějším a nejzranitelnějším bodem interakce mezi týmy. Pokud jsou manažeři podpory a vývoje dostatečně staří, budou schopni proces opravit sami, pokud ne, bude proces nadále generovat konflikty a problémy, dokud nezasáhne manažer, který může situaci napravit.
Dalším typickým příkladem, který jsem opakovaně viděl v různých společnostech, je situace, kdy produkt píše jeden tým, automatické integrační testy pro něj píše druhý tým a infrastrukturu, na které je vše provozováno, doprovází třetí tým. tým. Problémy při provádění testů vznikají neustále a příčinou problémů v nich může být jak produkt, tak testy a infrastruktura. Obvykle je problematické dohodnout se na tom, kdo by měl provádět prvotní analýzu problémů, chyb souborů, analyzovat logy produktu, testy a infrastrukturu atd. Konflikty jsou zde velmi časté a zároveň jednotné. V případě vysoké emocionální intenzity účastníci často upadnou do dětinské pozice a diskuse začínají v sérii: „proč bych si s tím měl šťourat“, „častěji se hroutí“ atd.
Z hlediska pracovního postupu závisí konkrétní kroky k vyřešení problému na složení týmů, typu testů a produktu atd. V jednom z projektů jsme zavedli periodickou službu, kdy týmy sledovaly testy jeden po druhém, týden po týdnu. V druhém případě počáteční analýzu vždy provedli vývojáři testu, ale analýza byla velmi základní a produkt byl poměrně stabilní, takže fungoval dobře. Klíčem je zajistit, aby byl proces transparentní, aby očekávání byla jasná pro všechny strany a aby situace byla pro všechny spravedlivá.
Je konflikt dokonce problémem v organizaci?Je to špatné znamení, že se konflikty často (nebo jen periodicky) vyskytují ve vašem týmu? Obecně ne, protože pokud dochází k růstu, rozvoji, je tam nějaká dynamika, tak vznikají záležitosti, které se nikdy předtím neřešily a při jejich řešení mohou vznikat konflikty. To je indikátor toho, že některým oblastem je třeba věnovat pozornost, že existují oblasti, které je třeba zlepšit. Je špatné, když konflikty vznikají velmi často, těžko se řeší nebo trvají dlouho. Nejspíše se to podepisuje na nedostatečně zefektivněných pracovních procesech a nedostatečné vyspělosti týmu.
Zdroj: www.habr.com