Konfliktide juhtimine meeskonnas – akrobaatika või elu vajalikkus?

Epigraaf:
Ühel päeval kohtusid metsas Mesikäpp ja Siil.
— Tere, Siil!
— Tere, Mesikäpp!
Nii, sõna sõna, naljast nalja ja Mesikäpp sai Siililt vastu näkku ...

Allpool meie tiimijuhi ja RAS toote arenduse juhi Igor Maranati mõtted töökeskkonna konfliktide eripära ning nende juhtimise võimalike meetodite kohta.

Enamik konflikte, millega me tööl silmitsi seisame, arenevad sarnasel stsenaariumil nagu ülaltoodud epigraafis. On mitmeid osalisi, kes on esialgu üksteise suhtes tõeliselt head, nad püüavad mingit probleemi lahendada, kuid lõpuks jääb probleem ikka lahendamata ning omavahelised suhted on kuidagi rikutud.

Elu on mitmekesine; ülaltoodud stsenaariumis on variatsioonid. Mõnikord on osaliste vahel esialgu suhted halvad, mõnikord pole isegi küsimust, mis nõuaks vahetut lahendamist (nagu näiteks epigraafis), mõnikord jäävad suhted arutelu lõpuks samaks nagu enne, kuid probleem jääb lõpuks lahendamata.

Mis on iseloomulikud kõigile olukordadele, mida saame määratleda kui töökeskkonna konflikti olukordi?



Esiteks on olemas kaks või enam osalist. Need osalised võivad asuda organisatsioonis erinevates positsioonides, olla suhteid võrdsed (meeskonna kolleegid) või erinevatel hierarhiatasemetel (ülem — alluv), olla individuaalsed (töötaja) või grupilised (näiteks olukordades, kus konflikt on töötaja ja meeskonna või kahe meeskonna vahel) jne. Usaldustasand osaliste vahel mõjutab oluliselt konflikti tõenäosust ja selle lahendamise lihtsust. Mida paremini osalised üksteist tunnevad, seda kõrgem on usaldustase, seda suurem on võimalus, et nad suudavad kokku leppida. Näiteks kaugmeeskonnas töötavad töötajad, kes pole kunagi isiklikult kohtunud, satuvad tõenäolisemalt konflikti lihtsa tööalase küsimuse lahendamisel kui inimesed, kes on vähemalt paar korda isiklikult kohtunud. Seetõttu, töötades kaugmeeskondades, on äärmiselt oluline tagada, et kõik meeskonna liikmed kohtuksid omavahel perioodiliselt isiklikult.

Teiseks, töökonflikti olukorras osalised seisavad silmitsi küsimuse lahendamise vajadusega, mis on oluline üksnes mõnele osalisele, mõlemale või organisatsioonile tervikuna. Sellest tulenevalt on osalistel tihti piisavalt aega ja erinevaid lahendusviise (formaalsetest, mitteformaalsetest, kohtumistest, kirjades, juhtkonna otsustest, meeskonna eesmärkidest ja plaanidest, hierarhia olemasolust jne). See eristab töösituatsiooni (või mitte-töösituatsiooni) küsimuse lahendamist näiteks tõsisest küsimusest: „Hei, kutt, kust sa pärit oled?!“ tänaval või ülaltoodud konflikti puhul. Tööalase küsimuse lahendamisel on oluline tööprotsessi kvaliteet ja meeskonna küsimuste lahendamise kultuur.

Kolmandaks, konfliktide määravaks teguriks (meie arutelu perspektiivist) on see, et osalised ei suuda iseseisvalt jõuda kõiki osalisi rahuldavale lahendusele. Olukord nõuab kolmanda osapoole, välist vahekohtuniku, sekkumist. See punkt võib tunduda vaieldav, kuid tegelikult, kui konfliktne olukord lahendatakse eduka tulemusega ilma välist vahekohtunikku kaasamata, on küsimus lahendatud ja osaliste suhted ei halvenenud, siis on see olukord, mille poole tuleks püüelda. Sellise konflikti kohta ei pruugi me isegi teada, või saame sellest teada juhuslikult pärast lahendamist. Mida rohkem küsimusi suudab meeskond iseseisvalt lahendada, seda efektiivsemalt nad töötavad.

