<\/a><\/noindex>Teiseks, konfliktide korral t\u00f6\u00f6l on osalised olukorras, kus nad peavad lahendama k\u00fcsimuse, mis on oluline \u00fche v\u00f5i m\u00f5lema osapoole ning kogu organisatsiooni jaoks. Sellisel juhul, olukorra spetsiifika t\u00f5ttu, on osalistel tavaliselt piisavalt aega ja erinevaid viise probleemi lahendamiseks (formaalsed, mitteformaalsed, kohtumised, kirjad, juhtkonna otsused, meeskonna eesm\u00e4rkide ja plaanide olemasolu, hierarhia olemasolu jne). See eristab olukorda t\u00f6\u00f6alase (v\u00f5i mitte-t\u00f6\u00f6alase) k\u00fcsimuse lahendamisest organisatsioonis n\u00e4iteks t\u00e4naval, kus esitatakse t\u00e4htis k\u00fcsimus: \"Hei, kutid, millisest piirkonnast te olete?!\" v\u00f5i eelmainitud konflikti korral. T\u00f6\u00f6alase k\u00fcsimuse lahendamisel on oluline t\u00f6\u00f6protsessi kvaliteet ja k\u00fcsimuste lahendamise kultuur meeskonnas.<\/p>\n
Kolmandaks on meie arutelu seisukohalt konfliktis m\u00e4\u00e4ravaks teguriks asjaolu, et osalised ei suuda iseseisvalt leida lahendust, mis rahuldaks k\u00f5iki pooli. See olukord n\u00f5uab kolmanda osapoole, v\u00e4list arbitraatori sekkumist. See punkt v\u00f5ib tunduda vastuoluline, kuid p\u00f5him\u00f5tteliselt, kui konfliktne olukord suudetakse edukalt lahendada ilma v\u00e4list arbitraatorit kaasamata, on k\u00fcsimus edukalt lahendatud ja poolte suhted ei ole halvenenud. Sellest konfliktist me ilmselt isegi ei kuule v\u00f5i saame teada juhuslikult p\u00e4rast selle lahendamist. Mida rohkem k\u00fcsimusi meeskond suudab iseseisvalt lahendada, seda efektiivsemalt ta t\u00f6\u00f6tab.<\/p>\n
Veel \u00fcks konflikti iseloomulik joon, millega tasub tegeleda, on emotsionaalse pinge tase lahendamisel. Konflikt ei pruugi olla seotud k\u00f5rge emotsionaalse intensiivsusega. Osalejad ei pea kindlasti karjuma ja k\u00e4tega vehkima, et olukord oleks sisuliselt konfliktne. K\u00fcsimus ei lahene, teatud emotsionaalne pinget on siiski kohal (v\u00f5ib-olla ei avaldu see v\u00e4liselt selgelt), seega on meil tegemist konfliktolukorraga.<\/p>\n
Kas peaks \u00fcldiselt sekkuma konfliktsetesse olukordadesse v\u00f5i on parem lasta neil iseenesest lahendada ja oodata, kuni probleem ise kaob? Peab. Ei ole alati teie v\u00f5imuses ega p\u00e4devuses konflikti t\u00e4ielikult lahendada, kuid igas olukorras, s\u00f5ltumata konflikti suurusest, saate v\u00f5tta t\u00e4iskasvanu positsiooni, tuues sellega kaasa veel paar inimest enda \u00fcmber, leevendada konflikti negatiivseid tagaj\u00e4rgi ja soodustada selle lahendamist.<\/p>\n
Enne kui vaatame mitmeid konfliktsete olukordade n\u00e4iteid, peatume m\u00f5nel olulisel hetkel, mis on \u00fchised k\u00f5igile konfliktidele.<\/p>\n
Konflikti lahendamisel on oluline p\u00fcsida olukorra k\u00f5rgemal tasemel, mitte laskuda vaidlusesse (seda kutsutakse ka \u201emetakoha v\u00f5tmiseks\u201c), ehk siis mitte sattuda lahendamise protsessi \u00fchepoolseks osaliseks. Vastasel juhul muutute olema pigem \u00fche poole toetuseks, mis ainult s\u00fcvendab vaidlust teise poole kahjuks. Otsuste tegemisel on oluline, et see oleks moraalselt aktsepteeritud k\u00f5igi osapoolte poolt, nagu \u00f6eldakse, \"ostetud\". K\u00fcll isegi siis, kui pooled ei olnud rahul tehtud otsusega, peaksid nad siiski olema siiralt n\u00f5us selle t\u00e4itmisega. Teisis\u00f5nu, olema valmis erimeelsusi v\u00e4ljendama ja samas j\u00e4rgima. Muidu konflikt lihtsalt muutub vormi, h\u00f5\u00f5guv tuli j\u00e4\u00e4b turvastikku ja mingil hetkel p\u00f5leb see kindlasti uuesti.<\/p>\n
Teine punkt, mis on osaliselt seotud esimesega \u2014 kui olete juba otsustanud osaleda konflikti lahendamises, v\u00f5tke seda \u00e4\u00e4rmiselt t\u00f5siselt suhtlemise ja konteksti m\u00f5istmise seisukohalt. R\u00e4\u00e4kige isiklikult iga poolega. Eristi, alustuseks. \u00c4ra piirduma e-kirjaga. Jaotatud meeskonna korral r\u00e4\u00e4kige v\u00e4hemalt videok\u00f5ne teel. \u00c4ra rahuldu kuulujuttudega ega tunnistajate \u00fctlustega. M\u00f5ista, milline on iga poole lugu, mida nad tahavad, miks nad seda soovivad, mida nad ootavad, kas nad on seda k\u00fcsimust varem proovinud lahendada, mis juhtub, kui see ei lahene, milliseid lahendusv\u00f5imalusi nad n\u00e4evad, kuidas nad teise poole seisukohta kujutavad, mis nende arvates on \u00f5ige v\u00f5i vale jne. Laadige oma p\u00e4he kogu v\u00f5imalik kontekst, erapooletult, eeldades, et k\u00f5ik on \u00f5iged. Te ei ole konfliktis sees, te olete sellest v\u00e4ljaspool, meta-positsioonis. Kui kontekst on k\u00e4ttesaadav ainult e-posti ahelas \u2014 loe v\u00e4hemalt see tervikuna l\u00e4bi ja seotud arutlused ja dokumendid. P\u00e4rast lugemist \u2014 r\u00e4\u00e4gi ikkagi h\u00e4\u00e4lega. Peaaegu garanteeritult kuulete midagi olulist, mida e-kirjadest ei leidu.<\/p>\n
Kolmas oluline punkt on \u00fcldine suhtlemine. Need on tavalised asjad, mitte midagi erakordset, kuid neil on suur m\u00f5ju. Me ei p\u00fc\u00fca aega s\u00e4\u00e4sta, r\u00e4\u00e4gime k\u00f5igi osalistega, kritiseerime mitte inimest, vaid vaatleme tema tegevuste tagaj\u00e4rgi (mitte \"sa oled ebaviisakas\", vaid \"v\u00f5ib-olla, et inimesed v\u00f5ivad selle \u00fcle \u00e4ra minna\"), anname v\u00f5imaluse s\u00e4ilitada n\u00e4gu ning oma arutelud viime l\u00e4bi isiklikult, mitte avalikult.<\/p>\n
Konfliktide p\u00f5hjused on tavaliselt seotud \u00fche kahe p\u00f5hjusega. Esimene on seotud sellega, kas inimene on konflikti hetkel t\u00e4iskasvanu v\u00f5i lapse positsioonis (sellega seoses r\u00e4\u00e4gime allpool). See on seotud tema emotsionaalse k\u00fcpsuse ja suutlikkuse v\u00f5imega oma emotsioone juhtida (mis, muide, ei pruugi \u00fcldse alati olla seotud tema vanusega). Teine levinud p\u00f5hjus on t\u00f6\u00f6protsessi ebat\u00e4iuslikkus, mis loob halli tsooni olukordi, kus vastutus on jagatud osaliste vahel, osaliste ootused ei ole \u00fcksteisele selged ning rollid on protsessis h\u00e4gused. <\/p>\n
Seet\u00f5ttu peab konfliktide (nagu ka muude k\u00fcsimuste) lahendamisel juht arvestama kolme perspektiiviga: l\u00fchiajaline \u2014 probleem v\u00f5i konflikt lahendatakse kohe, keskp\u00e4rane \u2014 minimeerida sarnaste konfliktide tekkimise t\u00f5en\u00e4osust, ja pikaajaline \u2014 meeskonnas k\u00fcpse kultuuri arendamine. <\/p>\n
Igas meis on sisemine laps, umbes kolme-nelja aastane. Suurema osa ajast magab ta t\u00f6\u00f6l, kuid m\u00f5nikord \u00e4rkab ja v\u00f5tab juhtimise enda k\u00e4tte. Lapsel on oma prioriteedid. Tema jaoks on oluline n\u00f5uda, et see on tema liivakast, ema armastab teda rohkem, tema m\u00e4nguauto on k\u00f5ige parem (disain on parim, ta programmeerib paremini, \u2026). Konfliktsituatsioonis v\u00f5ib laps oma m\u00e4nguasju tugevalt hoida, jalgadega trampida ja labidaga l\u00f5hkuda, kuid ta ei suuda t\u00e4iskasvanute k\u00fcsimusi lahendada (lahenduse arhitektuur, automatiseerimise testimise l\u00e4henemised, t\u00e4htajad jne), ta ei m\u00f5tle meeskonnale kasulike asjade peale. Lapsi konfliktis v\u00f5ib julgustada, lohutada ja saata magama, paludes tal kutsuda oma t\u00e4iskasvanu. Enne arutelu alustamist konflikti tingimustes veenduge, et te r\u00e4\u00e4gite praegu t\u00e4iskasvanuga, mitte lapsiga, ja et olete ise t\u00e4iskasvanu positsioonil. Kui teie aus eesm\u00e4rk praegu on t\u00f5sise k\u00fcsimuse lahendamine, olete t\u00e4iskasvanu positsioonil. Kui teie eesm\u00e4rk on jalgadega trampida ja labidaga l\u00f5hkuda - see on lapse positsioon. Saatke oma sisemine laps magama ja kutsuge t\u00e4iskasvanu, v\u00f5i edasil\u00fckake arutelu. Inimene teeb emotsionaalse otsuse ja seej\u00e4rel otsib sellele ratsionaalset \u00f5igustust. Otsus, mille teeb laps, l\u00e4htudes laste prioriteetidest, ei ole optimaalne.<\/p>\n
Lisaks konfliktik\u00e4itumisele iseloomustab laste v\u00f5i t\u00e4iskasvanute positsiooni ka vastutuse tase, mille inimene on valmis enda peale v\u00f5tma. Ekstreemsetes ilmingutes n\u00e4eb programmeerija laste positsioon, mida olen korduvalt kohanud, v\u00e4lja nii: ma kirjutasin koodi, saatsin selle \u00fclevaatamiseks \u2014 minu t\u00f6\u00f6 on l\u00f5petatud. \u00dclevaatajad peavad selle \u00fcle vaatama ja \u00fchendama, QA peab selle kontrollima, kui esinevad probleemid \u2014 nad teavitavad mind. Kuidas kummaline, isegi \u00fcsna vanad ja kogenud inimesed k\u00e4ituvad m\u00f5nikord sarnaselt. Teine \u00e4\u00e4rmus on, et inimene peab end vastutavaks selle eest, et tema kood t\u00f6\u00f6taks, oleks katnud testidega, oleks isiklikult kontrollitud, edukalt l\u00e4binud \u00fclevaatamise (vajadusel pole probleemi \u00fclevaatajate t\u00e4iendavaid k\u00fcsimusi arutada) ja oleks \u00fchendatud, QA abi osutatakse vajadusel, testimise stsenaariumid on kirjeldatud jne. Normaalsetes tingimustes on programmeerija kas algselt l\u00e4hemal t\u00e4iskasvanule v\u00f5i liigub sinna koos kogemuse kasvuga (tingimusel, et meeskonnas kultiveeritakse \u00f5iglast kultuuri). Ekstreemsetes olukordades j\u00e4tkab ta tavaliselt laste positsiooni omamist, mist\u00f5ttu tekivad tal ja meeskonnal perioodiliselt probleemid ja konfliktid.<\/p>\n
Meeskonna \u00f5ige ja k\u00fcpse kultuuri kasvatamine on iga juhi oluline \u00fclesanne. See n\u00f5uab pikka aega ja iga p\u00e4ev pingutusi, kuid tulemus on seda v\u00e4\u00e4rt. Meeskonna kultuuri m\u00f5jutamiseks on kaks viisi \u2014 isiklik eeskuju (millele j\u00e4rgitakse kindlasti, sest meeskond vaatab alati liidri poole) ning arutelud ja \u00f5ige k\u00e4itumise edendamine. Siin pole samuti midagi keerulist ega eriliselt formaalset: probleemide arutamisel m\u00e4rkige, kuidas oleks saanud teisiti tegutseda, r\u00f5hutage, kui olete m\u00e4rganud, et probleem lahendati \u00f5igesti, kiitke ning tooge v\u00e4lja releasi \u00fclevaatuses jne.<\/p>\n
K\u00e4sitleme mitmeid t\u00fc\u00fcpilisi konfliktseid olukordi, lihtsast keeruliseni:<\/p>\n
T\u00f6\u00f6tamisega mitte seotud konfliktid<\/b><\/p>\n
T\u00f6\u00f6l esinevad \u00fcsna tihti konfliktid, mis ei ole seotud t\u00f6\u00f6alaste probleemidega. Nende tekkimine ja lihtsus lahendamisel on tavaliselt otseselt seotud osalejate emotsionaalse intelligentsuse ja k\u00fcpsuse tasemega ning ei ole seotud t\u00f6\u00f6protsessi t\u00e4iuslikkuse v\u00f5i puudulikkusega.<\/p>\n
T\u00fc\u00fcpilised n\u00e4ited \u2014 keegi ei kasuta piisavalt sageli pesumasinat v\u00f5i du\u0161i all k\u00e4imist, mis h\u00e4irib teisi, m\u00f5ni meesterahvas tunneb end kitsas ruumis, kui aken on avatud, \u00fcks inimene teeb liiga palju l\u00e4rmi, samas kui teised vajavad vaikust t\u00f6\u00f6ks, ja nii edasi. Selliste konfliktide lahendamisega ei tohiks venitada ega lasta olukorral iseenesest areneda. Need ei lahene iseenesest ja h\u00e4irivad igap\u00e4evaselt t\u00f6\u00f6d ning m\u00fcrgitavad meeskonna \u00f5hkkonda. \u00d5nneks on nende lahendamine tavaliselt lihtne \u2014 piisab, kui r\u00e4\u00e4kida rahulikult (muidugi silmast silma) kolleegiga, kes ei j\u00e4lgi h\u00fcgieeni, tagada mugav istumisasetus neile, kes hindavad vaikust\/jahedust, osta helisummutavad k\u00f5rvaklapid v\u00f5i paigutada vaheseinad jne. <\/p>\n
Teine n\u00e4ide, millega olen oma t\u00f6\u00f6s mitmel korral kokku puutunud, on meeskonnaliikmete ps\u00fchholoogiline \u00fchilduvus. Mingil p\u00f5hjusel ei saa inimesed lihtsalt koos t\u00f6\u00f6tada; iga suhtlus l\u00f5ppeb skandaaliga. M\u00f5nikord on see seotud sellega, et inimesed peavad kinni polariseeritud arvamustest m\u00f5ne tulise k\u00fcsimuse osas (tavaliselt poliitilise) ega suuda neid t\u00f6\u00f6 v\u00e4liselt j\u00e4rel j\u00e4tta. Nende veenmine taluma \u00fcksteist v\u00f5i oma k\u00e4itumist muutma on pigem lootusetu tegevus. Ainus erand, millega olen kokku puutunud, on noored kolleegid, kellel on avatud m\u00f5tlemine; nende k\u00e4itumist on veel v\u00f5imalik j\u00e4rk-j\u00e4rgult muuta perioodiliste vestlustega. Tavaliselt lahendatakse see probleem edukalt, jagades nad erinevatesse meeskondadesse v\u00f5i, v\u00e4hemalt, tagades v\u00f5imaluse v\u00e4ga harva omavahel kokku puutuda.<\/p>\n
K\u00f5ikides nimetatud olukordades peaks iga osalejaga r\u00e4\u00e4kima isiklikult, arutama olukorda, huvi tundma, kas nad n\u00e4evad iseenesest probleemina, k\u00fcsima, millised on nende arvates lahendused, ja tagama nende kaasamise selle otsuse vastuv\u00f5tmisse.<\/p>\n
T\u00f6\u00f6tasandi optimeerimise seisukohalt (keskmise t\u00e4htajaga, millest ma r\u00e4\u00e4kisin) ei ole siin palju parandada, ainus asi, mida optimeerida, on arvestada meeskonna koost\u00f6\u00f6faktorit ja mitte panna koos inimesi, kes v\u00f5ivad omavahel konflikti sattuda. <\/p>\n
Meeskonnakultuuri seisukohalt esinevad sellised olukorrad palju harvemini meeskondades, kus on k\u00fcps kultuur, kus inimesed austavad \u00fcksteist ja suudavad k\u00fcsimusi iseseisvalt lahendada. Lisaks sellele lahendatakse sellised konfliktid palju lihtsamalt (tihti automaatselt) meeskondades, kus on k\u00f5rge usaldus, inimesed on koos kaua t\u00f6\u00f6tanud ja\/v\u00f5i suhtlevad sageli v\u00e4ljaspool t\u00f6\u00f6d.<\/p>\n
T\u00f6\u00f6alaste konfliktide t\u00fc\u00fcbid:<\/b><\/p>\n
Sellised konfliktid tulenevad tavaliselt m\u00f5lemast p\u00f5hjusest korraga, nii emotsionaalsest (kui keegi osalejatest ei ole t\u00e4iskasvanu positsioonil) kui ka t\u00f6\u00f6protsessi puudustest. \u00dcks levinumaid konflikte, millega ma kokku olen puutunud, on konfliktid koodi \u00fclevaatamise v\u00f5i arutelu k\u00e4igus arendajate vahel. <\/p>\n
T\u00f5staksin esile kaks t\u00fc\u00fcpilist juhtumit:<\/p>\n
1) Esimesel juhul ei saa arendaja kolleegilt koodikontrolli. Patch on \u00fclevaatamiseks saadetud ja midagi ei juhtu. Esmapilgul ei tundu kahe osapoole vahel ilmset konflikti olevat, kuid l\u00e4hemalt vaadates tuleb see v\u00e4lja. T\u00f6\u00f6probleem j\u00e4\u00e4b lahendamata, \u00fcks osapool (\u00fclevaadet oodates) tunneb selgelt ebamugavust. Ekstreemne variant sellest juhtumist on arendamine kogukonnas v\u00f5i erinevates meeskondades, kusjuures \u00fclevaatajal ei pruugi olla huvi just selle konkreetse koodi vastu, kuna t\u00f6\u00f6koormus v\u00f5i muud asjaolud v\u00f5ivad teda isegi \u00fclevaatamise p\u00e4ringutele t\u00e4helepanu p\u00f6\u00f6ramast takistada, ning v\u00e4list arbitraatori (\u00fclema, kes m\u00f5lemale osapoolele \u00fchine on) ei pruugi \u00fcldse olla. <\/p>\n
Lahendus, mis aitab sellistes olukordades, l\u00e4htub pikaajalistest eesm\u00e4rkidest ja k\u00fcpsest kultuurist. Esiteks, m\u00f5istlik aktiivsus. Ei tasu oodata, et lihtsalt \u00fclevaatusel riputatud kood k\u00f6idab \u00fclevaatajate t\u00e4helepanu iseenesest. Tuleb aidata \u00fclevaatajatel seda m\u00e4rkama. Pinguta paar inimest, esita k\u00fcsimus synkapi ajal, osale aruteludes. Loomulikult v\u00f5ib liialdamine pigem kahjulik olla, seega tasub kasutada tervet m\u00f5istust. Teiseks, eelnev ettevalmistus on v\u00e4ga t\u00f5hus. Kui meeskond m\u00f5istab, mis ja miks toimub ning miks see kood \u00fcldse vajalik on, arutatakse ja koosk\u00f5lastatakse disain eelnevalt k\u00f5igiga, siis on suurem t\u00f5en\u00e4osus, et inimesed m\u00e4rkavad sellist koodi ja aktsepteerivad selle t\u00f6\u00f6sse. Kolmandaks, autoriteet m\u00e4ngib rolli. Kui soovid, et sinu koodi vaadatakse \u00fcle, tegele ka ise aktiivselt \u00fclevaatustega. Tee kvaliteetseid \u00fclevaateid, koos reaalse kontrollimise, testimise ja kasulike kommentaaridega. Kui su nimi on meeskonnas tuntud headest k\u00fclgedest, on suurem t\u00f5en\u00e4osus, et sinu koodile p\u00f6\u00f6ratakse t\u00e4helepanu.<\/p>\n
T\u00f6\u00f6protsessi seisukohalt on siinkohal v\u00f5imalikud parandused \u2014 \u00f5igete prioriteetide seadmine, mis aitab arendajal saavutada enda ja meeskonna eesm\u00e4rke (teisi \u00fcle vaadata, kirjutada kirju kogukonnale, toetada koodi arhitektuuri, dokumentatsiooni, testimise kirjeldamisega, osaleda aruteludes kogukonna liikmetega jne), v\u00e4ltides samaaegselt liiga pikaaja ootej\u00e4rjekorra loomist ja nii edasi. <\/p>\n
Teiseks levinud konfliktide puhul koodi v\u00f5i disaini \u00fclevaatamisel on erinevad arusaamad tehnilistest k\u00fcsimustest, kodeerimisstiilist ja t\u00f6\u00f6riistade valikust. Siinkohal on usk osalejate vahel \u00e4\u00e4rmiselt oluline, kuuluvus \u00fchte meeskonda ja varasem koost\u00f6\u00f6 kogemus. Pattide olukord tekib siis, kui m\u00f5ni osalejatest v\u00f5tab lapsiku positsiooni, mitte ei p\u00fc\u00fca aru saada, mida teine osaleja talle edastada soovib. Sageli v\u00f5ivad nii teise poole pakkunud l\u00e4henemine kui ka algselt pakutud l\u00e4henemine olla t\u00e4iesti edukad ja pole olulist vahet, millist neist valida. <\/p>\n
Kordagi \u00fches mu meeskonna arendajas (nimetame teda Pasha) valmistas ta paranduse pakettide juurutamise s\u00fcsteemi, mida arendas ja toetas naabripoolse osakonna kolleegid. \u00dchel neist (Igoril) oli oma tugev arvamus selle kohta, kuidas t\u00e4pselt Linuxi teenuseid seadistada pakettide juurutamisel. See arvamus erines paranduses pakutud l\u00e4henemisest ja nad ei suutnud kokku leppida. Nagu ikka, olid t\u00e4htajad l\u00e4henemas ja pidime leidma mingi lahenduse, keegi pidi v\u00f5tma t\u00e4iskasvanud positsiooni. Pasha tunnustas, et m\u00f5lemal l\u00e4henemisel on oma \u00f5igustused, kuid tal oli soov, et tema variant l\u00e4heks l\u00e4bi, kuna \u00fchelgi variandil ei olnud selgeid tehnilisi eeliseid. <\/p>\n
Meie arutelu n\u00e4gi v\u00e4lja umbes nii (muidugi v\u00e4ga skeemaatiliselt, vestlus kestis pool tundi): <\/p>\n
\u2014 Pasha, meil on paar p\u00e4eva feature freeze. Oluline on, et me k\u00f5ik kokku koguksime ja testimist v\u00f5imalikult kiiresti alustada. Kuidas me saaksime Igorist \u00fcle k\u00e4ia?
K\u00fcsimus sai lahendatud, v\u00e4ljaanne ilmus \u00f5igeaegselt, Pasha ei v\u00e4ljendanud erilist rahulolematust, sest ta ise pakkus lahenduse ja viis selle ellu. Igor oli \u00fcldiselt rahul, kuna tema arvamust arvestati ja tegid nii, nagu ta eelnevalt soovitas.<\/p>\n
Teine sarnane konflikt, mis t\u00f5eliselt esindab, on valik tehniliste lahenduste\/raamatukogude\/l\u00e4htepunktide vahel projektis, eelk\u00f5ige jaotatud meeskonnas. \u00dches projektis, mis esitleb ennast C\/C++-na, selgus l\u00f5puks, 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\u00e4ga harjunud. Selgus, et projekt on palju l\u00e4hemal C-le kui C++-le, mis ei olnud meeskonda just eriti innustav, kuna juhtkond oli valinud t\u00f5eliselt heade C++-dearendajate. Samal ajal t\u00f6\u00f6tas Ameerika osa meeskonnast, nii insenerid kui ka juhid, ettev\u00f5ttes juba pikka aega, nad olid harjunud olemasoleva olukorraga ning neid rahuldas see. Venemaa osa meeskonnast koondati kokku hoopis hiljuti, vaid paar n\u00e4dalat tagasi (sh mina). Venemaa osa meeskonnast ei soovinud kategooriliselt loobuda oma traditsioonilisest l\u00e4henemisest arendusele.<\/p>\n
Alustasid l\u00f5putud kirjalikud arutelud kahe manda vahel, kus kirjad, mis ulatusid kolme-nelja ekraanini, lendasid edasi-tagasi, nii grupikirjade kui isiklike kaudu, programmeerijate vahel \u2014 programmeerijatele ja juhtidele. Nagu tavaliselt juhtub, ei lugenud sellise suurusega kirju keegi peale autorite ja nende tulihingeliste toetajate. Vestlused kr\u00f5bisesid pingest, edastades igas suunas mitmekesiseid m\u00f5tteid STL tehniliste eeliste kohta, kui h\u00e4sti see on testitud, ohutu ning \u00fcldiselt, kui suurep\u00e4rane on elu selle kasutamisel ja kui kohutav ilma selleta. <\/p>\n
See oli \u00fcsna pikalt, kuni ma l\u00f5puks aru sain, et arutame tehnilisi k\u00fclgi, kuid probleem ei ole tegelikult tehniline. Probleem ei seisne STL hindamises v\u00f5i selle kasutamise keerukuses. Probleem on pigem organisatoriline. Meil oli lihtsalt vaja m\u00f5ista, kuidas meie ettev\u00f5te t\u00f6\u00f6tab. Enne ei olnud kellelgi meist kogemust t\u00f6\u00f6tada sellises ettev\u00f5ttes. Probleem seisnes selles, et koodi arendamise ja tootmisseviimise j\u00e4rel hooldasid seda t\u00e4iesti teised inimesed teistest meeskondadest ja teistest riikidest. See tohutu inseneriteemade meeskond, kuhu kuulus mitu tuhat inseneri, suutis endale lubada vaid t\u00e4iesti minimaalset tehniliste vahendite komplekti, nii \u00f6elda, minimum minimorum. K\u00f5ik, mis \u00fcletas ettev\u00f5ttes kehtestatud inseneristandardi, ei saanud tulevikus f\u00fc\u00fcsiliselt toetust. Meeskonna tase m\u00e4\u00e4ratakse tema n\u00f5rgimate liikmete j\u00e4rgi. P\u00e4rast seda, kui me m\u00f5istsime, reaalset motivatsiooni<\/i> Ameerika meeskonna tegevuste osas, see k\u00fcsimus v\u00f5eti p\u00e4evakorrast \u00e4ra ning me k\u00f5ik koos suutsime edukalt arendada ja turule tuua toote, j\u00e4rgides ettev\u00f5ttes kehtinud standardeid. Kirjad ja vestlused ei toiminud sel juhul h\u00e4sti, et j\u00f5uda \u00fchiselt kokkuleppele, n\u00f5udis see mitmeid reise ja palju isiklikku suhtlemist.<\/p>\n
T\u00f6\u00f6protsessi seisukohalt oleks antud juhul kasulik, kui oleks olemas kirjeldus kasutatavatest vahenditest, nende n\u00f5uetest, piirangutest uute lisamisel ja selliste piirangute p\u00f5hjendamine. Sellised dokumendid vastavad umbes punktides kirjeldatud Reuse Strategy ja Development Environment juhtn\u00f6\u00f6ridele \u201eManager's Handbook for Software Development\u201d, mille on v\u00e4lja t\u00f6\u00f6tanud NASA<\/a><\/noindex>. Omal ajal kirjeldab see suurep\u00e4raselt k\u00f5iki peamisi tegevusi ja etappe sellise tarkvaraarenduse planeerimisel. Selliste dokumentide olemasolu lihtsustab oluliselt arutelu selle \u00fcle, milliseid komponente ja l\u00e4henemisi tootes v\u00f5ib kasutada ning miks.<\/p>\nKultuuri seisukohalt on selge, et kui osalised p\u00fc\u00fcavad kuulata ja m\u00f5ista kolleegide tegude tegelikke motiveerivaid tegureid ning tegutsevad projekti ja meeskonna prioriteetide, mitte isikliku ego j\u00e4rgi, siis konflikti lahendamine oleks kergem ja kiirem.<\/p>\n
Teises konfliktis seoses tehnilise lahenduse valikuga vajasin samuti m\u00e4rkimisv\u00e4\u00e4rset aega, et m\u00f5ista \u00fche poole motivatsiooni (see juhtum oli v\u00e4ga ebatavaline), kuid p\u00e4rast seda, kui motivatsioon selgeks sai, oli lahendus ilmne. <\/p>\n
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\u00e4htekoodiga tarkvara f\u00e4nn, kasutades ainult selliseid t\u00f6\u00f6riistu ja operatsioonis\u00fcsteeme, mille l\u00e4htekood on avalikult kergesti k\u00e4ttesaadav ja mis kasutavad avalikult kirjeldatud protokolle. Skype selliste t\u00f6\u00f6riistade seas ei ole. Me kulutasime tohutult aega selle l\u00e4henemise eeliste ja puuduste arutamiseks, katsetes k\u00e4ivitada Skype'i analooge erinevates operatsioonis\u00fcsteemides, Stasi p\u00fc\u00fcdel veenda meeskonda teistelt standarditele \u00fcle minema, kirjutada talle isiklikult e-kirju, helistada talle isiklikult telefoniga, osta talle teine arvuti spetsiaalselt Skype'i jaoks jne. L\u00f5puks arvasin, et see probleem ei ole tegelikult tehniline ega korralduslik, pigem on see maailmavaateline probleem, v\u00f5i isegi v\u00f5ib \u00f6elda, et religiooniline (Stasi jaoks). Isegi kui me l\u00f5puks Stasi ja Skype'i \u00fchendasime (milleks oli kulunud mitu kuud), tekkiks sama probleem j\u00e4rgmisel t\u00f6\u00f6riistal uuesti. Mul ei olnud reaalset v\u00f5imalust Stasi maailmavaadet muuta ja mul ei olnud p\u00f5hjust p\u00fc\u00fcda muuta meeskonna maailmavaadet, mis t\u00f6\u00f6tas selles keskkonnas suurep\u00e4raselt. Inimene ja ettev\u00f5te olid maailmavaateliselt lihtsalt ortogonaalsed. Taolistes olukordades on hea lahendus \u2014 korralduslik. Me liikusime Stasi teise meeskonda, kus ta oleks rohkem orgaaniline.<\/p>\n
Probleemi p\u00f5hjus on minu arvates seotud konkreetse inimese isikliku kultuuri ja ettev\u00f5tte 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\u00f5tta ta sellise projekti peale. Stas kraadi l\u00f5ppes avatud l\u00e4htekoodiga tarkvara arendusprojekti juurde ja ta edeneb seal suurep\u00e4raselt.<\/p>\n
Hea n\u00e4ide konfliktist, mis on tekitatud samal ajal arendaja lapsemeelsest l\u00e4henemisest ja t\u00f6\u00f6k\u00e4igus esinevatest puudustest \u2014 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 \u2014 seal nad saavad ise hakkama. \u00dcksk\u00f5ik, et tegu oli \u00fcsna kogenud programmijaga, oli tal siiski madal kvaliteedi t\u00f5e piir. QA ei olnud sellega n\u00f5us ja n\u00f5udsid, et ta n\u00e4itaks neile ja kirjeldaks, mida ta ise kontrollis, ning k\u00fcsisid testimistestide stsenaariumi. Neil oli varem olnud probleeme selle arendaja funktsionaalsusega ning nad ei soovinud oma aega tarbetult raisata. Muide, nad olid \u00f5iged \u2014 funktsioon ei t\u00f6\u00f6tanud t\u00f5epoolest, koodi ei kontrollitud enne QA-le edastamist. <\/p>\n
Selle olukorra lahendamiseks palusin tal n\u00e4idata, et k\u00f5ik t\u00f5esti t\u00f6\u00f6tab (see ei t\u00f6\u00f6tanud ning tal tuli see parandada), arutasime meeskonnaga ja QA-ga valmimise m\u00e4\u00e4ratlemist (kirjalikuks see ei saanud, kuna ei soovinud protsessi liiga b\u00fcrokraatlikuks muuta), ning selle spetsialistiga lahkusime peagi (\u00fcldise kergenduse m\u00f5ttes).<\/p>\n
T\u00f6\u00f6protsessi seisukohalt on selles osas v\u00f5imalikud parandused - valmimise m\u00e4\u00e4ratlemise olemasolu, iga funktsiooni toetamise n\u00f5uded \u00fchik- ja integratsioonitestidega, arendaja l\u00e4biviidud testimise kirjeldus. \u00dches projektis m\u00f5\u00f5tsime testide katvust CI ajal ning juhul, kui katvus p\u00e4rast pat\u0161i lisamist langes, m\u00e4rgiti testid l\u00e4bikukkumisena, st iga uut koodi v\u00f5idi lisada ainult siis, kui selle jaoks olid olemas uued testid. <\/p>\n
Veel levinum n\u00e4ide konfliktist, mis on tihedalt seotud t\u00f6\u00f6korraldusega. Meil on toode, selle toote arendusmeeskond, tugiteenuste meeskond ja tellija. Tellijal tekivad toote osas probleemid, ta p\u00f6\u00f6rdub tugiteenuste poole. Tugiteenused anal\u00fc\u00fcsivad probleemi ja m\u00f5istavad, et see on toote viga, edastades probleemi arendusmeeskonnale. Arendusmeeskonnal on kiire aeg, v\u00e4ljaanne l\u00e4heneb, seega tellija probleemiga seotud pilet, mis on arendajale m\u00e4\u00e4ratud, j\u00e4\u00e4b n\u00e4dalateks t\u00e4helepanuta teiste piletite keskele. Tugiteenused arvavad, et arendaja t\u00f6\u00f6tab tellija probleemi kallal. Tellija ootab ja loodab, et tema probleemiga tegeletakse. Tegelikult ei toimu midagi. P\u00e4rast mitmeid n\u00e4dalaid otsustab tellija l\u00f5puks p\u00e4rida edusamme ja k\u00fcsib tugiteenustelt, kuidas l\u00e4heb. Tugiteenused k\u00fcsivad arenduse k\u00e4est. Arendaja s\u00e4hvab, vaatab piletite loendit ja leiab sealt tellija pilet. Lugedes tellija piletit, m\u00f5istab ta, et probleemide lahendamiseks ei ole piisavalt teavet ning tal on vaja veel logisid ja dump'e. Tugiteenused k\u00fcsivad tellijalt t\u00e4iendavat teavet. Ja siis m\u00f5istab tellija, et keegi ei ole tema probleemiga vahepeal tegelenud. Ja \u00e4kki tabab \u00e4ike ...<\/p>\n
Selles olukorras on konflikti lahendamine \u00fcsna ilmne ja lineaarne (toote parandamine, dokumentatsiooni ja testide v\u00e4rskendamine, kliendi rahustamine, kiire paranduse v\u00e4ljaandmine jne). Oluline on anal\u00fc\u00fcsida t\u00f6\u00f6voogu ja m\u00f5ista, kes vastutab kahe meeskonna koost\u00f6\u00f6 korraldamise eest ja miks selline olukord \u00fcldse tekkis. On selge, et protsessis tuleb midagi parandada \u2014 keegi peaks ilma kliendi meeldetuletusteta j\u00e4lgima \u00fcldpilti, olema proaktiivne. Kliendi piletid peaksid arendajate seas silma paistma. Toetamine peaks n\u00e4gema, kas arendus t\u00f6\u00f6tab 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\u00f5rgete lahendamiseks peaks olema maksimaalselt automatiseeritud jne.<\/p>\n
Nagu s\u00f5da, kus vastane \u00fcritab l\u00fc\u00fca kahe \u00fcksuse vahelt, on ka t\u00f6\u00f6s k\u00f5ige n\u00f5rgem ja haavatavam koht sageli tiimide vaheline suhtlemine. Kui tugija arendusjuhid on piisavalt k\u00fcpsed, saavad nad protsessi iseseisvalt parandada; kui ei, siis j\u00e4tkab protsess konfliktide ja probleemide genereerimist, kuni sekkub juht, kes suudab olukorda parandada.<\/p>\n
Teine iseloomulik n\u00e4ide, millega olen kokku puutunud erinevates ettev\u00f5tetes, on olukord, kus \u00fche meeskonna poolt arendatud toode, automaatsete integratsioonitestide teostamine teise meeskonna poolt ja infrastruktuur, millel seda k\u00f5ike t\u00f6\u00f6s hoitakse, on kolmanda meeskonna t\u00f5hustamisel. Testide l\u00e4biviimise k\u00e4igus tekivad pidevalt probleemid, mille p\u00f5hjuseks v\u00f5ivad olla nii toode kui ka testid ja infrastruktuur. Sageli on keeruline kokku leppida, kes peab tegema esmase probleemide anal\u00fc\u00fcsi, j\u00e4relvalvema vigu, anal\u00fc\u00fcsima toote, testide ja infrastruktuuri logisid jne. Konfliktid on siin \u00fcsna sagedased ja samas ka kindlad. K\u00f5rge emotsionaalse pinge korral kipuvad osalised sageli v\u00f5tma laste positsioone, algavad arutelud stiilis: \"miks ma pean sellega tegelema\", \"neil on sagedamini rikkeid\" jne. <\/p>\n
T\u00f6\u00f6protsessist l\u00e4htudes s\u00f5ltuvad konkreetsed sammud k\u00fcsimuse lahendamiseks tiimide koosseisust, testide t\u00fc\u00fcbist ja tootest jne. \u00dches projektis kehtestasime perioodilised vahetused, mille k\u00e4igus meeskonnad j\u00e4lgisid teste vaheldumisi, n\u00e4dalate kaupa. Teises projektis teostasid esialgse anal\u00fc\u00fcsi alati testide arendajad, kuid see anal\u00fc\u00fcs oli \u00fcsna p\u00f5hjalik ja toode oli piisavalt stabiilne, seega t\u00f6\u00f6tas see sarnaselt h\u00e4sti. Peamine on tagada protsessi l\u00e4bipaistvus, ootuste selgus k\u00f5ikide osaliste jaoks ja iga\u00fche jaoks \u00f5iglane olukord.<\/p>\n
Kas konflikt organisatsioonis tegelikult on probleem v\u00f5i on see halb m\u00e4rk, et teie meeskonnas tekivad konfliktid sageli (v\u00f5i lihtsalt perioodiliselt)? \u00dcldiselt ei ole see nii, sest kui toimub kasv, areng ja mingit t\u00fc\u00fcpi d\u00fcnaamika, siis tekivad k\u00fcsimused, mida pole kunagi varem k\u00e4sitletud, ning nende lahendamisel v\u00f5ivad tekkida konfliktid. See on m\u00e4rk sellest, et teatud valdkondadele tuleks rohkem t\u00e4helepanu p\u00f6\u00f6rata ja et on parendamise kohti. Halb on see, kui konfliktid tekivad v\u00e4ga sageli ja neid on raske v\u00f5i pikk lahendada. See on t\u00f5en\u00e4oliselt m\u00e4rk halvasti v\u00e4lja t\u00f6\u00f6tatud t\u00f6\u00f6protsessidest ja meeskonna ebak\u00fcpsusest.habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u042d\u043f\u0438\u0433\u0440\u0430\u0444: \u0412\u0441\u0442\u0440\u0435\u0442\u0438\u043b\u0438\u0441\u044c \u043a\u0430\u043a-\u0442\u043e \u0432 \u043b\u0435\u0441\u0443 \u0401\u0436\u0438\u043a \u0438 \u041c\u0435\u0434\u0432\u0435\u0436\u043e\u043d\u043e\u043a. \u2014 \u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439, \u0401\u0436\u0438\u043a! \u2014 \u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439, \u041c\u0435\u0434\u0432\u0435\u0436\u043e\u043d\u043e\u043a! \u0422\u0430\u043a, \u0441\u043b\u043e\u0432\u043e \u0437\u0430 \u0441\u043b\u043e\u0432\u043e, \u0448\u0443\u0442\u043a\u0430 \u0437\u0430 \u0448\u0443\u0442\u043a\u043e\u0439, \u0438 \u043f\u043e\u043b\u0443\u0447\u0438\u043b \u0401\u0436\u0438\u043a \u043e\u0442 \u041c\u0435\u0434\u0432\u0435\u0436\u043e\u043d\u043a\u0430 \u043f\u043e \u043c\u043e\u0440\u0434\u0435 \u2026 \u041f\u043e\u0434 \u043a\u0430\u0442\u043e\u043c \u0440\u0430\u0441\u0441\u0443\u0436\u0434\u0435\u043d\u0438\u044f \u043d\u0430\u0448\u0435\u0433\u043e \u0442\u0438\u043c\u043b\u0438\u0434\u0430, \u0430 \u0442\u0430\u043a\u0436\u0435 \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440\u0430 \u043f\u043e \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044e \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430 RAS \u2014 \u0418\u0433\u043e\u0440\u044f \u041c\u0430\u0440\u043d\u0430\u0442\u0430 \u043e \u0441\u043f\u0435\u0446\u0438\u0444\u0438\u043a\u0435 \u0440\u0430\u0431\u043e\u0447\u0438\u0445 \u043a\u043e\u043d\u0444\u043b\u0438\u043a\u0442\u043e\u0432 \u0438 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u044b\u0445 \u043c\u0435\u0442\u043e\u0434\u0430\u0445 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u0438\u043c\u0438. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043a\u043e\u043d\u0444\u043b\u0438\u043a\u0442\u043e\u0432, […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27283,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[702],"tags":[],"class_list":["post-36457","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-novosti-interneta"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Meeskonna](\"\/wp-content\/uploads\/2019\/07\/de379c9eedec8cecda6651b5339a0277.jpg\")