epigraf:
Jednom davno u šumi su se sreli Jež i Medo.
- Zdravo, Jež!
- Zdravo, mali medo!
Dakle, reč po reč, šalu po vic, ježa je udario Mali medved u lice...
U nastavku je diskusija našeg vođe tima, kao i direktora razvoja proizvoda RAS Igora Marnata, o specifičnostima radnih sukoba i mogućim metodama za njihovo upravljanje.
Većina konflikata s kojima se susrećemo na poslu razvijaju se prema scenariju sličnom onom opisanom u gornjem epigrafu. Ima nekoliko učesnika koji su u početku prilično naklonjeni jedni prema drugima, pokušavaju da reše neko pitanje, ali na kraju problem ostaje nerešen, a odnosi između učesnika u diskusiji iz nekog razloga ispadaju pokvareni.
Život je raznolik, a varijacije se javljaju u gore opisanom scenariju. Ponekad odnos između učesnika u početku nije baš dobar, ponekad čak ni ne postoji pitanje koje zahteva direktno rešenje (kao, na primer, u epigrafu), ponekad nakon diskusije odnos ostaje isti kao i pre početka, ali problem na kraju nije riješen.
Šta je zajedničko u svim situacijama koje se mogu definisati kao situacija radnog konflikta?
Prvo, postoje dvije ili više strana. Ove stranke mogu zauzimati različita mjesta u organizaciji, biti u ravnopravnom odnosu (kolege u timu), ili na različitim nivoima hijerarhije (šef - podređeni), biti individualne (zaposleni) ili grupne (u slučajevima sukoba između zaposlenika i tim ili dva tima) i tako dalje. Na vjerovatnoću sukoba i lakoću njegovog rješavanja u velikoj mjeri utiče nivo povjerenja između učesnika. Što se strane bolje poznaju, što je veći nivo poverenja, veća je šansa da će doći do sporazuma. Na primjer, članovi distribuiranog tima koji nikada nisu imali interakciju licem u lice imaju veću vjerovatnoću da će doživjeti sukob zbog jednostavnog radnog pitanja nego ljudi koji su imali barem nekoliko interakcija licem u lice. Stoga, kada radite u raspoređenim timovima, veoma je važno osigurati da se svi članovi tima periodično sastaju lično jedni s drugima.
Drugo, u situaciji konflikta na poslu, strane su u situaciji da rješavaju neko pitanje koje je važno za jednu od strana, za obje, ili za organizaciju u cjelini. Istovremeno, zbog specifičnosti situacije, strane obično imaju dovoljno vremena i različite načine da je riješe (formalni, neformalni, sastanci, pisma, odluke uprave, prisutnost ciljeva i planova tima, činjenica o hijerarhiji, itd.). Ovo se razlikuje od situacije kada se rješava radno (ili neradno) pitanje u organizaciji od, na primjer, rješavanja važnog pitanja: „Eh, mali, iz koje si ti oblasti?!“ na ulici, ili sukob iz epigrafa. U slučaju rješavanja radnog pitanja bitna je kvaliteta procesa rada i kultura rješavanja pitanja u timu.
Treće, odlučujući faktor sukoba (sa stanovišta naše rasprave) je činjenica da strane u procesu ne mogu samostalno doći do rješenja pitanja koje odgovara svim stranama. Situacija zahtijeva intervenciju treće strane, vanjskog arbitra. Ovo pitanje može izgledati kontroverzno, ali, u suštini, ako je konfliktna situacija uspješno riješena bez intervencije vanjskog arbitra, pitanje je uspješno riješeno i odnosi strana se nisu pogoršali, to je situacija kojoj treba težiti . Za takav sukob najvjerovatnije nećemo ni znati, ili ćemo slučajno saznati nakon što se on razriješi. Što više problema tim može da reši sam, to će biti efikasniji.
Još jedna karakteristična karakteristika sukoba koju vrijedi dotaknuti je stepen emocionalnog intenziteta tokom odluke. Konflikt nije nužno povezan s visokim emocionalnim nivoom. Učesnici ne moraju da viču i mašu rukama da bi situacija bila, u suštini, sukob. Problem nije riješen, prisutna je određena emocionalna napetost (možda nije jasno izražena spolja), što znači da smo suočeni sa situacijom konflikta.
Da li je uopšte potrebno intervenisati u konfliktnim situacijama ili je bolje pustiti njihovo rešavanje da ide svojim tokom i čekati da se problem reši sam od sebe? Treba. Nije uvijek u vašoj moći ili nadležnosti da u potpunosti riješite konflikt, ali u bilo kojoj situaciji, u sukobu bilo kojeg razmjera, možete zauzeti odraslu poziciju, čime ćete u nju dovesti još nekoliko ljudi oko sebe, ublažiti negativne posljedice sukoba i doprinijeti njegovom rješavanju.
Prije nego što pogledamo nekoliko primjera konfliktnih situacija, pogledajmo nekoliko važnih tačaka zajedničkih za sve sukobe.
Prilikom rješavanja sukoba važno je biti iznad borbe, a ne unutar nje (ovo se još naziva i “zauzimanje meta-pozicije”), odnosno ne biti dio jedne od strana u procesu rješavanja. U suprotnom, pomoć vanjskog arbitra u odluci samo će ojačati poziciju jedne od strana na štetu druge strane. Prilikom donošenja odluke važno je da ona bude moralno prihvaćena od svih strana, kako se kaže, „kupljeno“. Tako da, čak i ako stranke nisu bile oduševljene donesenom odlukom, barem su se iskreno složile da je provedu. Kako kažu, moći se ne slagati i obavezati. U suprotnom, sukob će jednostavno promijeniti svoj izgled, tinjajuća vatra će ostati ispod tresetišta i u nekom trenutku će se neminovno ponovo rasplamsati.
Druga stvar, dijelom povezana s prvom, je da ako ste već odlučili da učestvujete u rješavanju sukoba, shvatite to što je moguće ozbiljnije sa stanovišta komunikacije i proučavanja konteksta. Razgovarajte lično sa svakom od strana. Sa svakim posebno, za početak. Ne zadovoljavajte se poštom. U slučaju distribuiranog tima, barem razgovarajte putem video veze. Nemojte se zadovoljiti pričama iz druge ruke i izvještajima očevidaca. Shvatite priču, šta svaka strana želi, zašto to želi, šta očekuju, da li su već pokušavali da riješe ovo pitanje, šta će se dogoditi ako se ne riješi, kakva rješenja vide, kako zamišljaju poziciju druga strana, šta oni misle, ispravno ili pogrešno, itd. Učitajte sav mogući kontekst u svoju glavu, otvorenog uma, pod pretpostavkom da su svi u pravu. Vi niste unutar konflikta, vi ste izvan njega, u metapoziciji. Ako je kontekst dostupan samo u temi posta, barem ga pročitajte u cijelosti i teme i dokumente koji se odnose na njega. Nakon što ga pročitate, i dalje govorite svojim glasom. Gotovo je zagarantovano da ćete čuti nešto važno što nije u poruci.
Treća važna tačka je opšti pristup komunikaciji. To su obične stvari, ništa kosmičko, ali su veoma važne. Ne pokušavamo da uštedimo vreme, razgovaramo sa svim učesnicima, ne kritikujemo osobu, ali razmatramo posledice njegovih postupaka (ne „ti si bezobrazan“, već „možda su momci uvređeni zbog ovu stvar”), dajemo priliku da sačuvamo obraz, vodimo razgovore lično, a ne ispred reda.
Konflikti su obično uzrokovani jednim od dva razloga. Prvi se odnosi na to da li je osoba u trenutku sukoba u položaju odrasle osobe ili u položaju djeteta (o tome više u nastavku). To je zbog njegove emocionalne zrelosti, sposobnosti upravljanja svojim emocijama (što, inače, nije uvijek povezano s njegovim godinama). Drugi čest razlog je nesavršenost procesa rada, što stvara situacije sivih zona u kojima je odgovornost raspoređena između učesnika, očekivanja strana nisu transparentna jedna drugoj, a uloge u procesu su zamagljene.
U skladu s tim, u rješavanju konflikta (kao i svakog drugog pitanja), menadžer mora imati na umu tri perspektive: kratkoročnu - da riješi problem/konflikt ovdje i sada, srednjoročnu - da minimizira vjerovatnoću izbijanja novog sukoba iz istog razloga, a dugoročno – negovati kulturu odraslih u timu.
Svako od nas ima svoje unutrašnje dete, staro oko tri ili četiri godine. Većinu vremena spava na poslu, ali se ponekad probudi i preuzme kontrolu. Dijete ima svoje prioritete. Bitno mu je da insistira da je ovo njegov sandbox, njegova majka ga više voli, njegova mašina je najbolja (dizajn je najbolji, on najbolje programira,...). U situaciji sukoba, dijete može pritisnuti igračke, gaziti nogama i pucati lopaticom, ali ne može riješiti probleme odraslih (arhitektura rješenja, pristupi automatiziranom testiranju, datumi puštanja u prodaju itd.), ne razmišlja o koristima za tim. Dijete u sukobu može se ohrabriti, utješiti i poslati u krevet tako što ćete ga zamoliti da pozove svoju odraslu osobu. Prije nego započnete raspravu u konfliktnoj situaciji, uvjerite se da razgovarate s odraslom osobom, a ne s djetetom, i da ste i sami u poziciji odrasle osobe. Ako vam je trenutno iskren cilj da riješite ozbiljan problem, vi ste u poziciji odrasle osobe. Ako vam je cilj da gazite nogama i popucate lopaticu, ovo je djetinjast položaj. Pošaljite svoje unutrašnje dijete u krevet i pozovite odraslu osobu ili ponovo zakažite diskusiju. Osoba donosi emocionalnu odluku, a zatim traži racionalno opravdanje za to. Odluka koju dijete donese na osnovu dječijih prioriteta neće biti optimalna.
Pored ponašanja u trenutku sukoba, položaj djeteta ili odrasle osobe karakteriše i nivo odgovornosti koji je osoba spremna da preuzme na sebe. U svojim ekstremnim manifestacijama, detinjasta pozicija programera, koju sam sreo više puta, izgleda ovako: napisao sam kod, poslao ga na pregled - moj posao je završen. Recenzenti bi ga trebali pregledati i odobriti, QA bi trebao provjeriti, ako bude problema, obavijestit će me. Čudno je da se čak i prilično zreli i iskusni ljudi ponekad tako ponašaju. Drugi kraj skale je da osoba sebe smatra odgovornom da osigura da njegov kod radi, da je pokriven testovima, da je on lično provjerio, da je uspješno prošao pregled (ako je potrebno, nema problema pingovanje recenzenta, diskusija o problemima glasom, itd.) i je potisnut, QA će pružiti pomoć ako je potrebno, scenariji testiranja će biti opisani itd. U normalnim slučajevima, programer ili počinje bliže kraju skale za odrasle, ili se kreće tamo kako stiče iskustvo (pod uslovom da se u timu gaji prava kultura). U ekstremnim slučajevima nastavlja raditi, obično zauzima djetinjastu poziciju, tada on i tim povremeno imaju probleme i sukobe.
Negovanje prave, zrele kulture u timu važan je zadatak za svakog menadžera. Potrebno je mnogo vremena i svakodnevnog truda, ali rezultat je vrijedan toga. Postoje dva načina utjecaja na timsku kulturu – vođenje primjera (koji će se svakako slijediti; tim uvijek gleda na vođu) i razgovor i nagrađivanje ispravnog ponašanja. Ni tu nema ničeg apstruznog ili vrlo formalnog, samo kada se raspravlja o problemima, uočite da se tu nešto moglo uraditi, naglasiti da ste primijetili kada je to ispravno odlučeno, pohvalite, napomenite prilikom pregleda izdanja itd.
Razmotrimo nekoliko tipičnih konfliktnih situacija, od jednostavnih do složenih:
Konflikti koji nisu vezani za radna pitanja
Vrlo često dolazi do sukoba na poslu koji nisu vezani za radna pitanja. Njihova pojava i lakoća rješavanja obično su u direktnoj vezi sa nivoom emocionalne inteligencije učesnika, stepenom njihove zrelosti, a nisu u vezi sa savršenstvom ili nesavršenošću procesa rada.
Tipični primjeri: neko ne koristi dovoljno često veš mašinu ili tuš, što se drugima ne sviđa, nekome je zagušljivo, dok drugi dobijaju vetar ako otvore prozor, neko je previše bučan, a drugima je potrebna tišina za rad i tako dalje. Bolje je ne odlagati rješavanje ovakvih sukoba i ne dozvoliti im da idu svojim tokom. Neće se sami riješiti i svakodnevno će vas odvlačiti od posla i trovati atmosferu u timu. Srećom, njihovo rješavanje obično nije veliki problem - samo mirno razgovarajte (jedan na jedan, naravno) s kolegom koji zanemaruje higijenu, osigurajte udobno sjedenje ljudima koji preferiraju tišinu/hladnoću, kupite slušalice koje upijaju zvuk ili instalirajte pregrade , itd.
Drugi primjer sa kojim sam se nekoliko puta susreo tokom svog rada je psihološka nekompatibilnost članova tima. Iz nekog razloga ljudi jednostavno ne mogu raditi zajedno, svaka interakcija završava skandalom. Ponekad je to zbog činjenice da ljudi imaju polarne stavove o nekom hitnom pitanju (obično političkom) i ne znaju kako da ih ostave izvan posla. Uvjeriti ih da toleriraju jedni druge ili promijene svoje ponašanje prilično je uzaludan zadatak. Jedini izuzetak s kojim sam se susreo su mlade kolege otvorene percepcije, čije ponašanje se još uvijek može postepeno mijenjati kroz periodične razgovore. Obično se problem uspješno rješava razdvajanjem u različite timove ili barem pružanjem mogućnosti da se vrlo rijetko preklapaju na poslu.
U svim navedenim situacijama vrijedi lično razgovarati sa svim učesnicima, prodiskutirati situaciju, pitati da li uopće vide problem u ovom slučaju, pitati se koja su, po njihovom mišljenju rješenja, i osigurati njihovo učešće u izradi ovog odluka.
Sa stanovišta optimizacije procesa rada (srednjoročna perspektiva koju sam pomenuo), tu se ne može mnogo učiniti, jedino što treba da se optimizira je da se pri formiranju tima vodi računa o faktoru kompatibilnosti i da se ne stavljaju ljudi. zajedno unapred ko će se sukobiti.
Iz perspektive timske kulture, takve situacije se mnogo rjeđe javljaju u timovima sa zrelom kulturom, gdje ljudi poštuju tim i kolege i znaju kako samostalno rješavati probleme. Osim toga, takvi se sukobi mnogo lakše (često automatski) rješavaju u timovima u kojima postoji visok nivo povjerenja, ljudi dugo rade zajedno i/ili često komuniciraju van posla.
Konflikti vezani za radna pitanja:
Ovakve sukobe najčešće izazivaju oba razloga odjednom, kako emocionalni (činjenica da jedan od učesnika nije u poziciji odrasle osobe) tako i nesavršenost samog procesa rada. Možda najčešći tip sukoba s kojim sam se susreo su sukobi tokom pregleda koda ili diskusija o arhitekturi između programera.
Ovdje bih izdvojio dva tipična slučaja:
1) U prvom slučaju, programer ne može dobiti pregled koda od kolege. Zakrpa je poslana na pregled i ništa se ne dešava. Na prvi pogled ne postoji očigledan sukob između dve strane, ali ako bolje razmislite, ovo je prilično sukob. Pitanje rada nije riješeno, jedna od strana (koja čeka pregled) doživljava očiglednu nelagodu. Ekstremni podtip ovog slučaja je razvoj u zajednici ili u različitim timovima, dok recenzent možda neće biti zainteresiran za ovaj konkretan kod, zbog učitavanja ili drugih okolnosti, možda uopće ne obraća pažnju na zahtjev za reviziju, a vanjski arbitar (menadžer zajednički za obje strane) ) možda uopće ne postoji.
Pristup rješenja koji pomaže u takvoj situaciji odnosi se upravo na dugoročnu perspektivu, kulturu odrasle osobe. Prvo, pametna aktivnost funkcionira. Ne treba očekivati da će kod koji visi na recenziji privući pažnju samog recenzenta. Moramo pomoći recenzentima da ga primjete. Pingani par ljudi, postavi pitanje na sinkape, učestvuje u diskusijama. Očigledno je da će upornost prije naštetiti nego pomoći, morate koristiti zdrav razum. Drugo, pretpriprema dobro funkcionira. Ako tim razumije šta se dešava i zašto, zašto je ovaj kod uopće potreban, dizajn je sa svima unaprijed prodiskutovan i dogovoren, vjerojatnije je da će ljudi obratiti pažnju na takav kod i prihvatiti ga za rad. Treće, autoritet radi. Ako želite da vas recenziraju, sami napravite mnogo recenzija. Napravite recenzije visokog kvaliteta, sa stvarnim provjerama, stvarnim testovima i korisnim komentarima. Ako je vaš nadimak dobro poznat u timu, veća je šansa da će vaš kod biti primjećen.
Sa stanovišta toka posla, moguća poboljšanja su ispravan prioritet koji ima za cilj da pomogne programeru da postigne svoje i ciljeve tima (pregleda druge, piše pisma zajednici, poprati kod opisom arhitekture, dokumentacijom, testovima, učestvuje u raspravama sa zajednica, itd.), spriječiti da zakrpe predugo vise u redu čekanja i tako dalje.
2) Drugi uobičajeni slučaj sukoba tokom pregleda koda ili dizajna su različiti pogledi na tehnička pitanja, stil kodiranja i izbor alata. Od velikog značaja u ovom slučaju je nivo poverenja između učesnika, pripadnost istom timu i iskustvo zajedničkog rada. Slepa ulica nastaje kada jedan od učesnika zauzme detinjastu poziciju i ne pokušava da čuje šta mu sagovornik želi da prenese. Često, i pristup koji je predložila druga strana i pristup koji je prvobitno predložen mogu dobro funkcionirati i u principu nije važno koji odabrati.
Jednog dana, programer iz mog tima (nazovimo ga Pasha) pripremio je zakrpu sa izmenama sistema za implementaciju paketa, koju su razvile i podržale kolege iz susednog odeljenja. Jedan od njih (Igor) je imao svoje čvrsto mišljenje o tome kako bi se Linux servisi trebali konfigurirati prilikom postavljanja paketa. Ovo mišljenje se razlikovalo od pristupa predloženog u zakrpi i nisu se mogli složiti. Kao i obično, rokovi su istjecali i trebalo je donijeti neku odluku, bilo je potrebno da neko od njih zauzme punoljetnu poziciju. Paša je prepoznao da oba pristupa imaju pravo na život, ali je želio da njegova opcija prođe, jer Ni jedna ni druga opcija nisu imale očigledne tehničke prednosti.
Naša diskusija je izgledala otprilike ovako (vrlo shematski, naravno, razgovor je trajao pola sata):
- Pasha, imamo zamrzavanje funkcije za nekoliko dana. Važno je da sve skupimo i počnemo testirati što je prije moguće. Kako možemo preći preko Igora?
— Želi drugačije da postavi servise, tu mi je stavio komentare...
- A šta je tu, velike izmene, velika gužva?
- Ne, posla ima par sati, ali na kraju nema razlike, radiće kako god, zašto je to potrebno? Napravio sam nešto što radi, prihvatimo to.
- Slušaj, koliko dugo raspravljaš o svemu ovome?
- Da, već nedelju i po obeležavamo vreme.
- Hm... da li možemo da rešimo problem za par sati koji je već trajao nedelju i po dana, a da to ne uradimo?
- Pa da, ali ne želim da Igor pomisli da sam pokleknula...
- Slušaj, šta ti je važnije, da izdaš oslobađanje, uz svoju odluku unutra, ili da ubiješ Igora? Možemo ga blokirati, međutim, postoji dobra šansa da prođemo s izdavanjem.
- Pa... bilo bi kul, naravno, Igoru obrisati nos, ali dobro, bitnije je oslobađanje, slažem se.
- Da li vam je zaista toliko važno šta Igor misli? Iskreno govoreći, njega uopće ne zanima, samo želi jedinstven pristup na različitim mjestima stvari za koje je odgovoran.
- Pa dobro, pusti me da uradim kako on traži u komentarima i krenimo sa testiranjem.
- Hvala ti, Paša! Bio sam siguran da ćeš od vas dvoje biti zreliji, iako je Igorek stariji od vas :)
Problem je riješen, izdanje je pušteno na vrijeme, paša nije osjećao veliko nezadovoljstvo, jer on je sam predložio rješenje i implementirao ga. Igor je generalno bio zadovoljan, jer... Njegovo mišljenje je uzeto u obzir i uradili su kako je predložio.
Druga vrsta suštinski istog sukoba je izbor između tehničkih rješenja/biblioteka/pristupa u projektu, posebno u distribuiranom timu. U jednom od projekata, koji je pozicioniran kao korištenje C/C++, pokazalo se da je tehničko upravljanje projektom kategorički protiv korištenja STL (Standard Template Library). Ovo je biblioteka standardnih jezika koja pojednostavljuje razvoj, a naš tim je na to vrlo navikao. Ispostavilo se da je projekat mnogo bliži C-u nego C++-u, što nije previše inspirisalo tim, jer menadžment se potrudio i regrutovao zaista cool plus igrače. Istovremeno, američki dio tima, i inženjeri i menadžeri, dugo su radili u kompaniji, navikli na postojeće stanje i svime su bili zadovoljni. Ruski dio tima okupljen je sasvim nedavno, za nekoliko sedmica (uključujući i mene). Ruski dio tima kategorički nije želio napustiti uobičajeni pristup razvoju.
Počele su beskrajne pisane rasprave između dva kontinenta, pisma na tri ili četiri ekrana su letjela naprijed-nazad, u grupnim i ličnim porukama, od programera do programera i menadžera. Kao što to obično biva, pisma ove dužine nije čitao niko osim autora i njihovih vatrenih pristalica. Chatovi su škripali od napetosti, prenoseći misli na više ekrana u različitim smjerovima o tehničkim prednostima STL-a, koliko je dobro testiran, koliko je siguran, i općenito, kako je divan život s njim, a kako je užasan bez njega .
Sve je to trajalo dosta dugo, dok nisam konačno shvatio da smo razgovarali o tehničkim aspektima problema, ali problem u stvarnosti nije bio tehnički. Problem nisu prednosti ili nedostaci STL-a ili teškoća rada bez njega. Problem je pre organizacionog karaktera. Trebalo je samo da shvatimo kako funkcioniše kompanija za koju smo radili. Niko od nas ranije nije imao iskustva u radu u takvoj kompaniji. Stvar je bila u tome da su nakon što je kod razvijen i pušten u produkciju, podrškom su se bavili potpuno drugačiji ljudi iz drugih timova, iz drugih zemalja. Ovaj ogromni inženjerski tim od nekoliko desetina hiljada inženjera (ukupno) mogao je sebi priuštiti samo sasvim osnovni minimum tehničkih sredstava, da tako kažem, minimalni minimum. Sve što je prevazilazilo inženjerski standard uspostavljen u kompaniji fizički nije moglo biti podržano u budućnosti. Nivo tima određuje se nivoom njegovih najslabijih članova. Nakon što smo razumeli prava motivacija akcijama američkog dijela tima ovo pitanje je skinuto s dnevnog reda, te smo zajedno uspješno razvili i pustili proizvod koristeći standarde koje je usvojila kompanija. Pisma i razgovori u ovom slučaju nisu dobro funkcionirali, bilo je potrebno nekoliko putovanja i puno lične komunikacije da bi došli do zajedničkog imenitelja.
Sa stanovišta toka rada, u ovom konkretnom slučaju, bilo bi od pomoći da postoji opis korištenih alata, zahtjevi za njima, ograničenja za dodavanje novih i opravdanje za takva ograničenja. Takvi dokumenti približno odgovaraju onima opisanim u paragrafima Strategija ponovne upotrebe i razvojno okruženje „Priručnika za menadžere za razvoj softvera“, izrađenog u . Uprkos svojoj starosti, savršeno opisuje sve glavne aktivnosti i faze planiranja razvoja softvera ove vrste. Posjedovanje ovakvih dokumenata olakšava raspravu o tome koje komponente i pristupi se mogu koristiti u proizvodu i zašto.
Sa kulturološke tačke gledišta, očigledno, sa zrelijom pozicijom, u kojoj stranke pokušavaju da čuju i razumeju stvarnu motivaciju akcija svojih kolega i deluju na osnovu prioriteta projekta i tima, a ne ličnog ega , sukob bi se lakše i brže riješio.
U jednom drugom sukobu oko izbora tehničkog rješenja također mi je trebalo dosta vremena da shvatim motivaciju jedne od strana (to je bio vrlo neobičan slučaj), ali nakon što je motivacija bila jasna, rješenje je bilo očigledno.
Situacija je sledeća: novi programer se pojavljuje u timu od oko 20 ljudi, nazovimo ga Stas. U to vrijeme, naš standardni alat za timsku komunikaciju bio je Skype. Kako se kasnije ispostavilo, Stas je bio veliki obožavatelj otvorenih standarda i softvera otvorenog koda, te je koristio samo alate i operativne sisteme čiji su izvori bili javno dostupni i koji su koristili javno opisane protokole. Skype nije jedan od ovih alata. Proveli smo dosta vremena raspravljajući o prednostima i nedostacima ovog pristupa, pokušajima lansiranja analoga Skype-a na različitim operativnim sistemima, Stasovim pokušajima da uvjeri tim da pređe na druge standarde, pisati mu lično poštom, nazvati ga lično na telefon, kupi mu drugi kompjuter specijalno za Skype, itd. Konačno, shvatio sam da ovaj problem, u suštini, nije tehnički ili organizacioni, nego ideološki, čak, reklo bi se, religiozni (za Stasa). Čak i kada bismo na kraju povezali Stasa i Skype (što je trajalo nekoliko mjeseci), problem bi se ponovo pojavio na svakom sljedećem instrumentu. Nisam imao pravih sredstava na raspolaganju da promenim Stasov pogled na svet, a nije bilo ni razloga da pokušam da promenim pogled na svet tima koji je savršeno funkcionisao u ovoj sredini. Osoba i kompanija su jednostavno bili ortogonalni u svom svjetonazoru. U takvim situacijama dobro rješenje je organizaciono. Stasa smo prebacili u drugi tim, gde je bio organskiji.
Razlog za ovaj sukob je, po mom mišljenju, nesklad između lične kulture određene osobe (koja ima čvrsto mišljenje koje mu ne dozvoljava kompromis) i kulture kompanije. U ovom slučaju, to je, naravno, greška menadžera. U početku je bilo pogrešno uzeti ga na projekat ove vrste. Stas je na kraju prešao na projekat razvoja softvera otvorenog koda i tu se istakao.
Dobar primjer sukoba uzrokovanog djetinjastim stavom programera i nedostacima procesa rada je situacija u kojoj, u nedostatku definicije urađenog, programer i QA tim imaju različita očekivanja u pogledu spremnosti funkcija prenesena na QA. Programer je vjerovao da je dovoljno napisati kod i baciti funkciju preko ograde QA-u - oni će to riješiti tamo. Inače, prilično zreo i iskusan programer, ali to je bio njegov unutrašnji prag kvaliteta. QA se nije složio sa ovim i zahtijevao je da im pokaže i opiše ono što je sam provjerio, te je za njih tražio skriptu za testiranje. Imali su problema s funkcionalnostima ovog programera u prošlosti i nisu željeli ponovo gubiti vrijeme. Usput, bili su u pravu - funkcija zaista nije radila, nije provjerio kod prije nego što ga je poslao QA-u.
Da riješim situaciju, zamolio sam ga da mi pokaže da sve zaista funkcionira (nije radilo, a on je morao to popraviti), razgovarali smo sa timom i sa QA definicijom gotovo (nisu uspjeli u pisanja, jer nismo hteli da proces bude previše birokratski), pa, ubrzo smo se rastali od ovog specijaliste (na opšte olakšanje).
Sa stanovišta toka posla, moguća poboljšanja u ovom slučaju su prisustvo definicije urađenog, zahteva za podršku svake karakteristike jedinice i integracijskih testova, kao i opis testiranja koje sprovodi programer. U jednom od projekata mjerili smo nivo pokrivenosti koda testovima tokom CI i ako je nivo pokrivenosti pao nakon dodavanja zakrpe, testovi su označeni kao neuspjeli, tj. bilo koji novi kod se mogao dodati samo ako postoje novi testovi za njega.
Još jedan tipičan primjer sukoba usko vezan za organizaciju radnog procesa. Imamo proizvod, tim za razvoj proizvoda, tim za podršku i kupca. Kupac ima problema sa proizvodom i kontaktira podršku. Podrška analizira problem i shvata da je problem u proizvodu i prenosi problem na proizvodni tim. Proizvodni tim je u gužvi, bliži se izlazak, pa tiket sa problemom od kupca, izgubljen među ostalim tiketima programera kojem je dodijeljen, visi nekoliko sedmica bez pažnje. Podrška smatra da programer radi na problemu korisnika. Kupac čeka i nada se da će se njihov problem riješiti. U stvarnosti se još ništa ne dešava. Nakon nekoliko sedmica, korisnik konačno odlučuje da se zainteresuje za napredak i pita podršku kako stvari idu. Podrška traži razvoj. Programer se strese, pregleda listu tiketa i tamo pronađe tiket od kupca. Čitajući tiket od kupca, on shvaća da nema dovoljno informacija za rješavanje problema, te mu je potrebno više dnevnika i deponija. Podrška traži dodatne informacije od korisnika. I tada kupac shvati da niko nije radio na njegovom problemu sve ovo vrijeme. I grom će udariti...
U ovoj situaciji, rješenje samog konflikta je prilično očigledno i linearno (popraviti proizvod, ažurirati dokumentaciju i testove, umiriti kupca, objaviti hitnu ispravku, itd.). Važno je analizirati proces rada i razumjeti ko je odgovoran za organizaciju interakcije između dva tima i zašto je ova situacija uopće postala moguća. Jasno je šta treba popraviti u procesu – neko mora proaktivno pratiti cjelokupnu sliku bez podsjetnika kupaca. Ulaznice od kupaca trebale bi se izdvojiti među ostalim ulaznicama programera. Podrška bi trebala vidjeti da li razvojni tim trenutno radi na svojim tiketima, a ako ne, kada može početi s radom i kada se mogu očekivati rezultati. Podrška i razvoj bi trebali periodično komunicirati i razgovarati o statusu tiketa, prikupljanje informacija potrebnih za otklanjanje grešaka treba biti automatizirano što je više moguće, itd.
Kao što u ratu neprijatelj pokušava pogoditi spoj između dvije jedinice, tako je u radu najosjetljivija i najranjivija točka obično interakcija između timova. Ako su menadžeri za podršku i razvoj dovoljno stari, moći će sami da poprave proces, ako ne, proces će nastaviti stvarati sukobe i probleme sve dok se ne umiješa menadžer koji može popraviti situaciju.
Još jedan tipičan primjer koji sam više puta viđao u različitim kompanijama je situacija u kojoj proizvod piše jedan tim, automatske integracijske testove za njega piše drugi tim, a infrastrukturu na kojoj sve to radi prati treći tim. tim. Problemi pri pokretanju testova se javljaju stalno, a uzrok problema u njima može biti i proizvod i testovi i infrastruktura. Obično je problematično dogovoriti se ko treba da izvrši početnu analizu problema, grešaka u fajlovima, parsiranje dnevnika proizvoda, testova i infrastrukture itd. Sukobi su ovdje vrlo česti, a ujedno i jednoobrazni. U slučaju visokog emocionalnog intenziteta, učesnici često padaju u detinjastu poziciju i u seriji počinju rasprave: „zašto da se petljam sa ovim“, „češće se kvare“ itd.
Iz perspektive toka posla, konkretni koraci za rješavanje problema zavise od sastava timova, vrste testova i proizvoda, itd. U jednom od projekata uveli smo periodično dežurstvo, u kojem su timovi pratili testove jedan po jedan, sedmicu po sedmicu. S druge strane, početnu analizu su uvijek radili programeri testa, ali analiza je bila vrlo osnovna i proizvod je bio prilično stabilan, tako da je dobro radio. Ključno je osigurati da proces bude transparentan, da su očekivanja jasna za sve strane i da je situacija pravedna prema svima.
Da li je konflikt čak i problem u organizaciji? Da li je loš znak da se sukobi često (ili samo povremeno) javljaju u vašem timu? Generalno, ne, jer ako postoji rast, razvoj, postoji neka dinamika, onda nastaju problemi koji nikada ranije nisu bili riješeni, a prilikom njihovog rješavanja mogu nastati konflikti. Ovo je pokazatelj da nekim oblastima treba obratiti pažnju, da postoje oblasti za poboljšanje. Loše je ako se sukobi javljaju vrlo često, teško ih je riješiti ili traju dugo. To je najvjerovatnije znak nedovoljno usaglašenih radnih procesa i nedovoljne zrelosti tima.
izvor: www.habr.com