Veel üks iseloomulik joon konfliktist, mida tasub puudutada – emotsionaalse pinge aste lahendamise käigus. Konflikt ei tähenda tingimata kõrget emotsionaalset taset. Osalised ei pea karjuma ja kätega vehkima, et olukord oleks tõeliselt konfliktne. Kui küsimus ei lahene ja teatud emotsionaalne pinge on kohal (võib-olla ei väljendu see selgelt), tähendab see, et oleme silmitsi konfliktiga.

Kas on üldse vajalik sekkuda konfliktsetesse olukordadesse või on parem lasta neil iseenesest lahenduda ja oodata, kuni probleem kaob? On vajalik. Mitte alati ei ole teie võimuses või pädevuses konflikti täielikult lahendada, kuid igas olukorras, igasuguste konfliktide puhul, saate võtta täiskasvanu positsiooni, tõstes sellega ka mitmeid inimesi enda ümber, pehmendada konflikti negatiivseid tagajärgi ja soodustada selle lahendamist.

Enne kui vaatame üle mõned konfliktsete olukordade näited, peatugem mõnedele olulistele aspektidele, mis on kõikidele konfliktidele ühised.

Konflikti lahendamisel on oluline olla võitlusest kõrgemal, mitte selle sees (seda nimetatakse ka „meta-positsiooni võtmiseks”), st mitte osalema lahendamisprotsessis ühe osapoole poolel. Vastupidisel juhul muutute te väliseks vahemeheks, kes aitab lahendust, ja te tugevdage ühe osapoole positsiooni teise arvelt. Otsuse tegemisel on oluline, et see oleks kõigi osapoolte moraalselt vastuvõetav, nagu öeldakse, „ostetud”. Et isegi kui osalised ei olnud vastuvõetud otsusest rõõmsad, olid nad siiski siiralt nõus seda täitma. Nii öeldes, olla seisukohal, et ei pruugi nõustuda, kuid nõustuda. Vastasel juhul muudab konflikt lihtsalt oma välimust, söed jäävad turba alla ja mingil hetkel põletavad nad paratamatult uuesti.

Teine moment, mis osaliselt on seotud esimesega — kui olete juba otsustanud osaleda konflikti lahendamises, võtke seda maksimaalselt tõsiselt suhtlemise ja konteksti uurimise seisukohalt. Rääkige isiklikult iga osapoolega. Alguses eraldi igaühega. Ärge leppige kirjadega. Jaotatud meeskonna puhul rääkige vähemalt videokõne teel. Ärge rahuldage kuulujutte ja tunnistajate ülekandeid. Mõistke lugu, mida iga osapool tahab, miks nad seda tahavad, mida nad ootavad, kas nad on proovinud seda küsimust varem lahendada, mis juhtub, kui seda ei lahendata, milliseid lahendusvõimalusi nad näevad, kuidas nad esitavad teise poole positsiooni, mis nende arvates on õige või vale jne. Laadige endasse kogu võimalik kontekst, erapooletult, eeldades, et kõik on õiged. Te ei ole konfliktis sees, olete selle väljas, metaasendis. Kui kontekst on saadaval ainult e-kirjade ahelas — vähemalt lugege see täielikult läbi ning seotud arutelud ja dokumendid. Pärast lugemist — rääkige ikkagi hääle kaudu. Peaaegu garanteeritult kuulete midagi olulist, mida kirjas ei ole.

Kolmas oluline punkt — üldine lähenemine suhtlemisele. Need on tavalised asjad, mitte midagi kosmilist, kuid neil on väga suur tähendus. Ärge üritage aega säästa, rääkige kõigi osalistega, kritiseerige mitte inimest, vaid tema tegevuse tagajärgi (mitte "sa oled jäme", vaid "võib-olla võivad poisid selle asja üle vihastada"), andke võimalus näo säilitamiseks, arutelud toimuvad isiklikult, mitte rivi ees.

Konfliktid on tavaliselt tingitud kahest põhjusest. Esimene on seotud sellega, kas inimene on konflikti hetkel täiskasvanu või lapse positsioonis (sellest allpool). See on seotud tema emotsionaalse küpsusega, võimega juhtida oma emotsioone (mis muide ei ole alati seotud tema vanusega). Teine levinud põhjus on tööprotsessi ebatäiuslikkus, mis loob halli ala olukordi, kus vastutus on hajutatud osaliste vahel, osapoolte ootused pole üksteisele selged, rollid protsessis on hägusad.

Seega konfliktide lahendamisel (nagu iga teise küsimuse puhul) peab juht silmas pidama kolme perspektiivi: lühiajalist - lahendada küsimus / konflikt siin ja praegu, keskpärast - vähendada tõenäosust, et sarnane konflikt uuesti tekib, ja pikaajalist - kasvatada meeskonnas täiskasvanute kultuuri.

