Meeskonna konfliktide juhtimine – tasakaal või hädavajadus?

Epigraaf:
Kordagi metsas kohtusid Siiliku ja Karupoeg.
— Tere, Siiliku!
— Tere, Karupoeg!
Nii, sõna sõna juurde, nalja nalja kõrvale ja Siiliku sai Karupoja käest pihta ...

Allpool on meie tiimijuhi ja RAS toote arendusdirektori — Igor Marnati mõtteid tööalaste konfliktide iseloomust ning võimalikest juhtimismeetoditest.

Enamik tööalaseid konflikte, millega me silmitsi seisame, areneb sarnaselt ülaltoodud epigraafis kirjeldatule. Osalised, kes algselt suhtuvad üksteisesse üsna sõbralikult, püüavad lahendada mingit küsimust, kuid lõpuks jääb probleem lahendamata ja osalistevahelised suhted näiliselt halvenevad.

Elu on mitmekesine; eespool kirjeldatud stsenaariumis esineb variatsioone. Mõnikord on osaliste vahel alusetult halvad suhted, mõnikord ei ole küsimust, mis vajaks vahetut lahendamist (nagu näiteks epigraafis), mõnikord jäävad suhted pärast arutelu samaks, mis olid enne, kuid küsimus jääb siiski lahendamata.

Millised on ühised jooned kõikides olukordades, mida võib määratleda kui töökontakti olukord?



Esiteks on olemas kaks või enam osapoolt. Need osapooled võivad olla erinevates positsioonides organisatsioonis, olla omavahelises suhetes võrdsed (meeskonnakaaslased) või asuda erinevatel hierarhiatasanditel (ülem - alluv), olla individuaalsed (töötaja) või grupiviisilised (juhtudel, kus konflikt on töötaja ja meeskonna või kahe meeskonna vahel) jne. Konflikti tõenäosusele ja selle lahendamise lihtsusele avaldab suurt mõju osaliste vaheline usaldustase. Mida paremini osalised üksteist tunnevad ja mida kõrgem on usaldustase, seda suurem on võimalus, et nad saavad omavahel kokkuleppele. Näiteks hajutatud meeskonna töötajad, kes ei ole kunagi isiklikult kohtunud, satuvad tõenäolisemalt konfliktsesse olukorda lihtsa tööküsimuse lahendamisel kui inimesed, kes on vähemalt paar korda isiklikult kohtunud. Seetõttu on hajutatud meeskondades töötades äärmiselt oluline tagada, et kõik meeskonna liikmed saaksid regulaarselt omavahel isiklikult kokku.

Teiseks, konfliktide korral tööl on osalised olukorras, kus nad peavad lahendama küsimuse, mis on oluline ühe või mõlema osapoole ning kogu organisatsiooni jaoks. Sellisel juhul, olukorra spetsiifika tõttu, on osalistel tavaliselt piisavalt aega ja erinevaid viise probleemi lahendamiseks (formaalsed, mitteformaalsed, kohtumised, kirjad, juhtkonna otsused, meeskonna eesmärkide ja plaanide olemasolu, hierarhia olemasolu jne). See eristab olukorda tööalase (või mitte-tööalase) küsimuse lahendamisest organisatsioonis näiteks tänaval, kus esitatakse tähtis küsimus: "Hei, kutid, millisest piirkonnast te olete?!" või eelmainitud konflikti korral. Tööalase küsimuse lahendamisel on oluline tööprotsessi kvaliteet ja küsimuste lahendamise kultuur meeskonnas.

Kolmandaks on meie arutelu seisukohalt konfliktis määravaks teguriks asjaolu, et osalised ei suuda iseseisvalt leida lahendust, mis rahuldaks kõiki pooli. See olukord nõuab kolmanda osapoole, välist arbitraatori sekkumist. See punkt võib tunduda vastuoluline, kuid põhimõtteliselt, kui konfliktne olukord suudetakse edukalt lahendada ilma välist arbitraatorit kaasamata, on küsimus edukalt lahendatud ja poolte suhted ei ole halvenenud. Sellest konfliktist me ilmselt isegi ei kuule või saame teada juhuslikult pärast selle lahendamist. Mida rohkem küsimusi meeskond suudab iseseisvalt lahendada, seda efektiivsemalt ta töötab.

Veel üks konflikti iseloomulik joon, millega tasub tegeleda, on emotsionaalse pinge tase lahendamisel. Konflikt ei pruugi olla seotud kõrge emotsionaalse intensiivsusega. Osalejad ei pea kindlasti karjuma ja kätega vehkima, et olukord oleks sisuliselt konfliktne. Küsimus ei lahene, teatud emotsionaalne pinget on siiski kohal (võib-olla ei avaldu see väliselt selgelt), seega on meil tegemist konfliktolukorraga.

