Epigraf:
Jednom davno sreli su se Jež i Mali medo u šumi.
- Zdravo, Jež!
- Zdravo, Mali medo!
Tako je, riječ po riječ, šala po šala, Jež dobio po licu Mali Medo...
U nastavku je rasprava voditelja našeg tima, kao i direktora razvoja proizvoda RAS-a Igora Marnata, o specifičnostima radnih sukoba i mogućim metodama za njihovo upravljanje.
Većina sukoba s kojima se susrećemo na poslu razvija se prema scenariju sličnom onom opisanom u gornjem epigrafu. Postoji nekoliko sudionika koji su u početku prilično blagonaklono raspoloženi jedni prema drugima, pokušavaju riješiti neki problem, ali na kraju problem ostaje neriješen, a odnosi između sudionika u raspravi iz nekog razloga ispadaju pokvareni.
Život je raznolik, a varijacije se javljaju u gore opisanom scenariju. Ponekad odnos između sudionika u početku nije baš dobar, ponekad čak i ne postoji pitanje koje zahtijeva izravno rješenje (kao npr. u epigrafu), ponekad nakon rasprave odnos ostaje isti kao prije nego što je započela, ali problem na kraju nije riješen.
Što je zajedničko svim situacijama koje se mogu definirati kao situacija radnog konflikta?
Prvo, postoje dvije ili više strana. Te strane mogu zauzimati različita mjesta u organizaciji, biti u odnosu ravnopravnosti (kolege u timu) ili na različitim razinama hijerarhije (šef - podređeni), biti pojedinačne (zaposlenik) ili grupa (u slučajevima sukoba između zaposlenik i tim ili dva tima), i tako dalje. Na vjerojatnost sukoba i lakoću njegovog rješavanja uvelike utječe razina povjerenja između sudionika. Što se strane bolje poznaju, što je veća razina povjerenja, veća je šansa da će se dogovoriti. Na primjer, veća je vjerojatnost da će članovi distribuiranog tima koji nikada nisu komunicirali licem u lice doživjeti sukob oko jednostavnog poslovnog problema nego ljudi koji su imali barem nekoliko interakcija licem u lice. Stoga, kada radite u distribuiranim timovima, vrlo je važno osigurati da se svi članovi tima povremeno međusobno sastaju osobno.
Drugo, u situaciji sukoba na poslu strane su u situaciji rješavanja nekog pitanja 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, dopisi, odluke uprave, prisutnost ciljeva i planova tima, činjenica hijerarhije itd.). To se razlikuje od situacije rješavanja radnog (ili neradnog) pitanja u organizaciji od npr. rješavanja važnog pitanja: “Eh, mali, iz kojeg si kraja?!” na ulici, odnosno sukob iz epigrafa. U slučaju rješavanja radnog pitanja bitna je kvaliteta radnog procesa i kultura rješavanja problema u timu.
Treće, odlučujući čimbenik sukoba (sa stajališ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. Ova se točka može činiti kontroverznom, ali, u biti, ako je konfliktna situacija uspješno riješena bez intervencije vanjskog arbitra, problem je uspješno riješen i odnosi strana se nisu pogoršali, to je situacija kojoj trebamo težiti . Za takav sukob najvjerojatnije nećemo ni znati ili ćemo saznati slučajno nakon što se on riješi. Što više problema tim može riješiti sam, to će biti učinkovitiji.
Još jedno karakteristično obilježje sukoba koje se vrijedi dotaknuti je stupanj emocionalnog intenziteta tijekom odluke. Sukob nije nužno povezan s visokom emocionalnom razinom. Sudionici ne moraju vikati i mahati rukama da bi situacija bila, u biti, sukob. Problem nije riješen, prisutna je određena emocionalna napetost (možda nije jasno izražena prema van), što znači da smo suočeni s konfliktnom situacijom.
Je li uopće potrebno intervenirati u konfliktnim situacijama ili je bolje pustiti njihovo rješavanje svojim tijekom i pričekati da se problem riješi sam od sebe? Moram. Nije uvijek u vašoj moći ili kompetenciji riješiti sukob u potpunosti, ali u svakoj situaciji, u sukobu bilo kojeg razmjera, možete zauzeti stav odrasle osobe, privući na njega još nekoliko ljudi oko sebe, ublažiti negativne posljedice sukoba i doprinijeti njegovom rješavanju.
Prije nego pogledamo nekoliko primjera konfliktnih situacija, pogledajmo nekoliko važnih točaka zajedničkih svim sukobima.
Prilikom rješavanja sukoba važno je biti iznad borbe, a ne unutar nje (ovo se naziva i “zauzimanje metapozicije”), odnosno ne biti dio jedne od strana u procesu rješavanja. U suprotnom, pomoć vanjskog arbitra u odluci samo će ojačati položaj jedne strane na štetu druge strane. Pri donošenju odluke važno je da je moralno prihvaćena od svih strana, kako se kaže, “kupljena”. Tako da su stranke, ako i nisu bile oduševljene donesenom odlukom, barem iskreno pristale na njezino provođenje. Kako kažu, moći se ne slagati i obvezati. Inače će sukob jednostavno promijeniti izgled, tinjajuća vatra ostat će ispod tresetišta i kad-tad će se neizbježno ponovno rasplamsati.
Druga točka, djelomično povezana s prvom, jest da ako ste već odlučili sudjelovati u rješavanju sukoba, shvatite to što je moguće ozbiljnije sa stajališta komunikacije i proučavanja konteksta. Osobno razgovarajte sa svakom od strana. Sa svakim posebno, za početak. Nemojte se zadovoljiti poštom. U slučaju distribuiranog tima, razgovarajte barem putem video veze. Nemojte se zadovoljiti glasinama i izvještajima očevidaca. Razumjeti priču, što svaka strana želi, zašto to želi, što očekuje, jesu li prije pokušali riješiti ovo pitanje, što će se dogoditi ako se ne riješi, kakva rješenja vide, kako zamišljaju položaj druga strana, što oni misle, ispravno ili krivo, itd. Učitajte sav mogući kontekst u svoju glavu, otvorenog uma, pod pretpostavkom da su svi u pravu. Vi niste unutar sukoba, vi ste izvan njega, u metapoziciji. Ako je kontekst dostupan samo u temi objave, barem je pročitajte u cijelosti, kao i teme i dokumente povezane s njom. Nakon što ga pročitate, i dalje govorite svojim glasom. Gotovo je zajamčeno da ćete čuti nešto važno što nije u pošti.
Treća važna točka je opći pristup komunikaciji. To su obične stvari, ništa svemirske, ali su jako važne. Ne pokušavamo štedjeti vrijeme, razgovaramo sa svim sudionicima, ne kritiziramo osobu, već razmatramo posljedice njezinih postupaka (ne “bezobrazan si”, nego “možda bi dečki mogli biti uvrijeđeni ova stvar”), dajemo priliku da sačuvamo obraz, vodimo razgovore osobno, a ne ispred reda.
Sukobi su obično uzrokovani jednim od dva razloga. Prvi se odnosi na to je li osoba u trenutku sukoba u poziciji odrasle osobe ili u poziciji djeteta (više o tome u nastavku). To je zbog njegove emocionalne zrelosti, sposobnosti da upravlja svojim emocijama (koja, usput rečeno, nije uvijek povezana s njegovom dobi). Drugi čest razlog je nesavršenost procesa rada koji stvara situacije sivih zona u kojima je odgovornost raspoređena između sudionika, očekivanja strana nisu transparentna jedna prema drugoj, a uloge u procesu zamagljene.
Sukladno tome, pri rješavanju sukoba (kao i bilo kojeg drugog pitanja) menadžer mora imati na umu tri perspektive: kratkoročnu – riješiti problem/konflikt ovdje i sada, srednjoročnu – smanjiti vjerojatnost ponovnog izbijanja sukoba. iz istog razloga, i dugoročno - njegovati kulturu odraslih u timskoj osobi.
Svatko od nas ima unutarnje dijete, staro otprilike tri ili četiri godine. Na poslu većinu vremena spava, no ponekad se probudi i preuzme kontrolu. Dijete ima svoje prioritete. Bitno mu je da inzistira na tome da je ovo njegov pješčanik, mama ga više voli, njegova mašina je najbolja (dizajn je najbolji, on najbolje programira, ...). U situaciji sukoba dijete može pritiskati igračke, lupati nogama i pucketati lopaticom, ali ne može rješavati pitanja odraslih (arhitektura rješenja, pristupi automatskom testiranju, datumi izdavanja itd.), ne razmišlja o koristima za tim. Dijete u sukobu može se ohrabriti, utješiti i poslati u krevet zamolivši ga da pozove odraslu osobu. Prije nego započnete raspravu u konfliktnoj situaciji, provjerite razgovarate li s odraslom osobom, a ne s djetetom, te jeste li i sami u poziciji odrasle osobe. Ako vam je u ovom trenutku iskreni cilj riješiti ozbiljan problem, u poziciji ste odrasle osobe. Ako vam je cilj lupati nogama i slomiti lopaticu, ovo je djetinjasti položaj. Pošaljite svoje unutarnje dijete u krevet i nazovite odraslu osobu ili odgodite raspravu. Osoba donosi emocionalnu odluku, a zatim za nju traži racionalno opravdanje. Odluka koju dijete donese na temelju djetetovih prioriteta neće biti optimalna.
Osim ponašanjem u trenutku sukoba, položaj djeteta ili odrasle osobe karakterizira i razina odgovornosti koju je osoba spremna preuzeti. U svojim ekstremnim manifestacijama, djetinjasta pozicija programera, koju sam više puta susreo, izgleda ovako: napisao sam kod, poslao ga na pregled - moj rad je gotov. Recenzenti bi ga trebali pregledati i odobriti, QA bi trebao provjeriti, ako bude problema, javit će mi. Čudno je da se čak i prilično zreli i iskusni ljudi ponekad ponašaju na ovaj način. Drugi kraj ljestvice je da se osoba smatra odgovornom osigurati da njegov kod radi, da je pokriven testovima, da ga je osobno provjerio, da je uspješno prošao recenziju (ako je potrebno, nema problema pingati recenzente, raspravljati o problemima glasom, itd.) i potisnut je, QA će pružiti pomoć ako je potrebno, bit će opisani testni scenariji, itd. U normalnim slučajevima, programer ili počinje bliže kraju ljestvice za odrasle ili se tamo pomiče kako stječe iskustvo (pod uvjetom da se unutar tima njeguje prava kultura). U ekstremnim slučajevima, on nastavlja raditi, obično zauzima djetinjasti stav, tada on i tim povremeno imaju problema i sukoba.
Poticanje prave, zrele kulture u timu važan je zadatak svakog menadžera. Potrebno je puno vremena i svakodnevnog truda, ali rezultat je vrijedan toga. Postoje dva načina utjecaja na timsku kulturu - vođenje primjerom (koji će se svakako slijediti; tim uvijek gleda na vođu) te rasprava i nagrađivanje ispravnog ponašanja. Ni tu nema ništa nejasno niti vrlo formalno, samo kada se raspravlja o problemima, primijetite da se tu nešto moglo učiniti, naglasite da ste primijetili kada je odlučeno ispravno, pohvalite, napomenite tijekom pregleda objave itd.
Razmotrimo nekoliko tipičnih konfliktnih situacija, od jednostavnih do složenih:
Sukobi koji nisu povezani s radnim pitanjima
Vrlo često na poslu dolazi do sukoba koji nisu vezani uz radna pitanja. Njihova pojava i lakoća rješavanja najčešće su u izravnoj vezi s razinom emocionalne inteligencije sudionika, njihovom razinom zrelosti, a ne sa savršenstvom ili nesavršenošću procesa rada.
Tipični primjeri: netko ne koristi dovoljno često perilicu rublja ili tuširanje, što se drugima ne sviđa, nekome je zagušljivo, a drugima puše vjetrovi ako otvore prozor, netko je prebučan, a trećima je za rad potrebna tišina, a tako dalje. Bolje je ne odgađati rješavanje sukoba ove vrste i ne dopustiti im da idu svojim tokom. One se neće riješiti same od sebe i svakodnevno će vas odvraćati od posla i trovati atmosferu u timu. Srećom, njihovo rješavanje obično nije veliki problem - samo mirno razgovarajte (naravno, jedan na jedan) s kolegom koji zanemaruje higijenu, osigurajte udobno sjedenje osobama koje vole tišinu/hladnoću, kupite slušalice koje apsorbiraju zvuk ili postavite pregrade itd.
Još jedan primjer s kojim sam se više puta susrela tijekom rada je psihička nekompatibilnost članova tima. Iz nekog razloga ljudi jednostavno ne mogu raditi zajedno, svaka interakcija završi skandalom. Ponekad je to zbog činjenice da ljudi imaju polarna stajališta o nekom hitnom pitanju (obično političkom) i ne znaju kako ih ostaviti izvan posla. Uvjeravati ih da se međusobno toleriraju ili da promijene svoje ponašanje prilično je uzaludan zadatak. Jedina iznimka s kojom sam se susreo su mladi kolege otvorenih percepcija, čije se ponašanje ipak može postupno mijenjati povremenim razgovorima. Obično se problem uspješno riješi razdvajanjem u različite timove ili barem pružanjem prilike da se vrlo rijetko preklapaju na poslu.
U svim navedenim situacijama vrijedi osobno razgovarati sa svim sudionicima, prodiskutirati situaciju, pitati vide li oni uopće problem u ovom slučaju, pitati koja su, po njihovom mišljenju, rješenja te osigurati njihovo sudjelovanje u izradi ovoga odluka.
Sa stajališta optimizacije procesa rada (srednjoročna perspektiva koju sam spomenuo) tu se ne može puno učiniti, jedina poanta optimizacije je uzeti u obzir faktor kompatibilnosti pri formiranju tima, a ne stavljati ljude zajedno unaprijed tko će se sukobiti.
Iz perspektive timske kulture, takve se situacije mnogo rjeđe pojavljuju u timovima sa zrelom kulturom, gdje ljudi poštuju tim i kolege i znaju kako samostalno rješavati probleme. Osim toga, takvi se sukobi puno lakše (često automatski) rješavaju u timovima u kojima postoji visoka razina povjerenja, ljudi rade zajedno dugo vremena i/ili često komuniciraju izvan posla.
Sukobi vezani uz probleme na poslu:
Takve sukobe obično uzrokuju oba razloga odjednom, i emocionalni (činjenica da jedan od sudionika nije u poziciji odrasle osobe) i nesavršenost samog procesa rada. Možda su najčešći tip sukoba s kojima sam se susreo sukobi tijekom pregleda koda ili rasprava o arhitekturi između programera.
Ovdje bih istaknuo dva tipična slučaja:
1) U prvom slučaju programer ne može dobiti pregled koda od kolege. Zakrpa se šalje na pregled i ništa se ne događa. Na prvi pogled nema očitog sukoba između dviju strana, ali ako bolje razmislite, ovo je popriličan sukob. Problem s radom nije riješen, jedna od strana (koja čeka pregled) doživljava očitu nelagodu. Ekstremna podvrsta ovog slučaja je razvoj u zajednici ili u različitim timovima, dok recenzent možda neće biti zainteresiran za ovaj određeni kod, zbog učitavanja ili drugih okolnosti, možda uopće neće obratiti pozornost na zahtjev za recenziju, a vanjski arbitar (menadžer zajednički za obje strane) ) možda uopće ne postoji.
Pristup rješenju koji pomaže u takvoj situaciji odnosi se upravo na dugoročnu perspektivu, kulturu odrasle osobe. Prvo, pametna aktivnost djeluje. Ne biste trebali očekivati da će kod koji visi na recenziji privući pozornost samog recenzenta. Moramo pomoći recenzentima da ga primijete. Pingani par ljudi, postavi pitanje na syncapeu, sudjeluj u raspravama. Očito je vjerojatnije da će napadnost prije štetiti nego pomoći, morate koristiti zdrav razum. Drugo, predpriprema dobro funkcionira. Ako tim razumije što se događa i zašto, zašto je ovaj kod uopće potreban, dizajn je raspravljen i dogovoren unaprijed sa svima, veća je vjerojatnost da će ljudi obratiti pozornost na takav kod i prihvatiti ga za rad. Treće, autoritet djeluje. Ako želite da vas recenziraju, sami napravite mnogo recenzija. Napravite visokokvalitetne preglede, sa stvarnim provjerama, stvarnim testovima i korisnim komentarima. Ako je vaš nadimak dobro poznat u timu, veće su šanse da će vaš kod biti primijećen.
Sa stajališta tijeka rada, moguća poboljšanja ovdje su ispravno određivanje prioriteta usmjereno na pomoć programeru da postigne svoje ciljeve i ciljeve tima (pregledajte druge, napišite pisma zajednici, popratite kod s opisom arhitekture, dokumentacijom, testovima, sudjelujte u raspravama s zajednice, itd.), spriječiti da zakrpe predugo stoje u redu čekanja, i tako dalje.
2) Drugi uobičajeni slučaj sukoba tijekom pregleda koda ili dizajna su različiti pogledi na tehnička pitanja, stil kodiranja i izbor alata. Od velike važnosti u ovom slučaju je razina povjerenja između sudionika, pripadnost istom timu i iskustvo zajedničkog rada. Do slijepe ulice dolazi kada jedan od sudionika zauzme djetinjasti stav i ne trudi se čuti što mu sugovornik želi poručiti. Često i pristup koji je predložila druga strana i pristup koji je prvobitno predložen mogu uspješno funkcionirati i u načelu nije važno koji odabrati.
Jednog dana, programer iz mog tima (nazovimo ga Pasha) pripremio je zakrpu s promjenama u sustavu implementacije paketa, koji su razvili i podržali kolege iz susjednog odjela. Jedan od njih (Igor) imao je svoje čvrsto mišljenje o tome kako bi Linux usluge trebale biti konfigurirane prilikom postavljanja paketa. Ovo se mišljenje razlikovalo od pristupa predloženog u zakrpi i nisu se mogli složiti. Kao i obično, rokovi su istjecali, trebalo je donijeti nekakvu odluku, bilo je potrebno da netko od njih zauzme poziciju odrasle osobe. Paša je priznao da oba pristupa imaju pravo na život, ali je želio da njegova opcija prođe, jer Ni jedna ni druga opcija nisu imale očite tehničke prednosti.
Naša rasprava izgledala je otprilike ovako (vrlo shematski, naravno, razgovor je trajao pola sata):
- Pasha, imamo zamrzavanje značajki za nekoliko dana. Bitno je da sve skupimo i što prije krenemo s testiranjima. Kako možemo preko Igora?
— Želi drukčije postaviti usluge, ubacio mi je komentare...
- A što je tu, velike preinake, puno frke?
- Ne, posla ima par sati, ali na kraju nema razlike, radit će se i ovako i tako, zašto je to potrebno? Napravio sam nešto što radi, prihvatimo to.
- Slušaj, koliko dugo raspravljaš o svemu tome?
- Da, već tjedan i pol obilježavamo vrijeme.
- Hm... možemo li u par sati riješiti problem koji je već oduzeo tjedan i pol, a da to ne učinimo?
- Pa da, ali ne želim da Igor pomisli da sam popustila...
- Slušaj, što ti je važnije izdati puštanje uz svoju odluku unutra ili ubiti Igora? Možemo ga blokirati, tada, međutim, postoji dobra šansa da proletimo s puštanjem.
- Pa... bilo bi cool, naravno, Igoru obrisati nos, ali dobro, izdanje je važnije, slažem se.
- Zar ti je stvarno toliko važno što Igor misli? Iskreno govoreći, njega uopće nije briga, on samo želi jedinstven pristup na različitim mjestima stvari za koju je odgovoran.
- Pa dobro, pusti me da napravim kako traži u komentarima i krenimo s testiranjem.
- Hvala ti, paša! Bio sam siguran da ćeš od vas dvoje biti zreliji, iako je Igorek stariji od tebe :)
Problem je riješen, izdanje je pušteno na vrijeme, Paša nije osjećao mnogo nezadovoljstva, jer sam je predložio rješenje i proveo ga u djelo. Igor je uglavnom bio zadovoljan, jer... Njegovo mišljenje su uvažili i učinili kako je predložio.
Drugi tip 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 da koristi C/C++, pokazalo se da je tehničko upravljanje projektom kategorički protiv korištenja STL-a (Standard Template Library). Ovo je knjižnica standardnog jezika koja pojednostavljuje razvoj i naš je tim jako navikao na nju. Ispostavilo se da je projekt puno bliži C-u nego C++-u, što tim nije previše inspiriralo, jer uprava je dala sve od sebe i regrutirala stvarno cool plus igrače. Istovremeno, američki dio tima, i inženjeri i menadžeri, dugo su radili u tvrtki, navikli su na postojeće stanje i svime su bili zadovoljni. Ruski dio tima okupio se nedavno, u roku od nekoliko tjedana (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-četiri ekrana letjela su tamo-amo, u grupnim i osobnim slanjima, od programera do programera i menadžera. Kako to obično biva, ovolika pisma nije čitao nitko osim autora i njihovih gorljivih pristaša. Chatovi su škripali od napetosti, prebacujuć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 zapravo nije bio tehnički. Problem nisu prednosti ili nedostaci STL-a ili teškoća rada bez njega. Problem je prije organizacijski. Samo smo trebali razumjeti kako funkcionira tvrtka za koju smo radili. Nitko od nas prije nije imao iskustva rada u takvoj tvrtki. Stvar je bila u tome što su nakon razvoja koda i puštanja u produkciju, podrškom upravljali potpuno drugi ljudi iz drugih timova, iz drugih zemalja. Ovaj golemi inženjerski tim od nekoliko desetaka tisuća inženjera (ukupno) mogao je priuštiti samo sasvim osnovni minimum tehničkih sredstava, da tako kažemo minimum minimorum. Sve što je fizički izlazilo iz okvira inženjerskih standarda uspostavljenih u tvrtki nije se moglo podržati u budućnosti. Razina tima određena je razinom njegovih najslabijih članova. Nakon što smo shvatili prava motivacija akcijama američkog dijela tima ovo je pitanje skinuto s dnevnog reda te smo zajedno uspješno razvili i pustili proizvod prema standardima koje je tvrtka usvojila. Pisma i chatovi u ovom slučaju nisu dobro funkcionirali; bilo je potrebno nekoliko putovanja i puno osobne komunikacije da se dođe do zajedničkog nazivnika.
Sa stajališta tijeka rada, u ovom konkretnom slučaju, bilo bi korisno imati opis alata koji se koriste, zahtjeve za njih, ograničenja za dodavanje novih i opravdanje za takva ograničenja. Takvi dokumenti otprilike odgovaraju onima opisanim u paragrafima Strategija ponovne upotrebe i razvojno okruženje “Manager's Handbook for Software Development”, razvijenog u . Unatoč svojoj starosti, savršeno opisuje sve glavne aktivnosti i faze planiranja razvoja softvera ove vrste. Posjedovanje ovakvih dokumenata olakšava raspravu o tome koje se komponente i pristupi mogu koristiti u proizvodu i zašto.
S kulturnog stajališta, očito, sa zrelijom pozicijom, u kojoj strane pokušavaju čuti i razumjeti stvarnu motivaciju postupaka svojih kolega i djelovati temeljeno na prioritetima projekta i tima, a ne na osobnom egu. , sukob bi se lakše i brže riješio.
U drugom sukobu oko izbora tehničkog rješenja također mi je trebalo primjetno dugo da shvatim motivaciju jedne od strana (bio je to vrlo neobičan slučaj), no nakon što je motivacija bila jasna, rješenje je bilo očito.
Situacija je sljedeća: u timu od 20-ak ljudi pojavljuje se novi programer, nazovimo ga Stas. U to vrijeme naš standardni alat za timsku komunikaciju bio je Skype. Kako se kasnije pokazalo, Stas je bio veliki ljubitelj otvorenih standarda i softvera otvorenog koda te je koristio samo alate i operativne sustave čiji su izvori bili javno dostupni i koji su koristili javno opisane protokole. Skype nije jedan od tih alata. Proveli smo dosta vremena raspravljajući o prednostima i nedostacima ovog pristupa, pokušajima pokretanja analoga Skypea na različitim operativnim sustavima, Stasovim pokušajima da uvjeri tim da prijeđu na druge standarde, pisali mu osobno poštom, osobno ga nazvali na telefon, kupiti mu drugo računalo posebno za Skype itd. Na kraju sam shvatio da ovaj problem, u biti, nije tehnički ni organizacijski, već ideološki, čak, reklo bi se, vjerski (za Stasa). Čak i da smo na kraju povezali Stasa i Skype (što je trajalo nekoliko mjeseci), problem bi se ponovno pojavio na svakom sljedećem instrumentu. Nisam imao stvarna sredstva na raspolaganju da promijenim Stasov svjetonazor, a nije bilo ni razloga da pokušavam promijeniti svjetonazor tima koji je savršeno funkcionirao u ovom okruženju. Osoba i tvrtka su jednostavno bile ortogonalne u svom svjetonazoru. U takvim situacijama dobro rješenje je organizacijsko. Stasa smo prebacili u drugi tim, gdje je bio organskiji.
Razlog ovog sukoba je, po mom mišljenju, nesklad između osobne kulture određene osobe (koja ima čvrsto mišljenje koje mu ne dopušta kompromise) i kulture tvrtke. U ovom slučaju, naravno, riječ je o pogrešci menadžera. U početku je bilo pogrešno uzeti ga na projekt ove vrste. Stas je naposljetku prešao na projekt razvoja softvera otvorenog koda i tamo se istaknuo.
Dobar primjer sukoba izazvanog djetinjastim stavom programera i manjkavostima procesa rada je situacija u kojoj, u nedostatku definicije gotovog, programer i QA tim imaju različita očekivanja u pogledu spremnosti značajka prenesena u QA. Programer je vjerovao da je dovoljno napisati kod i baciti značajku preko ograde QA-u - oni će to tamo riješiti. Usput, prilično zreo i iskusan programer, ali to je bio njegov interni prag kvalitete. QA se s tim nije složio i zahtijevao je da im pokaže i opiše što je sam provjerio, te je zatražio skriptu za testiranje za njih. Imali su problema s funkcionalnošću ovog programera u prošlosti i više nisu htjeli gubiti vrijeme. Usput, bili su u pravu - značajka stvarno nije radila, nije provjerio kod prije nego što ga je poslao QA-u.
Kako bih riješio situaciju, zamolio sam ga da mi pokaže da sve stvarno radi (nije radilo, a on je to morao popraviti), razgovarali smo s timom i s QA definicijom gotovo (nisu uspjeli pisanja, jer nismo htjeli učiniti proces previše birokratiziranim ), pa, ubrzo smo se rastali od ovog stručnjaka (na opće olakšanje).
Sa stajališta tijeka rada, moguća poboljšanja u ovom slučaju su prisutnost definicije gotovog, zahtjeva za podršku značajki svake jedinice i integracijskih testova te opisa testiranja koje provodi programer. U jednom od projekata mjerili smo razinu pokrivenosti koda testovima tijekom CI-ja i ako je razina pokrivenosti pala nakon dodavanja zakrpe, testovi su označeni kao neuspjeli, tj. svaki novi kod mogao bi se dodati samo ako za njega postoje novi testovi.
Još jedan tipičan primjer sukoba usko vezanog uz organizaciju procesa rada. Imamo proizvod, tim za razvoj proizvoda, tim za podršku i kupca. Kupac ima problema s proizvodom i kontaktira podršku. Podrška analizira problem i razumije da je problem u proizvodu te prenosi problem proizvodnom timu. Proizvodni tim je u gužvi, bliži se izdanje, pa tiket s problemom kupca, izgubljen među ostalim tiketima programera kojem je dodijeljen, visi nekoliko tjedana bez pažnje. Podrška smatra da programer radi na korisnikovom problemu. Kupac čeka i nada se da se radi na njegovom problemu. U stvarnosti se još ništa ne događa. Nakon nekoliko tjedana, korisnik se konačno odlučuje zainteresirati za napredak i pita podršku kako stvari stoje. Podrška traži razvoj. Programer zadrhti, pregleda listu ulaznica i tamo pronađe kartu od kupca. Čitajući tiket kupca, on shvaća da nema dovoljno informacija za rješavanje problema i da mu je potrebno više zapisa i deponija. Podrška traži dodatne informacije od korisnika. I onda kupac shvati da sve ovo vrijeme nitko nije radio na njegovom problemu. I grom će udariti...
U ovoj situaciji, samo rješenje sukoba je sasvim očito i linearno (popraviti proizvod, ažurirati dokumentaciju i testove, umiriti kupca, objaviti hitni popravak itd.). Važno je analizirati radni proces i shvatiti tko je odgovoran za organizaciju interakcije između dva tima i zašto je ova situacija uopće moguća. Jasno je što treba popraviti u procesu – netko mora pratiti cjelokupnu sliku bez opomena kupaca, proaktivno. Ulaznice od kupaca trebale bi se istaknuti među ostalim ulaznicama programera. Podrška bi trebala vidjeti radi li razvojni tim trenutno na svojim tiketima, a ako ne, kada može početi s radom i kada se mogu očekivati rezultati. Podrška i razvoj trebaju povremeno komunicirati i raspravljati o statusu ulaznica, prikupljanje informacija potrebnih za otklanjanje pogrešaka treba biti automatizirano što je više moguće, itd.
Baš kao što u ratu neprijatelj pokušava pogoditi spoj između dviju jedinica, tako je u radu najdelikatnija i najranjivija točka obično interakcija između timova. Ako su voditelji podrške i razvoja dovoljno stari, moći će sami popraviti proces, ako nisu, proces će nastaviti stvarati sukobe i probleme dok ne intervenira voditelj koji može popraviti situaciju.
Još jedan tipičan primjer koji sam više puta vidio u različitim tvrtkama je situacija u kojoj proizvod piše jedan tim, automatske integracijske testove za njega piše drugi tim, a infrastrukturu na kojoj se sve radi prati treći tim tim. Problemi pri izvođenju testova pojavljuju se stalno, a uzrok problema u njima može biti kako proizvod tako i testovi i infrastruktura. Obično je problematično dogovoriti se oko toga tko bi trebao izvršiti početnu analizu problema, grešaka u datotekama, parsirati zapisnike proizvoda, testove i infrastrukturu itd. Sukobi su ovdje vrlo česti, a pritom jednolični. U slučaju visokog emocionalnog intenziteta, sudionici često padaju u djetinjasti položaj i započinju rasprave u nizu: “zašto bih se ja s tim petljao”, “češće se slome” itd.
Iz perspektive tijeka rada, specifični koraci za rješavanje problema ovise o sastavu timova, vrsti testova i proizvoda itd. U jednom od projekata uveli smo periodična dežurstva u kojima su timovi jedan po jedan pratili testove iz tjedna u tjedan. U drugom, početnu analizu uvijek su 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 je proces transparentan, da su očekivanja jasna za sve strane i da se situacija čini pravednom prema svima.
Je li sukob uopće problem u organizaciji? Je li loš znak da se sukobi često (ili samo povremeno) događaju u vašem timu? Općenito ne, jer ako postoji rast, razvoj, postoji neka dinamika, onda se pojavljuju pitanja koja nikada prije nisu bila riješena, a pri njihovom rješavanju mogu nastati sukobi. Ovo je pokazatelj da nekim područjima treba posvetiti pozornost, da postoje područja za poboljšanje. Loše je ako se sukobi javljaju vrlo često, ako se teško rješavaju ili dugo traju. To je najvjerojatnije znak nedovoljno organiziranih radnih procesa i nedovoljne zrelosti tima.
Izvor: www.habr.com