Igas meis on sisemine laps, umbes kolme-nelja aastane. Suurema osa ajast magab ta tööl, kuid vahel tõuseb ta üles ja võtab juhtimise enda kätte. Lapsel on omad prioriteedid. Temale on oluline kinnitada, et see on tema liivakast, emme armastab teda rohkem, tema auto on parim (disain on parim, ta programmeerib paremini kui keegi teine jne). Konfliktiolukorras võib laps mänguasju pigistada, jalgu trampida ja labidaga paukuda, kuid ta ei oska lahendada täiskasvanute küsimusi (lahenduse arhitektuur, automaatsete testimismetoodikad, väljaandmise tähtaeg jne), ta ei mõtle meeskonna kasule. Lapse konfliktis võib julgustada, lohutada ja saadetud magama, paludes tal kutsuda oma täiskasvanu. Enne arutelu alustamist konfliktitingimustes veenduge, et räägite just nüüd täiskasvanuga, mitte lapsega, ja seisate ise täiskasvanu positsioonil. Kui teie siiras eesmärk on hetkel lahendada tõsine küsimus, olete täiskasvanu positsioonil. Kui teie eesmärk on jalgu trampida ja labidaga paukuda - see on lapse positsioon. Saatke oma sisemine laps magama ja kutsuge täiskasvanu, või lükake arutelu edasi. Inimene teeb emotsionaalse otsuse ja seejärel otsib sellele ratsionaalset põhjendust. Otsus, mille laps teeb, lähtuvalt lasteprioriteetidest, ei ole optimaalne.

Lisaks käitumisele konflikti hetkedel iseloomustab lapse või täiskasvanu positsioon ka vastutuse taset, mille inimene on valmis võtma. Äärmuslikel juhtudel näeb programmeerija lapse positsioon, mida ma olen korduvalt kohanud, välja nii: ma kirjutasin koodi, saatsin selle ülevaatamiseks — minu töö on lõpule viidud. Ülevaatajad peavad selle vaatama ja liitma, QA peab selle kontrollima, kui esinevad mingid probleemid — nad teavitavad mind. Kummaline, kuid isegi üsna küpsed ja kogenud inimesed käituvad mõnikord nii. Teine äärmus on see, et inimene arvab, et ta on vastutav selle eest, et tema kood töötaks, oleks testitud, kontrollitud tema poolt, edukalt üle vaadatud (kui vaja, pole probleemi ülevaatajaid pingutada, arutada küsimusi häälega jne.) ja oleks liidetud, QA abi osutatakse vajadusel, testimise stsenaariume kirjeldatakse jne. Tavalistes oludes on programmeerija kas algusest peale lähemal täiskasvanu äärmus või nihkub sinna koos kogemuse kasvamisega (eeldusel, et meeskonnas viljeletakse õiget kultuuri). Ekstreemsetes juhtudes jätkab ta tavaliselt lapse positsioonil töötamist, mille tõttu esinevad tal ja meeskonnal perioodiliselt probleemid ja konfliktid.

Meeskonnas õige, täiskasvanulik kultuuri kasvatamine on iga juhi oluline ülesanne. See nõuab pikka aega ja igapäevaseid jõupingutusi, kuid tulemus on seda väärt. On kaks viisi, kuidas meeskonna kultuurile mõju avaldada — isiklikud näited (millele järgivad kindlasti, meeskond jälgib alati liidrit) ja õige käitumise arutamine ja julgustamine. Siin pole samuti midagi keerulist ega väga formaalset, lihtsalt probleemide arutamisel märkige, mida oleks saanud teha teisiti, rõhutage, et olete märganud, kui lahendus on õige, kiitke, märkige üles väljaande analüüsis jne.

Vaatleme mõned tüüpilised konfliktolukorrad, lihtsatest keerulisteni:

Konfliktid, mis ei ole seotud tööalaste küsimustega

Tööl esineb üsna tihti konflikte, mis ei ole otseselt seotud tööalaste küsimustega. Nende tekkimine ja kerge lahendamine on tavaliselt otseselt seotud osalejate emotsionaalse intelligentsuse tasemega, nende täiskasvanu tasemega ja ei ole seotud tööprotsessi täiuslikkuse või puudustega.