Kas peaks üldiselt sekkuma konfliktsetesse olukordadesse või on parem lasta neil iseenesest lahendada ja oodata, kuni probleem ise kaob? Peab. Ei ole alati teie võimuses ega pädevuses konflikti täielikult lahendada, kuid igas olukorras, sõltumata konflikti suurusest, saate võtta täiskasvanu positsiooni, tuues sellega kaasa veel paar inimest enda ümber, leevendada konflikti negatiivseid tagajärgi ja soodustada selle lahendamist.

Enne kui vaatame mitmeid konfliktsete olukordade näiteid, peatume mõnel olulisel hetkel, mis on ühised kõigile konfliktidele.

Konflikti lahendamisel on oluline püsida olukorra kõrgemal tasemel, mitte laskuda vaidlusesse (seda kutsutakse ka „metakoha võtmiseks“), ehk siis mitte sattuda lahendamise protsessi ühepoolseks osaliseks. Vastasel juhul muutute olema pigem ühe poole toetuseks, mis ainult süvendab vaidlust teise poole kahjuks. Otsuste tegemisel on oluline, et see oleks moraalselt aktsepteeritud kõigi osapoolte poolt, nagu öeldakse, "ostetud". Küll isegi siis, kui pooled ei olnud rahul tehtud otsusega, peaksid nad siiski olema siiralt nõus selle täitmisega. Teisisõnu, olema valmis erimeelsusi väljendama ja samas järgima. Muidu konflikt lihtsalt muutub vormi, hõõguv tuli jääb turvastikku ja mingil hetkel põleb see kindlasti uuesti.

Teine punkt, mis on osaliselt seotud esimesega — kui olete juba otsustanud osaleda konflikti lahendamises, võtke seda äärmiselt tõsiselt suhtlemise ja konteksti mõistmise seisukohalt. Rääkige isiklikult iga poolega. Eristi, alustuseks. Ära piirduma e-kirjaga. Jaotatud meeskonna korral rääkige vähemalt videokõne teel. Ära rahuldu kuulujuttudega ega tunnistajate ütlustega. Mõista, milline on iga poole lugu, mida nad tahavad, miks nad seda soovivad, mida nad ootavad, kas nad on seda küsimust varem proovinud lahendada, mis juhtub, kui see ei lahene, milliseid lahendusvõimalusi nad näevad, kuidas nad teise poole seisukohta kujutavad, mis nende arvates on õige või vale jne. Laadige oma pähe kogu võimalik kontekst, erapooletult, eeldades, et kõik on õiged. Te ei ole konfliktis sees, te olete sellest väljaspool, meta-positsioonis. Kui kontekst on kättesaadav ainult e-posti ahelas — loe vähemalt see tervikuna läbi ja seotud arutlused ja dokumendid. Pärast lugemist — räägi ikkagi häälega. Peaaegu garanteeritult kuulete midagi olulist, mida e-kirjadest ei leidu.

Kolmas oluline punkt on üldine suhtlemine. Need on tavalised asjad, mitte midagi erakordset, kuid neil on suur mõju. Me ei püüa aega säästa, räägime kõigi osalistega, kritiseerime mitte inimest, vaid vaatleme tema tegevuste tagajärgi (mitte "sa oled ebaviisakas", vaid "võib-olla, et inimesed võivad selle üle ära minna"), anname võimaluse säilitada nägu ning oma arutelud viime läbi isiklikult, mitte avalikult.

Konfliktide põhjused on tavaliselt seotud ühe kahe põhjusega. Esimene on seotud sellega, kas inimene on konflikti hetkel täiskasvanu või lapse positsioonis (sellega seoses räägime allpool). See on seotud tema emotsionaalse küpsuse ja suutlikkuse võimega oma emotsioone juhtida (mis, muide, ei pruugi üldse alati olla seotud tema vanusega). Teine levinud põhjus on tööprotsessi ebatäiuslikkus, mis loob halli tsooni olukordi, kus vastutus on jagatud osaliste vahel, osaliste ootused ei ole üksteisele selged ning rollid on protsessis hägused.

Seetõttu peab konfliktide (nagu ka muude küsimuste) lahendamisel juht arvestama kolme perspektiiviga: lühiajaline — probleem või konflikt lahendatakse kohe, keskpärane — minimeerida sarnaste konfliktide tekkimise tõenäosust, ja pikaajaline — meeskonnas küpse kultuuri arendamine.

