motto:
Kedysi dávno sa v lese stretli ježko a medvedík.
- Ahoj, ježko!
- Ahoj, Medvedík!
Takže, slovo za slovom, vtip za vtipom, ježko dostal od Medvedíka do tváre...
Nižšie je diskusia od nášho vedúceho tímu, ako aj riaditeľa vývoja produktov RAS Igora Marnata o špecifikách pracovných konfliktov a možných metódach ich zvládania.
Väčšina konfliktov, s ktorými sa stretávame v práci, sa vyvíja podľa scenára podobného tomu, ktorý je opísaný v epigrafe vyššie. Existuje niekoľko účastníkov, ktorí sú spočiatku celkom priaznivo naklonení k sebe, snažia sa vyriešiť nejaký problém, ale nakoniec problém zostáva nevyriešený a z nejakého dôvodu sa vzťahy medzi účastníkmi diskusie kazia.
Život je rôznorodý a vo vyššie opísanom scenári sa vyskytujú variácie. Niekedy vzťah medzi účastníkmi spočiatku nie je príliš dobrý, niekedy dokonca neexistuje problém, ktorý by si vyžadoval priame riešenie (ako napríklad v epigrafe), niekedy po diskusii zostáva vzťah rovnaký ako pred začiatkom, ale problém nakoniec nie je vyriešený.
Čo je spoločné vo všetkých situáciách, ktoré možno definovať ako situáciu pracovného konfliktu?
Po prvé, existujú dve alebo viac strán. Tieto strany môžu zaberať rôzne miesta v organizácii, byť v rovnocennom vzťahu (kolegovia v tíme), alebo na rôznych úrovniach hierarchie (šéf - podriadený), byť individuálny (zamestnanec) alebo skupinový (v prípade konfliktu medzi zamestnanec a tím alebo dva tímy) atď. Pravdepodobnosť konfliktu a jednoduchosť jeho riešenia sú vo veľkej miere ovplyvnené úrovňou dôvery medzi účastníkmi. Čím lepšie sa strany poznajú, čím vyššia je miera dôvery, tým vyššia je šanca, že sa dohodnú. Napríklad členovia distribuovaného tímu, ktorí nikdy neinteragovali tvárou v tvár, majú väčšiu pravdepodobnosť konfliktu kvôli jednoduchému pracovnému problému ako ľudia, ktorí mali aspoň niekoľko osobných interakcií. Preto je pri práci v distribuovaných tímoch veľmi dôležité zabezpečiť, aby sa všetci členovia tímu pravidelne osobne stretávali.
Po druhé, v situácii konfliktu v práci sú strany v situácii, keď riešia nejaký problém, ktorý je dôležitý pre jednu zo strán, pre obe strany alebo pre organizáciu ako celok. Zároveň vzhľadom na špecifiká situácie majú strany zvyčajne dostatok času a rôzne spôsoby na jej vyriešenie (formálne, neformálne, stretnutia, listy, manažérske rozhodnutia, prítomnosť cieľov a plánov tímu, skutočnosť hierarchie atď.). Toto sa líši od situácie riešenia pracovného (alebo nepracovného) problému v organizácii, napríklad od vyriešenia dôležitej otázky: „Eh, chlapče, z akej si oblasti? na ulici, alebo konflikt z epigrafu. V prípade riešenia pracovného problému záleží na kvalite pracovného procesu a kultúre riešenia problémov v tíme.
Po tretie, určujúcim faktorom konfliktu (z pohľadu našej diskusie) je skutočnosť, že účastníci procesu nemôžu samostatne dospieť k riešeniu problému, ktoré by vyhovovalo všetkým stranám. Situácia si vyžaduje zásah tretej strany, externého arbitra. Tento bod sa môže zdať kontroverzný, ale v podstate, ak bola konfliktná situácia úspešne vyriešená bez zásahu externého arbitra, problém bol úspešne vyriešený a vzťahy medzi stranami sa nezhoršili, je to situácia, o ktorú by sme sa mali snažiť . S najväčšou pravdepodobnosťou sa o takomto konflikte ani nedozvieme, alebo sa to dozvieme náhodou po jeho vyriešení. Čím viac problémov dokáže tím vyriešiť sám, tým bude efektívnejší.
Ďalšou charakteristickou črtou konfliktu, ktorej sa oplatí dotknúť, je miera emocionálnej intenzity počas rozhodovania. Konflikt nie je nevyhnutne spojený s vysokou emocionálnou úrovňou. Účastníci nemusia kričať a mávať rukami, aby situácia bola v podstate konfliktná. Problém nie je vyriešený, je prítomné určité emocionálne napätie (možno nie je jasne vyjadrené navonok), čo znamená, že sme postavení pred konfliktnú situáciu.
Je potrebné do konfliktných situácií vôbec zasahovať, alebo je lepšie nechať ich vyriešenie voľný priebeh a počkať, kým sa problém vyrieši sám? Potrebovať. Nie vždy je vo vašej moci alebo kompetencii konflikt úplne vyriešiť, ale v akejkoľvek situácii, v konflikte akéhokoľvek rozsahu môžete zaujať pozíciu dospelého človeka, čím doň privediete niekoľko ďalších ľudí okolo seba, zmiernite negatívne dôsledky konfliktu a prispieť k jeho riešeniu.
Predtým, ako sa pozrieme na niekoľko príkladov konfliktných situácií, pozrime sa na niekoľko dôležitých bodov spoločných pre všetky konflikty.
Pri riešení konfliktu je dôležité byť nad bojom a nie v ňom (hovorí sa tomu aj „zaujatie metapozície“), teda nebyť súčasťou jednej zo strán v procese riešenia. V opačnom prípade pomoc externého arbitra pri rozhodovaní len posilní postavenie jednej zo strán na úkor druhej strany. Pri rozhodovaní je dôležité, aby bolo morálne prijaté všetkými stranami, ako sa hovorí „kúpené“. Aby aj keď strany neboli nadšené z prijatého rozhodnutia, aspoň úprimne súhlasili s jeho realizáciou. Ako sa hovorí, vedieť nesúhlasiť a zaviazať sa. V opačnom prípade konflikt jednoducho zmení svoj vzhľad, tlejúci oheň zostane pod rašeliniskom a v určitom okamihu sa nevyhnutne znova rozhorí.
Druhý bod, čiastočne súvisiaci s prvým, je ten, že ak ste sa už rozhodli podieľať sa na riešení konfliktu, berte ho čo najvážnejšie z hľadiska komunikácie a štúdia súvislostí. Porozprávajte sa osobne s každou zo strán. Pre začiatok samostatne s každým. Neuspokojte sa s poštou. V prípade distribuovaného tímu sa porozprávajte aspoň cez video odkaz. Neuspokojte sa s počutiami a správami očitých svedkov. Pochopte príbeh, čo každá strana chce, prečo to chcú, čo očakávajú, pokúsili sa už tento problém vyriešiť, čo sa stane, ak sa nevyrieši, aké riešenia vidia, ako si predstavujú postavenie druhá strana, čo si myslia, správne alebo nesprávne atď. Nahrajte si do hlavy všetky možné súvislosti, s otvorenou mysľou a za predpokladu, že každý má pravdu. Nie ste vo vnútri konfliktu, ste mimo neho, v metapozícii. Ak je kontext dostupný iba vo vlákne príspevku, prečítajte si ho aspoň celý a s ním súvisiace vlákna a dokumenty. Po prečítaní stále hovorte svojim hlasom. Je takmer zaručené, že budete počuť niečo dôležité, čo nie je v pošte.
Tretím dôležitým bodom je všeobecný prístup ku komunikácii. Sú to bežné veci, nič kozmické, ale sú veľmi dôležité. Nesnažíme sa šetriť čas, rozprávame sa so všetkými účastníkmi, nekritizujeme človeka, ale zvažujeme dôsledky jeho činov (nie „si drzý“, ale „možno by sa chlapi mohli uraziť táto vec”), dávame možnosť zachovať si tvár, vedieme diskusie osobne, nie pred linkou.
Konflikty sú zvyčajne spôsobené jedným z dvoch dôvodov. Prvý súvisí s tým, či je človek v čase konfliktu v pozícii dospelého alebo v pozícii dieťaťa (viac o tom nižšie). Môže za to jeho emocionálna zrelosť, schopnosť zvládať emócie (čo mimochodom nie vždy súvisí s jeho vekom). Druhým častým dôvodom je nedokonalosť pracovného procesu, ktorá vytvára situácie šedých zón, v ktorých je zodpovednosť rozložená medzi účastníkov, očakávania strán sú navzájom neprehľadné a roly v procese sú rozmazané.
V súlade s tým musí mať manažér pri riešení konfliktu (ako aj akéhokoľvek iného problému) na pamäti tri perspektívy: krátkodobý - vyriešiť problém/konflikt tu a teraz, strednodobý - minimalizovať pravdepodobnosť vzniku ďalšieho konfliktu z rovnakého dôvodu a dlhodobo – pestovať v tímovom človeku kultúru dospelých.
Každý z nás má vnútorné dieťa, má asi tri-štyri roky. V práci väčšinu času prespí, ale niekedy sa zobudí a preberie kontrolu. Dieťa má svoje priority. Je dôležité, aby trval na tom, že toto je jeho pieskovisko, jeho mama ho ľúbi viac, jeho strojček je najlepší (najlepší je dizajn, najlepšie programuje, ...). V konfliktnej situácii môže dieťa stláčať hračky, dupať nohami a praskať špachtľou, ale nevie riešiť problémy dospelých (architektúra riešenia, prístupy k automatizovanému testovaniu, dátumy vydania a pod.), nemyslí na výhody. pre tím. Dieťa v konflikte možno povzbudiť, utešiť a poslať do postele tým, že ho požiadate, aby zavolalo svojmu dospelému. Pred začatím diskusie v konfliktnej situácii sa uistite, že hovoríte s dospelým, nie s dieťaťom, a že vy sami ste v pozícii dospelého. Ak je momentálne vaším úprimným cieľom vyriešiť vážny problém, ste v pozícii dospelého človeka. Ak je vaším cieľom dupať nohami a praskať lopatkou, ide o detskú pozíciu. Pošlite svoje vnútorné dieťa do postele a zavolajte dospelému alebo preložte diskusiu. Človek urobí emocionálne rozhodnutie a potom pre to hľadá racionálne zdôvodnenie. Rozhodnutie, ktoré urobí dieťa na základe priorít detí, nebude optimálne.
Postavenie dieťaťa alebo dospelého je okrem správania v čase konfliktu charakterizované aj mierou zodpovednosti, ktorú je človek pripravený vziať na seba. V extrémnych prejavoch detinská pozícia programátora, s ktorou som sa neraz stretol, vyzerá takto: Napísal som kód, poslal na posúdenie – moja práca je hotová. Recenzenti by to mali skontrolovať a schváliť, kontrola kvality by to mala skontrolovať, ak sa vyskytnú problémy, dajú mi vedieť. Napodiv, aj pomerne zrelí a skúsení ľudia sa niekedy správajú takto. Na druhom konci stupnice je, že človek sa považuje za zodpovedný za to, že jeho kód funguje, je pokrytý testami, bol ním osobne skontrolovaný, úspešne prešiel kontrolou (v prípade potreby nie je problém pingnúť recenzentov, diskutovať o problémoch hlasom atď.) a bola potlačená, QA v prípade potreby poskytne pomoc, popíšu sa testovacie scenáre atď. V normálnych prípadoch programátor buď začína bližšie ku koncu pre dospelých, alebo sa tam presúva, keď získava skúsenosti (za predpokladu, že sa v tíme pestuje správna kultúra). V extrémnych prípadoch pokračuje v práci, zvyčajne zastáva detinskú pozíciu, potom má on a tím pravidelne problémy a konflikty.
Pestovanie správnej, zrelej kultúry v tíme je dôležitou úlohou každého manažéra. Vyžaduje si to veľa času a každodenného úsilia, ale výsledok stojí za to. Sú dva spôsoby, ako ovplyvniť tímovú kultúru – ísť príkladom (ktorý bude určite nasledovať; tím vždy hľadí na lídra) a diskutovať a odmeňovať správne správanie. Ani tu nie je nič nejasné ani veľmi formálne, len si pri diskusii o problémoch všimnite, že sa tu niečo dalo urobiť, zdôraznite, že ste si všimli, kedy sa rozhodlo správne, chváľte, poznámkujte pri kontrole vydania atď.
Zoberme si niekoľko typických konfliktných situácií, od jednoduchých po zložité:
Konflikty nesúvisiace s pracovnými problémami
Pomerne často dochádza ku konfliktom v práci, ktoré nesúvisia s pracovnými záležitosťami. Ich výskyt a ľahkosť riešenia zvyčajne priamo súvisia s úrovňou emocionálnej inteligencie účastníkov, úrovňou ich zrelosti a nesúvisia s dokonalosťou alebo nedokonalosťou pracovného procesu.
Typické príklady: niekto nepoužíva práčku alebo sprchu dostatočne často, čo iní nemajú radi, niekto je dusno, inému fúka vietor, ak otvorí okno, niekto je príliš hlučný a iní potrebujú na prácu ticho a tak ďalej. Riešenie konfliktov tohto druhu je lepšie neodkladať a nenechať im voľný priebeh. Sami sa nevyriešia a každý deň vás budú odvádzať od práce a otravovať atmosféru v tíme. Našťastie ich vyriešenie nebýva veľký problém – stačí sa pokojne porozprávať (samozrejme jeden na jedného) s kolegom, ktorý zanedbáva hygienu, zabezpečiť pohodlné sedenie pre ľudí, ktorí uprednostňujú ticho/chlad, kúpiť slúchadlá pohlcujúce zvuk alebo nainštalovať priečky , atď.
Ďalším príkladom, s ktorým som sa počas svojej práce niekoľkokrát stretol, je psychická nekompatibilita členov tímu. Z nejakého dôvodu ľudia jednoducho nemôžu spolupracovať, každá interakcia končí škandálom. Niekedy je to spôsobené tým, že ľudia zastávajú polárne názory na niektoré naliehavé problémy (zvyčajne politické) a nevedia, ako ich nechať mimo práce. Presvedčiť ich, aby sa navzájom tolerovali alebo zmenili svoje správanie, je dosť zbytočná úloha. Jedinou výnimkou, s ktorou som sa stretol, sú mladí kolegovia s otvoreným vnímaním, ktorých správanie sa stále dá postupne meniť pravidelnými rozhovormi. Zvyčajne je problém úspešne vyriešený ich rozdelením do rôznych tímov alebo prinajmenšom poskytnutím možnosti prekrývať sa v práci veľmi zriedka.
Vo všetkých vyššie uvedených situáciách stojí za to porozprávať sa so všetkými účastníkmi osobne, prediskutovať situáciu, opýtať sa, či v tomto prípade vôbec vidia problém, spýtať sa, aké sú podľa ich názoru riešenia, a zabezpečiť ich spoluúčasť na riešení tohto problému. rozhodnutie.
Z hľadiska optimalizácie pracovného procesu (strednodobá perspektíva, ktorú som spomínal) sa tu veľa urobiť nedá, jediným bodom pre optimalizáciu je brať do úvahy faktor kompatibility pri zostavovaní tímu a nedávať ľudí spolu vopred, kto bude v konflikte.
Z pohľadu tímovej kultúry takéto situácie vznikajú oveľa menej často v tímoch s vyspelou kultúrou, kde ľudia rešpektujú tím a kolegov a vedia problémy riešiť samostatne. Takéto konflikty sa navyše oveľa jednoduchšie (často automaticky) riešia v tímoch, kde vládne vysoká miera dôvery, ľudia spolu dlho spolupracujú a/alebo často komunikujú mimo práce.
Konflikty súvisiace s pracovnými problémami:
Takéto konflikty sú zvyčajne spôsobené oboma dôvodmi naraz, tak emocionálnymi (to, že jeden z účastníkov nie je v pozícii dospelého človeka), ako aj nedokonalosťou samotného pracovného procesu. Snáď najbežnejším typom konfliktov, s ktorými som sa stretol, sú konflikty počas kontroly kódu alebo diskusií o architektúre medzi vývojármi.
Tu by som zdôraznil dva typické prípady:
1) V prvom prípade nemôže vývojár získať kontrolu kódu od kolegu. Oprava sa odošle na kontrolu a nič sa nestane. Na prvý pohľad medzi oboma stranami nie je zjavný konflikt, no ak sa nad tým zamyslíte, je to celkom konflikt. Pracovná otázka nie je vyriešená, jedna zo strán (čakajúca na posúdenie) zažíva zjavné nepohodlie. Extrémnym podtypom tohto prípadu je vývoj v komunite alebo v rôznych tímoch, pričom recenzenta tento konkrétny kód nemusí zaujímať, kvôli načítaniu alebo iným okolnostiam, žiadosti o recenziu nemusí vôbec venovať pozornosť a externý arbiter (správca spoločný pre obe strany) nemusí vôbec existovať.
Prístup riešenia, ktorý v takejto situácii pomáha, sa týka práve dlhodobej perspektívy, kultúry dospelého človeka. Po prvé, inteligentná aktivita funguje. Nemali by ste očakávať, že kód visiaci na recenzii pritiahne pozornosť samotného recenzenta. Musíme pomôcť recenzentom, aby si ho všimli. Pingani pár ľudí, položte otázku na syncape, zúčastnite sa diskusií. Je zrejmé, že dômyselnosť skôr uškodí ako pomôže, treba použiť zdravý rozum. Po druhé, predpríprava funguje dobre. Ak tím rozumie tomu, čo sa deje a prečo, prečo je tento kód vôbec potrebný, dizajn bol vopred prediskutovaný a dohodnutý so všetkými, ľudia s väčšou pravdepodobnosťou budú takémuto kódu venovať pozornosť a akceptujú ho pre prácu. Po tretie, autorita funguje. Ak chcete byť recenzovaní, urobte si veľa recenzií sami. Robte vysokokvalitné recenzie so skutočnými kontrolami, skutočnými testami a užitočnými komentármi. Ak je vaša prezývka v tíme dobre známa, je väčšia šanca, že si váš kód všimnú.
Z hľadiska pracovného toku sú tu možné zlepšenia správne stanovenie priorít s cieľom pomôcť vývojárovi dosiahnuť jeho ciele a ciele tímu (kontrolovať ostatných, písať listy komunite, sprevádzať kód popisom architektúry, dokumentáciou, testovať, zúčastňovať sa diskusií s komunita atď.), zabrániť tomu, aby záplaty viseli vo fronte príliš dlho atď.
2) Druhým bežným prípadom konfliktov počas kontroly kódu alebo dizajnu sú rôzne pohľady na technické problémy, štýl kódovania a výber nástrojov. V tomto prípade je veľmi dôležitá úroveň dôvery medzi účastníkmi, príslušnosť k rovnakému tímu a skúsenosti zo spoločnej práce. Slepá ulička nastáva, keď jeden z účastníkov zaujme detskú pozíciu a nesnaží sa počuť, čo mu chce partner povedať. Prístup navrhovaný druhou stranou a pôvodne navrhovaný prístup môžu často úspešne fungovať a v zásade nezáleží na tom, ktorý z nich si vybrať.
Jedného dňa programátor z môjho tímu (volajme ho Pasha) pripravil patch so zmenami v systéme nasadzovania balíkov, ktorý vyvinuli a podporili kolegovia zo susedného oddelenia. Jeden z nich (Igor) mal svoj vlastný silný názor na to, ako presne by mali byť služby Linuxu nakonfigurované pri nasadzovaní balíkov. Tento názor sa líšil od prístupu navrhovaného v patchi a nemohli sa dohodnúť. Ako to už býva, termíny sa krátili a bolo treba dospieť k nejakému rozhodnutiu, bolo potrebné, aby jeden z nich zaujal pozíciu dospelého. Pasha uznal, že oba prístupy majú právo na život, ale chcel, aby jeho možnosť prešla, pretože Ani jedna, ani druhá možnosť nemali žiadne zjavné technické výhody.
Naša diskusia vyzerala asi takto (veľmi schematicky, samozrejme, rozhovor trval pol hodiny):
— Pasha, o pár dní tu máme zmrazenie funkcií. Je dôležité, aby sme si dali všetko dokopy a začali testovať čo najskôr. Ako sa dostaneme cez Igora?
— Chce to inak nastaviť služby, nalepil mi tam komentáre...
- A čo je tam, veľké zmeny, veľa rozruchu?
- Nie, je tu práca na pár hodín, ale nakoniec v tom nie je žiadny rozdiel, bude to fungovať tak či tak, prečo je to potrebné? Vytvoril som niečo, čo funguje, prijmime to.
- Počuj, ako dlho o tom všetkom diskutuješ?
- Áno, už týždeň a pol určujeme čas.
- Hm... môžeme vyriešiť problém za pár hodín, ktorý už trvá týždeň a pol, a neurobiť to?
- Áno, ale nechcem, aby si Igor myslel, že som upadol...
- Počuj, čo je pre teba dôležitejšie, vydať prepustenie spolu s tvojím rozhodnutím vo vnútri, alebo zabiť Igora? Môžeme to zablokovať, potom je však dobrá šanca preletieť s uvoľnením.
- No... bolo by fajn, samozrejme, utrieť Igorov nos, ale dobre, uvoľnenie je dôležitejšie, súhlasím.
- Naozaj je pre teba také dôležité, čo si myslí Igor? Úprimne povedané, je mu to úplne jedno, chce len jednotný prístup na rôznych miestach veci, za ktorú je zodpovedný.
- Dobre, dovoľte mi urobiť to, čo žiada v komentároch, a začnime testovať.
- Ďakujem, Pasha! Bola som si istá, že z vás dvoch budete ten zrelší, hoci Igorek je od vás starší :)
Problém bol vyriešený, vydanie bolo vydané včas, Pasha necítil veľkú nespokojnosť, pretože sám navrhol riešenie a zrealizoval ho. Igor bol celkovo spokojný, pretože... Jeho názor bol vzatý do úvahy a urobili tak, ako navrhol.
Ďalším typom v podstate rovnakého konfliktu je voľba medzi technickými riešeniami/knižnicami/prístupmi v projekte, najmä v distribuovanom tíme. V jednom z projektov, ktorý bol označený ako používajúci C/C++, sa ukázalo, že technické riadenie projektu bolo kategoricky proti používaniu STL (Standard Template Library). Ide o štandardnú jazykovú knižnicu, ktorá zjednodušuje vývoj a náš tím je na ňu veľmi zvyknutý. Ukázalo sa, že projekt má oveľa bližšie k C ako k C++, čo tím veľmi nenadchlo, pretože vedenie sa snažilo zo všetkých síl a naverbovalo naozaj skvelých plusových hráčov. Zároveň americká časť tímu, inžinieri aj manažéri, pracovali v spoločnosti už dlhší čas, boli zvyknutí na súčasný stav a boli so všetkým spokojní. Ruská časť tímu sa dala dokopy pomerne nedávno, v priebehu niekoľkých týždňov (vrátane mňa). Ruská časť tímu kategoricky nechcela opustiť zaužívaný prístup k vývoju.
Začali sa nekonečné písomné diskusie medzi dvoma kontinentmi, listy na troch alebo štyroch obrazovkách lietali tam a späť, v skupinových i osobných, od programátorov po programátorov a manažérov. Ako to už býva, listy tejto dĺžky nečítal nikto okrem autorov a ich zanietených priaznivcov. Chaty škrípali napätím, prechádzali myšlienkami na viacerých obrazovkách rôznymi smermi o technických výhodách STL, o tom, ako dobre je testovaný, aký je bezpečný a vo všeobecnosti, aký úžasný je život s ním a aký hrozný je bez neho .
Celé to trvalo dosť dlho, až som si nakoniec uvedomil, že sme diskutovali o technických aspektoch problému, ale problém v skutočnosti nebol technický. Problémom nie sú výhody alebo nevýhody STL alebo náročnosť práce bez neho. Problém je skôr organizačný. Potrebovali sme len pochopiť, ako funguje spoločnosť, pre ktorú sme pracovali. Nikto z nás predtým nemal skúsenosti s prácou v takejto spoločnosti. Išlo o to, že po vývoji kódu a uvoľnení do produkcie sa o podporu starali úplne iní ľudia z iných tímov, z iných krajín. Tento obrovský inžiniersky tím pozostávajúci z niekoľkých desiatok tisíc inžinierov (spolu) si mohol dovoliť len úplne základné minimum technických prostriedkov, takpovediac minimálne minimum. Čokoľvek, čo fyzicky presahuje inžiniersky štandard stanovený v spoločnosti, nemôže byť v budúcnosti podporované. Úroveň tímu je určená úrovňou jeho najslabších členov. Potom, čo sme pochopili skutočná motivácia akcie americkej časti tímu bola táto problematika vyradená z programu a spoločne sme úspešne vyvinuli a vydali produkt s využitím štandardov prijatých spoločnosťou. Listy a chaty v tomto prípade nefungovali dobre, bolo potrebných niekoľko ciest a veľa osobnej komunikácie, kým sme dospeli k spoločnému menovateľovi.
Z hľadiska pracovného postupu by v tomto konkrétnom prípade pomohol popis používaných nástrojov, požiadavky na ne, obmedzenia pri pridávaní nových a zdôvodnenie takýchto obmedzení. Takéto dokumenty zhruba zodpovedajú tým, ktoré sú opísané v odsekoch Stratégia opätovného použitia a Vývojové prostredie „Manažérskej príručky pre vývoj softvéru“, vypracovanej v r. . Napriek svojmu veku dokonale popisuje všetky hlavné činnosti a fázy plánovania vývoja softvéru tohto druhu. S dokumentmi, ako je tento, je veľmi jednoduché diskutovať o tom, aké komponenty a prístupy možno použiť v produkte a prečo.
Z kultúrneho hľadiska samozrejme s zrelšou pozíciou, v ktorej sa strany snažia počuť a pochopiť skutočnú motiváciu konania svojich kolegov a konať na základe priorít projektu a tímu, a nie osobného ega. , konflikt by sa vyriešil jednoduchšie a rýchlejšie.
V inom konflikte pri voľbe technického riešenia mi tiež trvalo citeľne dlho, kým som pochopil motiváciu jednej zo strán (bol to veľmi neobvyklý prípad), ale keď bola motivácia jasná, riešenie bolo zrejmé.
Situácia je takáto: v tíme asi 20 ľudí sa objaví nový vývojár, nazvime ho Stas. V tom čase bol naším štandardným nástrojom na komunikáciu ako tímu Skype. Ako sa neskôr ukázalo, Stas bol veľkým fanúšikom otvorených štandardov a softvéru s otvoreným zdrojovým kódom a používal iba nástroje a operačné systémy, ktorých zdroje boli verejne dostupné a ktoré používali verejne opísané protokoly. Skype nie je jedným z týchto nástrojov. Strávili sme veľa času diskusiou o výhodách a nevýhodách tohto prístupu, pokusoch o spustenie analógov Skype na rôznych operačných systémoch, pokusoch Stasa presvedčiť tím, aby prešiel na iné štandardy, napísať mu osobne poštou, zavolať mu osobne na telefón, kúpiť mu druhý počítač špeciálne pre Skype atď. Nakoniec som si uvedomil, že tento problém v podstate nie je technický ani organizačný, je skôr ideologický, dokonca, možno povedať, náboženský (pre Staša). Aj keby sme nakoniec prepojili Stas a Skype (čo trvalo niekoľko mesiacov), problém by sa znova objavil na akomkoľvek nasledujúcom nástroji. Nemal som k dispozícii žiadne reálne prostriedky na zmenu Stašovho videnia sveta a nebol dôvod pokúšať sa zmeniť svetonázor tímu, ktorý v tomto prostredí perfektne fungoval. Osoba a spoločnosť boli vo svojom svetonázore jednoducho ortogonálne. V takýchto situáciách je dobré riešenie organizačné. Staša sme presunuli do iného tímu, kde bol organickejší.
Dôvodom tohto konfliktu je podľa mňa rozpor medzi osobnou kultúrou konkrétneho človeka (ktorý má vyhranený názor, ktorý mu neumožňuje robiť kompromisy) a kultúrou firmy. V tomto prípade je to samozrejme chyba konateľa. Zo začiatku bolo nesprávne vziať ho na projekt tohto druhu. Stas nakoniec prešiel na projekt vývoja softvéru s otvoreným zdrojovým kódom a vynikal tam.
Dobrým príkladom konfliktu spôsobeného detinským prístupom vývojára a nedostatkami pracovného procesu je situácia, keď pri absencii definície hotovo, vývojár a tím QA majú odlišné očakávania týkajúce sa pripravenosti funkcia prenesená do QA. Vývojár veril, že stačí napísať kód a prehodiť funkciu cez plot do QA – tam to vyriešia. Mimochodom, pomerne zrelý a skúsený programátor, ale to bol jeho vnútorný prah kvality. QA s tým nesúhlasil a požadoval, aby im ukázal a opísal, čo sám skontroloval, a požadoval pre nich testovací skript. Už v minulosti mali problémy s funkcionalitou od tohto vývojára a nechceli opäť strácať čas. Mimochodom, mali pravdu - táto funkcia naozaj nefungovala, nekontroloval kód pred jeho odoslaním do QA.
Aby som situáciu vyriešil, požiadal som ho, aby mi ukázal, že všetko naozaj funguje (nefungovalo to a on to musel napraviť), porozprávali sme sa s tímom a s definíciou QA hotovo (nestihli to v r. písanie, pretože sme nechceli, aby bol proces príliš byrokratický, no, čoskoro sme sa s týmto špecialistom rozišli (na všeobecnú úľavu).
Z hľadiska pracovného toku sú možné vylepšenia v tomto prípade prítomnosť definície hotovo, požiadavky na podporu každej funkcie jednotky a integračných testov a popis testovania vykonávaného vývojárom. V jednom z projektov sme merali úroveň pokrytia kódu testami počas CI a ak po pridaní patchu úroveň pokrytia klesla, testy boli označené ako neúspešné, t.j. akýkoľvek nový kód mohol byť pridaný iba vtedy, ak by preň existovali nové testy.
Ďalší typický príklad konfliktu úzko súvisiaci s organizáciou pracovného procesu. Máme produkt, tím vývoja produktu, tím podpory a zákazníka. Zákazník má problémy s produktom a kontaktuje podporu. Podpora analyzuje problém a chápe, že problém je v produkte a prenesie ho na produktový tím. Produktový tím je v rušnej dobe, blíži sa vydanie, takže tiket s problémom od zákazníka, stratený medzi ostatnými tiketmi vývojára, ktorému je pridelený, visí niekoľko týždňov bez pozornosti. Podpora si myslí, že vývojár pracuje na probléme zákazníka. Zákazník čaká a dúfa, že sa na jeho probléme pracuje. V skutočnosti sa zatiaľ nič nedeje. Po niekoľkých týždňoch sa zákazník konečne rozhodne zaujímať o priebeh a pýta sa podpory, ako sa veci majú. Podpora vyžaduje rozvoj. Vývojár sa otrasie, prezrie si zoznam lístkov a nájde tam lístok od zákazníka. Keď si prečíta lístok od zákazníka, pochopí, že na vyriešenie problému nie je dostatok informácií a potrebuje viac protokolov a výpisov. Podpora vyžaduje od zákazníka dodatočné informácie. A vtedy si zákazník uvedomí, že na jeho probléme celý ten čas nikto nepracoval. A udrie hrom...
V tejto situácii je riešenie samotného konfliktu celkom zrejmé a lineárne (opraviť produkt, aktualizovať dokumentáciu a testy, upokojiť zákazníka, vydať hotfix atď.). Je dôležité analyzovať pracovný proces a pochopiť, kto je zodpovedný za organizáciu interakcie medzi týmito dvoma tímami a prečo sa táto situácia vôbec stala možná. Je jasné, čo je potrebné v procese opraviť – niekto musí proaktívne sledovať celkový obraz bez pripomienok od zákazníkov. Lístky od zákazníka by mali vyčnievať medzi ostatnými lístkami od vývojárov. Podpora by mala vidieť, či vývojový tím momentálne pracuje na svojich lístkoch, a ak nie, kedy môže začať pracovať a kedy možno očakávať výsledky. Podpora a vývoj by mali pravidelne komunikovať a diskutovať o stave lístkov, zber informácií potrebných na ladenie by mal byť čo najviac automatizovaný atď.
Tak ako sa vo vojne nepriateľ snaží zasiahnuť spojnicu medzi dvoma jednotkami, tak aj v práci je najcitlivejším a najzraniteľnejším bodom interakcia medzi tímami. Ak sú manažéri podpory a vývoja dostatočne starí, budú schopní opraviť proces sami; ak nie, proces bude naďalej generovať konflikty a problémy, kým manažér nezasiahne a nedokáže situáciu napraviť.
Ďalším typickým príkladom, ktorý som opakovane videl v rôznych spoločnostiach, je situácia, keď produkt píše jeden tím, automatické integračné testy preň píše druhý tím a infraštruktúru, na ktorej to celé funguje, sprevádza tretí tím. tím. Problémy pri spúšťaní testov vznikajú neustále a príčinou problémov v nich môže byť tak produkt, ako aj testy a infraštruktúra. Zvyčajne je problematické dohodnúť sa, kto má vykonať prvotnú analýzu problémov, chýb súborov, analyzovať protokoly produktu, testy a infraštruktúru atď. Konflikty sú tu veľmi časté a zároveň jednotné. V prípade vysokej emocionálnej intenzity sa účastníci často dostanú do detinskej polohy a diskusie sa začínajú v sérii: „prečo by som sa s tým mal zaoberať“, „častejšie sa rozpadávajú“ atď.
Z hľadiska pracovného toku závisia konkrétne kroky na vyriešenie problému od zloženia tímov, typu testov a produktu atď. V jednom z projektov sme zaviedli periodickú službu, v rámci ktorej tímy sledovali testy jeden po druhom, týždeň po týždni. V druhom prípade počiatočnú analýzu vždy vykonali vývojári testov, ale analýza bola veľmi jednoduchá a produkt bol pomerne stabilný, takže fungoval dobre. Kľúčom je zabezpečiť, aby bol proces transparentný, aby boli očakávania jasné pre všetky strany a aby sa situácia zdala spravodlivá pre všetkých.
Je konflikt dokonca problémom v organizácii?Je to zlé znamenie, že sa vo vašom tíme často (alebo len periodicky) vyskytujú konflikty? Vo všeobecnosti nie, pretože ak existuje rast, rozvoj, existuje nejaká dynamika, potom vznikajú problémy, ktoré sa nikdy predtým neriešili a pri ich riešení môžu vzniknúť konflikty. To je indikátor, že niektorým oblastiam treba venovať pozornosť, že existujú oblasti, ktoré treba zlepšiť. Je zlé, ak konflikty vznikajú veľmi často, ťažko sa riešia alebo trvajú dlho. S najväčšou pravdepodobnosťou sa to podpísalo pod nedostatočne zefektívnené pracovné procesy a nedostatočnú vyspelosť tímu.
Zdroj: hab.com