Tüüpilised näited - keegi ei kasuta pesumasinat või dušši piisavalt sageli, millest ümbritsevad saavad tüdinud, mõnele on kitsas, aga teisele puhub, kui aken avada, keegi on liiga lärmakas, samas kui teistele on tööks vajalik vaikus jne. Tüüpiliste konfliktide lahendamisega ei tule venitada ega lase see iseenesest minna. Need ei lahene eraldi ja häirivad tööd ning mürgitavad meeskonna atmosfääri. Õnneks ei ole nende lahendamine tavaliselt suur probleem - piisab, kui rääkida rahulikult (loomulikult silmast silma) kolleegiga, kes hügieenist ei hooli, tagada mugav istumine neile, kes eelistavad vaikust või jahedust, osta helisummutavad kõrvaklapid või paigaldada vaheseinad jne.

Teine näide, millega olen oma tööaja jooksul paar korda kokku puutunud, on meeskonnaliikmete psühholoogiline ühilduvus. Miski pärast ei saa inimesed lihtsalt koos töötada, iga suhtlemine lõpeb skandaaliga. Mõnikord on see seotud sellega, et inimesed jäävad kinni polariseeritud arvamustesse mõnes põletavas küsimuses (tavaliselt poliitilises) ja ei oska neid tööväliselt jätta. Nende veenmises teineteise talumisse või oma käitumise muutmisse pole mõtet. Ainus erand, mida olen kohanud, on noored kolleegid avatud mõtlemisega, kelle käitumist on veel võimalik aegamisi muuta perioodiliste vestluste kaudu. Probleem lahendatakse tavaliselt nende erinevatesse meeskondadesse paigutamisega või vähemalt tagades võimaluse harva kokku puutuda.

Küsimustes, mis on seotud kõikide osalistega, tasub rääkida isiklikult, arutada olukorda, uurida, kas nad näevad sel juhul probleemi, ja küsida, millised on nende arvates lahendusvõimalused, ning tagada nende osalus otsuste tegemisel.

Tööpoliitika optimeerimise aspektist (keskmise perspektiivi puhul, millest ma rääkisin) ei saa siin palju teha, ainus võimalus optimeerimiseks on arvestada ühilduvust factorit meeskonna moodustamisel ja mitte panna kokku inimesi, kes võivad konflikte tekitada.

Meeskonnakultuuri seisukohalt esinevad sellised olukorrad palju harvemini rikka kultuuriga meeskondades, kus inimesed respekteerivad oma tiimi ja kolleege ning suudavad küsimused iseseisvalt lahendada. Lisaks lahendatakse sellised konfliktid palju lihtsamalt (tihti automaatselt) meeskondades, kus on kõrge usaldusväärsuse tase, inimesed on pikka aega koos töötanud ja/või suhtlevad sageli väljaspool tööd.

Tööalaste küsimustega seotud konfliktid:

Sellised konfliktid on tavaliselt põhjustatud mõlemast tegurist korraga: emotsionaalsest (kui mõni osaleja ei ole täiskasvanu positsioonil) ja tööprotsessi puudustest. Kõige sagedasem konfliktitüüp, millega olen kokku puutunud, on konfliktid koodireviie või arhitektuuri arutelu käigus arendajate vahel.

Räägiksin siin kahest tüüpilisest olukorrast:

1) Esimeses olukorras ei suuda arendaja saada koodireviid oma kolleegilt. Patch on saadetud reviile, kuid midagi ei toimu. Esmapilgul ei tundu, et kahe osapoole vahel oleks avatud konflikti, kuid süvenedes on see täiesti konflikt. Tööaline küsimus ei lahene, üks osapool (revii ootav) tunneb selgelt ebamugavust. Ekstreemne vorm sellisest olukorrast on arendamine kogukonnas või erinevates meeskondades, kus reviier võib olla mitte huvitatud just sellest konkreetsest koodist, kuna tal on liiga palju tööd või muudel asjaoludel ei pruugi ta tähelepanu pöörata reviiküsitlusele ning välise vahemehe (kelle ülesanne on mõlema osapoole jaoks) ei pruugi üldse olla.