Igas meis on sisemine laps, umbes kolme-nelja aastane. Suurema osa ajast magab ta tööl, kuid mõnikord ärkab ja võtab juhtimise enda kätte. Lapsel on oma prioriteedid. Tema jaoks on oluline nõuda, et see on tema liivakast, ema armastab teda rohkem, tema mänguauto on kõige parem (disain on parim, ta programmeerib paremini, …). Konfliktsituatsioonis võib laps oma mänguasju tugevalt hoida, jalgadega trampida ja labidaga lõhkuda, kuid ta ei suuda täiskasvanute küsimusi lahendada (lahenduse arhitektuur, automatiseerimise testimise lähenemised, tähtajad jne), ta ei mõtle meeskonnale kasulike asjade peale. Lapsi konfliktis võib julgustada, lohutada ja saata magama, paludes tal kutsuda oma täiskasvanu. Enne arutelu alustamist konflikti tingimustes veenduge, et te räägite praegu täiskasvanuga, mitte lapsiga, ja et olete ise täiskasvanu positsioonil. Kui teie aus eesmärk praegu on tõsise küsimuse lahendamine, olete täiskasvanu positsioonil. Kui teie eesmärk on jalgadega trampida ja labidaga lõhkuda - see on lapse positsioon. Saatke oma sisemine laps magama ja kutsuge täiskasvanu, või edasilükake arutelu. Inimene teeb emotsionaalse otsuse ja seejärel otsib sellele ratsionaalset õigustust. Otsus, mille teeb laps, lähtudes laste prioriteetidest, ei ole optimaalne.

Lisaks konfliktikäitumisele iseloomustab laste või täiskasvanute positsiooni ka vastutuse tase, mille inimene on valmis enda peale võtma. Ekstreemsetes ilmingutes näeb programmeerija laste positsioon, mida olen korduvalt kohanud, välja nii: ma kirjutasin koodi, saatsin selle ülevaatamiseks — minu töö on lõpetatud. Ülevaatajad peavad selle üle vaatama ja ühendama, QA peab selle kontrollima, kui esinevad probleemid — nad teavitavad mind. Kuidas kummaline, isegi üsna vanad ja kogenud inimesed käituvad mõnikord sarnaselt. Teine äärmus on, et inimene peab end vastutavaks selle eest, et tema kood töötaks, oleks katnud testidega, oleks isiklikult kontrollitud, edukalt läbinud ülevaatamise (vajadusel pole probleemi ülevaatajate täiendavaid küsimusi arutada) ja oleks ühendatud, QA abi osutatakse vajadusel, testimise stsenaariumid on kirjeldatud jne. Normaalsetes tingimustes on programmeerija kas algselt lähemal täiskasvanule või liigub sinna koos kogemuse kasvuga (tingimusel, et meeskonnas kultiveeritakse õiglast kultuuri). Ekstreemsetes olukordades jätkab ta tavaliselt laste positsiooni omamist, mistõttu tekivad tal ja meeskonnal perioodiliselt probleemid ja konfliktid.

Meeskonna õige ja küpse kultuuri kasvatamine on iga juhi oluline ülesanne. See nõuab pikka aega ja iga päev pingutusi, kuid tulemus on seda väärt. Meeskonna kultuuri mõjutamiseks on kaks viisi — isiklik eeskuju (millele järgitakse kindlasti, sest meeskond vaatab alati liidri poole) ning arutelud ja õige käitumise edendamine. Siin pole samuti midagi keerulist ega eriliselt formaalset: probleemide arutamisel märkige, kuidas oleks saanud teisiti tegutseda, rõhutage, kui olete märganud, et probleem lahendati õigesti, kiitke ning tooge välja releasi ülevaatuses jne.

Käsitleme mitmeid tüüpilisi konfliktseid olukordi, lihtsast keeruliseni:

Töötamisega mitte seotud konfliktid

Tööl esinevad üsna tihti konfliktid, mis ei ole seotud tööalaste probleemidega. Nende tekkimine ja lihtsus lahendamisel on tavaliselt otseselt seotud osalejate emotsionaalse intelligentsuse ja küpsuse tasemega ning ei ole seotud tööprotsessi täiuslikkuse või puudulikkusega.

