Epigraf:
Dawno, dawno temu Jeż i Mały Niedźwiedź spotkali się w lesie.
- Cześć, Jeżyku!
- Witaj, Mały Niedźwiedziu!
I tak słowo po słowie, żart po dowcipie, Jeż został uderzony w twarz przez Małego Niedźwiedzia...
Poniżej dyskusja lidera naszego zespołu, a także Dyrektora ds. Rozwoju Produktu RAS Igora Marnata, na temat specyfiki konfliktów w pracy i możliwych sposobów zarządzania nimi.
Większość konfliktów, z którymi spotykamy się w pracy, rozwija się według scenariusza podobnego do tego opisanego w powyższym motto. Jest kilku uczestników, którzy początkowo są do siebie dość przychylnie nastawieni, próbują rozwiązać jakąś kwestię, ale ostatecznie problem pozostaje nierozwiązany i z jakiegoś powodu relacje między uczestnikami dyskusji okazują się zepsute.
Życie jest różnorodne i w scenariuszu opisanym powyżej występują zmiany. Czasem relacja między uczestnikami początkowo nie jest zbyt dobra, czasem nie ma nawet kwestii wymagającej bezpośredniego rozwiązania (jak na przykład w motto), czasem po dyskusji relacja pozostaje taka sama jak przed jej rozpoczęciem, ale jednak ostatecznie problem nie został rozwiązany.
Co jest wspólnego we wszystkich sytuacjach, które można określić jako sytuację konfliktu w pracy?
Po pierwsze, istnieją dwie lub więcej stron. Strony te mogą zajmować różne miejsca w organizacji, znajdować się w relacji równości (współpracownicy w zespole), znajdować się na różnych poziomach hierarchii (szef – podwładny), być indywidualne (pracownik) lub grupowe (w przypadku konfliktu pomiędzy pracownik i zespół lub dwa zespoły) i tak dalej. Na prawdopodobieństwo konfliktu i łatwość jego rozwiązania duży wpływ ma poziom zaufania pomiędzy uczestnikami. Im lepiej strony się znają, im wyższy poziom zaufania, tym większa szansa, że dojdą do porozumienia. Na przykład członkowie rozproszonego zespołu, którzy nigdy nie mieli kontaktu twarzą w twarz, są bardziej narażeni na konflikt dotyczący prostych kwestii zawodowych niż osoby, które miały co najmniej kilka interakcji twarzą w twarz. Dlatego też podczas pracy w rozproszonych zespołach bardzo ważne jest, aby wszyscy członkowie zespołu spotykali się okresowo osobiście.
Po drugie, w sytuacji konfliktu w pracy strony znajdują się w sytuacji rozwiązania jakiejś kwestii ważnej dla jednej ze stron, dla obu stron lub dla organizacji jako całości. Jednocześnie, ze względu na specyfikę sytuacji, strony zazwyczaj mają wystarczająco dużo czasu i różnorodne sposoby jej rozwiązania (formalne, nieformalne, spotkania, pisma, decyzje zarządcze, obecność celów i planów zespołu, fakt hierarchii itp.). Różni się to od sytuacji rozwiązania problemu służbowego (lub niezwiązanego z pracą) w organizacji od na przykład rozwiązania ważnego pytania: „Ech, dzieciaku, z jakiego jesteś obszaru?!” na ulicy, albo konflikt z epigrafu. W przypadku rozwiązywania problemów zawodowych liczy się jakość procesu pracy i kultura rozwiązywania problemów w zespole.
Po trzecie, czynnikiem determinującym konflikt (z punktu widzenia naszej dyskusji) jest fakt, że strony procesu nie mogą samodzielnie dojść do rozwiązania problemu, które będzie odpowiadać wszystkim stronom. Sytuacja wymaga interwencji strony trzeciej, arbitra zewnętrznego. Punkt ten może wydawać się kontrowersyjny, ale w istocie, jeśli sytuacja konfliktowa została pomyślnie rozwiązana bez interwencji zewnętrznego arbitra, spór został pomyślnie rozwiązany, a relacje stron nie uległy pogorszeniu, to jest to sytuacja, do której powinniśmy dążyć . O takim konflikcie najprawdopodobniej w ogóle nie dowiemy się lub dowiemy się o nim przypadkiem po jego rozwiązaniu. Im więcej problemów zespół będzie w stanie rozwiązać samodzielnie, tym będzie skuteczniejszy.
Kolejną charakterystyczną cechą konfliktu, o której warto wspomnieć, jest stopień intensywności emocjonalnej podczas podejmowania decyzji. Konflikt niekoniecznie wiąże się z wysokim poziomem emocjonalnym. Uczestnicy nie muszą krzyczeć i machać rękami, aby sytuacja była w istocie konfliktem. Problem nie zostaje rozwiązany, pojawia się pewne napięcie emocjonalne (być może nie jest ono jasno wyrażone na zewnątrz), co oznacza, że mamy do czynienia z sytuacją konfliktową.
Czy w sytuacjach konfliktowych należy w ogóle interweniować, czy też lepiej pozwolić, aby ich rozwiązanie samo się rozwiązało i poczekać, aż problem sam się rozwiąże? Potrzebować. Nie zawsze w Twojej mocy i kompetencjach leży całkowite rozwiązanie konfliktu, ale w każdej sytuacji, w konflikcie o dowolnej skali możesz zająć dorosłe stanowisko, przyciągając w ten sposób do siebie kilka dodatkowych osób, złagodzić negatywne konsekwencje konfliktu konfliktu i przyczynić się do jego rozwiązania.
Zanim przyjrzymy się kilku przykładom sytuacji konfliktowych, przyjrzyjmy się kilku ważnym punktom wspólnym dla wszystkich konfliktów.
Rozwiązując konflikt, ważne jest, aby znajdować się ponad walką, a nie wewnątrz niej (nazywa się to również „zajmowaniem metapozycji”), to znaczy nie być częścią żadnej ze stron w procesie rozwiązywania. W przeciwnym razie skorzystanie z pomocy zewnętrznego arbitra jedynie wzmocni pozycję jednej ze stron na niekorzyść drugiej. Przy podejmowaniu decyzji ważne jest, aby była ona moralnie akceptowana przez wszystkie strony, jak to mówią, „kupiona”. Tak, aby nawet jeśli strony nie były zachwycone podjętą decyzją, to chociaż szczerze zgodziły się ją wdrożyć. Jak to mówią, umieć się nie zgodzić i zaangażować. W przeciwnym razie konflikt po prostu zmieni swój wygląd, tlący się ogień pozostanie pod torfowiskiem i w pewnym momencie nieuchronnie wybuchnie ponownie.
Druga kwestia, częściowo związana z pierwszą, jest taka, że jeśli już zdecydowałeś się wziąć udział w rozwiązaniu konfliktu, potraktuj go tak poważnie, jak to możliwe, z punktu widzenia komunikacji i badania kontekstu. Porozmawiaj osobiście z każdą ze stron. Na początek z każdym osobno. Nie zadowalaj się pocztą. W przypadku rozproszonego zespołu przynajmniej rozmawiaj za pomocą łącza wideo. Nie zadowalaj się pogłoskami i relacjami naocznych świadków. Zrozum historię, czego chce każda ze stron, dlaczego tego chce, czego się spodziewa, czy próbowała już wcześniej rozwiązać tę kwestię, co się stanie, jeśli nie zostanie ona rozwiązana, jakie rozwiązania widzą, jak wyobrażają sobie stanowisko strony drugiej strony, co o tym myślą, czy mają rację, czy nie, itp. Załaduj do głowy cały możliwy kontekst z otwartym umysłem, zakładając, że wszyscy mają rację. Nie jesteś wewnątrz konfliktu, jesteś poza nim, w metapozycji. Jeśli kontekst jest dostępny tylko w wątku postu, przeczytaj przynajmniej go w całości oraz powiązane z nim wątki i dokumenty. Po przeczytaniu nadal mów głosem. Prawie masz gwarancję, że usłyszysz coś ważnego, czego nie ma w poczcie.
Trzecią ważną kwestią jest ogólne podejście do komunikacji. To zwykłe rzeczy, nic kosmicznego, a jednak bardzo ważne. Nie oszczędzamy czasu, rozmawiamy ze wszystkimi uczestnikami, nie krytykujemy danej osoby, ale zastanawiamy się nad konsekwencjami jej działań (nie „jesteś niegrzeczny”, ale „może chłopaków może obrazić tę rzecz”), dajemy możliwość zachowania twarzy, dyskusje prowadzimy osobiście, a nie przed linią.
Konflikty są zwykle spowodowane jedną z dwóch przyczyn. Pierwsza dotyczy tego, czy dana osoba w momencie konfliktu znajduje się w pozycji osoby dorosłej, czy w pozycji dziecka (więcej na ten temat poniżej). Wynika to z jego dojrzałości emocjonalnej, umiejętności panowania nad emocjami (co zresztą nie zawsze jest związane z jego wiekiem). Drugą częstą przyczyną jest niedoskonałość procesu pracy, która stwarza sytuacje „szarej strefy”, w której odpowiedzialność jest rozłożona pomiędzy uczestnikami, oczekiwania stron nie są dla siebie przejrzyste, a role w procesie są rozmyte.
Zatem rozwiązując konflikt (jak i każdą inną kwestię) menedżer musi mieć na uwadze trzy perspektywy: krótkoterminową – aby rozwiązać problem/konflikt tu i teraz, średnioterminową – aby zminimalizować prawdopodobieństwo pojawienia się kolejnego konfliktu z tego samego powodu i długoterminowo - kultywować dorosłą kulturę w zespole.
Każdy z nas ma w sobie wewnętrzne dziecko, które ma około trzech, czterech lat. W pracy większość czasu śpi, ale czasem się budzi i przejmuje kontrolę. Dziecko ma swoje priorytety. Ważne jest, aby upierał się, że to jego piaskownica, jego matka kocha go bardziej, jego maszyna jest najlepsza (projekt jest najlepszy, on najlepiej programuje…). W sytuacji konfliktu dziecko może naciskać zabawki, tupać nogami i trzaskać szpatułką, ale nie potrafi rozwiązać problemów dorosłych (architektura rozwiązania, podejście do testów automatycznych, daty premiery itp.), nie myśli w kategoriach korzyści dla drużyny. Dziecko znajdujące się w konflikcie można zachęcić, pocieszyć i posłać do łóżka, prosząc, aby zadzwoniło do osoby dorosłej. Zanim rozpoczniesz dyskusję w sytuacji konfliktowej, upewnij się, że rozmawiasz z osobą dorosłą, a nie dzieckiem i że sam jesteś na miejscu osoby dorosłej. Jeśli Twoim uczciwym celem w tej chwili jest rozwiązanie poważnego problemu, jesteś w sytuacji osoby dorosłej. Jeśli Twoim celem jest tupanie nogami i łamanie łopatki, jest to dziecinna pozycja. Wyślij swoje wewnętrzne dziecko do łóżka i zadzwoń do osoby dorosłej lub przełóż dyskusję. Osoba podejmuje decyzję emocjonalnie, a następnie szuka jej racjonalnego uzasadnienia. Decyzja podjęta przez dziecko w oparciu o priorytety dziecka nie będzie optymalna.
Oprócz zachowania w momencie konfliktu pozycję dziecka lub osoby dorosłej charakteryzuje także poziom odpowiedzialności, jaką dana osoba jest gotowa wziąć na siebie. Dziecinna postawa programisty, z którą spotkałem się nie raz, w swoich skrajnych przejawach wygląda tak: napisałem kod, wysłałem do recenzji – moja praca jest skończona. Recenzenci powinni to sprawdzić i zatwierdzić, kontrola jakości powinna to sprawdzić, a jeśli pojawią się problemy, poinformują mnie o tym. Co dziwne, nawet dość dojrzali i doświadczeni ludzie czasami zachowują się w ten sposób. Drugi koniec skali jest taki, że człowiek uważa się za odpowiedzialnego za to, żeby jego kod działał, został objęty testami, został przez niego osobiście sprawdzony, pomyślnie przeszedł recenzję (w razie potrzeby nie ma problemu z pingowaniem recenzentów, omawianiem problemów głosowo itp.) i zostało wyciszone, kontrola jakości zapewni pomoc w razie potrzeby, zostaną opisane scenariusze testowe itp. W normalnych przypadkach programista albo zaczyna bliżej dorosłego końca skali, albo przesuwa się tam w miarę zdobywania doświadczenia (pod warunkiem kultywowania odpowiedniej kultury w zespole). W skrajnych przypadkach kontynuuje pracę, zwykle przyjmując dziecinną postawę, wtedy on i zespół okresowo mają problemy i konflikty.
Pielęgnowanie właściwej, dojrzałej kultury w zespole to ważne zadanie każdego menedżera. Zajmuje to dużo czasu i codziennego wysiłku, ale wynik jest tego wart. Istnieją dwa sposoby wpływania na kulturę zespołu – dawanie przykładu (który z pewnością będzie naśladowany; zespół zawsze patrzy na lidera) oraz omawianie i nagradzanie właściwego zachowania. Tutaj też nie ma nic zawiłego ani bardzo formalnego, właśnie przy omawianiu problemów zwróć uwagę, że coś można było tutaj zrobić, podkreśl, że zauważyłeś, kiedy zostało to podjęte prawidłowo, pochwal, zwróć uwagę podczas przeglądu wydania itp.
Rozważmy kilka typowych sytuacji konfliktowych, od prostych do złożonych:
Konflikty niezwiązane z problemami w pracy
Dość często zdarzają się konflikty w pracy, które nie są związane z problemami zawodowymi. Ich występowanie i łatwość rozwiązania są zwykle bezpośrednio związane z poziomem inteligencji emocjonalnej uczestników, poziomem ich dojrzałości, a nie mają związku z doskonałością lub niedoskonałością procesu pracy.
Typowe przykłady: ktoś za rzadko korzysta z pralki lub prysznica, czego innym się nie podoba, komuś jest duszno, innym przeszkadza otwieranie okna, ktoś jest za głośny, a jeszcze inni potrzebują ciszy do pracy, a innym Wkrótce. Lepiej nie zwlekać z rozwiązaniem tego rodzaju konfliktów i nie pozwolić im toczyć się własnym biegiem. Same się nie rozwiążą, a na co dzień będą odciągać Cię od pracy i zatruwać atmosferę w zespole. Na szczęście ich rozwiązanie zwykle nie jest dużym problemem - wystarczy spokojnie porozmawiać (oczywiście w cztery oczy) z kolegą zaniedbującym higienę, zapewnić wygodne siedzenia osobom preferującym ciszę/chłód, kupić słuchawki dźwiękochłonne lub zamontować ścianki działowe itp.
Kolejnym przykładem, z którym spotkałem się kilkukrotnie w swojej pracy, jest niedopasowanie psychiczne członków zespołu. Z jakiegoś powodu ludzie po prostu nie mogą ze sobą współpracować, każda interakcja kończy się skandalem. Czasami wynika to z faktu, że ludzie mają odmienne poglądy na jakąś palącą kwestię (zwykle polityczną) i nie wiedzą, jak zostawić je poza pracą. Przekonanie ich, aby tolerowali się nawzajem lub zmienili swoje zachowanie, jest raczej daremnym zadaniem. Jedynym wyjątkiem, z jakim się spotkałem, są młodzi koledzy z otwartą percepcją; ich zachowanie można nadal stopniowo zmieniać poprzez okresowe rozmowy. Zwykle problem zostaje pomyślnie rozwiązany poprzez rozdzielenie ich na różne zespoły lub przynajmniej zapewnienie możliwości nakładania się zadań w pracy, bardzo rzadko.
We wszystkich powyższych sytuacjach warto osobiście porozmawiać ze wszystkimi uczestnikami, omówić sytuację, zapytać, czy w ogóle widzą problem w tej sprawie, zapytać, jakie są ich zdaniem rozwiązania i zapewnić ich udział w podejmowaniu tej decyzji. decyzja.
Z punktu widzenia optymalizacji procesu pracy (perspektywa średniookresowa, o której wspomniałem) niewiele można tu zrobić, jedyny punkt optymalizacji to uwzględnienie czynnika kompatybilności przy tworzeniu zespołu, a nie umieszczanie ludzi razem z góry, kto będzie w konflikcie.
Z punktu widzenia kultury zespołowej 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 rozwiązuje się znacznie łatwiej (często automatycznie) w zespołach, w których panuje wysoki poziom zaufania, ludzie pracują razem od dawna i/lub często komunikują się poza pracą.
Konflikty związane z problemami w pracy:
Konflikty takie wynikają zwykle z obu przyczyn jednocześnie, zarówno emocjonalnych (fakt, że jeden z uczestników nie jest na miejscu osoby dorosłej), jak i niedoskonałości samego procesu pracy. Być może najczęstszym typem konfliktów, z jakim się spotkałem, są konflikty podczas przeglądania kodu lub dyskusji na temat architektury pomiędzy programistami.
Chciałbym wyróżnić tutaj dwa typowe przypadki:
1) W pierwszym przypadku programista nie może uzyskać recenzji kodu od kolegi. Łatka jest wysyłana do sprawdzenia i nic się nie dzieje. Na pierwszy rzut oka nie ma oczywistego konfliktu między obiema stronami, ale jeśli się nad tym zastanowić, jest to spory konflikt. Problem pracy nie został rozwiązany, jedna ze stron (oczekująca na recenzję) odczuwa wyraźny dyskomfort. Skrajnym podtypem tego przypadku jest rozwój w społeczności lub w różnych zespołach, podczas gdy recenzent może nie być zainteresowany tym konkretnym kodem ze względu na ładowanie lub inne okoliczności, może w ogóle nie zwracać uwagi na prośbę o recenzję, a zewnętrzny arbiter (menedżer wspólny dla obu stron)) może w ogóle nie istnieć.
Podejście rozwiązujące, które pomaga w takiej sytuacji, odnosi się właśnie do perspektywy długoterminowej, kultury osoby dorosłej. Po pierwsze, inteligentne działanie działa. Nie należy oczekiwać, że kod wiszący na recenzji przyciągnie uwagę samego recenzenta. Musimy pomóc recenzentom go zauważyć. Pingani kilka osób, zadaj pytanie na temat syncape, weź udział w dyskusjach. Oczywiście natrętność bardziej zaszkodzi niż pomoże, trzeba kierować się zdrowym rozsądkiem. Po drugie, przygotowanie wstępne działa dobrze. Jeśli zespół rozumie, co się dzieje i dlaczego, po co w ogóle ten kod jest potrzebny, projekt został wcześniej omówiony i uzgodniony ze wszystkimi, ludzie chętniej zwrócą uwagę na taki kod i zaakceptują go do pracy. Po trzecie, władza działa. Jeśli chcesz być recenzowany, sam rób wiele recenzji. Wykonuj wysokiej jakości recenzje, zawierające prawdziwe kontrole, prawdziwe testy i przydatne komentarze. Jeśli Twój nick jest dobrze znany w zespole, jest większa szansa, że Twój kod zostanie zauważony.
Z punktu widzenia przepływu pracy możliwe ulepszenia to prawidłowe ustalenie priorytetów, mające na celu pomóc programiście w osiągnięciu celów jego i zespołu (przeglądaj innych, pisz listy do społeczności, dołączaj do kodu opis architektury, dokumentację, testy, bierz udział w dyskusjach z społeczność itp.), zapobiegają zbyt długiemu zawieszaniu się poprawek w kolejce i tak dalej.
2) Drugim częstym przypadkiem konfliktów podczas przeglądów kodu lub projektu są różne poglądy na kwestie techniczne, styl kodowania i wybór narzędzi. Duże znaczenie ma w tym przypadku poziom zaufania pomiędzy uczestnikami, należącymi do tego samego zespołu, oraz doświadczenie wspólnej pracy. Ślepy zaułek pojawia się, gdy jeden z uczestników przyjmuje dziecinną postawę i nie stara się usłyszeć, co rozmówca chce mu przekazać. Często zarówno podejście zaproponowane przez drugą stronę, jak i podejście zaproponowane początkowo może okazać się skuteczne i w zasadzie nie ma znaczenia, które z nich wybrać.
Któregoś dnia programista z mojego zespołu (nazwijmy go Pasza) przygotował łatkę ze zmianami w systemie wdrażania pakietów, którą opracowali i wspierali koledzy z sąsiedniego działu. Jeden z nich (Igor) miał własne, zdecydowane zdanie na temat tego, jak dokładnie należy skonfigurować usługi Linux podczas wdrażania pakietów. Opinia ta różniła się od podejścia zaproponowanego w łatce i nie mogli się zgodzić. Terminy jak zwykle uciekały i trzeba było podjąć jakąś decyzję, trzeba było, żeby któreś z nich objęło dorosłe stanowisko. Pasza uznał, że oba podejścia mają prawo do życia, ale chciał, aby jego opcja przeszła, bo Ani jedna, ani druga opcja nie miała żadnych oczywistych zalet technicznych.
Nasza dyskusja wyglądała mniej więcej tak (oczywiście bardzo schematycznie rozmowa trwała pół godziny):
- Pasza, za kilka dni mamy zamrożenie funkcji. Ważne jest, abyśmy wszystko zebrali i rozpoczęli testy tak szybko, jak to możliwe. Jak możemy przebić się przez Igora?
— Chce inaczej skonfigurować usługi, umieścił tam dla mnie komentarze…
- I co tu jest, duże zmiany, dużo zamieszania?
- Nie, jest praca na kilka godzin, ale ostatecznie nie ma różnicy, będzie działać w obie strony, dlaczego jest to konieczne? Zrobiłem coś, co działa, zaakceptujmy to.
- Słuchaj, jak długo o tym rozmawiasz?
- Tak, odmierzamy czas już od półtora tygodnia.
- Hm... czy możemy rozwiązać w kilka godzin problem, który zajął już półtora tygodnia i nie robić tego?
- No tak, ale nie chcę, żeby Igor pomyślał, że się poddałam...
- Słuchaj, co jest dla ciebie ważniejsze, wydać zwolnienie wraz z wewnętrzną decyzją, czy zabić Igora? Możemy to wtedy zablokować, jednak jest duża szansa, że uda nam się przebić z uwolnieniem.
- No cóż... fajnie byłoby oczywiście wytrzeć Igorowi nos, ale ok, ważniejsze jest wyzwolenie, zgadzam się.
- Czy naprawdę jest dla ciebie takie ważne, co myśli Igor? Szczerze mówiąc, zupełnie go to nie obchodzi, zależy mu tylko na jednolitym podejściu w różnych miejscach rzeczy, za którą jest odpowiedzialny.
- No dobrze, pozwól mi zrobić, o co prosi w komentarzach i zacznijmy testować.
- Dziękuję, Pasza! Byłem pewien, że z Was dwójki będziecie dojrzalsi, choć Igorek jest od Was starszy :)
Problem został rozwiązany, wydanie ukazało się na czas, Pasza nie czuł wielkiego niezadowolenia, bo sam zaproponował rozwiązanie i je wdrożył. Igor był ogólnie zadowolony, bo... Jego zdanie zostało wzięte pod uwagę i postąpiono zgodnie z jego sugestią.
Innym rodzajem zasadniczo tego samego konfliktu jest wybór pomiędzy rozwiązaniami technicznymi/bibliotekami/podejściami w projekcie, zwłaszcza w rozproszonym zespole. W jednym z projektów, który był pozycjonowany jako wykorzystujący C/C++, okazało się, że kierownictwo techniczne projektu kategorycznie sprzeciwiało się wykorzystaniu STL (Standard Template Library). Jest to standardowa biblioteka językowa, która upraszcza programowanie, a nasz zespół jest do niej bardzo przyzwyczajony. Okazało się, że projekt jest znacznie bliższy C niż C++, co nie zainspirowało zespołu zbytnio, bo Zarząd dał z siebie wszystko i zrekrutował naprawdę fajnych, plusowych graczy. Jednocześnie amerykańska część zespołu, zarówno inżynierowie, jak i menedżerowie, pracowali w firmie od dawna, przyzwyczaili się do istniejącego stanu rzeczy i byli ze wszystkiego zadowoleni. Rosyjska część zespołu została zebrana całkiem niedawno, w ciągu kilku tygodni (łącznie ze mną). Rosyjska część zespołu kategorycznie nie chciała porzucić zwykłego podejścia do rozwoju.
Rozpoczęły się niekończące się pisemne dyskusje pomiędzy dwoma kontynentami, na trzech lub czterech ekranach leciały tam i z powrotem, w mailingach grupowych i osobistych, od programistów do programistów i menedżerów. Jak to zwykle bywa, listów tej długości nie czytał nikt poza autorami i ich zagorzałymi zwolennikami. Czaty trzeszczały z napięcia, przekazując wieloekranowe myśli w różnych kierunkach na temat technicznych zalet STL, tego, jak dobrze jest przetestowany, jak bezpieczny jest i ogólnie, jak wspaniale się z nim żyje, a jak okropnie jest bez niego .
Wszystko to trwało dość długo, aż w końcu zdałem sobie sprawę, że omawialiśmy techniczne aspekty problemu, ale w rzeczywistości problem nie był techniczny. Problemem nie są zalety i wady STL lub trudność pracy bez niego. Problem jest raczej organizacyjny. Musieliśmy tylko zrozumieć, jak działa firma, dla której pracowaliśmy. Nikt z nas nie miał wcześniej doświadczenia w pracy w takiej firmie. Rzecz w tym, że po opracowaniu kodu i wypuszczeniu go do produkcji, wsparciem zajmowały się zupełnie inne osoby z innych zespołów, z innych krajów. Ten ogromny zespół inżynieryjny, składający się z kilkudziesięciu tysięcy inżynierów (w sumie), mógł sobie pozwolić jedynie na całkowicie podstawowe minimum środków technicznych, że tak powiem, minimalne minimum. Wszystko, co fizycznie wykraczało poza standardy inżynieryjne ustalone w firmie, nie mogło być wspierane w przyszłości. Poziom drużyny zależy od poziomu jej najsłabszych członków. Po tym jak zrozumieliśmy prawdziwą motywację działaniami amerykańskiej części zespołu, kwestia ta została usunięta z porządku obrad i wspólnie z sukcesem opracowaliśmy i wypuściliśmy produkt, stosując przyjęte przez firmę standardy. Listy i czaty w tym przypadku nie działały dobrze; trzeba było kilku podróży i wielu osobistych rozmów, aby dojść do wspólnego mianownika.
Z punktu widzenia przepływu pracy w tym konkretnym przypadku przydałby się opis używanych narzędzi, wymagania wobec nich, ograniczenia w dodawaniu nowych i uzasadnienie takich ograniczeń. Dokumenty takie z grubsza odpowiadają dokumentom opisanym w paragrafach Strategia ponownego użycia i środowisko programistyczne „Podręcznika menedżera dotyczącego tworzenia oprogramowania”, opracowanego w . Mimo swojego wieku doskonale opisuje wszystkie główne działania i etapy planowania rozwoju tego rodzaju oprogramowania. Posiadanie takich dokumentów bardzo ułatwia dyskusję, jakie komponenty i podejścia można zastosować w produkcie i dlaczego.
Z kulturowego punktu widzenia oczywiście z bardziej dojrzałego stanowiska, w którym strony starają się usłyszeć i zrozumieć prawdziwą motywację działań swoich kolegów i działać w oparciu o priorytety projektu i zespołu, a nie osobiste ego konflikt zostałby rozwiązany łatwiej i szybciej.
W innym konflikcie o wybór rozwiązania technicznego również zajęło mi zauważalnie dużo czasu zrozumienie motywacji jednej ze stron (był to bardzo nietypowy przypadek), ale gdy motywacja była jasna, rozwiązanie było oczywiste.
Sytuacja wygląda następująco: w około 20-osobowym zespole pojawia się nowy programista, nazwijmy go Staś. W tamtym czasie naszym standardowym narzędziem do komunikacji w zespole był Skype. Jak się później okazało, Staś był wielkim fanem otwartych standardów i oprogramowania typu open source, korzystał jedynie z narzędzi i systemów operacyjnych, których źródła były publicznie dostępne i które korzystały z publicznie opisywanych protokołów. Skype nie jest jednym z tych narzędzi. Dużo czasu spędziliśmy na omawianiu zalet i wad tego podejścia, próbach uruchomienia analogów Skype'a na różnych systemach operacyjnych, próbach Stasia nakłonienia zespołu do przejścia na inne standardy, pisaniu do niego osobiście pocztą, dzwonieniu osobiście na telefon, kup mu drugi komputer specjalnie do Skype'a itp. Wreszcie zdałem sobie sprawę, że problem ten w istocie nie jest natury technicznej czy organizacyjnej, lecz raczej ideologicznej, a nawet, można by rzec, religijnej (dla Stasia). Nawet gdybyśmy w końcu połączyli Stasia i Skype'a (co trwało kilka miesięcy), problem pojawiałby się ponownie na każdym kolejnym instrumencie. Nie miałem realnych środków, aby zmienić światopogląd Stasia i nie było powodu, aby próbować zmieniać światopogląd zespołu, który doskonale sprawdził się w tym środowisku. Osoba i firma były po prostu ortogonalne w swoim światopoglądzie. W takich sytuacjach dobrym rozwiązaniem jest działanie organizacyjne. Przenieśliśmy Stasia do innego zespołu, gdzie był bardziej organiczny.
Przyczyną tego konfliktu, moim zdaniem, jest rozbieżność pomiędzy kulturą osobistą konkretnej osoby (która ma silne zdanie, które nie pozwala jej na kompromis) a kulturą firmy. W tym przypadku jest to oczywiście błąd menadżera. Początkowo angażowanie go w tego rodzaju projekt było niewłaściwe. Staś ostatecznie przeniósł się do projektu tworzenia oprogramowania typu open source i odniósł w nim doskonałe wyniki.
Dobrym przykładem konfliktu spowodowanego zarówno dziecinną postawą programisty, jak i niedoskonałościami procesu pracy, jest sytuacja, w której przy braku definicji wykonanej programista i zespół QA mają odmienne oczekiwania co do gotowości funkcja została przeniesiona do kontroli jakości. Deweloper uważał, że wystarczy napisać kod i przerzucić funkcję przez płot do kontroli jakości, a oni załatwią sprawę na miejscu. Swoją drogą dość dojrzały i doświadczony programista, ale taki był jego wewnętrzny próg jakości. Kontrola jakości nie zgodziła się z tym i zażądała pokazania i opisania tego, co sam sprawdził, oraz zażądała dla nich skryptu testowego. W przeszłości mieli problemy z funkcjonalnością tego dewelopera i nie chcieli ponownie tracić czasu. Swoją drogą mieli rację – funkcja naprawdę nie działała, nie sprawdził kodu przed wysłaniem go do kontroli jakości.
Aby rozwiązać tę sytuację, poprosiłem go, aby pokazał mi, że wszystko naprawdę działa (nie działało i musiał to naprawić), rozmawialiśmy z zespołem i z definicją kontroli jakości jako „skończone” (nie udało im się to w pisania, bo nie chcieliśmy, żeby proces był zbyt biurokratyczny), cóż, szybko rozstaliśmy się z tym specjalistą (ku ogólnej uldze).
Z punktu widzenia przepływu pracy możliwymi udoskonaleniami w tym przypadku jest obecność definicji gotowego rozwiązania, wymagań dotyczących obsługi każdej jednostki testów cechowych i integracyjnych oraz opisu testów przeprowadzonych przez programistę. W jednym z projektów mierzyliśmy poziom pokrycia kodu testami podczas CI i jeśli po dodaniu łatki poziom pokrycia spadał, testy były oznaczane jako nieudane, tj. każdy nowy kod można było dodać tylko wtedy, gdy były dla niego nowe testy.
Kolejny typowy przykład konfliktu ściśle związanego z organizacją procesu pracy. Mamy produkt, zespół rozwoju produktu, zespół wsparcia i klienta. Klient ma problemy z produktem i kontaktuje się z supportem. Wsparcie analizuje problem i rozumie, że problem tkwi w produkcie, po czym przekazuje problem zespołowi ds. produktu. Zespół produktowy ma pracowity okres, zbliża się premiera, więc zgłoszenie z problemem od klienta, zagubione wśród innych zgłoszeń dewelopera, do którego jest przypisane, wisi bez uwagi przez kilka tygodni. Wsparcie uważa, że programista pracuje nad problemem klienta. Klient czeka i ma nadzieję, że jego problem zostanie rozwiązany. Tak naprawdę jeszcze nic się nie dzieje. Po kilku tygodniach klient w końcu decyduje się zainteresować postępem i pyta o wsparcie, jak leci. Wsparcie prosi o rozwój. Deweloper wzdryga się, przegląda listę biletów i znajduje tam bilet od klienta. Czytając zgłoszenie od klienta, rozumie, że nie ma wystarczających informacji, aby rozwiązać problem i potrzebuje więcej logów i zrzutów. Wsparcie prosi klienta o dodatkowe informacje. I wtedy klient zdaje sobie sprawę, że przez cały ten czas nikt nie pracował nad jego problemem. I uderzy grzmot...
W tej sytuacji samo rozwiązanie konfliktu jest dość oczywiste i liniowe (napraw produkt, zaktualizuj dokumentację i testy, uspokój klienta, wypuść hotfix itp.). Ważne jest, aby przeanalizować proces pracy i zrozumieć, kto jest odpowiedzialny za organizację interakcji między obydwoma zespołami i dlaczego w ogóle taka sytuacja stała się możliwa. Jasne jest, co należy w tym procesie naprawić – ktoś musi aktywnie monitorować ogólny obraz bez przypomnień ze strony klientów. Bilety od klienta powinny wyróżniać się spośród innych biletów od deweloperów. Wsparcie powinno sprawdzić, czy zespół programistów pracuje obecnie nad zgłoszeniami, a jeśli nie, kiedy może rozpocząć pracę i kiedy można spodziewać się wyników. Wsparcie i rozwój powinny okresowo komunikować się i omawiać status zgłoszeń, zbieranie informacji niezbędnych do debugowania powinno być w jak największym stopniu zautomatyzowane itp.
Tak jak na wojnie wróg próbuje trafić w styk pomiędzy dwiema jednostkami, tak w pracy najbardziej delikatnym i wrażliwym punktem jest zazwyczaj interakcja pomiędzy zespołami. Jeśli menedżerowie wsparcia i rozwoju są wystarczająco starzy, będą w stanie samodzielnie naprawić proces. Jeśli nie, proces będzie nadal generował konflikty i problemy, dopóki nie zainterweniuje menedżer, który będzie w stanie naprawić sytuację.
Innym typowym przykładem, który wielokrotnie widziałem w różnych firmach, jest sytuacja, w której produkt pisze jeden zespół, automatyczne testy integracyjne dla niego pisze drugi zespół, a infrastrukturze, na której to wszystko działa, towarzyszy trzeci zespół. Problemy przy uruchamianiu testów pojawiają się cały czas, a przyczyną problemów w nich może być zarówno produkt, jak i testy oraz infrastruktura. Zwykle problematyczne jest ustalenie, kto powinien przeprowadzić wstępną analizę problemów, błędów w plikach, analizować logi produktu, testy i infrastrukturę itp. Konflikty są tu bardzo częste, a jednocześnie jednolite. W przypadku dużego natężenia emocji uczestnicy często przybierają dziecinną postawę i dyskusje rozpoczynają się w serii: „po co mam się tym zajmować”, „oni częściej się psują” itp.
Z punktu widzenia przepływu pracy konkretne kroki mające na celu rozwiązanie problemu zależą od składu zespołów, rodzaju testów i produktu itp. W jednym z projektów wprowadziliśmy dyżury okresowe, w ramach których zespoły monitorowały testy pojedynczo, tydzień po tygodniu. W drugim przypadku twórcy testów zawsze przeprowadzali wstępną analizę, ale była ona bardzo podstawowa, a produkt był dość stabilny, więc działał dobrze. Kluczem jest zapewnienie przejrzystości procesu, jasnych oczekiwań dla wszystkich stron i zapewnienia wszystkim, że sytuacja będzie sprawiedliwa.
Czy konflikt w ogóle jest problemem w organizacji i czy to zły znak, że w Twoim zespole konflikty zdarzają się często (lub tylko okresowo)? Generalnie nie, bo jeśli jest wzrost, rozwój, jest jakaś dynamika, to pojawiają się problemy, które nigdy wcześniej nie zostały rozwiązane, a przy ich rozwiązywaniu mogą pojawić się konflikty. Jest to sygnał, że niektóre obszary wymagają uwagi, że istnieją obszary wymagające poprawy. Źle jest, jeśli konflikty pojawiają się bardzo często, są trudne do rozwiązania lub zajmują dużo czasu. Najprawdopodobniej jest to oznaką niedostatecznie usprawnionych procesów pracy i niedostatecznej dojrzałości zespołu.
Źródło: www.habr.com