Lähtekoht, mis aitab selliste olukordade lahendamisel, on pigem pikaajaline, küpse inimese kultuur. Esiteks tuleb rakendada mõistlikku aktiivsust. Ei tasu loota, et ülevaatusele pandud kood tõmbab ülevaataja tähelepanu iseenesest. Tuleb aidata ülevaatajal seda märgata. Pinguta paar inimest, küsi tõstatatud küsimusi, osale aruteludes. Ilmselgelt võib tüütus rohkem kahju teha kui kasu, seepärast tasub kasutada hea sensoone. Teiseks, hästi toimib ettevalmistamine. Kui meeskond mõistab, mis ja miks toimub, miks see kood üldse vajalik on, ning disain on eelnevalt arutletud ja kooskõlastatud, pööravad inimesed sellisele koodile tõenäolisemalt tähelepanu ja võtavad selle kasutusele. Kolmandaks, autoriteet mängib suurt rolli. Kui soovid, et sind ülevaatetaks – tee ise palju ülevaateid. Tee kvaliteetseid ülevaateid, tõeliste kontrollide, reaalse testimise ja kasulike kommentaaridega. Kui su hüüdnimi on meeskonnas tuntud heas valguses, on rohkem võimalusi, et su koodile tähelepanu pööratakse.

Tööpoliitika seisukohalt on siinkohal võimalikud täiustused õige prioriteetide seadmine, mille eesmärk on aidata arendajal saavutada oma ja meeskonna eesmärke (teiste ülevaatamine, kogukonnas kirjade kirjutamine, koodi toetamine arhitektuuri, dokumentatsiooni ja testidega, osalemine kogukonna aruteludes jne), mitte lubada patšide liiga pikka seismist järjekorras, ja nii edasi.

2) Teine levinud juhtum konfliktide tekkes koodi või disaini ülevaatamisel on erinevad arvamused tehniliste küsimuste, koodimisstiili ja tööriistade valiku osas. Usaldustase osalejate vahel, kuuluvus samasse meeskonda ja ühiselt töötamise kogemus on selle juures äärmiselt olulised. Takistus tekib siis, kui mõni osalejatest võtab lapsiku positsiooni ning ei püüa kuulata, mida vestluspartner talle öelda tahab. Sageli võivad mõlemad lähenemised, nii algne kui teise osapoole pakutud, edukalt toimida ja pole põhimõtteliselt oluline, milline neist valida.

Kordagi programmist minu meeskonnast (ütleme, et ta on Pasha) valmistas ette patši pakettide juurutamise süsteemi muudatustega, mida arendasid ja toetasid kolleegid naabruses asuvast osakonnast. Ühel neist (Igor) oli oma tugev arvamus, kuidas täpselt seadeid Linuxis pakettide juurutamisel konfigureerida. See arvamus erines patšis pakutud lähenemisviisist ning nad ei suutnud kokku leppida. Nagu tavaliselt, ajasid tähtaegade piirangud neid lõksu ning oli vaja leida mingi lahendus, keegi neist pidi võtma täiskasvanu positsiooni. Pasha tunnustas, et mõlemal lähteviisil on õigust elule, kuid ta soovis, et tema variant saaks heakskiidu, kuna ei olnud selgeid tehnilisi eeliseid ühegi variandi jaoks.

Meie arutelu nägi välja umbes nii (muidugi, see oli üsna skeemiline, tegelik vestlus kestis pool tundi):

— Pasha, meil on paar päeva ülejäänud enne funktsioonide külmutamist. On oluline, et me kõik kokku koguksime ja testimise võimalikult kiiresti alustaksime. Kuidas me saame Igorist mööda minna?
— Ta tahab seadmeid teistmoodi konfigureerida, on seal mulle kommentaare maha pannud…
— Ja mis seal, suured muudatused, palju vaeva?
— Ei, seal on paar tundi tööd, aga lõppkokkuvõttes pole ju mingit vahet, nii nagu nii töötab, miks see vajalik on? Ma tegin töötava asja, võtame selle vastu.
— Kuule, kui kaua te seda arutate?
— Jah, me oleme juba poolteist nädalat kinni.
— Em… me saame paar tunni jooksul lahendada küsimuse, mis on juba poolteist nädalat kestnud, ja me ei tee seda?
— Nojah, aga ma ei taha, et Igor arvan, et ma alla andsin…
— Kuule, mis on sulle endale tähtsam, kas lasta välja versioon koos sinu lahendusega või ajada Igor maha? Saame ajada, aga siis on tõeline oht, et läheme versiooniga kiirustades pekki.
— No… see oleks muidugi lahe, Igorile nina näkku pühkida, aga olgu, versioon on tähtsam, ma nõustun.
— Kas sulle tõeliselt oluline, mida Igor mõtleb? Ausalt öeldes, teda see ei huvita, ta tahab lihtsalt ühtset lähenemist erinevates kohtades sellele asjale, mille eest ta vastutab.
— Noh, ok, las ma teen nii, nagu ta kommentaarides palus, ja alustame testimist.
— Aitäh, Pasha! Mul oli kindel tunne, et teist kahest oled sina küpsem, kuigi Igor on sinust vanem :)