Tüüpilised näited — keegi ei kasuta piisavalt sageli pesumasinat või duši all käimist, mis häirib teisi, mõni meesterahvas tunneb end kitsas ruumis, kui aken on avatud, üks inimene teeb liiga palju lärmi, samas kui teised vajavad vaikust tööks, ja nii edasi. Selliste konfliktide lahendamisega ei tohiks venitada ega lasta olukorral iseenesest areneda. Need ei lahene iseenesest ja häirivad igapäevaselt tööd ning mürgitavad meeskonna õhkkonda. Õnneks on nende lahendamine tavaliselt lihtne — piisab, kui rääkida rahulikult (muidugi silmast silma) kolleegiga, kes ei jälgi hügieeni, tagada mugav istumisasetus neile, kes hindavad vaikust/jahedust, osta helisummutavad kõrvaklapid või paigutada vaheseinad jne.

Teine näide, millega olen oma töös mitmel korral kokku puutunud, on meeskonnaliikmete psühholoogiline ühilduvus. Mingil põhjusel ei saa inimesed lihtsalt koos töötada; iga suhtlus lõppeb skandaaliga. Mõnikord on see seotud sellega, et inimesed peavad kinni polariseeritud arvamustest mõne tulise küsimuse osas (tavaliselt poliitilise) ega suuda neid töö väliselt järel jätta. Nende veenmine taluma üksteist või oma käitumist muutma on pigem lootusetu tegevus. Ainus erand, millega olen kokku puutunud, on noored kolleegid, kellel on avatud mõtlemine; nende käitumist on veel võimalik järk-järgult muuta perioodiliste vestlustega. Tavaliselt lahendatakse see probleem edukalt, jagades nad erinevatesse meeskondadesse või, vähemalt, tagades võimaluse väga harva omavahel kokku puutuda.

Kõikides nimetatud olukordades peaks iga osalejaga rääkima isiklikult, arutama olukorda, huvi tundma, kas nad näevad iseenesest probleemina, küsima, millised on nende arvates lahendused, ja tagama nende kaasamise selle otsuse vastuvõtmisse.

Töötasandi optimeerimise seisukohalt (keskmise tähtajaga, millest ma rääkisin) ei ole siin palju parandada, ainus asi, mida optimeerida, on arvestada meeskonna koostööfaktorit ja mitte panna koos inimesi, kes võivad omavahel konflikti sattuda.

Meeskonnakultuuri seisukohalt esinevad sellised olukorrad palju harvemini meeskondades, kus on küps kultuur, kus inimesed austavad üksteist ja suudavad küsimusi iseseisvalt lahendada. Lisaks sellele lahendatakse sellised konfliktid palju lihtsamalt (tihti automaatselt) meeskondades, kus on kõrge usaldus, inimesed on koos kaua töötanud ja/või suhtlevad sageli väljaspool tööd.

Tööalaste konfliktide tüübid:

Sellised konfliktid tulenevad tavaliselt mõlemast põhjusest korraga, nii emotsionaalsest (kui keegi osalejatest ei ole täiskasvanu positsioonil) kui ka tööprotsessi puudustest. Üks levinumaid konflikte, millega ma kokku olen puutunud, on konfliktid koodi ülevaatamise või arutelu käigus arendajate vahel.

Tõstaksin esile kaks tüüpilist juhtumit:

1) Esimesel juhul ei saa arendaja kolleegilt koodikontrolli. Patch on ülevaatamiseks saadetud ja midagi ei juhtu. Esmapilgul ei tundu kahe osapoole vahel ilmset konflikti olevat, kuid lähemalt vaadates tuleb see välja. Tööprobleem jääb lahendamata, üks osapool (ülevaadet oodates) tunneb selgelt ebamugavust. Ekstreemne variant sellest juhtumist on arendamine kogukonnas või erinevates meeskondades, kusjuures ülevaatajal ei pruugi olla huvi just selle konkreetse koodi vastu, kuna töökoormus või muud asjaolud võivad teda isegi ülevaatamise päringutele tähelepanu pööramast takistada, ning välist arbitraatori (ülema, kes mõlemale osapoolele ühine on) ei pruugi üldse olla.

Lahendus, mis aitab sellistes olukordades, lähtub pikaajalistest eesmärkidest ja küpsest kultuurist. Esiteks, mõistlik aktiivsus. Ei tasu oodata, et lihtsalt ülevaatusel riputatud kood köidab ülevaatajate tähelepanu iseenesest. Tuleb aidata ülevaatajatel seda märkama. Pinguta paar inimest, esita küsimus synkapi ajal, osale aruteludes. Loomulikult võib liialdamine pigem kahjulik olla, seega tasub kasutada tervet mõistust. Teiseks, eelnev ettevalmistus on väga tõhus. Kui meeskond mõistab, mis ja miks toimub ning miks see kood üldse vajalik on, arutatakse ja kooskõlastatakse disain eelnevalt kõigiga, siis on suurem tõenäosus, et inimesed märkavad sellist koodi ja aktsepteerivad selle töösse. Kolmandaks, autoriteet mängib rolli. Kui soovid, et sinu koodi vaadatakse üle, tegele ka ise aktiivselt ülevaatustega. Tee kvaliteetseid ülevaateid, koos reaalse kontrollimise, testimise ja kasulike kommentaaridega. Kui su nimi on meeskonnas tuntud headest külgedest, on suurem tõenäosus, et sinu koodile pööratakse tähelepanu.

