Epigraf:
Nekoč sta se v gozdu srečala Ježek in Medved.
- Živjo, ježek!
- Živjo, mali medvedek!
Tako je, beseda za besedo, šala za šalo, Ježka medvedka udarila po obrazu ...
Spodaj je razprava našega vodje ekipe, pa tudi direktorja razvoja izdelkov RAS Igorja Marnata, o posebnostih delovnih konfliktov in možnih metodah za njihovo obvladovanje.
Večina konfliktov, s katerimi se srečamo pri delu, se razvije po scenariju, podobnem tistemu, ki je opisan v zgornjem epigrafu. Obstaja več udeležencev, ki so sprva precej naklonjeni drug drugemu, poskušajo rešiti neko vprašanje, vendar na koncu problem ostane nerešen, odnosi med udeleženci v razpravi pa so iz nekega razloga pokvarjeni.
Življenje je raznoliko in v zgoraj opisanem scenariju se pojavljajo razlike. Včasih odnos med udeleženci na začetku ni zelo dober, včasih sploh ni vprašanja, ki bi zahtevalo neposredno rešitev (kot na primer v epigrafu), včasih po razpravi odnos ostane enak kot pred začetkom, a vprašanje na koncu ni rešeno.
Kaj je skupno vsem situacijam, ki jih lahko opredelimo kot situacijo delovnega konflikta?
Prvič, obstajata dve ali več strani. Te strani lahko zasedajo različna mesta v organizaciji, so v enakopravnem odnosu (sodelavci v timu) ali na različnih ravneh hierarhije (šef - podrejeni), so individualne (zaposleni) ali skupinske (v primerih konflikta med zaposleni in ekipa ali dve ekipi) in tako naprej. Na verjetnost konflikta in enostavnost njegovega reševanja močno vpliva stopnja zaupanja med udeleženci. Bolje kot se stranki poznata, večja kot je stopnja zaupanja, večja je možnost, da se bosta dogovorili. Na primer, člani porazdeljene ekipe, ki nikoli niso komunicirali iz oči v oči, imajo večjo verjetnost, da bodo doživeli konflikt zaradi preprostega delovnega vprašanja kot ljudje, ki so imeli vsaj nekaj osebnih interakcij. Zato je pri delu v porazdeljenih timih zelo pomembno zagotoviti, da se vsi člani tima občasno srečujejo med seboj.
Drugič, v delovni konfliktni situaciji sta stranki v situaciji reševanja nekega vprašanja, ki je pomembno za eno od strani, za obe ali za organizacijo kot celoto. Hkrati imata stranki zaradi specifičnosti situacije običajno dovolj časa in različne načine za rešitev (formalni, neformalni, sestanki, pisma, vodstvene odločitve, prisotnost ciljev in načrtov tima, dejstvo hierarhije itd.). To se razlikuje od situacije reševanja službenega (ali nedelovnega) vprašanja v organizaciji od na primer reševanja pomembnega vprašanja: "Eh, mali, iz katerega konca si?!" na ulici ali konflikt iz epigrafa. Pri reševanju delovnega vprašanja je pomembna kakovost delovnega procesa in kultura reševanja vprašanj v timu.
Tretjič, odločilni dejavnik konflikta (z vidika naše razprave) je dejstvo, da udeleženci v procesu ne morejo samostojno priti do rešitve vprašanja, ki bi ustrezala vsem stranem. Situacija zahteva posredovanje tretje osebe, zunanjega razsodnika. Ta točka se morda zdi sporna, vendar v bistvu, če je bila konfliktna situacija uspešno rešena brez posredovanja zunanjega razsodnika, je bilo vprašanje uspešno rešeno in se odnosi med strankami niso poslabšali, je to situacija, h kateri bi morali stremeti. . Za takšen konflikt najverjetneje sploh ne bomo vedeli ali pa bomo izvedeli po naključju, ko bo razrešen. Več težav kot lahko ekipa reši sama, bolj učinkovita bo.
Druga značilnost konflikta, ki se je velja dotakniti, je stopnja čustvene intenzivnosti med odločitvijo. Konflikt ni nujno povezan z visoko čustveno ravnjo. Udeležencem ni treba kričati in mahati z rokami, da bi šlo v bistvu za konflikt. Problem ni razrešen, prisotna je določena čustvena napetost (morda ni jasno izražena navzven), kar pomeni, da se soočamo s konfliktno situacijo.
Ali je v konfliktnih situacijah sploh potrebno posredovati ali je bolje pustiti njihovo reševanje samoumevno in počakati, da se problem reši sam? Moram. Ni vedno v vaši moči ali pristojnosti, da popolnoma rešite konflikt, vendar lahko v vsaki situaciji, v konfliktu kakršnega koli obsega, zavzamete držo odrasle osebe in s tem pritegnete več ljudi okoli sebe, ublažite negativne posledice konflikta in prispevati k njegovemu reševanju.
Preden pogledamo nekaj primerov konfliktnih situacij, si poglejmo nekaj pomembnih točk, ki so skupne vsem konfliktom.
Pri reševanju konflikta je pomembno biti nad bojem in ne znotraj njega (temu pravimo tudi »zavzemanje metapozicije«), torej ne biti del ene od strani v procesu reševanja. V nasprotnem primeru bo pomoč zunanjega razsodnika pri odločitvi le okrepila položaj ene od strani v škodo druge strani. Pri odločitvi je pomembno, da je moralno sprejeta s strani vseh strani, kot pravijo, »kupljena«. Tako, da so stranke, četudi niso bile navdušene nad sprejeto odločitvijo, vsaj iskreno soglašale z njeno izvedbo. Kot pravijo, da se lahko ne strinjate in se zavežete. V nasprotnem primeru bo konflikt preprosto spremenil videz, tleči ogenj bo ostal pod šotnim barjem in se bo na neki točki neizogibno znova razplamtel.
Druga točka, ki je delno povezana s prvo, je, da če ste se že odločili sodelovati pri reševanju konflikta, ga jemljite čim bolj resno z vidika komunikacije in preučevanja konteksta. Osebno se pogovorite z vsako stranjo. Z vsakim posebej, za začetek. Ne zadovoljite se s pošto. V primeru porazdeljene ekipe se pogovarjajte vsaj prek video povezave. Ne zadovoljite se z govoricami in poročili očividcev. Razumeti zgodbo, kaj želi vsaka stran, zakaj to želi, kaj pričakuje, ali je že poskušala rešiti to vprašanje, kaj se bo zgodilo, če se ne reši, kakšne rešitve vidi, kako si predstavlja položaj druga stran, kaj mislijo, prav ali narobe itd. Naložite si ves možen kontekst v svojo glavo, odprtega uma, ob predpostavki, da imajo vsi prav. Niste znotraj konflikta, ste zunaj njega, v metapoziciji. Če je kontekst na voljo samo v niti objave, ga vsaj preberite v celoti ter teme in dokumente, povezane z njim. Ko jo preberete, še vedno govorite s svojim glasom. Skoraj zagotovljeno je, da boste slišali nekaj pomembnega, kar ni v pošti.
Tretja pomembna točka je splošni pristop k komunikaciji. To so običajne stvari, nič kozmičnega, a so zelo pomembne. Ne poskušamo prihraniti časa, pogovarjamo se z vsemi udeleženci, osebe ne kritiziramo, ampak upoštevamo posledice njegovih dejanj (ne »nesramen si«, ampak »mogoče so fantje užaljeni zaradi ta stvar«), dajemo priložnost, da si rešimo obraz, vodimo pogovore osebno, ne pred vrsto.
Konflikte običajno povzroči eden od dveh razlogov. Prvi je povezan s tem, ali je oseba v času konflikta v položaju odraslega ali v položaju otroka (več o tem v nadaljevanju). To je posledica njegove čustvene zrelosti, sposobnosti obvladovanja čustev (ki, mimogrede, ni vedno povezana z njegovo starostjo). Drugi pogost razlog je nepopolnost delovnega procesa, ki ustvarja situacije sivih lis, v katerih je odgovornost razpršena med udeležence, pričakovanja strani med seboj niso transparentna, vloge v procesu pa zamegljene.
Skladno s tem mora vodja pri reševanju konflikta (pa tudi katerega koli drugega vprašanja) upoštevati tri perspektive: kratkoročno – rešiti problem/konflikt tukaj in zdaj, srednjeročno – zmanjšati verjetnost ponovnega nastanka konflikta. iz istega razloga in dolgoročno - gojiti kulturo odraslih v timski osebi.
Vsak od nas ima v sebi otroka, starega približno tri ali štiri leta. V službi večino časa spi, včasih pa se zbudi in prevzame nadzor. Otrok ima svoje prioritete. Pomembno mu je, da vztraja, da je to njegov peskovnik, mama ga ima bolj rada, njegov stroj je najboljši (dizajn je najboljši, on najbolje programira, ...). V konfliktni situaciji lahko otrok pritiska igrače, tepta z nogami in poka z lopatico, vendar ne more rešiti vprašanj odraslih (arhitektura rešitve, pristopi k avtomatiziranemu testiranju, datumi izdaje itd.), Ne razmišlja o koristih za ekipo. Otroka v konfliktu lahko spodbudite, potolažite in pošljete v posteljo tako, da ga prosite, naj pokliče svojega odraslega. Preden začnete razpravo v konfliktni situaciji, se prepričajte, da se pogovarjate z odraslo osebo, ne z otrokom, in da ste sami v položaju odraslega. Če je vaš pošten cilj v tem trenutku rešiti resno težavo, ste v položaju odrasle osebe. Če je vaš cilj topotati z nogami in počiti lopatico, je to otročji položaj. Pošljite svojega notranjega otroka v posteljo in pokličite odraslo osebo ali prestavite pogovor. Človek sprejme čustveno odločitev, nato pa zanjo išče racionalno utemeljitev. Odločitev, ki jo otrok sprejme na podlagi otrokovih prioritet, ne bo optimalna.
Za položaj otroka oziroma odraslega je poleg vedenja v času konflikta značilna tudi stopnja odgovornosti, ki jo je oseba pripravljena prevzeti. V svojih skrajnih manifestacijah je otročji položaj programerja, ki sem ga srečal več kot enkrat, videti takole: napisal sem kodo, jo poslal v pregled - moje delo je končano. Recenzenti naj ga pregledajo in odobrijo, QA naj preveri, če bodo težave, me bodo obvestili. Nenavadno je, da se celo dokaj zreli in izkušeni ljudje včasih obnašajo tako. Druga stran lestvice je, da se oseba meni, da je odgovorna za zagotavljanje, da njegova koda deluje, da je pokrita s testi, da jo je osebno preveril, da je uspešno opravila pregled (če je potrebno, ni problema pingati pregledovalce, razpravljati o težavah z glasom itd.) in je bil zakrit, QA bo po potrebi zagotovil pomoč, opisani bodo testni scenariji itd. V običajnih primerih programer bodisi začne bližje koncu lestvice za odrasle ali pa se premakne tja, ko pridobi izkušnje (pod pogojem, da se v ekipi goji prava kultura). V skrajnih primerih nadaljuje z delom, običajno zavzame otročji položaj, nato pa ima on in ekipa občasno težave in konflikte.
Spodbujanje prave, zrele kulture v timu je pomembna naloga vsakega vodje. Zahteva veliko časa in vsakodnevnega truda, vendar je rezultat vreden. Obstajata dva načina vplivanja na timsko kulturo – vodenje z zgledom (ki mu bo zagotovo sledil; ekipa vedno gleda na vodjo) ter razprava in nagrajevanje pravilnega vedenja. Tudi tukaj ni nič neumnega ali zelo formalnega, le pri razpravljanju o težavah opazite, da bi se dalo nekaj narediti, poudarite, da ste opazili, ko je bilo pravilno odločeno, pohvalite, pripomnite med pregledom objave itd.
Razmislimo o več tipičnih konfliktnih situacijah, od preprostih do zapletenih:
Konflikti, ki niso povezani z delovnimi težavami
V službi pogosto prihaja do konfliktov, ki niso povezani z delovnimi vprašanji. Njihov nastanek in enostavnost razreševanja sta običajno neposredno povezana s stopnjo čustvene inteligence udeležencev, njihovo stopnjo zrelosti in nista povezana z dovršenostjo ali nepopolnostjo delovnega procesa.
Tipični primeri: nekdo ne uporablja dovolj pogosto pralnega stroja ali se tušira, kar drugim ni všeč, nekomu je zatohlo, drugemu piha, če odpre okno, nekdo je prehrupen, drugi potrebujejo tišino za delo in tako naprej Bolje je, da ne odlašate z reševanjem tovrstnih konfliktov in ne pustite, da gredo sami. Ne bodo se rešile same od sebe in vas bodo vsak dan odvračale od dela in zastrupljale vzdušje v kolektivu. K sreči njihovo reševanje običajno ni velik problem – le mirno se pogovorite (seveda ena na ena) s sodelavcem, ki zanemarja higieno, poskrbite za udobno sedenje za tiste, ki imajo raje tišino/hlad, kupite slušalke, ki absorbirajo zvok, ali namestite predelne stene. itd.
Drug primer, s katerim sem se med delom večkrat srečal, je psihološka nekompatibilnost članov tima. Iz nekega razloga ljudje preprosto ne morejo sodelovati, vsaka interakcija se konča s škandalom. Včasih je to posledica dejstva, da imajo ljudje polarne poglede na neko perečo zadevo (običajno politično) in ne vedo, kako jih pustiti zunaj dela. Prepričevati jih, naj se tolerirajo ali spremenijo svoje vedenje, je precej jalova naloga. Edina izjema, s katero sem se srečal, so mladi kolegi z odprtimi zaznavami, njihovo vedenje je še vedno mogoče postopoma spremeniti z občasnimi pogovori. Običajno se težava uspešno reši tako, da se jih razdeli v različne ekipe ali pa se vsaj zagotovi možnost, da se zelo redko prekrivajo pri delu.
V vseh naštetih situacijah se je vredno z vsemi udeleženci osebno pogovoriti, se pogovoriti o situaciji, se vprašati, ali v tem primeru sploh vidijo problem, se vprašati, kakšne so po njihovem mnenju rešitve, in zagotoviti njihovo sodelovanje pri nastajanju tega. odločitev.
Z vidika optimizacije delovnega procesa (srednjeročna perspektiva, ki sem jo omenil) se tu ne da veliko narediti, edino bistvo optimizacije je, da se pri sestavljanju ekipe upošteva faktor kompatibilnosti in ne postavlja ljudi. vnaprej skupaj, kdo bo v konfliktu.
Z vidika timske kulture se takšne situacije veliko redkeje pojavljajo v timih z zrelo kulturo, kjer ljudje spoštujejo ekipo in sodelavce ter znajo samostojno reševati težave. Poleg tega se takšni konflikti veliko lažje (pogosto samodejno) rešujejo v timih, kjer obstaja visoka stopnja zaupanja, ljudje že dolgo delajo skupaj in/ali pogosto komunicirajo izven službe.
Konflikti, povezani z delovnimi težavami:
Takšne konflikte običajno povzročita oba razloga hkrati, tako čustveni (dejstvo, da eden od udeležencev ni v položaju odraslega) kot nepopolnost samega delovnega procesa. Morda najpogostejša vrsta konfliktov, s katerimi sem se srečal, so konflikti med pregledi kode ali razpravami o arhitekturi med razvijalci.
Tu bi izpostavil dva tipična primera:
1) V prvem primeru razvijalec ne more dobiti pregleda kode od kolega. Popravek je poslan v pregled in nič se ne zgodi. Na prvi pogled ni očitnega konflikta med obema stranema, a če dobro pomislite, je to kar konflikt. Delovno vprašanje ni rešeno, ena od strank (čaka na pregled) doživlja očitno nelagodje. Ekstremna podvrsta tega primera je razvoj v skupnosti ali v različnih ekipah, medtem ko pregledovalca morda ne zanima ta posebna koda, zaradi nalaganja ali drugih okoliščin, morda sploh ne bo pozoren na zahtevo za pregled in zunanji razsodnik (upravljavec, ki je skupen obema stranema) ) morda sploh ne obstaja.
Rešitveni pristop, ki pomaga v takšni situaciji, se nanaša ravno na dolgoročno perspektivo, kulturo odraslega. Prvič, pametna dejavnost deluje. Ne pričakujte, da bo koda, ki visi na recenziji, pritegnila pozornost recenzenta. Recenzentom moramo pomagati, da ga opazijo. Pingani nekaj ljudi, postavite vprašanje o syncape, sodelujte v razpravah. Očitno je, da predrznost bolj škodi kot pomaga, zato morate uporabiti zdrav razum. Drugič, predpriprava dobro deluje. Če ekipa razume, kaj se dogaja in zakaj, zakaj je ta koda sploh potrebna, je bil dizajn razpravljen in dogovorjen vnaprej z vsemi, je večja verjetnost, da bodo ljudje pozorni na takšno kodo in jo sprejeli za delo. Tretjič, avtoriteta deluje. Če želite biti pregledani, naredite veliko pregledov sami. Opravite visokokakovostne preglede z resničnimi pregledi, resničnimi testi in uporabnimi komentarji. Če je vaš vzdevek dobro znan v ekipi, obstaja večja možnost, da bo vaša koda opažena.
Z vidika delovnega toka so tukaj možne izboljšave pravilna prednostna razvrstitev, namenjena pomoči razvijalcu pri doseganju njegovih ciljev in ciljev ekipe (pregled drugih, pisanje pisem skupnosti, spremljanje kode z opisom arhitekture, dokumentacijo, testi, sodelovanje v razpravah z skupnosti itd.), preprečite, da bi popravki predolgo viseli v čakalni vrsti itd.
2) Drugi pogost primer konfliktov med pregledi kode ali dizajna so različni pogledi na tehnična vprašanja, stil kodiranja in izbiro orodij. Pri tem je zelo pomembna stopnja zaupanja med udeleženci, pripadnost istemu timu in izkušnje pri sodelovanju. Slepa ulica nastane, ko eden od udeležencev zavzame otročje stališče in ne poskuša slišati, kaj mu želi sogovornik sporočiti. Pogosto lahko tako pristop, ki ga predlaga druga stran, kot pristop, predlagan na začetku, uspešno delujeta in načeloma ni pomembno, katerega izbrati.
Nekega dne je programer iz moje ekipe (recimo mu Pasha) pripravil popravek s spremembami sistema za namestitev paketov, ki so ga razvili in podprli kolegi iz sosednjega oddelka. Eden od njih (Igor) je imel svoje trdno mnenje o tem, kako naj bodo storitve Linuxa konfigurirane pri uvajanju paketov. To mnenje se je razlikovalo od pristopa, predlaganega v popravku, in niso se mogli strinjati. Kot ponavadi so se roki iztekali in treba je bilo priti do neke odločitve, nujno je bilo, da eden od njiju prevzame položaj odraslega. Paša je priznal, da imata oba pristopa pravico do življenja, vendar je želel, da njegova možnost mine, ker Ne ena ne druga možnost nista imeli očitnih tehničnih prednosti.
Najina razprava je izgledala nekako takole (seveda zelo shematično, pogovor je trajal pol ure):
- Pasha, v nekaj dneh imamo zamrznitev funkcije. Pomembno je, da se vse združimo in čimprej začnemo testirati. Kako lahko pridemo do Igorja?
— Storitve želi vzpostaviti drugače, pripomnil mi je tja ...
- In kaj je tam, velike spremembe, veliko hrupa?
- Ne, nekaj ur je delo, a na koncu ni razlike, tako ali tako bo šlo, zakaj je to potrebno? Naredil sem nekaj, kar deluje, sprejmimo to.
- Poslušaj, kako dolgo že razpravljaš o vsem tem?
- Da, že teden in pol označujemo čas.
- Hm ... ali lahko v nekaj urah rešimo težavo, ki je trajala že teden in pol, in tega ne storimo?
- No, ja, ampak nočem, da Igor misli, da sem popustil ...
- Poslušaj, kaj je zate bolj pomembno, izdati izpustitev, skupaj s svojo odločitvijo, ali ubiti Igorja? Lahko ga blokiramo, potem pa obstaja dobra možnost, da preletimo z izdajo.
- No ... seveda bi bilo kul, če bi Igorja obrisali nos, ampak v redu, izpustitev je pomembnejša, se strinjam.
- Vam je res tako pomembno, kaj Igor misli? Po pravici povedano mu je čisto vseeno, hoče le enoten pristop na različnih mestih stvari, za katero je odgovoren.
- No, v redu, naj naredim, kot je zahteval v komentarjih, in začnimo s testiranjem.
- Hvala, Pasha! Bila sem prepričana, da bosta od vaju dva bolj zrela, čeprav je Igorek starejši od tebe :)
Težava je bila rešena, izdaja je bila sproščena pravočasno, Pasha ni čutil veliko nezadovoljstva, ker sam je predlagal rešitev in jo uresničil. Igor je bil na splošno zadovoljen, saj... Njegovo mnenje so upoštevali in naredili, kot je predlagal.
Druga vrsta v bistvu istega konflikta je izbira med tehničnimi rešitvami/knjižnicami/pristopi v projektu, zlasti v porazdeljeni ekipi. V enem od projektov, ki je bil postavljen kot uporaba C/C++, se je izkazalo, da je tehnično vodstvo projekta kategorično proti uporabi STL (Standard Template Library). To je standardna jezikovna knjižnica, ki poenostavlja razvoj in naša ekipa je tega zelo vajena. Izkazalo se je, da je projekt veliko bližje C-ju kot C++-u, kar ekipe ni preveč navdušilo, saj vodstvo se je potrudilo po svojih najboljših močeh in zaposlilo res kul plus igralce. Hkrati je ameriški del ekipe, tako inženirji kot menedžerji, že dolgo delal v podjetju, navajen na obstoječe stanje in je bil z vsem zadovoljen. Ruski del ekipe se je zbral pred kratkim, v nekaj tednih (vključno z mano). Ruski del ekipe kategorično ni želel opustiti običajnega pristopa k razvoju.
Začele so se neskončne pisne razprave med obema celinama, pisma na treh ali štirih zaslonih so letela sem in tja, v skupinskih in osebnih, od programerjev do programerjev in menedžerjev. Kot je v navadi, tako dolgih pisem ni prebral nihče razen avtorjev in njihovih gorečih zagovornikov. Klepeti so škripali od napetosti, v različnih smereh so se širile misli na več zaslonih o tehničnih prednostih STL, kako dobro je preizkušen, kako varen je in na splošno, kako čudovito je življenje z njim in kako grozno je brez njega .
Vse to je trajalo precej dolgo, dokler nisem končno ugotovil, da se pogovarjamo o tehničnih vidikih vprašanja, vendar problem v resnici ni bil tehnični. Težava ni v prednostih ali slabostih STL ali težavah pri delu brez njega. Težava je bolj organizacijska. Samo razumeti smo morali, kako deluje podjetje, v katerem smo delali. Nihče od nas prej ni imel izkušenj z delom v takem podjetju. Stvar je bila v tem, da so po tem, ko je bila koda razvita in izdana v produkcijo, za podporo poskrbeli popolnoma drugi ljudje iz drugih ekip, iz drugih držav. Ta ogromna inženirska ekipa več deset tisoč inženirjev (skupaj) si je lahko privoščila le povsem osnovni minimum tehničnih sredstev, tako rekoč minimum minimorum. Karkoli, kar je fizično presegalo inženirski standard, ki je bil vzpostavljen v podjetju, v prihodnosti ni bilo mogoče podpirati. Raven ekipe je odvisna od ravni njenih najšibkejših članov. Potem ko smo razumeli prava motivacija ukrepov ameriškega dela ekipe je bilo to vprašanje umaknjeno z dnevnega reda in skupaj smo uspešno razvili in izdali izdelek po standardih, ki jih je sprejelo podjetje. Pisma in klepeti se v tem primeru niso dobro obnesli, potrebnih je bilo več potovanj in veliko osebne komunikacije, da smo prišli do skupnega imenovalca.
Z vidika poteka dela bi v konkretnem primeru pomagal opis uporabljenih orodij, zahteve zanje, omejitve pri dodajanju novih in utemeljitev teh omejitev. Takšni dokumenti približno ustrezajo tistim, ki so opisani v odstavkih Strategija ponovne uporabe in razvojno okolje »Managerjevega priročnika za razvoj programske opreme«, ki je bil razvit v . Kljub svoji starosti odlično opisuje vse glavne aktivnosti in faze načrtovanja tovrstnega razvoja programske opreme. S takšnimi dokumenti je zelo enostavno razpravljati o tem, katere komponente in pristope je mogoče uporabiti v izdelku in zakaj.
S kulturnega vidika očitno z bolj zrelo pozicijo, v kateri skušata stranki slišati in razumeti pravo motivacijo delovanja svojih sodelavcev ter delovati na podlagi prioritet projekta in ekipe, ne pa osebnega ega. , bi se konflikt lažje in hitreje rešil.
V drugem konfliktu glede izbire tehnične rešitve sem prav tako vzel precej časa, da sem razumel motivacijo ene od strani (šlo je za zelo nenavaden primer), ko pa je bila motivacija jasna, je bila rešitev očitna.
Situacija je naslednja: v ekipi približno 20 ljudi se pojavi nov razvijalec, recimo mu Stas. Takrat je bilo naše standardno orodje za timsko komunikacijo Skype. Kot se je pozneje izkazalo, je bil Stas velik oboževalec odprtih standardov in odprtokodne programske opreme ter je uporabljal samo orodja in operacijske sisteme, katerih viri so bili javno dostopni in so uporabljali javno opisane protokole. Skype ni eno od teh orodij. Veliko časa smo porabili za razpravo o prednostih in slabostih tega pristopa, poskusih zagona analogov Skypea v različnih operacijskih sistemih, Stasovih poskusih, da prepriča ekipo, da preide na druge standarde, mu osebno pišemo po pošti, ga osebno kličemo na telefon, mu kupite drugi računalnik posebej za Skype itd. Končno sem ugotovil, da ta problem v bistvu ni tehnični ali organizacijski, je prej ideološki, celo, lahko bi rekli, verski (za Stasa). Tudi če bi na koncu povezali Stasa in Skype (kar je trajalo več mesecev), bi se težava ponovno pojavila na vsakem naslednjem instrumentu. Na voljo nisem imel pravih sredstev, da bi spremenil Stasov pogled na svet, in ni bilo razloga, da bi poskušal spremeniti pogled na svet ekipe, ki je odlično delovala v tem okolju. Oseba in podjetje sta si bila preprosto ortogonalna v svojem pogledu na svet. V takih situacijah je dobra rešitev organizacijska. Stasa smo premestili v drugo ekipo, kjer je bil bolj organski.
Razlog za ta konflikt je po mojem mnenju neskladje med osebno kulturo določene osebe (ki ima trdno mnenje, ki mu ne dopušča sklepanja kompromisov) in kulturo podjetja. V tem primeru gre seveda za napako upravnika. Sprva je bilo narobe, da bi ga vzeli za takšen projekt. Stas se je sčasoma preselil k projektu razvoja odprtokodne programske opreme in tam blestel.
Dober primer konflikta, ki ga povzročata tako otročji odnos razvijalca kot pomanjkljivosti delovnega procesa, je situacija, v kateri imata ob odsotnosti definicije opravljenega razvijalec in QA ekipa različna pričakovanja glede pripravljenosti funkcija prenesena v QA. Razvijalec je verjel, da je dovolj, da napiše kodo in vrže funkcijo čez ograjo QA - tam jo bodo rešili. Mimogrede precej zrel in izkušen programer, a to je bil njegov interni prag kakovosti. QA se s tem ni strinjal in je zahteval, da jim pokaže in opiše, kaj je sam preveril, ter zahteval testno skripto zanje. V preteklosti so imeli težave s funkcionalnostjo tega razvijalca in niso želeli več izgubljati časa. Mimogrede, imeli so prav - funkcija res ni delovala, kode ni preveril, preden jo je poslal QA.
Da bi rešil situacijo, sem ga prosil, naj mi pokaže, da vse res deluje (ni delovalo in moral je to popraviti), pogovorili smo se z ekipo in z definicijo QA končano (niso uspeli pisanju, ker nismo želeli preveč birokratizirati postopka ), no, s tem specialistom smo se (na splošno olajšanje) kmalu razšli.
Z vidika poteka dela so možne izboljšave v tem primeru prisotnost definicije narejenega, zahteve za podporo posameznih funkcij enote in integracijskih testov ter opis testiranja, ki ga izvaja razvijalec. V enem od projektov smo merili stopnjo pokritosti kode s testi med CI in če je po dodajanju popravka raven pokritosti padla, so bili testi označeni kot neuspešni, tj. katera koli nova koda se lahko doda le, če zanjo obstajajo novi testi.
Še en tipičen primer konflikta, ki je tesno povezan z organizacijo delovnega procesa. Imamo izdelek, skupino za razvoj izdelkov, skupino za podporo in stranko. Stranka ima težave z izdelkom in kontaktira podporo. Podpora analizira težavo in razume, da je težava v izdelku, ter težavo prenese na ekipo izdelka. Produktna ekipa je v natrpanem času, bliža se izdaja, zato vstopnica s težavo stranke, izgubljena med drugimi vstopnicami razvijalca, ki mu je dodeljena, visi več tednov brez pozornosti. Podpora meni, da se razvijalec ukvarja s težavo stranke. Stranka čaka in upa, da se njena težava rešuje. V resnici se še nič ne dogaja. Po nekaj tednih se stranka končno odloči, da se bo zanimala za napredek in povprašala podporo, kako stvari napredujejo. Podpora zahteva razvoj. Razvijalec se zgrozi, pogleda po seznamu vstopnic in tam najde vstopnico od stranke. Ko bere vstopnico od stranke, razume, da ni dovolj informacij za rešitev težave in potrebuje več dnevnikov in odlagališč. Podpora od stranke zahteva dodatne informacije. In potem kupec ugotovi, da se ves ta čas nihče ni ukvarjal z njegovim problemom. In grom bo udaril ...
V tej situaciji je sama rešitev konflikta precej očitna in linearna (popraviti izdelek, posodobiti dokumentacijo in teste, pomiriti stranko, izdati hitri popravek itd.). Pomembno je analizirati delovni proces in razumeti, kdo je odgovoren za organizacijo interakcije med obema ekipama in zakaj je ta situacija sploh nastala. Jasno je, kaj je treba popraviti v procesu – nekdo mora spremljati celotno sliko brez opominov strank, proaktivno. Vstopnice od stranke bi morale izstopati med drugimi vstopnicami razvijalcev. Podpora bi morala preveriti, ali razvojna ekipa trenutno dela na svojih vstopnicah, in če ne, kdaj lahko začne delovati in kdaj je mogoče pričakovati rezultate. Podpora in razvoj bi morala občasno komunicirati in razpravljati o statusu vstopnic, zbiranje informacij, potrebnih za odpravljanje napak, mora biti čim bolj avtomatizirano itd.
Tako kot v vojni skuša sovražnik zadeti stičišče med dvema enotama, je pri delu običajno najbolj občutljiva in ranljiva točka interakcija med ekipami. Če so vodje podpore in razvoja dovolj stari, bodo lahko sami popravili proces, če ne, bo proces še naprej generiral konflikte in težave, dokler ne posreduje vodja, ki lahko popravi situacijo.
Drug tipičen primer, ki sem ga večkrat videl v različnih podjetjih, je situacija, v kateri izdelek piše ena ekipa, samodejne integracijske teste zanj piše druga ekipa, infrastrukturo, na kateri deluje, pa spremlja tretja. ekipa. Težave pri izvajanju testov se pojavljajo ves čas, vzrok za težave v njih pa so lahko tako produkt kot testi in infrastruktura. Običajno se je težko dogovoriti, kdo naj izvede začetno analizo težav, napak v datoteki, razčlenitev dnevnikov izdelka, testov in infrastrukture itd. Konflikti so tukaj zelo pogosti, hkrati pa enolični. V primeru visoke čustvene intenzivnosti udeleženci pogosto padejo v otročji položaj in v seriji se začnejo razprave: "zakaj bi se ukvarjal s tem", "pogosteje se zlomijo" itd.
Z vidika poteka dela so posebni koraki za rešitev težave odvisni od sestave ekip, vrste testov in izdelka itd. V enem od projektov smo uvedli obdobna dežurstva, v katerih so ekipe spremljale teste ena za drugo, teden za tednom. Pri drugem so začetno analizo vedno opravili razvijalci testov, vendar je bila analiza zelo osnovna in izdelek precej stabilen, zato je dobro deloval. Ključno je zagotoviti, da je postopek pregleden, da so pričakovanja jasna za vse strani in da se zdi situacija pravična za vse.
Je konflikt sploh problem v organizaciji? Ali je slab znak, da se v vaši ekipi pogosto (ali le občasno) pojavljajo konflikti? Na splošno ne, ker če je rast, razvoj, je neka dinamika, potem se pojavijo vprašanja, ki še nikoli niso bila rešena, in pri njihovem reševanju lahko pride do konfliktov. To je pokazatelj, da je nekaterim področjem treba posvetiti pozornost, da obstajajo področja za izboljšave. Slabo je, če se konflikti pojavljajo zelo pogosto, jih je težko rešiti ali trajajo dolgo. To je najverjetneje znak premalo urejenih delovnih procesov in nezadostne zrelosti ekipe.
Vir: www.habr.com