Küsimus lahendatud, väljaanne ilmus tähtajaks, Pasha ei olnud eriti rahulolematu, kuna ta ise pakkus lahendust ja tegi selle teoks. Igor oli üldiselt rahul, kuna tema arvamust arvestati ja tehti nii, nagu ta soovitas.

Teine sarnase konflikti liik on valik tehniliste lahenduste/raamatukogude/meetodite vahel projektis, eriti jaotatud meeskonnas. Ühes projektis, mida reklaamiti kui C/C++ kasutavat, osutus lõpuks, et projekti tehniline juhtimine on kategooriliselt vastu STL (Standard Template Library) kasutamisele. See on keele standardne raamatukogu, mis lihtsustab arendust ning meie meeskond oli sellega väga harjunud. Selgus, et projekt on palju lähemal C-le kui C++-le, mis ei olnud meeskonnale just inspireeriv, kuna juhtkond oli kokku pannud tõeliselt ägedad C++ arendajad. Samal ajal töötasid Ameerika meeskonna liikmed, nii insenerid kui juhid, ettevõttes juba pikka aega, nad olid harjunud olemasoleva olukorraga ja kõik oli nende jaoks okei. Venemaa meeskond koguti kokku alles hiljuti, vaid paar nädalat enne (sealhulgas mind). Venemaa meeskond ei soovinud kategooriliselt loobuda oma harjumuspärasest arendusmeest.

Alustasid lõputud kirjalikud arutelud kahe mandri vahel, kirjad kolme-nelja ekraani pikkune lendasid edasi-tagasi, grupi ja isiklike postitustega, programmeerijatelt - programmeerijatele ja juhtidele. Nagu tavaliselt, ei lugenud selliseid kirju keegi peale autorite ja nende innukate pooldajate. Vestlused krigisesid pingest, edastades eri suundades mitme ekraani mõtteid STL tehniliste eeliste kohta, kui hästi see on testitud, kui ohutu see on, ja üldiselt, kui ilus on elu selle kasutamisel ja kui hirmus ilma selleta.

See all this took quite a long time until I finally realized that we were discussing the technical aspects while the real problem wasn't technical at all. The issue isn't about the merits or demerits of STL or the complexity of working without it. Rather, the problem is organizational. We simply needed to understand how the company we were working for was structured. None of us had experience working in such a company before. The fact was that after developing the code and releasing it to production, support was handled by completely different people from other teams, from other countries. This huge engineering team of several tens of thousands of engineers (in total) could only afford a very basic minimum of technical means, so to speak, the minimum of the minimum. Everything that went beyond the engineering standard established in the company could not be supported later on. The level of the team is determined by the level of its weakest members. After we understood the real motivation of the actions of the American part of the team, this issue was removed from the agenda, and together we successfully developed and released the product using the standards adopted in the company. In this case, emails and chats worked poorly; it took several trips and a lot of face-to-face communication to come to a common denominator.

From the perspective of the workflow, in this particular case, having a description of the tools used, requirements for them, limitations on adding new ones, and the justification for such limitations would have been helpful. Such documents roughly correspond to those described in the sections of the Reuse Strategy and Development Environment of the 'Manager’s Handbook for Software Development', developed in NASA. Despite its age, it describes all the main activities and stages of planning software development of this kind very well. Having such documents greatly simplifies the discussion process regarding which components and approaches can be used in the product and why.

From the cultural perspective, obviously, with a more mature stance, where the parties try to hear and understand the real motivations behind their colleagues' actions and act based on project and team priorities rather than personal ego, the conflict would have been resolved more easily and quickly.

Teises konfliktis seoses tehnilise lahenduse valikuga kulus mul samuti märkimisväärselt aega, et mõista ühe poole motivatsiooni (juhtum oli tõeliselt ebatavaline), kuid kui motivatsioon oli selge, siis lahendus oli ilmselge.