Tööprotsessi seisukohalt on siinkohal võimalikud parandused — õigete prioriteetide seadmine, mis aitab arendajal saavutada enda ja meeskonna eesmärke (teisi üle vaadata, kirjutada kirju kogukonnale, toetada koodi arhitektuuri, dokumentatsiooni, testimise kirjeldamisega, osaleda aruteludes kogukonna liikmetega jne), vältides samaaegselt liiga pikaaja ootejärjekorra loomist ja nii edasi.

Teiseks levinud konfliktide puhul koodi või disaini ülevaatamisel on erinevad arusaamad tehnilistest küsimustest, kodeerimisstiilist ja tööriistade valikust. Siinkohal on usk osalejate vahel äärmiselt oluline, kuuluvus ühte meeskonda ja varasem koostöö kogemus. Pattide olukord tekib siis, kui mõni osalejatest võtab lapsiku positsiooni, mitte ei püüa aru saada, mida teine osaleja talle edastada soovib. Sageli võivad nii teise poole pakkunud lähenemine kui ka algselt pakutud lähenemine olla täiesti edukad ja pole olulist vahet, millist neist valida.

Kordagi ühes mu meeskonna arendajas (nimetame teda Pasha) valmistas ta paranduse pakettide juurutamise süsteemi, mida arendas ja toetas naabripoolse osakonna kolleegid. Ühel neist (Igoril) oli oma tugev arvamus selle kohta, kuidas täpselt Linuxi teenuseid seadistada pakettide juurutamisel. See arvamus erines paranduses pakutud lähenemisest ja nad ei suutnud kokku leppida. Nagu ikka, olid tähtajad lähenemas ja pidime leidma mingi lahenduse, keegi pidi võtma täiskasvanud positsiooni. Pasha tunnustas, et mõlemal lähenemisel on oma õigustused, kuid tal oli soov, et tema variant läheks läbi, kuna ühelgi variandil ei olnud selgeid tehnilisi eeliseid.

Meie arutelu nägi välja umbes nii (muidugi väga skeemaatiliselt, vestlus kestis pool tundi):

— Pasha, meil on paar päeva feature freeze. Oluline on, et me kõik kokku koguksime ja testimist võimalikult kiiresti alustada. Kuidas me saaksime Igorist üle käia?
— Ta tahab seadistada teenuseid teistmoodi, kommentaare sinna kleebitud …
— Kas seal on suured ümbertegemised, palju jamamist?
— Ei, seal on paar tundi tööd, aga lõpptulemuselt ei ole vahet, see toimib niikuinii, miks seda vaja on? Ma tegin toimiva asja, võtame selle vastu.
— Kuule, kui kaua te seda juba arutate?
— Oleme juba umbes poolteist nädalat selles kinni.
— Em ... me saame paari tunniga lahendada küsimuse, mis on juba poolteist nädalat kestnud, ja me ei tee seda?
— Noh, jah, aga ma ei taha, et Igor arvaks, et ma olen alla andnud ...
— Kuule, mis on sinu jaoks olulisem, väljaanne koos sinu lahenduse sees, või Igoriga võitlemine? Saame temaga võidelda, kuid siis on tõeliselt hea võimalus, et me jääme väljaandest ilma.
— Noh ... oleks muidugi äge, Igorile vastu vaadata, aga okei, väljaanne on olulisem, nõus.
— Kas sulle on tõeliselt nii tähtis, mida Igor arvab? Ausalt öeldes on tal sellest täiesti ükskõik, ta tahab lihtsalt ühtset lähenemist erinevates kohtades, mille eest ta vastutab.
— Okei, teen nii nagu ta kommentaarides palub ja alustame testimist.
— Aitäh, Pasha! Ma olin kindel, et teist kahest oled sina küpsem, kuigi Igor on sinust vanem :)

Küsimus sai lahendatud, väljaanne ilmus õigeaegselt, Pasha ei väljendanud erilist rahulolematust, sest ta ise pakkus lahenduse ja viis selle ellu. Igor oli üldiselt rahul, kuna tema arvamust arvestati ja tegid nii, nagu ta eelnevalt soovitas.

