Epigraaf:
Kunagi ammu kohtusid Siil ja Karuke metsas.
- Tere, Siil!
- Tere, Väike Karu!
Nii et sõna-sõnalt, nali naljalt sai Siil Karukese käest näkku...
Allpool on meie tiimijuhi, aga ka RAS-i tootearendusdirektori Igor Marnati arutelu töökonfliktide spetsiifikast ja võimalikest meetoditest nende lahendamiseks.
Enamik konflikte, millega me tööl kokku puutume, arenevad sarnase stsenaariumi järgi, nagu on kirjeldatud ülaltoodud epigraafis. On mitmeid osalejaid, kes on alguses üksteise suhtes üsna soosivalt suhtunud, püüavad mõnd probleemi lahendada, kuid lõpuks jääb probleem lahendamata ning arutelus osalejate vahelised suhted osutuvad millegipärast rikutuks.
Elu on mitmekesine ja ülalkirjeldatud stsenaariumi puhul esineb variatsioone. Mõnikord ei ole osalejate vahelised suhted alguses kuigi head, mõnikord pole isegi otsest lahendamist vajavat küsimust (nagu näiteks epigraafis), mõnikord jääb pärast arutelu suhe samaks, mis enne selle algust, kuid probleem ei lahene lõpuks.
Mis on ühist kõigis olukordades, mida saab määratleda töökonflikti olukorrana?
Esiteks on sellel kaks või enam külge. Need osapooled võivad asuda organisatsioonis erinevatel kohtadel, olla võrdõiguslikes suhetes (kolleegid meeskonnas) või hierarhia erinevatel tasanditel (ülemus - alluvad), olla üksikisikud (töötaja) või rühmad (konfliktide korral töötaja ja meeskond või kaks meeskonda) ja nii edasi. Konflikti tõenäosust ja selle lahendamise lihtsust mõjutab suuresti osalejate vaheline usaldus. Mida paremini osapooled üksteist tunnevad, seda suurem on usaldus, seda suurem on võimalus kokkuleppele jõuda. Näiteks hajutatud meeskonna liikmed, kes pole kunagi näost näkku suhelnud, kogevad tõenäolisemalt konflikte lihtsa tööprobleemi pärast kui inimesed, kes on vähemalt paar korda näost näkku suhelnud. Seetõttu on hajutatud meeskondades töötades väga oluline tagada, et kõik meeskonnaliikmed kohtuksid perioodiliselt üksteisega isiklikult.
Teiseks on osapooled tööalase konflikti olukorras olukorras, kus lahendatakse mõni küsimus, mis on oluline ühe osapoole, mõlema või organisatsiooni kui terviku jaoks. Samas on osapooltel olukorra eripärast tulenevalt tavaliselt piisavalt aega ja erinevaid viise selle lahendamiseks (ametlikud, mitteametlikud, koosolekud, kirjad, juhtimisotsused, meeskonna eesmärkide ja plaanide olemasolu, hierarhia fakt jne). See erineb olukorrast, kus organisatsioonis töö- (või mittetöö-)probleemi lahendatakse näiteks olulise küsimuse lahendamisega: "Eh, poiss, mis piirkonnast sa pärit oled?!" tänaval või konflikt epigraafist. Tööküsimuse lahendamise puhul loeb tööprotsessi kvaliteet ja küsimuste lahendamise kultuur meeskonnas.
Kolmandaks on konflikti määrav tegur (meie arutelu seisukohalt) asjaolu, et protsessi osapooled ei suuda iseseisvalt jõuda probleemile kõigile osapooltele sobiva lahenduseni. Olukord nõuab kolmanda osapoole, välise vahekohtuniku sekkumist. See punkt võib tunduda vastuoluline, kuid sisuliselt, kui konfliktiolukord lahenes edukalt ilma välise vahekohtuniku sekkumiseta, probleem lahenes edukalt ja osapoolte suhted ei halvenenud, on see olukord, mille poole peaksime püüdlema. . Tõenäoliselt ei saa me sellisest konfliktist isegi teada või saame teada juhuslikult pärast selle lahendamist. Mida rohkem probleeme suudab meeskond ise lahendada, seda tõhusam see on.
Teine konflikti iseloomulik tunnus, mida tasub puudutada, on emotsionaalse intensiivsuse määr otsuse tegemise ajal. Konflikt ei pruugi olla seotud kõrge emotsionaalse tasemega. Osalejad ei pea karjuma ja kätega vehkima, et olukord oleks sisuliselt konflikt. Teema ei lahene, esineb teatud emotsionaalne pinge (võib-olla ei väljendu see selgelt väljapoole), mis tähendab, et oleme silmitsi konfliktiolukorraga.
Kas konfliktiolukordadesse on üldse vaja sekkuda või on parem lasta nende lahendamisel omasoodu ja oodata, kuni probleem laheneb iseenesest? Vaja. Konflikti täielik lahendamine ei ole alati teie võimuses ega pädevuses, kuid igas olukorras, mis tahes ulatusega konfliktis võite võtta täiskasvanu positsiooni, tuues sellega enda ümber veel mitu inimest, leevendades konflikti negatiivseid tagajärgi. konflikti ja aidata kaasa selle lahendamisele.
Enne kui vaatame mõnda näidet konfliktsituatsioonidest, vaatleme mõnda olulist punkti, mis on kõigi konfliktide jaoks ühised.
Konflikti lahendamisel on oluline olla võitlusest kõrgemal, mitte selle sees (seda nimetatakse ka "metapositsiooni võtmiseks"), st mitte olla osaline lahendusprotsessis. Vastasel juhul tugevdab välise vahekohtuniku abi otsustamisel ainult ühe poole positsiooni teise poole kahjuks. Otsuse tegemisel on oluline, et kõik osapooled seda moraalselt aktsepteeriksid, nagu öeldakse, "ostetud". Nii et isegi kui osapooled tehtud otsuse üle ei rõõmustanud, olid nad vähemalt siiralt nõus seda ellu viima. Nagu öeldakse, et olla eriarvamusel ja pühenduda. Vastasel juhul muudab konflikt lihtsalt oma välimust, hõõguv tuli jääb turbaraba alla ja lahvatab ühel hetkel paratamatult uuesti.
Teine punkt, mis on osaliselt seotud esimesega, on see, et kui olete juba otsustanud konflikti lahendamises osaleda, võtke seda suhtluse ja konteksti uurimise seisukohast võimalikult tõsiselt. Rääkige iga osapoolega isiklikult. Alustuseks igaühega eraldi. Ärge leppige postiga. Hajutatud meeskonna puhul räägi vähemalt videolingi kaudu. Ärge rahulduge kuulduste ja pealtnägijate aruannetega. Saate aru loost, mida kumbki pool soovib, miks nad seda tahavad, mida nad ootavad, kas nad on proovinud seda probleemi varem lahendada, mis juhtub, kui seda ei lahendata, milliseid lahendusi nad näevad, kuidas nad kujutavad ette oma positsiooni teine pool, mida nad arvavad, kas õige või vale jne. Laadige avatud meelega pähe kogu võimalik kontekst, eeldades, et kõigil on õigus. Sa ei ole konflikti sees, vaid väljaspool seda, metapositsioonis. Kui kontekst on saadaval ainult postituslõimes, lugege seda vähemalt tervikuna ning sellega seotud lõime ja dokumente. Pärast selle lugemist rääkige ikka oma häälega. Peaaegu garanteeritud on, et kuulete midagi olulist, mida kirjas pole.
Kolmas oluline punkt on üldine lähenemine suhtlemisele. Need on tavalised asjad, ei midagi kosmilist, kuid need on väga olulised. Me ei püüa aega kokku hoida, räägime kõigi osalejatega, ei kritiseeri inimest, vaid arvestame tema tegude tagajärgedega (mitte “sa oled ebaviisakas”, vaid “võib-olla võivad poisid solvuda see asi”), anname võimaluse säästa nägu, viime läbi arutelusid isiklikult, mitte rivi ees.
Konfliktid on tavaliselt põhjustatud ühel kahest põhjusest. Esimene on seotud sellega, kas inimene on konflikti hetkel täiskasvanu või lapse positsioonis (sellest lähemalt allpool). See on tingitud tema emotsionaalsest küpsusest, oskusest oma emotsioone juhtida (mis, muide, ei ole alati seotud tema vanusega). Teiseks levinud põhjuseks on tööprotsessi ebatäiuslikkus, mis tekitab hallide alade olukordi, kus vastutus on osalejate vahel hajutatud, osapoolte ootused ei ole üksteisele läbipaistvad ning rollid protsessis hägustuvad.
Sellest tulenevalt peab juht konflikti (nagu ka mis tahes muu probleemi) lahendamisel silmas pidama kolme vaatenurka: lühiajaline – lahendada probleem/konflikt siin ja praegu, keskpikk – minimeerida uue konflikti tekkimise tõenäosust. samal põhjusel ja pikaajaliselt - kasvatada meeskonnainimeses täiskasvanulikku kultuuri.
Igaühel meist on sisemine laps, umbes kolme-neljaaastane. Ta magab suurema osa ajast tööl, kuid vahel ärkab ja võtab kontrolli enda kätte. Lapsel on oma prioriteedid. Tema jaoks on oluline rõhutada, et see on tema liivakast, ema armastab teda rohkem, tema masin on parim (disain on parim, tema programmeerib kõige paremini, ...). Laps võib konfliktiolukorras mänguasju vajutada, jalgu trampida ja spaatlit lõhkida, kuid täiskasvanuga seotud probleeme (lahenduse arhitektuur, lähenemised automatiseeritud testimisele, väljalaskekuupäevad jne) ta lahendada ei suuda, ta ei mõtle kasu peale. meeskonna jaoks. Konflikti sattunud last saab julgustada, lohutada ja magama saata, paludes tal oma täiskasvanule helistada. Enne konfliktsituatsioonis arutelu alustamist veendu, et räägid täiskasvanuga, mitte lapsega ning oled ise täiskasvanu positsioonis. Kui teie aus eesmärk on hetkel mõni tõsine probleem lahendada, olete täiskasvanud inimese positsioonis. Kui teie eesmärk on jalgu trampida ja abaluu lõhki lüüa, on see lapsik asend. Saatke oma sisemine laps voodisse ja helistage täiskasvanule või määrake arutelu ümber. Inimene teeb emotsionaalse otsuse ja otsib sellele siis ratsionaalset põhjendust. Otsus, mille laps teeb laste prioriteetide põhjal, ei ole optimaalne.
Lisaks konfliktiaegsele käitumisele iseloomustab lapse või täiskasvanu positsiooni ka vastutuse tase, mida inimene on valmis enda peale võtma. Oma äärmuslikes ilmingutes näeb programmeerija lapsik positsioon, mida olen korduvalt kohanud, selline: kirjutasin koodi, saatsin ülevaatamiseks - minu töö on valmis. Ülevaatajad peaksid selle üle vaatama ja heaks kiitma, QA kontrollima, kui on probleeme, siis annavad teada. Kummalisel kombel käituvad mõnikord isegi üsna küpsed ja kogenud inimesed nii. Skaala teine ots on see, et inimene peab end vastutavaks selle eest, et tema kood töötaks, oleks testitud, on tema poolt isiklikult kontrollitud, läbinud edukalt läbivaatuse (vajadusel pole probleemi arvustajaid pingida, probleeme arutada häälega jne) ja on maha surutud , QA pakub vajadusel abi, kirjeldatakse katsestsenaariume jne. Tavalistel juhtudel alustab programmeerija skaala täiskasvanud otsast lähemalt või liigub sinna, kui ta kogemusi omandab (eeldusel, et meeskonnas kasvatatakse õiget kultuuri). Äärmuslikel juhtudel jätkab ta tööd, võttes tavaliselt lapseliku positsiooni, siis on tal ja meeskonnal perioodiliselt probleeme ja konflikte.
Õige, küpse kultuuri edendamine meeskonnas on iga juhi jaoks oluline ülesanne. See võtab palju aega ja igapäevast pingutust, kuid tulemus on seda väärt. Meeskonnakultuuri mõjutamiseks on kaks võimalust – eeskuju näitamine (mida kindlasti järgitakse; meeskond vaatab alati juhi poole) ning õige käitumise arutamine ja premeerimine. Siin pole ka midagi abstraktset ega väga formaalset, lihtsalt probleemide üle arutledes märka, et siin oleks võinud midagi ette võtta, rõhuta, et märkasid, millal õigesti otsustati, kiita, märkige väljalaskeülevaate käigus vms.
Vaatleme mitut tüüpilist konfliktiolukorda, alates lihtsast kuni keeruliseni:
Tööprobleemidega mitteseotud konfliktid
Üsna sageli tuleb tööl ette konflikte, mis ei ole seotud tööteemadega. Nende esinemine ja lahendamise lihtsus on tavaliselt otseselt seotud osalejate emotsionaalse intelligentsuse tasemega, nende küpsusastmega ega ole seotud tööprotsessi täiuslikkuse või ebatäiuslikkusega.
Tüüpilised näited: keegi ei kasuta piisavalt sageli pesumasinat või dušši, mis teistele ei meeldi, keegi on lämbe, samas kui teised saavad akna avamisel tuul, keegi on liiga lärmakas ja teised vajavad töötamiseks vaikust ja nii edasi. Parem on mitte viivitada seda tüüpi konfliktide lahendamisega ja mitte lasta neil minna oma rada. Nad ei lahene iseenesest ja segavad teid iga päev töölt ja mürgitavad meeskonna õhkkonda. Õnneks ei ole nende lahendamine enamasti suur probleem – rääkige lihtsalt rahulikult (üks-ühele muidugi) hügieeni eirava kolleegiga, tagage vaikust/jahedust eelistavatele inimestele mugav istekoht, ostke helisummutavad kõrvaklapid või paigaldage vaheseinad. , jne.
Teine näide, millega oma töö käigus korduvalt kokku puutusin, on meeskonnaliikmete psühholoogiline sobimatus. Millegipärast ei saa inimesed lihtsalt koostööd teha, iga suhtlus lõpeb skandaaliga. Mõnikord on see tingitud asjaolust, et inimestel on mõnes pakilises (tavaliselt poliitilises) küsimuses polaarsed vaated ja nad ei tea, kuidas neid tööst kõrvale jätta. Nende veenmine üksteist taluma või oma käitumist muutma on üsna mõttetu ülesanne. Ainus erand, kellega olen kokku puutunud, on avatud arusaamadega noored kolleegid, kelle käitumist saab perioodiliste vestluste kaudu siiski järk-järgult muuta. Tavaliselt lahendatakse probleem edukalt, eraldades nad erinevatesse meeskondadesse või vähemalt pakkudes võimalust tööl väga harva kattuda.
Kõigis ülaltoodud olukordades tasub kõigi osalejatega isiklikult rääkida, olukorda arutada, küsida, kas nad näevad antud juhul üldse probleemi, küsida, millised on nende arvates lahendused ning tagada nende osalemine selle tegemisel. otsus.
Tööprotsessi optimeerimise (keskpika perspektiivi, mida mainisin) seisukohast ei saa siin palju teha, optimeerimise ainus punkt on meeskonna moodustamisel arvestada ühilduvusteguriga ja mitte panna inimesi. eelnevalt kokku, kes konflikti lähevad.
Meeskonnakultuuri vaatenurgast tuleb selliseid olukordi palju harvemini ette küpse kultuuriga meeskondades, kus inimesed austavad meeskonda ja kolleege ning oskavad probleeme iseseisvalt lahendada. Lisaks lahenevad sellised konfliktid palju lihtsamini (sageli automaatselt) meeskondades, kus on suur usaldus, inimesed on pikka aega koos töötanud ja/või suhtlevad sageli väljaspool tööd.
Tööprobleemidega seotud konfliktid:
Selliseid konflikte põhjustavad tavaliselt mõlemad põhjused korraga, nii emotsionaalsed (see, et üks osalejatest ei ole täiskasvanu positsioonis) kui ka tööprotsessi enda ebatäiuslikkus. Võib-olla on kõige levinumad konfliktid, millega olen kokku puutunud, konfliktid koodiülevaatuste või arendajatevaheliste arhitektuurialaste arutelude ajal.
Tooksin siin välja kaks tüüpilist juhtumit:
1) Esimesel juhul ei saa arendaja kolleegilt koodi ülevaadet. Plaaster saadetakse ülevaatamiseks ja midagi ei juhtu. Esmapilgul ei ole kahe poole vahel ilmselget konflikti, kuid kui järele mõelda, on see üsna suur konflikt. Tööprobleem ei lahene, üks osapool (ootab arvustust) kogeb ilmset ebamugavust. Selle juhtumi äärmuslik alatüüp on arendus kogukonnas või erinevates meeskondades, samas kui ülevaataja ei pruugi laadimise või muude asjaolude tõttu sellest konkreetsest koodist huvitatud olla, ei pruugi ülevaatustaotlusele üldse tähelepanu pöörata ning väline vahekohtunik (mõlemal poolel ühine juht) ) ei pruugi üldse olemas olla.
Lahenduskäsitlus, mis sellises olukorras aitab, seostub just pikaajalise perspektiiviga, täiskasvanu kultuuriga. Esiteks toimib nutikas tegevus. Te ei tohiks eeldada, et arvustusel rippuv kood tõmbab arvustaja enda tähelepanu. Peame aitama arvustajatel teda märgata. Pingani paar inimest, esitage sünkroonis küsimus, osalege aruteludes. Ilmselgelt teeb ülekohus pigem kahju kui abi, tuleb kasutada tervet mõistust. Teiseks toimib hästi eelnev ettevalmistus. Kui meeskond saab aru, mis ja milleks toimub, milleks seda koodi üldse vaja on, kujundus on kõigiga eelnevalt läbi arutatud ja kokku lepitud, siis on suurem tõenäosus, et inimesed pööravad sellisele koodile tähelepanu ja võtavad selle tööle. Kolmandaks, autoriteet toimib. Kui soovite, et teid arvustatakse, tehke palju arvustusi ise. Tehke kvaliteetseid arvustusi tõeliste kontrollide, tõeliste testide ja kasulike kommentaaridega. Kui teie hüüdnimi on meeskonnas hästi tuntud, on suurem tõenäosus, et teie koodi märgatakse.
Töövoo seisukohalt on siin võimalikud täiustused õige prioriteetide seadmine, mille eesmärk on aidata arendajal enda ja meeskonna eesmärke saavutada (üle vaadata teised, kirjutada kogukonnale kirju, lisada koodile arhitektuuri kirjeldus, dokumentatsioon, testid, osaleda aruteludes kommuun jne), vältige plaastrite liiga kaua järjekorda rippumist jne.
2) Teine levinud konfliktide juhtum koodi või disaini ülevaatamisel on erinevad vaated tehnilistele probleemidele, kodeerimisstiilile ja tööriistade valikule. Suur tähtsus on antud juhul osalejatevahelisel usaldusel, samasse meeskonda kuulumisel ja koos töötamise kogemusel. Ummik tekib siis, kui üks osalejatest võtab lapseliku positsiooni ega püüa kuulda, mida vestluskaaslane talle edastada tahab. Sageli võivad nii teise poole pakutud kui ka algselt pakutud lähenemisviis edukalt toimida ning põhimõtteliselt pole vahet, kumba valida.
Ühel päeval valmistas minu meeskonna programmeerija (nimetagem teda Pashaks) pakettide juurutussüsteemi muudatustega plaastri, mille töötasid välja ja toetasid kolleegid naaberosakonnast. Ühel neist (Igor) oli oma kindel arvamus selle kohta, kuidas Linuxi teenuseid pakettide juurutamisel täpselt konfigureerida. See arvamus erines plaastris pakutud lähenemisviisist ja nad ei saanud nõustuda. Nagu tavaliselt, olid tähtajad otsa saamas ja oli vaja mingi otsus teha, üks neist pidi võtma täiskasvanud ametikoha. Pasha tunnistas, et mõlemal lähenemisel on õigus elule, kuid ta tahtis, et tema valik mööduks, sest Ei ühel ega teisel variandil polnud ilmseid tehnilisi eeliseid.
Meie arutelu nägi välja umbes selline (väga skemaatiliselt kestis vestlus muidugi pool tundi):
- Pasha, meil on mõne päeva pärast funktsioon külmutatud. On oluline, et võtaksime kõik kokku ja alustame testimist niipea kui võimalik. Kuidas me Igorist läbi saame?
— Ta tahab teenuseid teisiti seadistada, ta torkas mulle sinna kommentaarid...
- Ja mis seal on, suured ümberehitused, palju kära?
- Ei, paar tundi on tööd, aga lõppkokkuvõttes pole vahet, see töötab mõlemal juhul, miks see vajalik on? Tegin midagi, mis töötab, võtame selle vastu.
- Kuule, kui kaua sa seda kõike arutanud oled?
- Jah, me oleme juba poolteist nädalat aega märkinud.
- Hm... kas me saame paari tunniga lahendada probleemi, mis on võtnud juba poolteist nädalat, ja mitte teha?
- Noh, jah, aga ma ei taha, et Igor arvaks, et ma andsin alla...
- Kuulge, mis on teie jaoks tähtsam, kas vabastada koos oma sisemise otsusega või tappa Igor? Saame selle blokeerida, kuid siis on hea võimalus vabastamisega läbi lennata.
- Noh... muidugi oleks lahe Igori nina pühkida, aga okei, vabastamine on tähtsam, nõustun.
- Kas teile on tõesti nii oluline, mida Igor arvab? Ausalt öeldes ei pane ta põrmugi, ta tahab lihtsalt ühtset lähenemist asjadele, mille eest ta vastutab.
- Noh, ok, las ma teen nii, nagu ta kommentaarides palub, ja hakkame testima.
- Aitäh, Pasha! Olin kindel, et teie kahest olete küpsem, kuigi Igorek on teist vanem :)
Probleem lahendati, väljalase ilmus õigel ajal, Pasha ei tundnud erilist rahulolematust, sest ta ise pakkus välja lahenduse ja viis selle ellu. Igor oli üldiselt rahul, sest... Tema arvamust võeti arvesse ja nad tegid nii, nagu ta soovitas.
Teine sisuliselt sama konflikti tüüp on valik tehniliste lahenduste/teekide/lähenemiste vahel projektis, eriti hajutatud meeskonnas. Ühes projektis, mis positsioneeriti C/C++ kasutavaks, selgus, et projekti tehniline juhtimine oli kategooriliselt STL-i (Standard Template Library) vastu. See on standardne keeleteek, mis lihtsustab arendamist ja meie meeskond on sellega väga harjunud. Selgus, et projekt on C-le palju lähemal kui C++-le, mis meeskonda eriti ei inspireerinud, sest juhtkond andis endast parima ja värbas tõeliselt lahedaid plussmängijaid. Samal ajal olid meeskonna ameeriklased, nii insenerid kui juhid, ettevõttes pikka aega töötanud, olemasoleva asjade seisuga harjunud ja kõigega rahul. Meeskonna venelaste osa toodi kokku üsna hiljuti, mõne nädala jooksul (ka mina). Meeskonna venelane ei soovinud kategooriliselt loobuda tavapärasest arenduskäsitlusest.
Algas lõputud kirjalikud arutelud kahe kontinendi vahel, kirjad kolmel-neljal ekraanil lendasid edasi-tagasi, nii grupi- kui ka isiklikes kirjades, programmeerijatest programmeerijate ja juhtideni. Nagu tavaliselt, ei lugenud sellise pikkusega kirju keegi peale autorite ja nende tulihingeliste toetajate. Vestlused krigisesid pingest, liikudes eri suundades mitme ekraaniga mõtteid, mis puudutasid STL-i tehnilisi eeliseid, kui hästi see on testitud, kui turvaline see on ja üldiselt, kui imeline elu sellega on ja kui kohutav ilma selleta on. .
See kõik kestis päris kaua, kuni lõpuks mõistsin, et arutasime teema tehnilisi aspekte, kuid tegelikult polnud probleem tehniline. Probleem ei ole STL-i eelistes või puudustes ega ilma selleta töötamise keerukuses. Probleem on pigem organisatsiooniline. Meil oli vaja lihtsalt aru saada, kuidas ettevõte, kus me töötasime, töötas. Kellelgi meist polnud varem sellises ettevõttes töötamise kogemust. Asi oli selles, et pärast koodi väljatöötamist ja tootmisse laskmist tegelesid toega täiesti erinevad inimesed teistest meeskondadest, teistest riikidest. See tohutu, mitmekümne tuhande insenerist koosnev insenerimeeskond (kokku) sai endale lubada vaid täiesti elementaarse tehniliste vahendite miinimumi, nii-öelda minimaalse miinimumi. Midagi, mis füüsiliselt ületas ettevõttes kehtestatud inseneristandardi, ei saa edaspidi toetada. Meeskonna taseme määrab selle nõrgimate liikmete tase. Pärast saime aru tõeline motivatsioon meeskonna Ameerika osa tegevusega eemaldati see teema päevakorrast ning koos arendasime ja väljastasime toote edukalt ettevõtte poolt vastuvõetud standardite alusel. Kirjad ja vestlused sel juhul hästi ei toiminud, ühise nimetajani jõudmiseks kulus mitu reisi ja palju isiklikku suhtlust.
Töövoo seisukohalt aitaks konkreetsel juhul kasutada kasutatavate vahendite kirjeldus, neile esitatavad nõuded, piirangud uute lisamisel ja selliste piirangute põhjendus. Sellised dokumendid vastavad ligikaudu aastal välja töötatud “Tarkvaraarenduse juhi käsiraamatu” lõikudes Taaskasutusstrateegia ja Arenduskeskkond kirjeldatud dokumentidele. . Vaatamata oma vanusele kirjeldab see suurepäraselt kõiki sedalaadi tarkvaraarenduse põhitegevusi ja planeerimisetappe. Selliste dokumentide olemasolu muudab väga lihtsaks arutada, milliseid komponente ja lähenemisviise saab tootes kasutada ning miks.
Kultuurilisest aspektist ilmselgelt küpsema positsiooniga, kus osapooled püüavad kuulda ja mõista kolleegide tegevuse tegelikku motivatsiooni ning tegutseda projekti ja meeskonna prioriteetidest, mitte isiklikust egost lähtuvalt. , laheneks konflikt lihtsamini ja kiiremini.
Ühes teises konfliktis tehnilise lahenduse valiku üle kulus mul samuti märgatavalt palju aega, et ühe osapoole motivatsioonist aru saada (see oli väga ebatavaline juhtum), kuid pärast motivatsiooni selgumist oli lahendus ilmne.
Olukord on järgmine: umbes 20-liikmelisse meeskonda ilmub uus arendaja, nimetagem teda Stas. Sel ajal oli meie standardne meeskonnatöö suhtlusvahend Skype. Nagu hiljem selgus, oli Stas suur avatud standardite ja avatud lähtekoodiga tarkvara fänn ning kasutas ainult tööriistu ja operatsioonisüsteeme, mille allikad olid avalikult kättesaadavad ja mis kasutasid avalikult kirjeldatud protokolle. Skype ei kuulu nende tööriistade hulka. Veetsime palju aega selle lähenemisviisi eeliste ja puuduste üle arutamisele, katsetele käivitada Skype'i analooge erinevates operatsioonisüsteemides, Stasi katseid veenda meeskonda teistele standarditele üle minema, kirjutama talle isiklikult posti teel, helistama isiklikult telefonil. telefoni, osta talle teine arvuti spetsiaalselt Skype'i jaoks jne. Lõpuks mõistsin, et see probleem ei ole sisuliselt tehniline ega organisatsiooniline, see on pigem ideoloogiline, isegi, võiks öelda, religioosne (Stase jaoks). Isegi kui me lõpuks ühendaksime Stasi ja Skype'i (mis võttis mitu kuud), tekiks probleem uuesti mis tahes järgmise instrumendi puhul. Minu käsutuses polnud reaalseid vahendeid Stase maailmavaate muutmiseks ja polnud põhjust proovida muuta selles keskkonnas suurepäraselt töötanud meeskonna maailmavaadet. Inimene ja seltskond olid oma maailmapildis lihtsalt ortogonaalsed. Sellistes olukordades on hea lahendus korralduslik. Viisime Stasi üle teise meeskonda, kus ta oli rohkem orgaaniline.
Selle konflikti põhjuseks on minu arvates lahknevus konkreetse inimese isikliku kultuuri (kellel on kindel arvamus, mis ei lase tal teha kompromisse) isikliku kultuuri ja ettevõtte kultuuri vahel. Sel juhul on see muidugi juhi viga. Algselt oli vale teda sellisesse projekti kaasa võtta. Stas siirdus lõpuks avatud lähtekoodiga tarkvara arendusprojekti ja sai seal suurepäraselt hakkama.
Hea näide konfliktist, mis on põhjustatud nii arendaja lapsikust suhtumisest kui ka tööprotsessi puudujääkidest, on olukord, kus tehtu definitsiooni puudumisel on arendajal ja QA meeskonnal erinevad ootused töövalmiduse suhtes. QA-le üle kantud funktsioon. Arendaja uskus, et piisab, kui kirjutada kood ja visata funktsioon üle aia QA-le – nad lahendavad selle seal. Üsna küps ja kogenud programmeerija muide, aga see oli tema sisemine kvaliteedilävi. QA ei nõustunud sellega ja nõudis neile näitamist ja kirjeldamist, mida ta oli ise kontrollinud, ning nõudis nende jaoks testimisskripti. Neil oli varem selle arendaja funktsionaalsusega probleeme ja nad ei tahtnud uuesti oma aega raisata. Muide, neil oli õigus – funktsioon tõesti ei töötanud, ta ei kontrollinud koodi enne selle QA-le saatmist.
Olukorra lahendamiseks palusin tal näidata, et kõik tõesti toimis (ei toiminud ja ta pidi selle parandama), rääkisime meeskonnaga ja QA määratlusest tehtud (nad ei jõudnud sisse kirjutades, sest me ei tahtnud protsessi liiga bürokraatlikuks muuta ), noh, läksime selle spetsialistiga varsti lahku (üldiseks kergenduseks).
Töövoo seisukohalt on võimalikud täiustused antud juhul tehtud määratluse olemasolu, iga üksuse funktsiooni ja integratsioonitestide toe nõuded ning arendaja läbiviidud testimise kirjeldus. Ühes projektis mõõtsime CI ajal testidega koodi katvuse taset ja kui katvuse tase pärast plaastri lisamist langes, märgiti testid ebaõnnestunuks, s.t. uut koodi saab lisada ainult siis, kui selle jaoks on uued testid.
Veel üks tüüpiline näide konfliktist, mis on tihedalt seotud tööprotsessi korraldusega. Meil on toode, tootearendusmeeskond, tugimeeskond ja klient. Kliendil on tootega probleeme ja ta võtab ühendust toega. Tugi analüüsib probleemi ja mõistab, et probleem on tootes ning edastab probleemi tootemeeskonnale. Tootemeeskonnal on kiire aeg, väljalase on lähenemas, nii et kliendi probleemiga pilet, mis on kadunud arendaja teiste piletite hulka, kellele see on määratud, ripub mitu nädalat tähelepanuta. Tugi arvab, et arendaja tegeleb kliendi probleemiga. Klient ootab ja loodab, et tema probleemiga tegeletakse. Tegelikkuses ei toimu veel midagi. Mõne nädala pärast otsustab klient lõpuks edenemise vastu huvi tunda ja küsib toelt, kuidas läheb. Toetus küsib arengut. Arendaja väriseb, vaatab piletite nimekirja ja leiab sealt kliendilt pileti. Kliendilt piletit lugedes saab ta aru, et probleemi lahendamiseks pole piisavalt infot ning tal on vaja rohkem palke ja prügimägesid. Tugi nõuab kliendilt lisateavet. Ja siis saab klient aru, et keegi pole kogu selle aja tema probleemiga tegelenud. Ja äike lööb...
Sellises olukorras on konflikti enda lahendus üsna ilmne ja lineaarne (toote parandamine, dokumentatsiooni ja testide värskendamine, kliendi rahustamine, kiirparanduse vabastamine jne). Oluline on analüüsida tööprotsessi ja mõista, kes vastutab kahe meeskonna vahelise suhtluse korraldamise eest ja miks selline olukord üldse võimalikuks sai. Selge on see, mida on vaja protsessi käigus parandada - keegi peab jälgima üldpilti ilma klientide meeldetuletusteta, ennetavalt. Kliendi piletid peaksid teiste arendajate piletite hulgast silma paistma. Tugi peaks nägema, kas arendusmeeskond töötab praegu oma piletite kallal ja kui ei, siis millal saab tööle hakata ja millal on oodata tulemusi. Tugi ja arendus peaksid perioodiliselt suhtlema ja arutama piletite staatust, silumiseks vajaliku info kogumist tuleks võimalikult palju automatiseerida jne.
Nii nagu sõjas püüab vaenlane tabada kahe üksuse vahelist ristmikku, nii on ka töös kõige õrnem ja haavatavam punkt meeskondade omavaheline suhtlus. Kui tugi- ja arendusjuhid on piisavalt vanad, saavad nad protsessi ise korda teha, kui mitte, siis jätkub protsess konfliktide ja probleemide genereerimiseks, kuni sekkub juht, kes suudab olukorra parandada.
Teine tüüpiline näide, mida olen erinevates ettevõtetes korduvalt näinud, on olukord, kus toote kirjutab üks meeskond, selle jaoks kirjutab automaatsed integratsioonitestid teine meeskond ja infrastruktuuriga, millel see kõik toimib, saadab kolmas meeskond. meeskond. Probleemid testide käivitamisel tekivad kogu aeg ning nendes esinevate probleemide põhjuseks võib olla nii toode kui ka testid ja infrastruktuur. Tavaliselt on problemaatiline kokku leppida, kes peaks esmase probleemide analüüsi, failivigade, toote parsilogide, testide ja infrastruktuuri jms läbi viima. Siin on konfliktid väga sagedased ja samal ajal ühetaolised. Kõrge emotsionaalse intensiivsuse korral satuvad osalejad sageli lapsikusse positsiooni ja sarjas algavad arutelud: “miks ma peaksin selle kallal nokitsema”, “nad lähevad sagedamini katki” jne.
Töövoo vaatenurgast sõltuvad konkreetsed sammud probleemi lahendamiseks meeskondade koosseisust, testide ja toote tüübist jne. Ühes projektis võtsime kasutusele perioodilise valve, mille käigus meeskonnad jälgisid teste ükshaaval, nädala kaupa. Teises tegid esialgse analüüsi alati testiarendajad, kuid analüüs oli väga elementaarne ja toode oli üsna stabiilne, nii et see töötas hästi. Peamine on tagada, et protsess oleks läbipaistev, ootused kõigile osapooltele selged ja olukord tunduks kõigile õiglane.
Kas konflikt on organisatsioonis isegi probleem Kas see on halb märk, et teie meeskonnas esineb sageli (või lihtsalt perioodiliselt) konflikte? Üldiselt mitte, sest kui on kasv, areng, mingi dünaamika, siis tekivad probleemid, mida pole kunagi varem lahendatud ja mille lahendamisel võivad tekkida konfliktid. See on näitaja, et mõned valdkonnad vajavad tähelepanu, et on valdkondi, mida tuleb parandada. On halb, kui konfliktid tekivad väga sageli, neid on raske lahendada või need võtavad kaua aega. Tõenäoliselt on see märk ebapiisavalt sujuvatest tööprotsessidest ja meeskonna ebapiisavast küpsusest.
Allikas: www.habr.com