Epicka:
Pewnego razu w lesie spotkały się Jeżyk i Misiaczek.
— Cześć, Jeżyku!
— Cześć, Misiaczku!
Tak, słowo za słowem, żart za żartem, i Jeżyk dostał od Misiaczka w pysk …
Poniżej przemyślenia naszego team leada oraz dyrektora ds. rozwoju produktu RAS — Igora Marnata na temat specyfiki konfliktów w pracy oraz możliwych metod ich zarządzania.
Większość konfliktów, z jakimi się spotykamy w pracy, rozwija się według scenariusza podobnego do opisanego powyżej w epigrafie. Jest kilku uczestników, którzy początkowo są do siebie wzajemnie dobrze nastawieni, starają się rozwiązać jakiś problem, ale w rezultacie sprawa pozostaje nierozwiązana, a relacje między uczestnikami dyskusji niespodziewanie się psują.
Życie jest różnorodne, w opisanym wyżej scenariuszu występują wariacje. Czasami relacje między uczestnikami są początkowo niezbyt dobre, czasami nie ma nawet kwestii wymagającej bezpośredniego rozwiązania (jak na przykład w epigrafie), czasami po dyskusji relacje pozostają takie same, jak przed jej rozpoczęciem, ale problem ostatecznie wciąż nie jest rozwiązany.
Co zatem łączy wszystkie sytuacje, które można określić jako sytuację konfliktu w pracy?
Po pierwsze, jest to obecność dwóch lub więcej stron. Strony te mogą zajmować różne miejsca w organizacji, być w relacjach równorzędnych (koledzy w zespole) lub na różnych poziomach hierarchii (przełożony — podwładny), być indywidualne (pracownik) lub grupowe (w przypadku konfliktu między pracownikiem a zespołem lub dwoma zespołami) i tak dalej. Na prawdopodobieństwo konfliktu i łatwość jego rozwiązania ma duży wpływ poziom zaufania między uczestnikami. Im lepiej strony się znają, im wyższy poziom zaufania, tym większa szansa, że dojdą do porozumienia. Na przykład, pracownicy zespołu rozproszonego, którzy nigdy nie rozmawiali osobiście, mają większe prawdopodobieństwo wpadnięcia w sytuację konfliktu przy rozwiązywaniu prostego problemu w pracy, niż ludzie, którzy przynajmniej kilka razy rozmawiali osobiście. Dlatego pracując w zespołach rozproszonych, bardzo ważne jest zapewnienie okresowych bezpośrednich spotkań wszystkich członków zespołu.
Po drugie, w sytuacji konfliktu w pracy strony znajdują się w sytuacji rozwiązania jakiegoś problemu, istotnego dla którejś ze stron, dla obu lub dla całej organizacji. Przy tym, z uwagi na specyfikę sytuacji, strony zazwyczaj mają wystarczająco dużo czasu i różnorodnych sposobów na jego rozwiązanie (formalnych, nieformalnych, spotkania, pisma, decyzje kierownictwa, istnienie celów i planów zespołu, fakt istnienia hierarchii itp.). To różni się od sytuacji rozwiązywania roboczego (lub nie roboczego) pytania w organizacji, od na przykład rozwiązania ważnego pytania: „He, chłopie, z jakiej jesteś dzielnicy?!” na ulicy, lub konfliktu z epigrafu. W przypadku rozwiązywania roboczego pytania znaczenie ma jakość procesu pracy i kultura rozwiązywania kwestii w zespole.
Po trzecie, decydującym czynnikiem konfliktu (z perspektywy naszej dyskusji) jest fakt, że strony procesu nie mogą samodzielnie dojść do rozwiązania kwestii, które zadowoli wszystkie strony. Sytuacja wymaga interwencji trzeciej strony, zewnętrznego arbitra. Ten punkt może wydawać się kontrowersyjny, ale w zasadzie, jeśli sytuacja konfliktowa została pomyślnie rozwiązana bez interwencji zewnętrznego arbitra, problem został pomyślnie rozwiązany i relacje stron nie pogorszyły się, to jest to sytuacja, do której należy dążyć. O takim konflikcie prawdopodobnie nawet się nie dowiemy, lub dowiemy się przypadkowo po jego rozwiązaniu. Im więcej pytań zespół może rozwiązać samodzielnie, tym bardziej efektywnie będzie pracować.
Kolejną charakterystyczną cechą konfliktu, której warto dotknąć, jest stopień emocjonalnego napięcia przy rozwiązaniu. Konflikt niekoniecznie wiąże się z wysokim stopniem emocji. Uczestnicy nie muszą krzyczeć i machać rękami, żeby sytuacja była w istocie konfliktowa. Problem nie zostaje rozwiązany, pewne napięcie emocjonalne przy tym występuje (możliwe, że nie jest ono wyraźnie wyrażone na zewnątrz), co oznacza, że mamy do czynienia z sytuacją konfliktu.
Czy w ogóle należy ingerować w sytuacje konfliktowe, czy lepiej pozwolić na ich naturalne rozwiązanie i czekać, aż problem sam się rozwiąże? Należy. Nie zawsze w twojej mocy lub kompetencji jest całkowite rozwiązanie konfliktu, ale w każdej sytuacji, w konflikcie każdej wielkości, możesz zająć dorosłą postawę, przyciągając w ten sposób jeszcze kilka osób wokół siebie, łagodząc negatywne skutki konfliktu i wspomagając jego rozwiązanie.
Zanim przejdziemy do kilku przykładów sytuacji konfliktowych, zatrzymajmy się na kilku ważnych kwestiach, wspólnych dla wszystkich konfliktów.
Podczas rozwiązywania konfliktu ważne jest bycie ponad walką, a nie w jej trakcie (to nazywa się „zajęciem metapozycji”), co oznacza, że nie należy stać po jednej ze stron w trakcie rozwiązywania. W przeciwnym razie, zamiast być zewnętrznym arbitrem pomagającym w rozwiązaniu, jedynie wzmocnisz pozycję jednej ze stron kosztem drugiej. Przy podejmowaniu decyzji ważne jest, aby była ona moralnie zaakceptowana przez wszystkie strony, jak to się mówi, „kupiona”. Aby, nawet jeśli strony nie były zachwycone podjętą decyzją, przynajmniej zgodziły się ją wdrożyć. Jak to się mówi, być w stanie różnić się i zobowiązać. W przeciwnym razie konflikt po prostu zmieni formę, tlący ogień pozostanie pod torfowiskiem i w pewnym momencie nieuchronnie znowu się rozwiąże.
Druga kwestia, częściowo związana z pierwszą – jeśli już bierzesz udział w rozwiązywaniu konfliktu, traktuj to maksymalnie poważnie z perspektywy komunikacji i badania kontekstu. Porozmawiaj osobiście z każdą ze stron. Oddzielnie z każdą z nich, na początek. Nie zadowalaj się e-mailem. W przypadku rozproszonego zespołu – porozmawiaj przynajmniej przez wideokonferencję. Nie zadowalaj się plotkami i relacjami świadków. Zrozum historię, czego chce każda ze stron, dlaczego tego chce, czego oczekuje, czy próbowały już rozwiązać ten problem, co się stanie, jeśli nie zostanie rozwiązany, jakie widzą opcje rozwiązania, jak wyobrażają sobie stanowisko drugiej strony, co ich zdaniem jest słuszne lub niesłuszne itd. Załaduj do swojej głowy cały możliwy kontekst, bezstronnie, zakładając, że wszyscy mają rację. Nie jesteś w środku konfliktu, jesteś na zewnątrz, w pozycji metawizji. Jeśli kontekst dostępny jest tylko w wątku mailowym – przynajmniej przeczytaj go w całości oraz związane z nim dyskusje i dokumenty. Po przeczytaniu – i tak porozmawiaj głosem. Prawie na pewno usłyszysz coś ważnego, czego nie ma w mailu.
Trzecia istotna kwestia – ogólne podejście do komunikacji. To są zwykłe rzeczy, nic nadzwyczajnego, ale mają ogromne znaczenie. Nie próbujemy zaoszczędzić czasu, rozmawiamy ze wszystkimi uczestnikami, krytykujemy nie osobę, lecz analizujemy konsekwencje jej działań (nie „jesteś niegrzeczny”, lecz „może, że ludzie mogą się na to obruszyć”), dajemy możliwość zachowania twarzy, dyskusje prowadzimy osobiście, a nie publicznie.
Konflikty zazwyczaj wynikają z jednej z dwóch przyczyn. Pierwsza związana jest z tym, czy osoba w momencie konfliktu znajduje się w pozycji dorosłego czy w pozycji dziecka (o tym poniżej). To jest powiązane z jej dojrzałością emocjonalną, zdolnością do zarządzania swoimi emocjami (co zresztą nie zawsze wiąże się z jej wiekiem). Drugą powszechną przyczyną jest niedoskonałość procesu pracy, która tworzy sytuacje szarości, w której odpowiedzialność jest rozmyta między uczestnikami, oczekiwania stron nie są dla siebie przejrzyste, a role w procesie są niejasne.
W związku z tym w rozwiązywaniu konfliktów (jak i w innych kwestiach) menedżer powinien mieć na uwadze trzy perspektywy: krótkoterminową — rozwiązać problem/konflikt na tu i teraz, średnioterminową — zminimalizować prawdopodobieństwo wystąpienia innego konfliktu z tego samego powodu, oraz długoterminową — kształtowanie w zespole kultury dorosłego człowieka.
W każdym z nas jest wewnętrzne dziecko, mające około trzech, czterech lat. Większość czasu w pracy śpi, ale czasem się budzi i przejmuje kontrolę. Dziecko ma swoje priorytety. Ważne jest dla niego upierać się, że to jego piaskownica, mama kocha go najbardziej, jego samochodzik jest najlepszy (design jest najlepszy, programuje najlepiej itd.). W sytuacji konfliktu dziecko może ściskać zabawki, tupnąć nogami i trzepnąć łopatką, ale nie potrafi rozwiązywać dorosłych spraw (architektura rozwiązania, podejścia do automatycznego testowania, terminy wydania itd.), nie myśli w kategoriach korzyści dla zespołu. Dziecko w konflikcie można pocieszyć, utulić i odesłać na spanie, prosząc, aby zawołało swojego dorosłego. Przed rozpoczęciem dyskusji w warunkach konfliktu upewnij się, że rozmawiasz teraz z dorosłym, a nie z dzieckiem i że sam stoisz na pozycji dorosłego. Jeśli twoim szczerym celem w tej chwili jest rozwiązanie poważnej kwestii, stoisz na pozycji dorosłego człowieka. Jeśli twoim celem jest tupanie nogami i trzepanie łopatką - to jest pozycja dziecka. Odeślij swoje wewnętrzne dziecko spać i zawołaj dorosłego lub przełóż dyskusję. Człowiek podejmuje emocjonalną decyzję, a potem znajduje dla niej racjonalne uzasadnienie. Decyzja podjęta przez dziecko, kierując się dziecinnymi priorytetami, nie będzie optymalna.
Oprócz zachowania w momencie konfliktu, pozycja dziecka lub dorosłego charakteryzuje się również poziomem odpowiedzialności, który osoba jest gotowa wziąć na siebie. W skrajnych przypadkach, dziecięca postawa programisty, którą spotkałem wielokrotnie, wygląda tak: napisałem kod, wysłałem go na recenzję — moja praca jest zakończona. Recenzenci powinni go przejrzeć i zmerżować, QA powinna go przetestować, a jeśli wystąpią problemy — powinni mi o tym powiedzieć. Co dziwne, nawet dość dorośli i doświadczeni ludzie czasami zachowują się w ten sposób. Drugi skraj skali — osoba uważa się za odpowiedzialną za to, by jej kod działał, był pokryty testami, został osobiście sprawdzony, pomyślnie przeszedł recenzję (jeśli to konieczne, nie ma problemu, by przypomnieć recenzentom, omówić kwestie głosowo itp.) i został zmerżowany, QA w razie potrzeby otrzyma wsparcie, opisane zostaną scenariusze testowe itp. W normalnych przypadkach programista albo z góry znajduje się bliżej dorosłego końca skali, albo przesuwa się tam w miarę zdobywania doświadczenia (pod warunkiem, że w zespole kultywowana jest właściwa kultura). W ekstremalnych przypadkach kontynuuje pracę, zwykle przyjmując dziecięcą postawę, wtedy on i zespół czasami napotykają problemy i konflikty.
Kształtowanie w zespole właściwej, dorosłej kultury to ważne zadanie każdego menedżera. Wymaga długiego czasu i codziennych wysiłków, ale warto. Istnieją dwa sposoby wpływania na kulturę zespołu — osobisty przykład (któremu z pewnością będą podążać, zespół zawsze patrzy na lidera) oraz dyskusja i promowanie właściwego zachowania. Tutaj też nie ma nic skomplikowanego ani nadmiernie formalnego, po prostu w trakcie omawiania problemów zwracaj uwagę, co można byłoby zrobić inaczej, podkreślaj, kiedy zauważyłeś, że coś zostało rozwiązane prawidłowo, chwal, zaznaczaj podczas omawiania wydania itp.
Rozważmy kilka typowych sytuacji konfliktowych, od prostych do bardziej złożonych:
Konflikty niezwiązane z kwestiami roboczymi
Zdarza się, że w pracy występują konflikty, które nie są związane z kwestiami roboczymi. Ich powstawanie i łatwość rozwiązania są zazwyczaj bezpośrednio związane z poziomem inteligencji emocjonalnej uczestników, ich dojrzałością, i nie związane z doskonałością lub niedoskonałością procesu pracy.
Typowe przykłady — ktoś rzadko korzysta z pralki lub prysznica, co nie podoba się innym, komuś jest duszno, a inny odczuwa przeciąg, gdy otworzy okno, ktoś jest zbyt głośny, a pozostali potrzebują ciszy do pracy, i tak dalej. Lepiej nie zwlekać z rozwiązywaniem takich konfliktów i nie pozwalać na ich eskalację. Nie rozwiążą się same i będą codziennie odciągać uwagę od pracy i zatruwać atmosferę w zespole. Na szczęście zwykle ich rozwiązanie nie wymaga dużych problemów — wystarczy spokojnie porozmawiać (oczywiście w cztery oczy) z kolegą, który zaniedbuje higienę, zapewnić komfortowe rozmieszczenie ludzi, którzy preferują ciszę/chłód, kupić słuchawki dźwiękochłonne lub postawić ścianki działowe itd.
Inny przykład, który spotkałem w trakcie pracy kilka razy — psychologiczna niezgodność członków zespołu. Z jakichś powodów ludzie po prostu nie mogą pracować razem, każda rozmowa kończy się kłótnią. Czasami wynika to z faktu, że ludzie mają skrajne poglądy w jakiejś istotnej kwestii (zazwyczaj politycznej) i nie potrafią zostawić ich poza miejscem pracy. Przekonywanie ich, aby znosili siebie nawzajem lub zmienili swoje zachowanie — to dość bezowocne zajęcie. Jedynym wyjątkiem, który spotkałem, są młodzi koledzy z otwartym podejściem, ich zachowanie można stopniowo zmieniać dzięki okresowym rozmowom. Zazwyczaj problem udaje się rozwiązać, dzieląc ich w różne zespoły lub przynajmniej zapewniając możliwość bardzo rzadkiego kontaktu w pracy.
Wszystkich uczestników w przedstawionych sytuacjach warto porozmawiać indywidualnie, omówić sytuację, zapytać, czy w ogóle dostrzegają problem w tym przypadku, spytać, jakie ich zdaniem są możliwości rozwiązania, zapewnić ich udział w podejmowaniu tej decyzji.
Z perspektywy optymalizacji procesu pracy (średnioterminowa perspektywa, o której wspominałem), niewiele można tu zrobić, jedyny moment, który można zoptymalizować — uwzględnienie czynnika kompatybilności przy formowaniu zespołu i z góry nie stawianie razem osób, które będą konfliktować.
Z perspektywy kultury zespołu takie sytuacje zdarzają się znacznie rzadziej w zespołach o dojrzałej kulturze, gdzie ludzie szanują zespół i współpracowników oraz potrafią samodzielnie rozwiązywać problemy. Ponadto takie konflikty są znacznie łatwiejsze do rozwiązania (często automatycznie) w zespołach, gdzie panuje wysoki poziom zaufania, ludzie długo współpracują i/lub często komunikują się poza pracą.
Konflikty związane z kwestiami roboczymi:
Takie konflikty zwykle spowodowane są oboma czynnikami jednocześnie: emocjonalnym (kiedy jeden z uczestników nie zajmuje pozycji dorosłego) oraz niedoskonałością samego procesu pracy. Najczęstszym rodzajem konfliktów, które spotkałem, są konflikty w trakcie przeglądów kodu lub dyskusji architektonicznych między programistami.
Wyróżniłbym tutaj dwa typowe przypadki:
1) W pierwszym przypadku programista nie może uzyskać przeglądu kodu od kolegi. Łatka została wysłana do przeglądu, a nic się nie dzieje. Na pierwszy rzut oka nie ma wyraźnego konfliktu między dwiema stronami, ale jeśli się nad tym zastanowić, jest to wyraźny konflikt. Problemy robocze nie są rozwiązywane, jedna ze stron (oczekująca przeglądu) odczuwa wyraźny dyskomfort. Ekstremalnym podtypem takiego przypadku jest praca w społeczności lub w różnych zespołach, przy czym recenzent może nie być zainteresowany tym konkretnym kodem; na skutek obciążenia lub innych okoliczności może w ogóle ignorować prośbę o przegląd, a zewnętrznego arbitra (wspólnego dla obu stron menedżera) może w ogóle nie być.
Podejście do rozwiązania, które pomaga w takiej sytuacji, dotyczy długotrwałej perspektywy, kultury dorosłego człowieka. Po pierwsze, działa racjonalna aktywność. Nie warto oczekiwać, że kod wiszący na przeglądzie przyciągnie uwagę recenzenta sam. Należy pomóc recenzentom zauważyć go. Zadzwoń do kilku osób, zadaj pytanie na synkpie, uczestnicz w dyskusjach. Oczywiście, natarczywość raczej zaszkodzi niż pomoże, warto używać zdrowego rozsądku. Po drugie, dobrze działa wcześniejsze przygotowanie. Jeśli zespół rozumie, co i dlaczego się dzieje, po co w ogóle potrzebny jest ten kod, projekt był omawiany i uzgodniony wcześniej z wszystkimi, ludzie chętniej zwrócą uwagę na taki kod i przyjmą go do pracy. Po trzecie, działa autorytet. Jeśli chcesz, aby twój kod był recenzowany — sam rób wiele recenzji. Rób jakościowe recenzje, z rzeczywistymi sprawdzeniami, rzeczywistymi testami, użytecznymi komentarzami. Jeśli twój nick jest znany w zespole w pozytywnym świetle, jest większa szansa, że zwrócą uwagę na twój kod.
Z perspektywy procesu roboczego, możliwe poprawki tutaj to odpowiednie ustalanie priorytetów, mające na celu pomoc programiście w osiąganiu swoich celów i celów zespołu (przeglądanie innych, pisanie listów do społeczności, wspieranie kodu opisaną architekturą, dokumentacją, testami, uczestniczenie w dyskusjach ze społecznością itd.), niedopuszczanie do zbyt długiego oczekiwania na wprowadzenie poprawek do kolejki i tak dalej.
2) Drugim powszechnym przypadkiem konfliktów przy przeglądzie kodu lub projektu są różne spojrzenia na kwestie techniczne, styl kodowania, wybór narzędzi. Ogromne znaczenie ma w tym poziom zaufania między uczestnikami, przynależność do jednego zespołu, doświadczenie wspólnej pracy. Patowa sytuacja następuje, gdy ktoś z uczestników zajmuje dziecięce stanowisko, nie próbując usłyszeć, co chce mu przekazać rozmówca. Często zarówno podejście zaproponowane przez drugą stronę, jak i podejście zaproponowane na początku mogą skutecznie działać i nie ma zasadniczego znaczenia, które z nich wybrać.
Pewnego razu programista z mojego zespołu (nazwijmy go Pasha) przygotował poprawkę do systemu wdrażania pakietów, który został opracowany i utrzymywany przez kolegów z sąsiedniego działu. Jeden z nich (Igor) miał swoją mocną opinię na temat tego, jak dokładnie należy konfigurować usługi Linuxa podczas wdrażania pakietów. To zdanie różniło się od podejścia zaproponowanego w poprawce, a oni nie mogli dojść do żadnego porozumienia. Jak to zwykle bywa, terminy goniły, trzeba było dojść do jakiegoś rozwiązania, ktoś z nich musiał zająć dojrzałą postawę. Pasha uznał, że oba podejścia mają prawo do istnienia, ale zależało mu, żeby jego wariant przeszedł, ponieważ nie było oczywistych technicznych zalet ani jednego, ani drugiego rozwiązania.
Nasza rozmowa wyglądała mniej więcej tak (oczywiście bardzo schematycznie, rozmowa trwała pół godziny):
— Pasha, za kilka dni mamy zamknięcie funkcji. Ważne, abyśmy wszystko zebrać i rozpoczęli testowanie jak najszybciej. Jak przejść przez Igora?
— On chce konfigurować usługi inaczej, napisał mi tam mnóstwo komentarzy …
— I co tam, duże przeróbki, dużo kłopotów?
— Nie, to praca na kilka godzin, ale różnicy tak czy inaczej nie ma, jedną i drugą wersja będzie działać, po co to potrzebne? Zrobiłem działającą rzecz, zaakceptujmy ją.
— Słuchaj, ile już to wszystko dyskutujecie?
— Już od półtora tygodnia się tym zajmujemy.
— Em… możemy za parę godzin rozwiązać problem, który już trwa półtora tygodnia, i tego nie robimy?
— No tak, ale nie chcę, żeby Igor pomyślał, że uległem …
— Słuchaj, co jest dla ciebie ważniejsze, wydanie, w które będzie twoje rozwiązanie, czy pokonanie Igora? Możemy go pokonać, ale wtedy istnieje duża szansa, że przegapimy wydanie.
— No… byłoby fajnie, oczywiście, dać Igorowi nauczkę, ale dobra, wydanie jest ważniejsze, zgadzam się.
— Czy to naprawdę jest dla ciebie tak ważne, co myśli Igor? Szczerze mówiąc, jemu w ogóle to nie obchodzi, on po prostu chce jednolitego podejścia w różnych miejscach tego, za co odpowiada.
— Ok, zróbmy więc tak, jak prosi w komentarzach, i zaczniemy testowanie.
— Dzięki, Pasha! Byłem pewien, że z was dwóch to ty okażesz się dojrzalszy, chociaż Igor jest starszy od ciebie :)
Problem solved, the release was made on time, Pasha did not have any particular dissatisfaction, as he himself proposed the solution and implemented it. Igor was generally satisfied, as his opinion was taken into account and they did it as he suggested.
Another kind of the same conflict essentially is the choice between technical solutions/libraries/approaches in a project, especially in a distributed team. In one of the projects, which was positioned as using C/C++, it turned out that the project’s technical management was categorically against using STL (Standard Template Library). This is a standard library of the language that simplifies development, and our team had grown very accustomed to it. It turned out that the project was much closer to C than to C++, which did not inspire the team much, as the management had made an effort and recruited some really cool C++ specialists. Meanwhile, the American part of the team, both engineers and managers, had been with the company for a long time, accustomed to the existing state of affairs, and they were satisfied. The Russian part of the team was gathered together only recently, over several weeks (including myself). The Russian team was categorically unwilling to give up their usual development approach.
Endless written discussions began between the two continents, emails three or four screens long flew back and forth, both in group distributions and personal messages, from programmers to programmers and managers. As is often the case, no one but the authors and their ardent supporters read emails of that length. Chats creaked with tension, sending multi-screen thoughts in different directions regarding the technical advantages of STL, how well it has been tested, its safety, and in general how great life is with it and how terrible it is without it.
To trwało dość długo, aż w końcu zrozumiałem, że dyskutujemy o aspektach technicznych, podczas gdy problem nie jest w rzeczywistości techniczny. Problem nie leży w zaletach ani wadach STL czy też w trudności pracy bez niej. To raczej kwestia organizacyjna. Musieliśmy po prostu zrozumieć, jak funkcjonuje firma, w której pracowaliśmy. Żaden z nas wcześniej nie miał doświadczenia w takiej firmie. Chodziło o to, że po opracowaniu kodu i jego wdrożeniu do produkcji, wsparciem zajmowały się zupełnie inne osoby z innych zespołów i krajów. Ta ogromna inżynieryjna ekipa składająca się z kilku dziesiątek tysięcy inżynierów mogła sobie pozwolić tylko na absolutne minimum narzędzi technicznych, tak zwane minimum minimorum. Wszystko, co wykraczało poza ustalony standard inżynieryjny w firmie, fizycznie nie mogło być dalej wspierane. Poziom zespołu określany jest przez poziom jego najsłabszych członków. Po tym, jak zrozumieliśmy prawdziwą motywację działań amerykańskiej części zespołu, ta kwestia została usunięta z porządku obrad, a my wspólnie z sukcesem opracowaliśmy i wypuściliśmy produkt, korzystając ze standardów przyjętych w firmie. W takim przypadku e-maile i czaty działały słabo - potrzebnych było kilka podróży i dużo osobistej komunikacji, żeby dojść do wspólnej płaszczyzny.
Z perspektywy procesu pracy, w tym konkretnym przypadku, pomocne byłoby posiadanie opisu używanych narzędzi, wymagań wobec nich, ograniczeń w dodawaniu nowych oraz uzasadnienia takich ograniczeń. Takie dokumenty odpowiadają mniej więcej temu, co opisano w punktach Reuse Strategy i Development Environment podręcznika „Manager’s Handbook for Software Development”, opracowanego w . Pomimo swojego wieku, doskonale opisuje wszystkie kluczowe aktywności i etapy planowania rozwoju oprogramowania tego rodzaju. Posiadanie takich dokumentów znacznie ułatwia proces dyskusji na temat tego, jakie komponenty i podejścia mogą być wykorzystane w produkcie i dlaczego.
Z perspektywy kultury, oczywiście, w przypadku bardziej dojrzałej postawy, w której strony starają się usłyszeć i zrozumieć prawdziwą motywację działań kolegów oraz działają w oparciu o priorytety projektu i zespołu, a nie osobiste ego, konflikt mógłby zostać rozwiązany łatwiej i szybciej.
W innym konflikcie związanym z wyborem rozwiązania technicznego również potrzebowałem sporo czasu, aby zrozumieć motywację jednej ze stron (przypadek był bardzo niezwykły), ale po tym, jak motywacja stała się jasna, rozwiązanie stało się oczywiste.
Sytuacja jest następująca: w zespole liczącym około 20 osób pojawia się nowy programista, nazwijmy go Stas. Naszym standardowym narzędziem do komunikacji w zespole był wówczas Skype. Jak się później okazało, Stas był wielkim fanem otwartych standardów i oprogramowania open source, korzystając tylko z narzędzi i systemów operacyjnych, których źródła są publicznie dostępne i które wykorzystują opisane publicznie protokoły. Skype nie należy do takich narzędzi. Spędziliśmy mnóstwo czasu na dyskusjach na temat zalet i wad tego podejścia, próbując uruchomić odpowiedniki Skype'a na różnych systemach operacyjnych, próbując przekonać Stasa, aby zespół przeszedł na inne standardy, pisząc mu prywatne maile, dzwoniąc do niego prywatnie, kupując mu drugi komputer specjalnie do Skype'a itd. W końcu zrozumiałem, że to nie jest problem techniczny ani organizacyjny, to problem światopoglądowy, wręcz można powiedzieć, religijny (dla Stasa). Nawet gdybyśmy ostatecznie połączyli Stasa z Skype'em (na co już poszło kilka miesięcy), problem ten powróciłby przy każdym kolejnym narzędziu. Nie miałem realnych możliwości, aby zmienić światopogląd Stasa i nie było podstaw, by próbować zmieniać światopogląd zespołu, który doskonale funkcjonował w tym środowisku. Człowiek i firma po prostu były ortogonalne pod względem światopoglądowym. W takich sytuacjach dobrym rozwiązaniem jest podejście organizacyjne. Przenieśliśmy Stasa do innego zespołu, w którym był bardziej odpowiedni.
Przyczyną tego konfliktu, moim zdaniem, jest niezgodność między osobistą kulturą konkretnej osoby (która ma silne zdanie, uniemożliwiające jej kompromisy) a kulturą firmy. W tym przypadku to oczywiście błąd menedżera. Na początku było źle zatrudnić go do projektu tego rodzaju. Stas ostatecznie przeszedł do projektu dotyczącego rozwoju oprogramowania open source i doskonale się tam odnalazł.
Dobry przykład konfliktu, spowodowanego jednocześnie dziecięcą postawą programisty i niedoskonałościami procesu roboczego — sytuacja, w której w braku definition of done programista i zespół QA mają różne oczekiwania co do gotowości funkcji przekazanej do QA. Programista uważał, że wystarczy napisać kod i przerzucić funkcję przez płot do QA — tam sobie poradzą. Zresztą, był to dość doświadczony programista, ale miał taki wewnętrzny próg jakości. QA się z tym nie zgodziło i wymagało, aby pokazał i opisał im, co sam sprawdził, oraz żądali scenariusza testowania. Mieli już w przeszłości problemy z funkcjonalnością tego programisty i nie chcieli marnować swojego czasu ponownie. A tak, mieli rację — funkcja rzeczywiście nie działała, programista nie sprawdził kodu przed przekazaniem do QA.
Aby rozwiązać sytuację, poprosiłem go, aby pokazał mi, że wszystko naprawdę działa (nie działało, więc musiał naprawić), omówiliśmy z zespołem i z QA definition of done (nie postanowiliśmy go spisywać, ponieważ nie chcieliśmy zbytnio biurokratyzować procesu), a z tym specjalistą wkrótce się rozstaliśmy (ku ogólnemu ulżeniu).
Z punktu widzenia procesu roboczego możliwe usprawnienia w tym przypadku to obecność definition of done, wymagania dotyczące wsparcia każdej funkcji testami jednostkowymi i integracyjnymi, opis testowania przeprowadzonego przez programistę. W jednym z projektów mierzyliśmy poziom pokrycia kodu testami podczas CI, a w przypadku, gdy poziom pokrycia po dodaniu poprawki spadał, testy były oznaczane jako niezaliczone, tzn. każdy nowy kod mógł być dodany tylko przy istnieniu nowych testów dla niego.
Jeszcze jeden typowy przykład konfliktu, ściśle związanego z organizacją pracy. Mamy produkt, zespół jego rozwoju, zespół wsparcia oraz klienta. Klient napotyka problemy z produktem, zwraca się do wsparcia. Wsparcie analizuje problem i stwierdza, że wina leży w produkcie, przekazuje problem zespołowi produktowemu. Zespół produktowy ma gorący czas, zbliża się wydanie, więc zgłoszenie z problemem od klienta, zagubione wśród innych zgłoszeń u dewelopera, do którego zostało przypisane, wisi kilka tygodni bez uwagi. Wsparcie myśli, że deweloper pracuje nad problemem klienta. Klient czeka i ma nadzieję, że nad jego problemem się pracuje. W rzeczywistości nic się jeszcze nie dzieje. Po kilku tygodniach klient w końcu postanawia zapytać o postęp i pyta wsparcie, jak sprawy. Wsparcie pyta o rozwój. Deweloper się wzdryga, przegląda listę zgłoszeń i odkrywa tam zgłoszenie od klienta. Czytając zgłoszenie od klienta, uświadamia sobie, że brakuje mu informacji potrzebnych do rozwiązania problemu i potrzebuje dodatkowych logów oraz zrzutów. Wsparcie prosi o dodatkowe informacje od klienta. I tu klient zdaje sobie sprawę, że nikt przez ten czas nad jego problemem nie pracował. I grom uderzy...
W tej sytuacji rozwiązanie samego konfliktu jest dość oczywiste i liniowe (naprawić produkt, zaktualizować dokumentację i testy, uspokoić klienta, wydać hotfix itp.). Ważne jest, aby przeanalizować proces pracy i zrozumieć, kto ponosi odpowiedzialność za organizację interakcji między dwoma zespołami, dlaczego taka sytuacja w ogóle miała miejsce. Oczywiste jest, że coś w procesie trzeba naprawić — ktoś powinien moni to rować ogólny obraz bez przypomnień od klientów, proaktywnie. Zgłoszenia od klientów powinny wyróżniać się spośród innych zgłoszeń deweloperów. Wsparcie powinno widzieć, czy rozwój pracuje w tej chwili nad swoimi zgłoszeniami, a jeśli nie — kiedy może zacząć pracować, kiedy można oczekiwać rezultatów. Wsparcie i rozwój powinny okresowo się komunikować i omawiać status zgłoszeń, zbieranie potrzebnych informacji do debugowania powinno być maksymalnie zautomatyzowane itd.
Tak jak w czasie wojny przeciwnik stara się uderzyć w miejsce styku dwóch jednostek, tak w pracy najdelikatniejszym i najbardziej wrażliwym miejscem zwykle okazuje się interakcja między zespołami. Jeśli menedżerowie wsparcia i rozwoju są wystarczająco dojrzali, będą w stanie naprawić proces samodzielnie. W innym przypadku proces będzie dalej generować konflikty i problemy, dopóki nie interweniuje menedżer, który potrafi naprawić sytuację.
Inny charakterystyczny przykład, który spotkałem wielokrotnie w różnych firmach — sytuacja, w której produkt jest rozwijany przez jeden zespół, automatyczne testy integracyjne dla niego — przez drugi zespół, a infrastruktura, na której to wszystko działa, jest zarządzana przez trzeci zespół. Problemy przy uruchamianiu testów występują nieustannie, a przyczyną problemów mogą być zarówno produkt, jak i testy oraz infrastruktura. Umówienie się, kto powinien przeprowadzać wstępną analizę problemów, zgłaszać błędy, analizować logi produktu, testów i infrastruktury, itp., bywa problematyczne. Konfrontacje są tu dość częste, a jednocześnie jednolite. W przypadku wysokiego napięcia emocjonalnego uczestnicy często przyjmują dziecinne postawy i dochodzi do dyskusji w stylu: „dlaczego ja mam się tym zajmować”, „u nich to częściej się psuje”, itp.
Z punktu widzenia procesu roboczego konkretne kroki w celu rozwiązania problemu zależą od składu zespołów, rodzaju testów i produktu, itp. W jednym z projektów wprowadziliśmy okresowe dyżury, podczas których zespoły na przemian monitorowały testy przez tydzień. W innym wstępną analizę zawsze przeprowadzali programiści testów, ale ta analiza była dość podstawowa, a produkt wystarczająco stabilny, więc to dobrze działało. Najważniejsze to zapewnić przejrzystość procesu, jasność oczekiwań dla wszystkich stron oraz poczucie sprawiedliwości sytuacji dla wszystkich.
Czy w ogóle konflikt w organizacji jest problemem, czy to zły znak, że w twoim zespole często (lub po prostu okresowo) występują konflikty? Ogólnie rzecz biorąc, nie, ponieważ jeśli następuje rozwój, są jakieś zmiany, to pojawiają się pytania, które wcześniej nigdy nie były rozwiązane, a ich rozwiązywanie może prowadzić do konfliktów. To wskaźnik, że pewne obszary wymagają uwagi, że są miejsca do poprawy. Źle jest, gdy konflikty występują zbyt często, są trudne do rozwiązania lub trwają długo. To prawdopodobnie oznaka niewystarczająco ustalonych procesów roboczych i niewystarczającej dojrzałości zespołu.
Źródło: habr.com