Olukord on selline: meeskonnas, kus on umbes 20 inimest, liitub uus arendaja, kutsume teda Staseks. Meie standardne suhtlusvahend meeskonnas oli tol ajal Skype. Kuidas hiljem selgus, oli Stas suur avatud standardite ja avatud tarkvara fänn ning kasutas ainult tööriistu ja operatsioonisüsteeme, mille allikakood on avalikult kergesti kättesaadav ja mis kasutavad avalikult kirja pandud protokolle. Skype ei kuulu selliste tööriistade hulka. Kulutasime tohutult aega selle lähenemise eeliste ja puuduste arutamisele, Skype'i analoogide käivitamise katsetele erinevates operatsioonisüsteemides, Stasele meeskonda teise standardisse ülemineku veenmise katsetele, talle isiklikele e-kirjade saatmisele, isiklikele kõnede tegemise katsetele, talle teise arvuti ostmisele spetsiaalselt Skype'i jaoks jne. Lõpuks mõistsin, et see probleem ei olnud tegelikult mitte tehniline, mitte korralduslik, vaid pigem maailmavaateline, võiks isegi öelda, et religioosne (Stase jaoks). Isegi kui me lõpuks ühendasime Stase ja Skype'i (milleks läks juba mitu kuud), tekiks probleem järgneva tööriistaga uuesti. Mul ei olnud tegelikult vahendeid Stase maailmavaate muutmiseks ja ei olnud aluseid proovida muuta ka meeskonna maailmavaadet, mis töötas selles keskkonnas suurepäraselt. Inimene ja ettevõte olid lihtsalt maailmavaate poolest ortogonaalsed. Taolistes olukordades on hea lahendus - korralduslik. Me viisin Stase teise meeskonda, kus ta sobis paremini.

Selle konflikti põhjus, minu arvates, tuleneb konkreetse inimese isikliku kultuuri (kellel on tugev arvamus, mis ei lase tal kompromisse teha) ja ettevõtte kultuuri mittesobivusest. Antud juhul on see muidugi juhtija eksimus. Alguses oli vale võtta teda sellisesse projekti. Stas lõpuks siirdus avatud tarkvara arendusprojekti ja edenes seal suurepäraselt.

Hea näide konfliktist, mis on põhjustatud samal ajal arendaja lapsemeelsest lähenemisest ja tööprotsessi puudustest — olukord, kus arendaja ja QA meeskond on erinevatel arusaamadel funktsiooni valmidusest, mis on QA-le edastatud, kuna ei olnud definition of done'i. Arendaja arvas, et piisab koodi kirjutamisest ja funktsiooni üleandmisest QA-le — seal nad saavad hakkama. Tõeliselt küps ja kogenud programmeerija, aga tal oli selline sisemine kvaliteedi lävend. QA polnud sellega nõus ja nõudis, et ta näitaks ja selgitaks, mida ta ise kontrollis, ning nad nõudsid testimistsenaariumi. Neil oli juba varem olnud probleeme selle arendaja funktsionaalsusega ja nad ei tahtnud enam aega raisata. Üldiselt olid nad õiged — funktsioon tõepoolest ei töötanud, sest ta ei kontrollinud koodi enne QA-le edastamist.

Selle olukorra lahendamiseks palusin tal näidata, et kõik tõesti töötab (see ei töötanud ja ta pidi selle parandama), rääkisime meeskonna ja QA-ga definition of done'ist (me ei teinud seda kirjalikuks, kuna ei tahtnud protsessi liiga bürokraatlikuks muuta), ning peagi lahkusime selle spetsialistiga (ülevaateks oli see kogu meeskonnale kergendav).

Tööprotsessi vaatenurgast on võimalikud parandused antud juhul — definition of done'i olemasolu, nõuded iga funktsiooni toetamiseks unit- ja integratsioonitestidega, arendaja läbiviidud testimise kirjeldus. Ühes projektis mõõtsime testidega koodikatvust CI ajal ja juhul, kui katvus pärast patši lisamist langes, märgiti testid ebaõnnestunuks, st uue koodi lisamine oli võimalik ainult siis, kui sellele olid olemas uued testid.