Teine sarnane konflikt, mis tõeliselt esindab, on valik tehniliste lahenduste/raamatukogude/lähtepunktide vahel projektis, eelkõige jaotatud meeskonnas. Ühes projektis, mis esitleb ennast C/C++-na, selgus lõpuks, et projekti tehniline juhtkond on STL (Standard Template Library) kasutamise vastu. See on keele standardne raamatukogu, mis lihtsustab arendust, meie meeskond on selle kasutamist väga harjunud. Selgus, et projekt on palju lähemal C-le kui C++-le, mis ei olnud meeskonda just eriti innustav, kuna juhtkond oli valinud tõeliselt heade C++-dearendajate. Samal ajal töötas Ameerika osa meeskonnast, nii insenerid kui ka juhid, ettevõttes juba pikka aega, nad olid harjunud olemasoleva olukorraga ning neid rahuldas see. Venemaa osa meeskonnast koondati kokku hoopis hiljuti, vaid paar nädalat tagasi (sh mina). Venemaa osa meeskonnast ei soovinud kategooriliselt loobuda oma traditsioonilisest lähenemisest arendusele.

Alustasid lõputud kirjalikud arutelud kahe manda vahel, kus kirjad, mis ulatusid kolme-nelja ekraanini, lendasid edasi-tagasi, nii grupikirjade kui isiklike kaudu, programmeerijate vahel — programmeerijatele ja juhtidele. Nagu tavaliselt juhtub, ei lugenud sellise suurusega kirju keegi peale autorite ja nende tulihingeliste toetajate. Vestlused krõbisesid pingest, edastades igas suunas mitmekesiseid mõtteid STL tehniliste eeliste kohta, kui hästi see on testitud, ohutu ning üldiselt, kui suurepärane on elu selle kasutamisel ja kui kohutav ilma selleta.

See oli üsna pikalt, kuni ma lõpuks aru sain, et arutame tehnilisi külgi, kuid probleem ei ole tegelikult tehniline. Probleem ei seisne STL hindamises või selle kasutamise keerukuses. Probleem on pigem organisatoriline. Meil oli lihtsalt vaja mõista, kuidas meie ettevõte töötab. Enne ei olnud kellelgi meist kogemust töötada sellises ettevõttes. Probleem seisnes selles, et koodi arendamise ja tootmisseviimise järel hooldasid seda täiesti teised inimesed teistest meeskondadest ja teistest riikidest. See tohutu inseneriteemade meeskond, kuhu kuulus mitu tuhat inseneri, suutis endale lubada vaid täiesti minimaalset tehniliste vahendite komplekti, nii öelda, minimum minimorum. Kõik, mis ületas ettevõttes kehtestatud inseneristandardi, ei saanud tulevikus füüsiliselt toetust. Meeskonna tase määratakse tema nõrgimate liikmete järgi. Pärast seda, kui me mõistsime, reaalset motivatsiooni Ameerika meeskonna tegevuste osas, see küsimus võeti päevakorrast ära ning me kõik koos suutsime edukalt arendada ja turule tuua toote, järgides ettevõttes kehtinud standardeid. Kirjad ja vestlused ei toiminud sel juhul hästi, et jõuda ühiselt kokkuleppele, nõudis see mitmeid reise ja palju isiklikku suhtlemist.

Tööprotsessi seisukohalt aitaks antud juhul olemasolu kirjeldus kasutatavatest vahenditest, nende nõudmistest, piirangud uute lisamisele ja põhjendused sellistele piirangutele. Sellised dokumendid vastavad umbes punktides kirjeldatule Reuse Strategy ja Development Environment juhendis „Manager’s Handbook for Software Development”, mis on koostatud NASA. Omal ajal kirjeldab see suurepäraselt kõiki peamisi tegevusi ja etappe sellise tarkvaraarenduse planeerimisel. Selliste dokumentide olemasolu lihtsustab oluliselt arutelu selle üle, milliseid komponente ja lähenemisi tootes võib kasutada ning miks.

Kultuuri seisukohalt on selge, et kui osalised püüavad kuulata ja mõista kolleegide tegude tegelikke motiveerivaid tegureid ning tegutsevad projekti ja meeskonna prioriteetide, mitte isikliku ego järgi, siis konflikti lahendamine oleks kergem ja kiirem.

Teises konfliktis seoses tehnilise lahenduse valikuga vajasin samuti märkimisväärset aega, et mõista ühe poole motivatsiooni (see juhtum oli väga ebatavaline), kuid pärast seda, kui motivatsioon selgeks sai, oli lahendus ilmne.

