Epigraf:
Jedného dňa sa v lese stretli Ježko a Medvedík.
— Ahoj, Ježko!
— Ahoj, Medvedík!
Tak, slovo za slovom, vtip za vtipom a Ježko dostal od Medvedíka po papuli …
Pod katom sú úvahy nášho tímového lídra a tiež riaditeľa rozvoja produktu RAS — Igora Marnata o špecifike pracovných konfliktov a možných metódach ich riadenia.
Väčšina konfliktov, ktorým čelíme v práci, sa vyvíja podľa scenára podobného tomu, ktorý bol opísaný vyššie v epigrafe. Existuje niekoľko účastníkov, ktorí sú navzájom sprvu celkom priaznivo naladení, snažia sa vyriešiť nejakú otázku, ale nakoniec problém ostáva nevyriešený a vzťahy medzi účastníkmi diskusie sa akosi zhoršujú.
Život je rôznorodý, v opísanom scenári sa vyskytujú variácie. Niekedy sú vzťahy medzi účastníkmi od začiatku nie veľmi dobré, niekedy ani nie je žiadna otázka, ktorá by potrebovala bezprostredné riešenie (ako napríklad v epigrafe), niekedy po diskusii zostávajú vzťahy rovnaké ako pred jej začiatkom, ale otázka nakoniec nie je vyriešená.
Čo je spoločné vo všetkých situáciách, ktoré môžeme definovať ako situáciu pracovného konfliktu?
Po prvé, ide o prítomnosť dvoch alebo viacerých strán. Tieto strany môžu mať rôzne postavenie v organizácii, môžu byť v rovnostárskych vzťahoch (kolegovia v tíme), alebo na rôznych úrovniach hierarchie (šéf — podriadený), môžu byť individuálne (zamestnanec) alebo skupinové (v prípadoch konfliktu medzi zamestnancom a tímom alebo dvoma tímami), a tak ďalej. Na pravdepodobnosť konfliktu a jednoduché jeho vyriešenie má veľký vplyv úroveň dôvery medzi účastníkmi. Čím lepšie sa strany poznajú, čím vyššia je úroveň dôvery, tým väčšia je šanca, že sa dohodnú. Napríklad, zamestnanci rozdeleného tímu, ktorí sa nikdy osobne nestretli, s väčšou pravdepodobnosťou upadnú do konfliktnej situácie pri riešení jednoduchého pracovného problému, ako ľudia, ktorí sa aspoň niekoľkokrát osobne stretli. Preto je pri práci v rozdelených tímoch veľmi dôležité zabezpečiť pravidelné osobné stretnutia všetkých členov tímu navzájom.
Po druhé, v prípade pracovného konfliktu sú strany v situácii, kde musia riešiť otázku, ktorá je pre jednu z nich, obidve alebo pre organizáciu celkovo dôležitá. Na základe špecifickosti situácie majú strany zvyčajne dostatok času a rôznych spôsobov na jej riešenie (formálne, neformálne, stretnutia, listy, rozhodnutia vedenia, existencia cieľov a plánov tímu, fakt existencie hierarchie atď.). Toto je na rozdiel od situácií, kde sa riešia pracovné (alebo nepracovné) otázky v organizácii, napríklad otázka: „Hej, chlapec, z ktorej štvrte si?!” na ulici alebo konflikt s epigrafom. V prípade pracovnej otázky má význam kvalita pracovného procesu a kultúra riešenia otázok v tíme.
Po tretie, určujúcim faktorom konfliktu (z pohľadu našej diskusie) je fakt, že strany procesu nemôžu samostatne prísť k riešeniu otázky, ktoré by vyhovovalo všetkým. Situácia si vyžaduje zásah tretej strany, vonkajšieho arbitra. Tento bod sa môže zdať sporný, ale v podstate, ak sa konflikt úspešne vyriešil bez zásahu vonkajšieho arbitra, otázka bola vyriešená úspešne a vzťahy strán sa nezhoršili, ide o situáciu, ktorú by sme mali usilovať dosiahnuť. O takom konflikte sa pravdepodobne ani nedozvieme, alebo sa to dozvieme náhodou po jeho vyriešení. Čím viac otázok dokáže tím vyriešiť samostatne, tým efektívnejšie bude pracovať.
Ďalšou charakteristickou črtou konfliktu, na ktorú sa oplatí zamerať, je stupeň emocionálneho napätia pri riešení. Konflikt nemusí nutne súvisieť s vysokým emocionálnym napätím. Účastníci nemusia kričať a mávať rukami, aby situácia bola konfliktna. Ak sa otázka nerieši, určité emocionálne napätie je pritom prítomné (možno nie je zjavné navonok), znamená to, že máme pred sebou situáciu konfliktu.
Je potrebné zasahovať do konfliktových situácií, alebo je lepšie nechať ich riešenie na osud a čakať, kým sa problém sám vyrieši? Je potrebné. Nie vždy je vo vašich silách alebo kompetencii úplne vyriešiť konflikt, ale v každej situácii, v konflikte akejkoľvek veľkosti, môžete zaujať dospelý postoj, čím vlastne privoláte ďalších ľudí okolo seba, zmierniť negatívne dôsledky konfliktu a prispieť k jeho riešeniu.
Predtým, než sa pozrieme na niekoľko príkladov konfliktových situácií, zastavíme sa na niekoľkých dôležitých aspektoch, spoločných pre všetky konflikty.
Pri riešení konfliktu je dôležité byť nad súdom, a nie vnútri neho (to sa ešte nazýva „zaujať metapozíciu“), to znamená, že sa nesmiete ocitnúť v procese riešenia na strane jednej zo strán. Inak sa namiesto vonkajšieho rozhodcu, ktorý pomáha v riešení, len posilníte pozíciu jednej strany na úkor druhej. Pri prijímaní rozhodnutí 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é prijatým rozhodnutím, aspoň boli úprimne ochotné ho realizovať. Čo sa nazýva byť schopný nesúhlasiť a súhlasiť. Inak konflikt jednoducho zmení vzhľad, žeravý oheň zostane pod rašelinou a v nejakom momente nevyhnutne znovu vzplanie.
Druhý moment, čiastočne súvisiaci s prvým — ak už sa chystáte zúčastniť sa na riešení konfliktu, berte to maximálne vážne z hľadiska komunikácie a štúdia kontextu. Porozprávajte sa osobne s každou zo strán. Osobitne s každou, najprv. Nespokojte sa s e-mailom. V prípade distribuovaného tímu — porozprávajte sa aspoň cez videohovor. Nespokojte sa so zvestiami a prehľadmi svedkov. Pochopte príbeh, čo chce každá strana, prečo to chce, čo očakáva, či sa snažili tento problém riešiť predtým, čo sa stane, ak sa nevyrieši, aké možnosti riešenia vidia, ako si predstavujú pozíciu druhej strany, čo považujú za správne alebo nesprávne, atď. Načítajte do svojej hlavy celý možný kontext, nezaujatý, predpokladajúc, že všetci majú pravdu. Nie ste vo vnútri konfliktu, ste mimo neho, v metapozícii. Ak je kontext dostupný iba v e-mailovej konverzácii — aspoň si ju prečítajte celú a aj súvisiace diskusie a dokumenty. Potom, čo ste prečítali — stále sa porozprávajte hlasom. Takmer určite počujete niečo dôležité, čo nie je v e-maile.
Tretí dôležitý moment — celkový prístup k komunikácii. Ide o bežné veci, nič prelomového, ale majú veľmi veľký význam. Nepokúšame sa ušetriť čas, hovoríme so všetkými účastníkmi, nekritizujeme osobu, ale zvažujeme dôsledky jej činov (nie "ty si hrubý", ale "myslím, že sa toto môže niekomu nepáčiť"), umožňujeme zachovanie tváre, diskusie vedeme osobne, nie pred kolektívom.
Konflikty sú zvyčajne vyvolané jednou z dvoch príčin. Prvá súvisí s tým, či je človek v momente konfliktu v pozícii dospelého alebo v pozícii dieťaťa (o tom nižšie). To súvisí s jeho emocionálnou zrelosťou, schopnosťou riadiť svoje emócie (čo, mimochodom, nie vždy súvisí s jeho vekom). Druhá rozšírená príčina — nedokonalosť pracovného procesu, ktorá vytvára situácie šedých zón, v ktorých je zodpovednosť rozmazaná medzi účastníkmi, očakávania strán nie sú navzájom jasné, úlohy v procese sú rozmazané.
Pri riešení konfliktu (ako aj v každom inom prípade) musí manažér mať na pamäti tri perspektívy: krátkodobú — vyriešiť otázku/konflikt tu a teraz, strednodobú — minimalizovať pravdepodobnosť vzniku iného konfliktu z rovnakého dôvodu, a dlhodobú — vychovávať v tíme kultúru dospelého človeka.
V každom z nás je vnútorné dieťa, približne troj- alebo štvoročné. Väčšinu času spí v práci, ale občas sa prebudí a vezme si riadenie. Dieťa má svoje priority. Je preň dôležité trvať na tom, že toto je jeho pieskovisko, mama ho má radšej, jeho autíčko je najlepšie (dizajn je najlepší, programuje najlepšie, …). V situácii konfliktu môže dieťa pukať hračkami, dupotať nohami a udrieť lopatkou, ale nemôže riešiť dospelé otázky (architektúra riešenia, prístupy k automatizovanému testovaniu, termíny vydania, atď.), nemyslí v pojmoch prínosu pre tím. Dieťa v konflikte je možné povzbudiť, utešiť a poslať spať, a požiadať ho, aby zavolalo svojho dospelého. Pred začiatkom diskusie v podmienkach konfliktu sa uistite, že práve teraz hovoríte s dospelým a nie s dieťaťom, a sami stoja na pozícii dospelého. Ak je váš úprimný cieľ v tomto momente riešiť vážnu otázku, nachádzate sa na pozícii dospelého človeka. Ak je vaším cieľom dupotať nohami a udierať lopatkou — to je detská pozícia. Pošlite svoje vnútorné dieťa spať a zavolajte dospelého, alebo presuňte diskusiu. Človek prijíma emocionálne rozhodnutie a potom mu hľadá racionálne odôvodnenie. Rozhodnutie, ktoré prijalo dieťa, vychádzajúce z detských priorít, nebude optimálne.
Okrem správania v čase konfliktu je detská alebo dospelá pozícia charakterizovaná aj úrovňou zodpovednosti, ktorú je človek ochotný prevziať. V extrémnych prípadoch sa detská pozícia programátora, ktorú som viackrát stretol, javí takto: napísal som kód, poslal som ho na revíziu — moja práca je hotová. Recenzenti ho musia predať a zlúčiť, QA ho musia skontrolovať, ak sa vyskytnú problémy — dajú mi vedieť. Akoby to bolo zvláštne, aj celkom dospelí a skúsení ľudia sa niekedy správajú podobne. Druhý kraj škály — človek považuje seba za zodpovedného za to, aby jeho kód fungoval, bol pokrytý testami, bol osobne skontrolovaný, úspešne prešiel revíziou (ak treba, nie je problém kontaktovať recenzentov, diskutovať otázky osobne atď.) a bol zlúčený, QA pri potrebách dostane pomoc, sú opísané testovacie scenáre atď. V normálnych prípadoch sa programátor buď od začiatku nachádza bližšie k dospelému kraju škály, alebo sa tam posúva s narastajúcimi skúsenosťami (za predpokladu, že v tíme je kultivovaná správna kultúra). V extrémnych prípadoch naďalej pracuje s obvykle detskou pozíciou, vtedy obvykle ním a tímom vznikajú problémy a konflikty.
Vytvorenie správnej, dospelej kultúry v tíme je dôležitou úlohou každého manažéra. Vyžaduje si to dlhý čas a každodenné úsilie, ale výsledok stojí za to. Existujú dva spôsoby, ako ovplyvniť kultúru tímu — osobný príklad (ktorému určite budú nasledovať, tím sa vždy pozerá na lídra) a diskusia a povzbudenie správneho správania. Ani tu nie je nič zložité alebo silne formálne, len pri diskusii o problémoch si všimnite, že tu sa dalo urobiť takto, zdôraznite, že ste si všimli, keď bolo rozhodnuté správne, pochváľte, zaznameňte na rozbore vydania atď.
Zvážme niekoľko typických konfliktových situácií, od jednoduchých po zložité:
Konflikty, nesúvisiace s pracovnými otázkami
Celkom často sa v práci vyskytujú konflikty, ktoré nie sú spojené s pracovnými otázkami. Ich vznik a ľahkosť vyriešenia sú zvyčajne priamo spojené s úrovňou emocionálnej inteligencie účastníkov, úrovňou ich dospelosti a nie sú spojené s dokonalosťou alebo nedokonalosťou pracovného procesu.
Typické príklady — niekto si nedostatočne často používa práčku alebo sprchu, čo sa nepáči okoliu, niekomu je horúco, inému fúka, ak sa otvorí okno, niekto je príliš hlučný a ostatní potrebujú ticho na prácu, a tak ďalej. S riešením konfliktov tohto druhu by sa nemalo otáľať a nedovoliť im plynúť samy. Samy o sebe sa nevyriešia a každý deň odvádzajú pozornosť od práce a otrávia atmosféru v tíme. Našťastie ich zvyčajne nie je ťažké vyriešiť — stačí pokojne si pohovoriť (samozrejme, jeden na jedného) s kolegom, ktorý zanedbáva hygienu, zabezpečiť komfortné sedenie pre tých, ktorí preferujú ticho/chlad, kúpiť zvukovo izolujúce slúchadlá alebo postaviť priečky, atď.
Ďalší príklad, s ktorým som sa stretol niekoľkokrát počas svojej práce — psychická nekompatibilita členov tímu. Z nejakých dôvodov sa ľudia jednoducho nedokážu spolu pracovať, každá komunikácia končí konfliktom. Niekedy to súvisí s tým, že ľudia majú polarizované názory na nejakú citlivú otázku (väčšinou politickú) a nevedia ich nechať na pracovisku. Presviedčať ich, aby sa navzájom tolerovali alebo aby zmenili svoje správanie, je dosť beznádejnou činnosťou. Jediné vynimočné prípady, ktoré som stretol — mladí kolegovia s otvoreným vnímaním, ich správanie je ešte možné postupne zmeniť prostredníctvom pravidelných rozhovorov. Zvyčajne sa problém úspešne rieši rozdelením ich do rôznych tímov, alebo aspoň zabezpečením možnosti zriedkavo sa stretávať pri práci.
Vo všetkých uvedených situáciách by sa so všetkými zúčastnenými malo osobne porozprávať, prediskutovať situáciu, zaujímať sa, či vôbec vidia problém v tomto prípade, opýtať sa, aké, podľa ich názoru, sú cesty riešenia, a zabezpečiť ich účasť na prijímaní tohto rozhodnutia.
Z hľadiska optimalizácie pracovného procesu (strednodobá perspektíva, o ktorej som spomínal) nie je veľa toho, čo sa tu dá urobiť, jediný aspekt, ktorý je možné optimalizovať — zohľadniť faktor kompatibility pri formovaní tímu a vopred nezostavovať ľudí, ktorí budú konfliktovať.
Z pohľadu kultúry tímu sa takéto situácie vyskytujú oveľa zriedkavejšie v tímoch s dospelou kultúrou, kde si ľudia navzájom vážia tím a kolegov a dokážu si sami vyriešiť otázky. Okrem toho sa takéto konflikty oveľa jednoduchšie riešia (často automaticky) v tímoch, kde je vysoká úroveň dôvery, ľudia spolu pracujú dlhú dobu a/alebo sa často stretávajú aj mimo pracovného prostredia.
Konflikty súvisiace s pracovnými otázkami:
Tieto konflikty sú obvykle spôsobené oboma príčinami naraz, a to emocionálnou (keď niektorý z účastníkov nie je na úrovni dospelého) a nedokonalosťou samotného pracovného procesu. Najbežnejší typ konfliktov, s ktorými som sa stretol, sú konflikty v procese revízie kódu alebo v diskusiách o architektúre medzi vývojármi.
Vyčlenil by som tu dva typické prípady:
1) V prvom prípade vývojár nemôže dosiahnuť revíziu kódu od kolegu. Patch bol odoslaný na revíziu a nič sa nedeje. Na prvý pohľad medzi oboma stranami nie je zjavný konflikt, ale po zamyslení je to celkom konflikt. Pracovná otázka nie je vyriešená, jedna zo strán (čakajúca na revíziu) pociťuje zjavný diskomfort. Extrémny podtyp tejto situácie je vývoj v komunite alebo v rôznych tímoch, pričom revízor nemusí mať záujem o tento konkrétny kód, kvôli zaťaženiu alebo iným okolnostiam môže úplne ignorovať požiadavku na revíziu a vonkajší arbitra (spoločného pre obe strany manažéra) môže vôbec nemusieť byť.
Prístup k riešeniu, ktorý pomáha v takejto situácii, patrí práve do dlhodobej perspektívy, kultúry dospelého človeka. Po prvé, funguje rozumná aktivita. Nenechaj sa prekvapiť, že kód, ktorý je v revízii, sám o sebe pritiahne pozornosť revízora. Treba pomôcť revízorom si ho všimnúť. Oslov niekoľkých ľudí, polož otázku na synke, zúčastňuj sa diskusií. Je zrejmé, že dotieravosť skôr uškodí, než pomôže, treba zapojiť zdravý rozum. Po druhé, dobre funguje predbežná príprava. Ak tím chápe, čo a prečo sa deje, prečo je tento kód vôbec potrebný, dizajn bol predtým prediskutovaný a odsúhlasený so všetkými, ľudia si pravdepodobnejšie všimnú taký kód a prijmú ho do praxe. Po tretie, funguje autorita. Ak chceš, aby ťa revízovali — rob veľa revízií sám. Rob kvalitné revízie, s reálnymi kontrolami, reálnymi testami, užitočnými komentármi. Ak je tvoje meno známe v tíme v dobrom svetle, je väčšia šanca, že si niekto všimne tvoj kód.
Z pohľadu pracovného procesu sú možné zlepšenia v správnom nastavovaní priorít, zameraných na pomoc vývojárovi dosiahnuť jeho ciele a ciele tímu (robiť revízie iných, písať správy v komunite, sprevádzať kód popisom architektúry, dokumentáciou, testami, zúčastňovať sa diskusií s komunitou atď.), zabrániť prílišnému uviazaniu záplat v poradí, a tak ďalej.
2) Druhý bežný prípad konfliktov pri revízii kódu alebo dizajnu — rôzne názory na technické otázky, štýl kódovania, výber nástrojov. Obrovský význam pritom má úroveň dôvery medzi účastníkmi, príslušnosť k jednému tímu, skúsenosť zo spoločnej práce. Patová situácia nastáva, keď niekto z účastníkov zaujme detskú pozíciu, nesnaží sa počuť, čo mu chce odovzdať jeho partner. Často pritom môžu byť aj prístupy, ktoré navrhuje druhá strana, aj prístup, ktorý bol pôvodne navrhnutý, celkom úspešné a nemá zásadný význam, ktorý z nich si vybrať.
Raz raz je programátor z môjho tímu (nazvime ho Paša) pripravil patch so zmenami v systéme nasadzovania balíkov, ktorý vyvinuli a spravovali kolegovia z vedľajšieho oddelenia. Jeden z nich (Igor) mal svoj silný názor na to, ako presne nastaviť Linuxové služby pri nasadzovaní balíkov. Tento názor sa líšil od prístupu navrhnutého v patche a dohovoriť sa im nedarilo. Ako obvykle, termíny tlačili a bolo potrebné dospieť k nejakému riešeniu, potrebovali, aby niekto z nich zaujal dospelú pozíciu. Paša uznával, že oba prístupy majú právo na existenciu, ale chcel, aby jeho variant prešiel, pretože neexistovali zjavné technické výhody ani pri jednom, ani pri druhom variante.
Naša diskusia vyzerala približne takto (veľmi schematicky, samozrejme, rozhovor trval pol hodiny):
— Paša, za pár dní máme feature freeze. Je dôležité, aby sme všetko poskladali a začali testovanie čo najskôr. Ako prejsť cez Igora?
— On chce nastavovať služby inak, nalepil mi tam komentáre…
— A čo tam, veľké prestavby, veľa roboty?
— Nie, tam je práca na pár hodín, ale nakoniec rozdiel nijaký, aj tak to bude fungovať, načo to je potrebné? Urobil som fungujúcu vec, poďme ju prijať.
— Počuj, a koľko už to všetko diskutujete?
— Už asi týždeň a pol sa v tom točíme.
— Em… môžeme za pár hodín vyriešiť otázku, ktorá už trvala týždeň a pol, a nerobíme to?
— Nuž, áno, ale nechcem, aby si Igor myslel, že som sa podvolil…
— Počuj, čo je pre teba dôležitejšie, vydať releas spolu so svojím riešením, alebo poraziť Igora? Môžeme ho poraziť, ale potom existuje dobrá šanca, že s releasom prepadneme.
— No… bolo by fajn, samozrejme, utriť Igorovi nos, ale dobre, releas je dôležitejší, súhlasím.
— Naozaj ti záleží na tom, čo si myslí Igor? Úprimne povedané, jemu je to celkom jedno, len chce, aby bol v rôznych miestach tej veci, za ktorú je zodpovedný, jednotný prístup.
— No, ok, spravím to, ako on žiada v komentároch, a začneme testovanie.
— Ďakujem, Paša! Bol som presvedčený, že z vás dvoch sa ukážeš ako zrelší, aj keď Igor je starší ako ty :)
Problém sa vyriešil, verzia bola vydaná načas, Paša nemal žiadne vážne výhrady, pretože sám navrhol a realizoval riešenie. Igor bol úplne spokojný, pretože jeho názor bol zohľadnený a urobili to tak, ako navrhoval.
Iný typ podobného konfliktu spočíva v rozhodovaní medzi technickými riešeniami/knižnicami/prístupmi v projekte, najmä v distribuovanom tíme. V jednom z projektov, ktorý bol prezentovaný ako využívajúci C/C++, sa nakoniec ukázalo, že technický manažment projektu je kategoricky proti používaniu STL (Standard Template Library). Je to štandardná knižnica jazyka, ktorá uľahčuje vývoj, náš tím si na ňu veľmi zvykol. Ukázalo sa, že projekt je oveľa bližšie k C ako k C++, čo tímu práve neprospievalo, pretože manažment sa snažil a naobstaral skutočne skvelých programátorov v C++. Americká časť tímu, a inžinieri, a manažéri, pracovali v spoločnosti dlhú dobu, zvykli si na existujúci stav, bolo im to jedno. Ruská časť tímu bola zložená celkom nedávno, len pred niekoľkými týždňami (vrátane mňa). Ruská časť tímu kategoricky nechcela vzdať svoj obvyklý prístup k vývoju.
Začali sa nekonečné písomné diskusie medzi dvoma kontinentmi, e-maily s dĺžkou tri-štyri obrazovky sa posúvali tam a späť, v skupinových aj osobných správach, od programátorov — k programátorom a manažérom. Ako to býva zvykom, e-maily takejto veľkosti nikto, okrem autorov a ich horlivých podporovateľov, nečítal. Chaty skričali od napätia, prenášajúc na obidve strany mnohostránkové úvahy o technických výhodách STL, aká dobre je otestovaná, bezpečná a vôbec, aký nádherný je život s ňou a aký hrozný bez nej.
Trvalo to celkom dlho, kým som si konečne neuvedomil, že sa zaoberáme technickými aspektmi problémov, ale skutočný problém nie je technický. Problém nespočíva v prednostiach alebo nedostatkoch STL, ani v zložitosti práce bez nej. Skôr je to organizačný problém. Potrebovali sme len pochopiť, ako funguje firma, v ktorej sme pracovali. Nikto z nás predtým nemal skúsenosti s takouto spoločnosťou. Problém bol ten, že po vývoji kódu a jeho uvedení do produkcie sa o podporu starali úplne iní ľudia z iných tímov a krajín. Tento obrovský inžiniersky tím pozostával z niekoľkých desiatok tisíc inžinierov (spolu) si mohol dovoliť iba úplne základné minimálne technické prostriedky, takpovediac minimum minimorum. Všetko, čo presahovalo inžiniersky štandard, ktorý sa vo firme ustálil, nemohlo byť neskôr podporované. Úroveň tímu je určená úrovňou najslabších členov. Po tom, ako sme pochopili skutočnú motiváciu činov americkej časti tímu, bola táto otázka odstránená z programu a všetci sme úspešne vyvinuli a uviedli produkt na trh, pričom sme používali normy prijaté v spoločnosti. E-maily a chaty v tomto prípade nefungovali dobre, aby sme dosiahli spoločný konsenzus, bolo potrebných niekoľko ciest a množstvo osobnej komunikácie.
Z hľadiska pracovného procesu by v tomto konkrétnom prípade bolo užitočné mať popis používaných prostriedkov, požiadavky na ne, obmedzenia na ich pridávanie a odôvodnenie týchto obmedzení. Takéto dokumenty približne zodpovedajú bodom Reuse Strategy a Development Environment z príručky “Manager’s Handbook for Software Development”, vyvinutej v . Napriek svojmu veku veľmi dobre popisuje všetky hlavné aktivity a fázy plánovania vývoja softvéru tohto druhu. Prítomnosť takýchto dokumentov veľmi uľahčuje diskusiu o tom, ktoré komponenty a prístupy môžu byť použité v produkte a prečo.
Z hľadiska kultúry je zjavné, že pri zrelejšom prístupe, pri ktorom sa strany snažia vypočuť a pochopiť skutočnú motiváciu činov kolegov a konajú na základe priorít projektu a tímu a nie osobného ega, by sa konflikt vyriešil jednoduchšie a rýchlejšie.
V inom konflikte týkajúcom sa výberu technického riešenia mi tiež trvalo značný čas, aby som pochopil motiváciu jednej zo strán (prípad bol naozaj nezvyčajný), ale keď bola motivácia jasná, riešenie bolo očividné.
Situácia je taká: v tíme z približne 20 ľudí sa objaví nový vývojár, povedzme, že sa volá Stas. Naším štandardným nástrojom na komunikáciu v tíme bol v tom čase Skype. Ako sa neskôr ukázalo, Stas bol veľkým fanúšikom otvorených štandardov a open-source softvéru a používal iba nástroje a operačné systémy, ktorých zdrojové kódy sú verejne dostupné a ktoré používajú verejne popísané protokoly. Skype medzi takéto nástroje nepatrí. Strávili sme množstvo času diskusiami o výhodách a nevýhodách tohto prístupu, pokusmi spustiť analógy Skypu na rôznych operačných systémoch, pokusmi Stasa presvedčiť tím prejsť na iné štandardy, písať mu osobne e-mail, telefonovať mu osobne, kúpiť mu druhý počítač špeciálne na Skype, atď. Nakoniec som si uvedomil, že toto je problém, ktorý nie je technický ani organizačný, skôr ide o pohľad na svet, dokonca by sa dalo povedať, náboženský (pre Stasa). Aj keby sme Stasa nakoniec spojili so Skypom (na čo už uplynulo niekoľko mesiacov), na akomkoľvek ďalšom nástroji by problém opäť vznikol. Nemal som skutočné prostriedky na zmenu Stasovho pohľadu na svet a nemal som dôvody pokúšať sa zmeniť pohľad na svet tímu, ktorý v tomto prostredí skvele fungoval. Človek a firma jednoducho mali ortogonálne pohľady. V takýchto situáciách je dobrá alternatíva organizačné riešenie. Preložili sme Stasa do iného tímu, kde bol viac organický.
Príčina tohto konfliktu je podľa mňa v nesúlade osobnej kultúry konkrétneho človeka (ktorý má silný názor, ktorý mu neumožňuje ísť na kompromisy) s kultúrou spoločnosti. V tomto prípade to, samozrejme, bola chyba manažéra. Od začiatku bolo nesprávne prijať ho na projekt tohto typu. Stas nakoniec prešiel na projekt vývoja otvoreného softvéru a tam výborne uspel.
Dobrý príklad konfliktu vyvolaného súčasným pohľadom vývojára a nedostatkami v pracovnom procese – situácia, v ktorej v absencii definition of done mal vývojár a tím QA rôzne očakávania ohľadom pripravenosti funkcie, ktorá bola poslaná do QA. Vývojár veril, že stačí napísať kód a poslať funkciu QA, kde sa o to postarajú. Celkom skúsený programista, mimochodom, ale taký bol jeho vnútorný prah kvality. QA s tým však nesúhlasilo a požadovalo, aby im ukázal a popísal, čo sám skontroloval, a tiež žiadalo testovací scenár. Už mali v minulosti problémy s funkčnosťou od tohto vývojára a nechceli zbytočne strácať čas. Mimochodom, mali pravdu – funkcia naozaj nefungovala, kód pred odovzdaním do QA si neoveril.
Na riešenie situácie som ho požiadal, aby mi ukázal, že všetko naozaj funguje (nefungovalo, a musel to opraviť), prebrali sme s tímom a QA definition of done (nestali sme sa písomnými, pretože sme nechceli proces príliš byrokratizovať), no s týmto špecialistom sme sa čoskoro rozlúčili (k všeobecnému uľaveniu).
Z hľadiska pracovného procesu možné vylepšenia v tomto prípade – existencia definition of done, požiadavky na podporu každej funkcie s jednotkovými a integračnými testami, popis testovania, ktoré vývojár vykonal. V jednom z projektov sme merali úroveň pokrytia kódu testami počas CI a v prípade, ak úroveň pokrytia po pridaní záplaty klesla, testy boli označené ako neúspešné, t.j. akýkoľvek nový kód mohol byť pridaný iba v prípade, že pre neho existovali nové testy.
Ďalší typický príklad konfliktu, ktorý je úzko spojený s organizovaním pracovného procesu. Máme produkt, tím na jeho vývoj, tím podpory a zákazníka. Zákazník má problémy s produktom a kontaktuje podporu. Podpora analyzuje problém a zistí, že problém je v produkte, a odovzdáva ho produktovému tímu. Produktový tím má obdobie zvýšenej pracovnej záťaže, blíži sa termín vydania, a preto je tiket so zákazníkovým problémom, ktorý bol priradený konkrétnemu vývojárovi, niekoľko týždňov bez povšimnutia. 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 však nič nedeje. Po niekoľkých týždňoch sa zákazník konečne rozhodne zistiť pokrok a pýta sa podpory, ako to ide. Podpora sa pýta vývoja. Vývojár sa zatrasie, prezerá zoznam tiketov a objaví tam tiket od zákazníka. Pri čítaní tiketov od zákazníka si uvedomuje, že informácií na riešenie problému je nedostatok a potrebuje ešte logy a dumpy. Podpora žiada o ďalšie informácie od zákazníka. A vtedy si zákazník uvedomí, že na jeho probléme celé to čas nikto nepracoval. A zahromí hrom ...
V tejto situácii je riešenie samotného konfliktu pomerne jasné 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 nesie zodpovednosť za organizáciu interakcie medzi oboma tímami, prečo sa takáto situácia vôbec mohla vyskytnúť. Je jasné, že je potrebné opraviť proces — niekto by mal monitorovať celkový obraz proaktívne bez upozornení od zákazníkov. Tikety od zákazníka by mali vyniknúť medzi ostatnými tiketmi u vývojárov. Podpora by mala vidieť, či vývoj pracuje na jej tiketoch v súčasnosti, a ak nie — kedy začne, kedy možno očakávať výsledok. Podpora a vývoj by sa mali pravidelne rozprávať a diskutovať o stave tiketov, zbieranie potrebných informácií na ladenie by malo byť maximálne automatizované, atď.
Rovnako ako sa protivník na vojne snaží zasiahnuť spojenie medzi dvoma jednotkami, aj v práci je najtenším a najzraniteľnejším miestom zvyčajne interakcia medzi tímami. Ak sú manažéri podpory a vývoja dostatočne vyspelí, dokážu proces opraviť sami; ak nie, proces bude naďalej generovať konflikty a problémy, kým nezasiahne manažér, ktorý dokáže situáciu napraviť.
Ďalším charakteristickým príkladom, s ktorým som sa opakovane stretol v rôznych spoločnostiach, je situácia, v ktorej jeden tím vyvíja produkt, automatické integračné testy sú vytvorené druhým tímom a infraštruktúra, na ktorej sa to všetko prevádzkuje, je spravovaná tretím tímom. Problémy pri spúšťaní testov sa objavujú neustále, pričom zdrojom problémov môžu byť ako produkt, tak aj testy a infraštruktúra. Zvyčajne býva problematické dohodnúť sa, kto by mal vykonávať počiatočnú analýzu problémov, zaznamenávať chyby, analyzovať logy produktu, testov a infraštruktúry atď. Konflikty sú tu pomerne časté a zároveň jednotné. V prípade vysokého emocionálneho napätia sa účastníci často dostávajú do detskej pozície a začínajú diskusie v štýle: „Prečo by som sa mal s tým zaoberať?“, „Oni sa častejšie pokazia“ atď.
Z hľadiska pracovného procesu konkrétne kroky na riešenie otázky závisia od zloženia tímov, typu testov a produktu atď. V jednom projekte sme zaviedli pravidelné služby, pričom tímy sledovali testy po jednom týždni. V inom projekte vždy prvotnú analýzu vykonávali vývojári testov, ale tento analýza bola veľmi základná a produkt bol dostatočne stabilný, takže to celkom dobre fungovalo. Hlavné je zabezpečiť transparentnosť procesu, jasnosť očakávaní pre všetky strany a pocit spravodlivosti situácie pre všetkých.
Je konflikt v organizácii vôbec problémom, alebo je to zlý znak, že vo vašej partii dochádza často (alebo len občas) ku konfliktom? Vo všeobecnosti nie, pretože ak dochádza k rastu, rozvoju a nejakej dynamike, objavujú sa otázky, ktoré sa predtým nikdy neriešili, a pri ich riešení môžu vzniknúť konflikty. To je indikátor toho, že treba venovať pozornosť určitým oblastiam, ktoré sú priestranstvami na zlepšenie. Je zlé, ak k konfliktom dochádza príliš často a ich riešenie je ťažké alebo zdĺhavé. To je pravdepodobne znak nedostatočne nastavených pracovných procesov a nízkej dospelosti tímu.
Zdroj: habr.com