Veel tavaline konflikt, mis on tihedalt seotud tööprotsessi korraldamisega. Meil on toode, tootearendusmeeskond, tugimeeskond ja klient. Klientidel on toote suhtes probleeme ning nad pöörduvad toetuse poole. Tugi analüüsib probleemi ja mõistab, et probleem on tootes, ning edastab probleemi tootemeeskonnale. Tootemeeskonnal on tihe aeg, versioon on peagi väljas, seega jääb kliendi probleemipilet arendaja seas kadunuks ja ripub nädalate viisi tähelepanuta. Tugi arvab, et arendaja töötab kliendi probleemiga. Klient ootab ja loodab, et tema probleemiga tegeletakse. Tegelikult ei toimu midagi. Mõne nädala pärast otsustab klient lõpuks uurida edusamme ja küsib toelt, kuidas läheb. Tugi küsib arenduse käest. Arendaja ehmatab, vaatab probleemipiletite nimekirja ja leiab sealt kliendi pilet. Klientide piletit lugedes mõistab ta, et probleemi lahendamiseks pole piisavalt teavet ja tal on vaja veel logisid ja mälupilte. Tugi küsib kliendilt täiendavat teavet. Ja siis mõistab klient, et tema probleemiga ei ole keegi selle aja jooksul töötanud. Ja mürin kohiseb ...

Selles olukorras on konflikti lahendus üsna selge ja lineaarne (toote parandamine, dokumentatsiooni ja testide uuendamine, kliendi rahustamine, kiirparanduse väljalaskmine jne). Oluline on analüüsida tööprotsessi ja mõista, kes vastutab kahe meeskonna vahekorra korraldamise eest, miks selline olukord üldse võimalikuks sai. Selge on, et protsessi tuleb midagi parandada — keegi peaks jälgima üldpilti ilma klientide meeldetuletusteta, proaktiivselt. Klientide piletid peaksid eristuma arendajate teiste probleemipiletite seas. Tugi peaks nägema, kas arendus töötab nende piletite kallal hetkel, kui ei — millal saavad nad tööle hakata, millal oodata tulemusi. Tugi ja arendus peaksid aeg-ajalt suhtlema ning arutama piletite staatust, vajaliku teabe kogumine silumisteks peaks olema maksimaalselt automatiseeritud jne.

Nii nagu sõda, üritab vastane lüüa kahe üksuse vahelt, on ka töös tavaliselt kõige õrnem ja haavatavam koht meeskondade vaheline koostöö. Kui tugimeeskonna ja arendajate juhid on piisavalt küpsed, suudavad nad protsessi ise parandada; kui ei, siis jätkab protsess konfliktide ja probleemide genereerimist, kuni sekkub juht, kes olukorra lahendab.

Teine iseloomulik näide, mida olen erinevates ettevõtetes korduvalt kohanud, on olukord, kus toote arendamine toimub ühe meeskonna poolt, automaatsete integratsioonitestide loomiseks on teine meeskond ja infrastruktuuri haldab kolmas meeskond. Testide käitamisel tekivad pidevalt probleemid, mille põhjuseks võivad olla nii toode kui ka testid ja infrastruktuur. Probleemiks on sageli leppida kokku, kes peaks esialgse probleemianalüüsi tegema, vead registreerima, toote, testide ja infrastruktuuri logisid analüüsima jne. Konfliktid on siin üsna tavalised ja samas ühtsed. Suure emotsionaalse pingega olukordades liikuvad osalised sageli lapsepõlve seisundisse ja arutelud muutuvad selliseks: “miks ma pean sellega tegelema”, “neil juhtub sagedamini rikkeid” jne.

Tööprotsessi vaatenurgast sõltuvad konkreetsed sammud probleemi lahendamiseks meeskondade koosseisust, testide tüübist ja tootest jne. Ühes projektis kehtestasime perioodilised vahetused, kus meeskonnad jälgisid testide käiku vaheldumisi, nädal kaupa. Teises projektis tegid esialgse analüüsi alati testide arendajad, kuid analüüs oli üsna põhiline ja toode oli piisavalt stabiilne, nii et see toimis hästi. Peamine on tagada protsessi läbipaistvus, selged ootused kõigile osalistele ja õiglane olukorra tunne kõigi jaoks.

Kas konflikt organisatsioonis on probleem? Kas on halb märk, et teie meeskonnas tekivad konfliktid sageli (või lihtsalt perioodiliselt)? Üldiselt mitte, kuna kui toimub kasv, areng ja mingit tüüpi dünaamika, kerkivad küsimused, mis pole kunagi varem lahendatud, ning nende lahendamisel võivad tekkida konfliktid. See on näitaja, et mingitele valdkondadele tuleks tähelepanu pöörata ja et on arenguvõimalusi. Halb on see, kui konfliktid tekivad liiga sageli ja neid on keeruline või aeganõudev lahendada. See on tõenäoliselt märk piisavalt talitsetud tööprotsesside ja meeskonna küpsuse puudumisest.

Allikas: habr.com