Olukord on selline: umbes 20 inimesest koosnevas meeskonnas tuleb uus arendaja, keda nimetame Stasiks. Meie selle hetke standardne suhtlemisinstrument meeskonnas oli Skype. Hiljem selgus, et Stas oli suur avatud standardite ja avatud lähtekoodiga tarkvara fänn, kasutades ainult selliseid tööriistu ja operatsioonisüsteeme, mille lähtekood on avalikult kergesti kättesaadav ja mis kasutavad avalikult kirjeldatud protokolle. Skype selliste tööriistade seas ei ole. Me kulutasime tohutult aega selle lähenemise eeliste ja puuduste arutamiseks, katsetes käivitada Skype'i analooge erinevates operatsioonisüsteemides, Stasi püüdel veenda meeskonda teistelt standarditele üle minema, kirjutada talle isiklikult e-kirju, helistada talle isiklikult telefoniga, osta talle teine arvuti spetsiaalselt Skype'i jaoks jne. Lõpuks arvasin, et see probleem ei ole tegelikult tehniline ega korralduslik, pigem on see maailmavaateline probleem, või isegi võib öelda, et religiooniline (Stasi jaoks). Isegi kui me lõpuks Stasi ja Skype'i ühendasime (milleks oli kulunud mitu kuud), tekkiks sama probleem järgmisel tööriistal uuesti. Mul ei olnud reaalset võimalust Stasi maailmavaadet muuta ja mul ei olnud põhjust püüda muuta meeskonna maailmavaadet, mis töötas selles keskkonnas suurepäraselt. Inimene ja ettevõte olid maailmavaateliselt lihtsalt ortogonaalsed. Taolistes olukordades on hea lahendus — korralduslik. Me liikusime Stasi teise meeskonda, kus ta oleks rohkem orgaaniline.

Probleemi põhjus on minu arvates seotud konkreetse inimese isikliku kultuuri ja ettevõtte kultuuri vahelise mittesobivusega (inimene, kellel on tugev arvamus, mis ei luba tal kompromisse teha). Sellisel juhul on see kahtlemata juhi viga. Alguses oli vale võtta ta sellise projekti peale. Stas kraadi lõppes avatud lähtekoodiga tarkvara arendusprojekti juurde ja ta edeneb seal suurepäraselt.

Hea näide konfliktist, mis on tekitatud samal ajal arendaja lapsemeelsest lähenemisest ja töökäigus esinevatest puudustest — olukord, kus arendajal ja QA meeskonnal on erinevad ootused funktsiooni valmiduse osas, mis on edastatud QA-le ilma definition of done'ita. Arendaja arvas, et piisab koodi kirjutamisest ja funktsiooni viskamisest QA-le — seal nad saavad ise hakkama. Ükskõik, et tegu oli üsna kogenud programmijaga, oli tal siiski madal kvaliteedi tõe piir. QA ei olnud sellega nõus ja nõudsid, et ta näitaks neile ja kirjeldaks, mida ta ise kontrollis, ning küsisid testimistestide stsenaariumi. Neil oli varem olnud probleeme selle arendaja funktsionaalsusega ning nad ei soovinud oma aega tarbetult raisata. Muide, nad olid õiged — funktsioon ei töötanud tõepoolest, koodi ei kontrollitud enne QA-le edastamist.

Selle olukorra lahendamiseks palusin tal näidata, et kõik tõesti töötab (see ei töötanud ning tal tuli see parandada), arutasime meeskonnaga ja QA-ga valmimise määratlemist (kirjalikuks see ei saanud, kuna ei soovinud protsessi liiga bürokraatlikuks muuta), ning selle spetsialistiga lahkusime peagi (üldise kergenduse mõttes).

Tööprotsessi seisukohalt on selles osas võimalikud parandused - valmimise määratlemise olemasolu, iga funktsiooni toetamise nõuded ühik- ja integratsioonitestidega, arendaja läbiviidud testimise kirjeldus. Ühes projektis mõõtsime testide katvust CI ajal ning juhul, kui katvus pärast patši lisamist langes, märgiti testid läbikukkumisena, st iga uut koodi võidi lisada ainult siis, kui selle jaoks olid olemas uued testid.

