<\/a><\/noindex>Teiseks, t\u00f6\u00f6konflikti olukorras osalised seisavad silmitsi k\u00fcsimuse lahendamise vajadusega, mis on oluline \u00fcksnes m\u00f5nele osalisele, m\u00f5lemale v\u00f5i organisatsioonile tervikuna. Sellest tulenevalt on osalistel tihti piisavalt aega ja erinevaid lahendusviise (formaalsetest, mitteformaalsetest, kohtumistest, kirjades, juhtkonna otsustest, meeskonna eesm\u00e4rkidest ja plaanidest, hierarhia olemasolust jne). See eristab t\u00f6\u00f6situatsiooni (v\u00f5i mitte-t\u00f6\u00f6situatsiooni) k\u00fcsimuse lahendamist n\u00e4iteks t\u00f5sisest k\u00fcsimusest: \u201eHei, kutt, kust sa p\u00e4rit oled?!\u201c t\u00e4naval v\u00f5i \u00fclaltoodud konflikti puhul. T\u00f6\u00f6alase k\u00fcsimuse lahendamisel on oluline t\u00f6\u00f6protsessi kvaliteet ja meeskonna k\u00fcsimuste lahendamise kultuur.<\/p>\n
Kolmandaks, konfliktide m\u00e4\u00e4ravaks teguriks (meie arutelu perspektiivist) on see, et osalised ei suuda iseseisvalt j\u00f5uda k\u00f5iki osalisi rahuldavale lahendusele. Olukord n\u00f5uab kolmanda osapoole, v\u00e4list vahekohtuniku, sekkumist. See punkt v\u00f5ib tunduda vaieldav, kuid tegelikult, kui konfliktne olukord lahendatakse eduka tulemusega ilma v\u00e4list vahekohtunikku kaasamata, on k\u00fcsimus lahendatud ja osaliste suhted ei halvenenud, siis on see olukord, mille poole tuleks p\u00fc\u00fcelda. Sellise konflikti kohta ei pruugi me isegi teada, v\u00f5i saame sellest teada juhuslikult p\u00e4rast lahendamist. Mida rohkem k\u00fcsimusi suudab meeskond iseseisvalt lahendada, seda efektiivsemalt nad t\u00f6\u00f6tavad.<\/p>\n
Veel \u00fcks iseloomulik joon konfliktist, mida tasub puudutada \u2013 emotsionaalse pinge aste lahendamise k\u00e4igus. Konflikt ei t\u00e4henda tingimata k\u00f5rget emotsionaalset taset. Osalised ei pea karjuma ja k\u00e4tega vehkima, et olukord oleks t\u00f5eliselt konfliktne. Kui k\u00fcsimus ei lahene ja teatud emotsionaalne pinge on kohal (v\u00f5ib-olla ei v\u00e4ljendu see selgelt), t\u00e4hendab see, et oleme silmitsi konfliktiga.<\/p>\n
Kas on \u00fcldse vajalik sekkuda konfliktsetesse olukordadesse v\u00f5i on parem lasta neil iseenesest lahenduda ja oodata, kuni probleem kaob? On vajalik. Mitte alati ei ole teie v\u00f5imuses v\u00f5i p\u00e4devuses konflikti t\u00e4ielikult lahendada, kuid igas olukorras, igasuguste konfliktide puhul, saate v\u00f5tta t\u00e4iskasvanu positsiooni, t\u00f5stes sellega ka mitmeid inimesi enda \u00fcmber, pehmendada konflikti negatiivseid tagaj\u00e4rgi ja soodustada selle lahendamist.<\/p>\n
Enne kui vaatame \u00fcle m\u00f5ned konfliktsete olukordade n\u00e4ited, peatugem m\u00f5nedele olulistele aspektidele, mis on k\u00f5ikidele konfliktidele \u00fchised.<\/p>\n
Konflikti lahendamisel on oluline olla v\u00f5itlusest k\u00f5rgemal, mitte selle sees (seda nimetatakse ka \u201emeta-positsiooni v\u00f5tmiseks\u201d), st mitte osalema lahendamisprotsessis \u00fche osapoole poolel. Vastupidisel juhul muutute te v\u00e4liseks vahemeheks, kes aitab lahendust, ja te tugevdage \u00fche osapoole positsiooni teise arvelt. Otsuse tegemisel on oluline, et see oleks k\u00f5igi osapoolte moraalselt vastuv\u00f5etav, nagu \u00f6eldakse, \u201eostetud\u201d. Et isegi kui osalised ei olnud vastuv\u00f5etud otsusest r\u00f5\u00f5msad, olid nad siiski siiralt n\u00f5us seda t\u00e4itma. Nii \u00f6eldes, olla seisukohal, et ei pruugi n\u00f5ustuda, kuid n\u00f5ustuda. Vastasel juhul muudab konflikt lihtsalt oma v\u00e4limust, s\u00f6ed j\u00e4\u00e4vad turba alla ja mingil hetkel p\u00f5letavad nad paratamatult uuesti.<\/p>\n
Teine moment, mis osaliselt on seotud esimesega \u2014 kui olete juba otsustanud osaleda konflikti lahendamises, v\u00f5tke seda maksimaalselt t\u00f5siselt suhtlemise ja konteksti uurimise seisukohalt. R\u00e4\u00e4kige isiklikult iga osapoolega. Alguses eraldi iga\u00fchega. \u00c4rge leppige kirjadega. Jaotatud meeskonna puhul r\u00e4\u00e4kige v\u00e4hemalt videok\u00f5ne teel. \u00c4rge rahuldage kuulujutte ja tunnistajate \u00fclekandeid. M\u00f5istke lugu, mida iga osapool tahab, miks nad seda tahavad, mida nad ootavad, kas nad on proovinud seda k\u00fcsimust varem lahendada, mis juhtub, kui seda ei lahendata, milliseid lahendusv\u00f5imalusi nad n\u00e4evad, kuidas nad esitavad teise poole positsiooni, mis nende arvates on \u00f5ige v\u00f5i vale jne. Laadige endasse kogu v\u00f5imalik kontekst, erapooletult, eeldades, et k\u00f5ik on \u00f5iged. Te ei ole konfliktis sees, olete selle v\u00e4ljas, metaasendis. Kui kontekst on saadaval ainult e-kirjade ahelas \u2014 v\u00e4hemalt lugege see t\u00e4ielikult l\u00e4bi ning seotud arutelud ja dokumendid. P\u00e4rast lugemist \u2014 r\u00e4\u00e4kige ikkagi h\u00e4\u00e4le kaudu. Peaaegu garanteeritult kuulete midagi olulist, mida kirjas ei ole.<\/p>\n
Kolmas oluline punkt \u2014 \u00fcldine l\u00e4henemine suhtlemisele. Need on tavalised asjad, mitte midagi kosmilist, kuid neil on v\u00e4ga suur t\u00e4hendus. \u00c4rge \u00fcritage aega s\u00e4\u00e4sta, r\u00e4\u00e4kige k\u00f5igi osalistega, kritiseerige mitte inimest, vaid tema tegevuse tagaj\u00e4rgi (mitte \"sa oled j\u00e4me\", vaid \"v\u00f5ib-olla v\u00f5ivad poisid selle asja \u00fcle vihastada\"), andke v\u00f5imalus n\u00e4o s\u00e4ilitamiseks, arutelud toimuvad isiklikult, mitte rivi ees.<\/p>\n
Konfliktid on tavaliselt tingitud kahest p\u00f5hjusest. Esimene on seotud sellega, kas inimene on konflikti hetkel t\u00e4iskasvanu v\u00f5i lapse positsioonis (sellest allpool). See on seotud tema emotsionaalse k\u00fcpsusega, v\u00f5imega juhtida oma emotsioone (mis muide ei ole alati seotud tema vanusega). Teine levinud p\u00f5hjus on t\u00f6\u00f6protsessi ebat\u00e4iuslikkus, mis loob halli ala olukordi, kus vastutus on hajutatud osaliste vahel, osapoolte ootused pole \u00fcksteisele selged, rollid protsessis on h\u00e4gusad. <\/p>\n
Seega konfliktide lahendamisel (nagu iga teise k\u00fcsimuse puhul) peab juht silmas pidama kolme perspektiivi: l\u00fchiajalist - lahendada k\u00fcsimus \/ konflikt siin ja praegu, keskp\u00e4rast - v\u00e4hendada t\u00f5en\u00e4osust, et sarnane konflikt uuesti tekib, ja pikaajalist - kasvatada meeskonnas t\u00e4iskasvanute kultuuri. <\/p>\n
Igas meis on sisemine laps, umbes kolme-nelja aastane. Suurema osa ajast magab ta t\u00f6\u00f6l, kuid vahel t\u00f5useb ta \u00fcles ja v\u00f5tab juhtimise enda k\u00e4tte. 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\u00f5ib laps m\u00e4nguasju pigistada, jalgu trampida ja labidaga paukuda, kuid ta ei oska lahendada t\u00e4iskasvanute k\u00fcsimusi (lahenduse arhitektuur, automaatsete testimismetoodikad, v\u00e4ljaandmise t\u00e4htaeg jne), ta ei m\u00f5tle meeskonna kasule. Lapse konfliktis v\u00f5ib julgustada, lohutada ja saadetud magama, paludes tal kutsuda oma t\u00e4iskasvanu. Enne arutelu alustamist konfliktitingimustes veenduge, et r\u00e4\u00e4gite just n\u00fc\u00fcd t\u00e4iskasvanuga, mitte lapsega, ja seisate ise t\u00e4iskasvanu positsioonil. Kui teie siiras eesm\u00e4rk on hetkel lahendada t\u00f5sine k\u00fcsimus, olete t\u00e4iskasvanu positsioonil. Kui teie eesm\u00e4rk on jalgu trampida ja labidaga paukuda - see on lapse positsioon. Saatke oma sisemine laps magama ja kutsuge t\u00e4iskasvanu, v\u00f5i l\u00fckake arutelu edasi. Inimene teeb emotsionaalse otsuse ja seej\u00e4rel otsib sellele ratsionaalset p\u00f5hjendust. Otsus, mille laps teeb, l\u00e4htuvalt lasteprioriteetidest, ei ole optimaalne.<\/p>\n
Lisaks k\u00e4itumisele konflikti hetkedel iseloomustab lapse v\u00f5i t\u00e4iskasvanu positsioon ka vastutuse taset, mille inimene on valmis v\u00f5tma. \u00c4\u00e4rmuslikel juhtudel n\u00e4eb programmeerija lapse positsioon, mida ma olen korduvalt kohanud, v\u00e4lja nii: ma kirjutasin koodi, saatsin selle \u00fclevaatamiseks \u2014 minu t\u00f6\u00f6 on l\u00f5pule viidud. \u00dclevaatajad peavad selle vaatama ja liitma, QA peab selle kontrollima, kui esinevad mingid probleemid \u2014 nad teavitavad mind. Kummaline, kuid isegi \u00fcsna k\u00fcpsed ja kogenud inimesed k\u00e4ituvad m\u00f5nikord nii. Teine \u00e4\u00e4rmus on see, et inimene arvab, et ta on vastutav selle eest, et tema kood t\u00f6\u00f6taks, oleks testitud, kontrollitud tema poolt, edukalt \u00fcle vaadatud (kui vaja, pole probleemi \u00fclevaatajaid pingutada, arutada k\u00fcsimusi h\u00e4\u00e4lega jne.) ja oleks liidetud, QA abi osutatakse vajadusel, testimise stsenaariume kirjeldatakse jne. Tavalistes oludes on programmeerija kas algusest peale l\u00e4hemal t\u00e4iskasvanu \u00e4\u00e4rmus v\u00f5i nihkub sinna koos kogemuse kasvamisega (eeldusel, et meeskonnas viljeletakse \u00f5iget kultuuri). Ekstreemsetes juhtudes j\u00e4tkab ta tavaliselt lapse positsioonil t\u00f6\u00f6tamist, mille t\u00f5ttu esinevad tal ja meeskonnal perioodiliselt probleemid ja konfliktid.<\/p>\n
Meeskonnas \u00f5ige, t\u00e4iskasvanulik kultuuri kasvatamine on iga juhi oluline \u00fclesanne. See n\u00f5uab pikka aega ja igap\u00e4evaseid j\u00f5upingutusi, kuid tulemus on seda v\u00e4\u00e4rt. On kaks viisi, kuidas meeskonna kultuurile m\u00f5ju avaldada \u2014 isiklikud n\u00e4ited (millele j\u00e4rgivad kindlasti, meeskond j\u00e4lgib alati liidrit) ja \u00f5ige k\u00e4itumise arutamine ja julgustamine. Siin pole samuti midagi keerulist ega v\u00e4ga formaalset, lihtsalt probleemide arutamisel m\u00e4rkige, mida oleks saanud teha teisiti, r\u00f5hutage, et olete m\u00e4rganud, kui lahendus on \u00f5ige, kiitke, m\u00e4rkige \u00fcles v\u00e4ljaande anal\u00fc\u00fcsis jne.<\/p>\n
Vaatleme m\u00f5ned t\u00fc\u00fcpilised konfliktolukorrad, lihtsatest keerulisteni:<\/p>\n
Konfliktid, mis ei ole seotud t\u00f6\u00f6alaste k\u00fcsimustega<\/b><\/p>\n
T\u00f6\u00f6l esineb \u00fcsna tihti konflikte, mis ei ole otseselt seotud t\u00f6\u00f6alaste k\u00fcsimustega. Nende tekkimine ja kerge lahendamine on tavaliselt otseselt seotud osalejate emotsionaalse intelligentsuse tasemega, nende t\u00e4iskasvanu tasemega ja ei ole seotud t\u00f6\u00f6protsessi t\u00e4iuslikkuse v\u00f5i puudustega.<\/p>\n
T\u00fc\u00fcpilised n\u00e4ited - keegi ei kasuta pesumasinat v\u00f5i du\u0161\u0161i piisavalt sageli, millest \u00fcmbritsevad saavad t\u00fcdinud, m\u00f5nele on kitsas, aga teisele puhub, kui aken avada, keegi on liiga l\u00e4rmakas, samas kui teistele on t\u00f6\u00f6ks vajalik vaikus jne. T\u00fc\u00fcpiliste konfliktide lahendamisega ei tule venitada ega lase see iseenesest minna. Need ei lahene eraldi ja h\u00e4irivad t\u00f6\u00f6d ning m\u00fcrgitavad meeskonna atmosf\u00e4\u00e4ri. \u00d5nneks ei ole nende lahendamine tavaliselt suur probleem - piisab, kui r\u00e4\u00e4kida rahulikult (loomulikult silmast silma) kolleegiga, kes h\u00fcgieenist ei hooli, tagada mugav istumine neile, kes eelistavad vaikust v\u00f5i jahedust, osta helisummutavad k\u00f5rvaklapid v\u00f5i paigaldada vaheseinad jne. <\/p>\n
Teine n\u00e4ide, millega olen oma t\u00f6\u00f6aja jooksul paar korda kokku puutunud, on meeskonnaliikmete ps\u00fchholoogiline \u00fchilduvus. Miski p\u00e4rast ei saa inimesed lihtsalt koos t\u00f6\u00f6tada, iga suhtlemine l\u00f5peb skandaaliga. M\u00f5nikord on see seotud sellega, et inimesed j\u00e4\u00e4vad kinni polariseeritud arvamustesse m\u00f5nes p\u00f5letavas k\u00fcsimuses (tavaliselt poliitilises) ja ei oska neid t\u00f6\u00f6v\u00e4liselt j\u00e4tta. Nende veenmises teineteise talumisse v\u00f5i oma k\u00e4itumise muutmisse pole m\u00f5tet. Ainus erand, mida olen kohanud, on noored kolleegid avatud m\u00f5tlemisega, kelle k\u00e4itumist on veel v\u00f5imalik aegamisi muuta perioodiliste vestluste kaudu. Probleem lahendatakse tavaliselt nende erinevatesse meeskondadesse paigutamisega v\u00f5i v\u00e4hemalt tagades v\u00f5imaluse harva kokku puutuda.<\/p>\n
K\u00fcsimustes, mis on seotud k\u00f5ikide osalistega, tasub r\u00e4\u00e4kida isiklikult, arutada olukorda, uurida, kas nad n\u00e4evad sel juhul probleemi, ja k\u00fcsida, millised on nende arvates lahendusv\u00f5imalused, ning tagada nende osalus otsuste tegemisel.<\/p>\n
T\u00f6\u00f6poliitika optimeerimise aspektist (keskmise perspektiivi puhul, millest ma r\u00e4\u00e4kisin) ei saa siin palju teha, ainus v\u00f5imalus optimeerimiseks on arvestada \u00fchilduvust factorit meeskonna moodustamisel ja mitte panna kokku inimesi, kes v\u00f5ivad konflikte tekitada. <\/p>\n
Meeskonnakultuuri seisukohalt esinevad sellised olukorrad palju harvemini rikka kultuuriga meeskondades, kus inimesed respekteerivad oma tiimi ja kolleege ning suudavad k\u00fcsimused iseseisvalt lahendada. Lisaks lahendatakse sellised konfliktid palju lihtsamalt (tihti automaatselt) meeskondades, kus on k\u00f5rge usaldusv\u00e4\u00e4rsuse tase, inimesed on pikka aega koos t\u00f6\u00f6tanud ja\/v\u00f5i suhtlevad sageli v\u00e4ljaspool t\u00f6\u00f6d.<\/p>\n
T\u00f6\u00f6alaste k\u00fcsimustega seotud konfliktid:<\/b><\/p>\n
Sellised konfliktid on tavaliselt p\u00f5hjustatud m\u00f5lemast tegurist korraga: emotsionaalsest (kui m\u00f5ni osaleja ei ole t\u00e4iskasvanu positsioonil) ja t\u00f6\u00f6protsessi puudustest. K\u00f5ige sagedasem konfliktit\u00fc\u00fcp, millega olen kokku puutunud, on konfliktid koodireviie v\u00f5i arhitektuuri arutelu k\u00e4igus arendajate vahel. <\/p>\n
R\u00e4\u00e4giksin siin kahest t\u00fc\u00fcpilisest olukorrast:<\/p>\n
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\u00fcvenedes on see t\u00e4iesti konflikt. T\u00f6\u00f6aline k\u00fcsimus ei lahene, \u00fcks osapool (revii ootav) tunneb selgelt ebamugavust. Ekstreemne vorm sellisest olukorrast on arendamine kogukonnas v\u00f5i erinevates meeskondades, kus reviier v\u00f5ib olla mitte huvitatud just sellest konkreetsest koodist, kuna tal on liiga palju t\u00f6\u00f6d v\u00f5i muudel asjaoludel ei pruugi ta t\u00e4helepanu p\u00f6\u00f6rata reviik\u00fcsitlusele ning v\u00e4lise vahemehe (kelle \u00fclesanne on m\u00f5lema osapoole jaoks) ei pruugi \u00fcldse olla. <\/p>\n
L\u00e4htekoht, mis aitab selliste olukordade lahendamisel, on pigem pikaajaline, k\u00fcpse inimese kultuur. Esiteks tuleb rakendada m\u00f5istlikku aktiivsust. Ei tasu loota, et \u00fclevaatusele pandud kood t\u00f5mbab \u00fclevaataja t\u00e4helepanu iseenesest. Tuleb aidata \u00fclevaatajal seda m\u00e4rgata. Pinguta paar inimest, k\u00fcsi t\u00f5statatud k\u00fcsimusi, osale aruteludes. Ilmselgelt v\u00f5ib t\u00fc\u00fctus rohkem kahju teha kui kasu, seep\u00e4rast tasub kasutada hea sensoone. Teiseks, h\u00e4sti toimib ettevalmistamine. Kui meeskond m\u00f5istab, mis ja miks toimub, miks see kood \u00fcldse vajalik on, ning disain on eelnevalt arutletud ja koosk\u00f5lastatud, p\u00f6\u00f6ravad inimesed sellisele koodile t\u00f5en\u00e4olisemalt t\u00e4helepanu ja v\u00f5tavad selle kasutusele. Kolmandaks, autoriteet m\u00e4ngib suurt rolli. Kui soovid, et sind \u00fclevaatetaks \u2013 tee ise palju \u00fclevaateid. Tee kvaliteetseid \u00fclevaateid, t\u00f5eliste kontrollide, reaalse testimise ja kasulike kommentaaridega. Kui su h\u00fc\u00fcdnimi on meeskonnas tuntud heas valguses, on rohkem v\u00f5imalusi, et su koodile t\u00e4helepanu p\u00f6\u00f6ratakse.<\/p>\n
T\u00f6\u00f6poliitika seisukohalt on siinkohal v\u00f5imalikud t\u00e4iustused \u00f5ige prioriteetide seadmine, mille eesm\u00e4rk on aidata arendajal saavutada oma ja meeskonna eesm\u00e4rke (teiste \u00fclevaatamine, kogukonnas kirjade kirjutamine, koodi toetamine arhitektuuri, dokumentatsiooni ja testidega, osalemine kogukonna aruteludes jne), mitte lubada pat\u0161ide liiga pikka seismist j\u00e4rjekorras, ja nii edasi. <\/p>\n
2) Teine levinud juhtum konfliktide tekkes koodi v\u00f5i disaini \u00fclevaatamisel on erinevad arvamused tehniliste k\u00fcsimuste, koodimisstiili ja t\u00f6\u00f6riistade valiku osas. Usaldustase osalejate vahel, kuuluvus samasse meeskonda ja \u00fchiselt t\u00f6\u00f6tamise kogemus on selle juures \u00e4\u00e4rmiselt olulised. Takistus tekib siis, kui m\u00f5ni osalejatest v\u00f5tab lapsiku positsiooni ning ei p\u00fc\u00fca kuulata, mida vestluspartner talle \u00f6elda tahab. Sageli v\u00f5ivad m\u00f5lemad l\u00e4henemised, nii algne kui teise osapoole pakutud, edukalt toimida ja pole p\u00f5him\u00f5tteliselt oluline, milline neist valida. <\/p>\n
Kordagi programmist minu meeskonnast (\u00fctleme, et ta on Pasha) valmistas ette pat\u0161i pakettide juurutamise s\u00fcsteemi muudatustega, mida arendasid ja toetasid kolleegid naabruses asuvast osakonnast. \u00dchel neist (Igor) oli oma tugev arvamus, kuidas t\u00e4pselt seadeid Linuxis pakettide juurutamisel konfigureerida. See arvamus erines pat\u0161is pakutud l\u00e4henemisviisist ning nad ei suutnud kokku leppida. Nagu tavaliselt, ajasid t\u00e4htaegade piirangud neid l\u00f5ksu ning oli vaja leida mingi lahendus, keegi neist pidi v\u00f5tma t\u00e4iskasvanu positsiooni. Pasha tunnustas, et m\u00f5lemal l\u00e4hteviisil on \u00f5igust elule, kuid ta soovis, et tema variant saaks heakskiidu, kuna ei olnud selgeid tehnilisi eeliseid \u00fchegi variandi jaoks. <\/p>\n
Meie arutelu n\u00e4gi v\u00e4lja umbes nii (muidugi, see oli \u00fcsna skeemiline, tegelik vestlus kestis pool tundi): <\/p>\n
\u2014 Pasha, meil on paar p\u00e4eva \u00fclej\u00e4\u00e4nud enne funktsioonide k\u00fclmutamist. On oluline, et me k\u00f5ik kokku koguksime ja testimise v\u00f5imalikult kiiresti alustaksime. Kuidas me saame Igorist m\u00f6\u00f6da minna?
K\u00fcsimus lahendatud, v\u00e4ljaanne ilmus t\u00e4htajaks, Pasha ei olnud eriti rahulolematu, kuna ta ise pakkus lahendust ja tegi selle teoks. Igor oli \u00fcldiselt rahul, kuna tema arvamust arvestati ja tehti nii, nagu ta soovitas.<\/p>\n
Teine sarnase konflikti liik on valik tehniliste lahenduste\/raamatukogude\/meetodite vahel projektis, eriti jaotatud meeskonnas. \u00dches projektis, mida reklaamiti kui C\/C++ kasutavat, osutus l\u00f5puks, 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\u00e4ga harjunud. Selgus, et projekt on palju l\u00e4hemal C-le kui C++-le, mis ei olnud meeskonnale just inspireeriv, kuna juhtkond oli kokku pannud t\u00f5eliselt \u00e4gedad C++ arendajad. Samal ajal t\u00f6\u00f6tasid Ameerika meeskonna liikmed, nii insenerid kui juhid, ettev\u00f5ttes juba pikka aega, nad olid harjunud olemasoleva olukorraga ja k\u00f5ik oli nende jaoks okei. Venemaa meeskond koguti kokku alles hiljuti, vaid paar n\u00e4dalat enne (sealhulgas mind). Venemaa meeskond ei soovinud kategooriliselt loobuda oma harjumusp\u00e4rasest arendusmeest.<\/p>\n
Alustasid l\u00f5putud 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\u00f5tteid STL tehniliste eeliste kohta, kui h\u00e4sti see on testitud, kui ohutu see on, ja \u00fcldiselt, kui ilus on elu selle kasutamisel ja kui hirmus ilma selleta. <\/p>\n
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<\/i> 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.<\/p>\n
\u0421 \u0442\u043e\u0447\u043a\u0438 \u0437\u0440\u0435\u043d\u0438\u044f \u0440\u0430\u0431\u043e\u0447\u0435\u0433\u043e \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430, \u0432 \u044d\u0442\u043e\u043c \u043a\u043e\u043d\u043a\u0440\u0435\u0442\u043d\u043e\u043c \u0441\u043b\u0443\u0447\u0430\u0435, \u043f\u043e\u043c\u043e\u0433\u043b\u043e \u0431\u044b \u043d\u0430\u043b\u0438\u0447\u0438\u0435 \u043e\u043f\u0438\u0441\u0430\u043d\u0438\u044f \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c\u044b\u0445 \u0441\u0440\u0435\u0434\u0441\u0442\u0432, \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u044f \u043a \u043d\u0438\u043c, \u043e\u0433\u0440\u0430\u043d\u0438\u0447\u0435\u043d\u0438\u044f \u043d\u0430 \u0434\u043e\u0431\u0430\u0432\u043b\u0435\u043d\u0438\u0435 \u043d\u043e\u0432\u044b\u0445, \u043e\u0431\u043e\u0441\u043d\u043e\u0432\u0430\u043d\u0438\u0435 \u0442\u0430\u043a\u0438\u0445 \u043e\u0433\u0440\u0430\u043d\u0438\u0447\u0435\u043d\u0438\u0439. \u0422\u0430\u043a\u0438\u0435 \u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442\u044b \u043f\u0440\u0438\u043c\u0435\u0440\u043d\u043e \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u044e\u0442 \u043e\u043f\u0438\u0441\u0430\u043d\u043d\u044b\u043c \u0432 \u043f\u0443\u043d\u043a\u0442\u0430\u0445 Reuse Strategy \u0438 Development Environment \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0441\u0442\u0432\u0430 \u201cManager’s Handbook for Software Development\u201d, \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043d\u043d\u043e\u0433\u043e \u0432 NASA<\/a><\/noindex>. 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.<\/p>\nFrom 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.<\/p>\n
Teises konfliktis seoses tehnilise lahenduse valikuga kulus mul samuti m\u00e4rkimisv\u00e4\u00e4rselt aega, et m\u00f5ista \u00fche poole motivatsiooni (juhtum oli t\u00f5eliselt ebatavaline), kuid kui motivatsioon oli selge, siis lahendus oli ilmselge. <\/p>\n
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\u00e4nn ning kasutas ainult t\u00f6\u00f6riistu ja operatsioonis\u00fcsteeme, mille allikakood on avalikult kergesti k\u00e4ttesaadav ja mis kasutavad avalikult kirja pandud protokolle. Skype ei kuulu selliste t\u00f6\u00f6riistade hulka. Kulutasime tohutult aega selle l\u00e4henemise eeliste ja puuduste arutamisele, Skype'i analoogide k\u00e4ivitamise katsetele erinevates operatsioonis\u00fcsteemides, Stasele meeskonda teise standardisse \u00fclemineku veenmise katsetele, talle isiklikele e-kirjade saatmisele, isiklikele k\u00f5nede tegemise katsetele, talle teise arvuti ostmisele spetsiaalselt Skype'i jaoks jne. L\u00f5puks m\u00f5istsin, et see probleem ei olnud tegelikult mitte tehniline, mitte korralduslik, vaid pigem maailmavaateline, v\u00f5iks isegi \u00f6elda, et religioosne (Stase jaoks). Isegi kui me l\u00f5puks \u00fchendasime Stase ja Skype'i (milleks l\u00e4ks juba mitu kuud), tekiks probleem j\u00e4rgneva t\u00f6\u00f6riistaga uuesti. Mul ei olnud tegelikult vahendeid Stase maailmavaate muutmiseks ja ei olnud aluseid proovida muuta ka meeskonna maailmavaadet, mis t\u00f6\u00f6tas selles keskkonnas suurep\u00e4raselt. Inimene ja ettev\u00f5te olid lihtsalt maailmavaate poolest ortogonaalsed. Taolistes olukordades on hea lahendus - korralduslik. Me viisin Stase teise meeskonda, kus ta sobis paremini.<\/p>\n
Selle konflikti p\u00f5hjus, minu arvates, tuleneb konkreetse inimese isikliku kultuuri (kellel on tugev arvamus, mis ei lase tal kompromisse teha) ja ettev\u00f5tte kultuuri mittesobivusest. Antud juhul on see muidugi juhtija eksimus. Alguses oli vale v\u00f5tta teda sellisesse projekti. Stas l\u00f5puks siirdus avatud tarkvara arendusprojekti ja edenes seal suurep\u00e4raselt.<\/p>\n
Hea n\u00e4ide konfliktist, mis on p\u00f5hjustatud samal ajal arendaja lapsemeelsest l\u00e4henemisest ja t\u00f6\u00f6protsessi puudustest \u2014 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 \u00fcleandmisest QA-le \u2014 seal nad saavad hakkama. T\u00f5eliselt k\u00fcps ja kogenud programmeerija, aga tal oli selline sisemine kvaliteedi l\u00e4vend. QA polnud sellega n\u00f5us ja n\u00f5udis, et ta n\u00e4itaks ja selgitaks, mida ta ise kontrollis, ning nad n\u00f5udsid testimistsenaariumi. Neil oli juba varem olnud probleeme selle arendaja funktsionaalsusega ja nad ei tahtnud enam aega raisata. \u00dcldiselt olid nad \u00f5iged \u2014 funktsioon t\u00f5epoolest ei t\u00f6\u00f6tanud, sest ta ei kontrollinud koodi 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 ja ta pidi selle parandama), r\u00e4\u00e4kisime meeskonna ja QA-ga definition of done'ist (me ei teinud seda kirjalikuks, kuna ei tahtnud protsessi liiga b\u00fcrokraatlikuks muuta), ning peagi lahkusime selle spetsialistiga (\u00fclevaateks oli see kogu meeskonnale kergendav).<\/p>\n
T\u00f6\u00f6protsessi vaatenurgast on v\u00f5imalikud parandused antud juhul \u2014 definition of done'i olemasolu, n\u00f5uded iga funktsiooni toetamiseks unit- ja integratsioonitestidega, arendaja l\u00e4biviidud testimise kirjeldus. \u00dches projektis m\u00f5\u00f5tsime testidega koodikatvust CI ajal ja juhul, kui katvus p\u00e4rast pat\u0161i lisamist langes, m\u00e4rgiti testid eba\u00f5nnestunuks, st uue koodi lisamine oli v\u00f5imalik ainult siis, kui sellele olid olemas uued testid. <\/p>\n
Veel tavaline konflikt, mis on tihedalt seotud t\u00f6\u00f6protsessi korraldamisega. Meil on toode, tootearendusmeeskond, tugimeeskond ja klient. Klientidel on toote suhtes probleeme ning nad p\u00f6\u00f6rduvad toetuse poole. Tugi anal\u00fc\u00fcsib probleemi ja m\u00f5istab, et probleem on tootes, ning edastab probleemi tootemeeskonnale. Tootemeeskonnal on tihe aeg, versioon on peagi v\u00e4ljas, seega j\u00e4\u00e4b kliendi probleemipilet arendaja seas kadunuks ja ripub n\u00e4dalate viisi t\u00e4helepanuta. Tugi arvab, et arendaja t\u00f6\u00f6tab kliendi probleemiga. Klient ootab ja loodab, et tema probleemiga tegeletakse. Tegelikult ei toimu midagi. M\u00f5ne n\u00e4dala p\u00e4rast otsustab klient l\u00f5puks uurida edusamme ja k\u00fcsib toelt, kuidas l\u00e4heb. Tugi k\u00fcsib arenduse k\u00e4est. Arendaja ehmatab, vaatab probleemipiletite nimekirja ja leiab sealt kliendi pilet. Klientide piletit lugedes m\u00f5istab ta, et probleemi lahendamiseks pole piisavalt teavet ja tal on vaja veel logisid ja m\u00e4lupilte. Tugi k\u00fcsib kliendilt t\u00e4iendavat teavet. Ja siis m\u00f5istab klient, et tema probleemiga ei ole keegi selle aja jooksul t\u00f6\u00f6tanud. Ja m\u00fcrin kohiseb ...<\/p>\n
Selles olukorras on konflikti lahendus \u00fcsna selge ja lineaarne (toote parandamine, dokumentatsiooni ja testide uuendamine, kliendi rahustamine, kiirparanduse v\u00e4ljalaskmine jne). Oluline on anal\u00fc\u00fcsida t\u00f6\u00f6protsessi ja m\u00f5ista, kes vastutab kahe meeskonna vahekorra korraldamise eest, miks selline olukord \u00fcldse v\u00f5imalikuks sai. Selge on, et protsessi tuleb midagi parandada \u2014 keegi peaks j\u00e4lgima \u00fcldpilti ilma klientide meeldetuletusteta, proaktiivselt. Klientide piletid peaksid eristuma arendajate teiste probleemipiletite seas. Tugi peaks n\u00e4gema, kas arendus t\u00f6\u00f6tab nende piletite kallal hetkel, kui ei \u2014 millal saavad nad t\u00f6\u00f6le hakata, millal oodata tulemusi. Tugi ja arendus peaksid aeg-ajalt suhtlema ning arutama piletite staatust, vajaliku teabe kogumine silumisteks peaks olema maksimaalselt automatiseeritud jne.<\/p>\n
Nii nagu s\u00f5da, \u00fcritab vastane l\u00fc\u00fca kahe \u00fcksuse vahelt, on ka t\u00f6\u00f6s tavaliselt k\u00f5ige \u00f5rnem ja haavatavam koht meeskondade vaheline koost\u00f6\u00f6. Kui tugimeeskonna ja arendajate juhid on piisavalt k\u00fcpsed, suudavad nad protsessi ise parandada; kui ei, siis j\u00e4tkab protsess konfliktide ja probleemide genereerimist, kuni sekkub juht, kes olukorra lahendab.<\/p>\n
Teine iseloomulik n\u00e4ide, mida olen erinevates ettev\u00f5tetes korduvalt kohanud, on olukord, kus toote arendamine toimub \u00fche meeskonna poolt, automaatsete integratsioonitestide loomiseks on teine meeskond ja infrastruktuuri haldab kolmas meeskond. Testide k\u00e4itamisel tekivad pidevalt probleemid, mille p\u00f5hjuseks v\u00f5ivad olla nii toode kui ka testid ja infrastruktuur. Probleemiks on sageli leppida kokku, kes peaks esialgse probleemianal\u00fc\u00fcsi tegema, vead registreerima, toote, testide ja infrastruktuuri logisid anal\u00fc\u00fcsima jne. Konfliktid on siin \u00fcsna tavalised ja samas \u00fchtsed. Suure emotsionaalse pingega olukordades liikuvad osalised sageli lapsep\u00f5lve seisundisse ja arutelud muutuvad selliseks: \u201cmiks ma pean sellega tegelema\u201d, \u201cneil juhtub sagedamini rikkeid\u201d jne. <\/p>\n
T\u00f6\u00f6protsessi vaatenurgast s\u00f5ltuvad konkreetsed sammud probleemi lahendamiseks meeskondade koosseisust, testide t\u00fc\u00fcbist ja tootest jne. \u00dches projektis kehtestasime perioodilised vahetused, kus meeskonnad j\u00e4lgisid testide k\u00e4iku vaheldumisi, n\u00e4dal kaupa. Teises projektis tegid esialgse anal\u00fc\u00fcsi alati testide arendajad, kuid anal\u00fc\u00fcs oli \u00fcsna p\u00f5hiline ja toode oli piisavalt stabiilne, nii et see toimis h\u00e4sti. Peamine on tagada protsessi l\u00e4bipaistvus, selged ootused k\u00f5igile osalistele ja \u00f5iglane olukorra tunne k\u00f5igi jaoks.<\/p>\n
Kas konflikt organisatsioonis on probleem? Kas on halb m\u00e4rk, et teie meeskonnas tekivad konfliktid sageli (v\u00f5i lihtsalt perioodiliselt)? \u00dcldiselt mitte, kuna kui toimub kasv, areng ja mingit t\u00fc\u00fcpi d\u00fcnaamika, kerkivad k\u00fcsimused, mis pole kunagi varem lahendatud, ning nende lahendamisel v\u00f5ivad tekkida konfliktid. See on n\u00e4itaja, et mingitele valdkondadele tuleks t\u00e4helepanu p\u00f6\u00f6rata ja et on arenguv\u00f5imalusi. Halb on see, kui konfliktid tekivad liiga sageli ja neid on keeruline v\u00f5i aegan\u00f5udev lahendada. See on t\u00f5en\u00e4oliselt m\u00e4rk piisavalt talitsetud t\u00f6\u00f6protsesside ja meeskonna k\u00fcpsuse puudumisest.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-news"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Konfliktide](\"\/wp-content\/uploads\/2019\/07\/de379c9eedec8cecda6651b5339a0277.jpg\")