Veel levinum näide konfliktist, mis on tihedalt seotud töökorraldusega. Meil on toode, selle toote arendusmeeskond, tugiteenuste meeskond ja tellija. Tellijal tekivad toote osas probleemid, ta pöördub tugiteenuste poole. Tugiteenused analüüsivad probleemi ja mõistavad, et see on toote viga, edastades probleemi arendusmeeskonnale. Arendusmeeskonnal on kiire aeg, väljaanne läheneb, seega tellija probleemiga seotud pilet, mis on arendajale määratud, jääb nädalateks tähelepanuta teiste piletite keskele. Tugiteenused arvavad, et arendaja töötab tellija probleemi kallal. Tellija ootab ja loodab, et tema probleemiga tegeletakse. Tegelikult ei toimu midagi. Pärast mitmeid nädalaid otsustab tellija lõpuks pärida edusamme ja küsib tugiteenustelt, kuidas läheb. Tugiteenused küsivad arenduse käest. Arendaja sähvab, vaatab piletite loendit ja leiab sealt tellija pilet. Lugedes tellija piletit, mõistab ta, et probleemide lahendamiseks ei ole piisavalt teavet ning tal on vaja veel logisid ja dump'e. Tugiteenused küsivad tellijalt täiendavat teavet. Ja siis mõistab tellija, et keegi ei ole tema probleemiga vahepeal tegelenud. Ja äkki tabab äike ...

Selles olukorras on konflikti lahendamine üsna ilmne ja lineaarne (toote parandamine, dokumentatsiooni ja testide värskendamine, kliendi rahustamine, kiire paranduse väljaandmine jne). Oluline on analüüsida töövoogu ja mõista, kes vastutab kahe meeskonna koostöö korraldamise eest ja miks selline olukord üldse tekkis. On selge, et protsessis tuleb midagi parandada — keegi peaks ilma kliendi meeldetuletusteta jälgima üldpilti, olema proaktiivne. Kliendi piletid peaksid arendajate seas silma paistma. Toetamine peaks nägema, kas arendus töötab nende piletite kallal, ja kui ei, siis millal nad saavad alustada ja millal tulemusi oodata. Toetamine ja arendus peaksid perioodiliselt suhtlema ja arutama piletite staatust, vajalik teave tõrgete lahendamiseks peaks olema maksimaalselt automatiseeritud jne.

Nagu sõda, kus vastane üritab lüüa kahe üksuse vahelt, on ka töös kõige nõrgem ja haavatavam koht sageli tiimide vaheline suhtlemine. Kui tugija arendusjuhid on piisavalt küpsed, saavad nad protsessi iseseisvalt parandada; kui ei, siis jätkab protsess konfliktide ja probleemide genereerimist, kuni sekkub juht, kes suudab olukorda parandada.

Teine iseloomulik näide, millega olen kokku puutunud erinevates ettevõtetes, on olukord, kus ühe meeskonna poolt arendatud toode, automaatsete integratsioonitestide teostamine teise meeskonna poolt ja infrastruktuur, millel seda kõike töös hoitakse, on kolmanda meeskonna tõhustamisel. Testide läbiviimise käigus tekivad pidevalt probleemid, mille põhjuseks võivad olla nii toode kui ka testid ja infrastruktuur. Sageli on keeruline kokku leppida, kes peab tegema esmase probleemide analüüsi, järelvalvema vigu, analüüsima toote, testide ja infrastruktuuri logisid jne. Konfliktid on siin üsna sagedased ja samas ka kindlad. Kõrge emotsionaalse pinge korral kipuvad osalised sageli võtma laste positsioone, algavad arutelud stiilis: "miks ma pean sellega tegelema", "neil on sagedamini rikkeid" jne.

Tööprotsessist lähtudes sõltuvad konkreetsed sammud küsimuse lahendamiseks tiimide koosseisust, testide tüübist ja tootest jne. Ühes projektis kehtestasime perioodilised vahetused, mille käigus meeskonnad jälgisid teste vaheldumisi, nädalate kaupa. Teises projektis teostasid esialgse analüüsi alati testide arendajad, kuid see analüüs oli üsna põhjalik ja toode oli piisavalt stabiilne, seega töötas see sarnaselt hästi. Peamine on tagada protsessi läbipaistvus, ootuste selgus kõikide osaliste jaoks ja igaühe jaoks õiglane olukord.

Kas konflikt organisatsioonis tegelikult on probleem või on see halb märk, et teie meeskonnas tekivad konfliktid sageli (või lihtsalt perioodiliselt)? Üldiselt ei ole see nii, sest kui toimub kasv, areng ja mingit tüüpi dünaamika, siis tekivad küsimused, mida pole kunagi varem käsitletud, ning nende lahendamisel võivad tekkida konfliktid. See on märk sellest, et teatud valdkondadele tuleks rohkem tähelepanu pöörata ja et on parendamise kohti. Halb on see, kui konfliktid tekivad väga sageli ja neid on raske või pikk lahendada. See on tõenäoliselt märk halvasti välja töötatud tööprotsessidest ja meeskonna ebaküpsusest.

Allikas: habr.com