Blog
Gdy projekt kończy się niepowodzeniem, często pada pytanie: “czyja to wina?”.
Spotkałem się z tym wielokrotnie. I trudno mi wyjść z podziwu, jakim cudem ludzie nie dostrzegają niedorzeczności tego pytania.
Czy to JEGO wina?
Czy ktokolwiek poważnie sądzi, że fiasko 3 miesięcznego, realizowanego przez 10 osób projektu może być winą jednej osoby?
Zastanówmy się przez chwilę, jak ten ktoś mógłby tego dokonac:
Może był kompletnym obibokiem? Osobiście nie wierzę w coś takiego, ale przyjmijmy takie założenie. Jak niska mogła być jego produktywność? Założenie, że zerowa, jest niezbyt realistyczne – oznaczałoby to, że nie robił kompletnie nic przez całe 3 miesiące i nikt z jego zespołu tego nie zauważył.
Przyjmijmy nieco rozsądniejsze założenie. Może jego produktywność była na poziomie 50%? To nadal fatalnie (i wciąż zdumiewające, że nikt przez 3 miesiące nie zauważył, ale przyjmijmy na moment małe zawieszenie niewiary). Jednak w przypadku 10 osobowego projektu i tak oznacza to tylko o 5% dłuższy czas ukończenia. Nie aż tak dużo, by projekt zakończył się fiaskiem.
Może więc nie był leniwy, lecz niechlujny i popełnił jakąś pomyłkę, która zagroziła projektowi?
Czy jest możliwe, by pojedyncza pomyłka naraziła na szwank cały projekt? O ile nie zajmujesz się budową promów kosmicznych, śmiem wątpić. A nawet jeżeli się zajmujesz, założę się, że stosujesz rygorystyczny, wieloetapowy proces QA, więc pomyłka musiałaby się prześliznąć przez wszystkie jego kroki – co raczej należy uznać za porażkę Twojego procesu QA a nie pojedynczej osoby.
No dobrze, więc może nie była to pojedynczya pomyłka? Może oddawał on słabej jakości, wadliwą pracę cały czas, przez co projekt wlókł się żółwim tempem?
I wszyscy to widzieli, i nikt nie zareagował przez 3 miesiące, po cichu pozwalając projektowi zmierzać ku katastrofie?
Naprawdę, jedyny sposób, w jaki pojedyncza osoba mogłaby położyć duży, zespołowy projekt, jaki jestem w stanie wymyśleć, to celowe – i bardzo sprytne – sabotowanie projektu. Ale nie jest to najbardziej wiarygodna z teorii.
Czy to ICH wina?
Projekt jest przedsięwzięciem zespołowym. Eksperci biznesowi pomagają developerom zrozumieć wymagania. Developerzy tworzą kod i recenzują kod innych developerów. Specjaliści QA pomagają im wszystkim zweryfikować, że to co budują działa poprawnie. Projekt może zakończyć się fiaskiem jedynie gdy ciąg wielu zaniedbań wielu różnych ludzi się zakumuluje.
W tej sytuacji, “oczywistym” podejściem jest założenie, że to wina wszystkich tych ludzi. Zrzućmy winę na cały zespół i naciskajmy ich, żeby następnym razem bardziej się postarali. Problem “rozwiązany”.
Zastanówmy się, czemu miałoby to zadziałać? Dlaczego nie postarali się tak bardzo, jak tylko mogli, tym razem?
Jednym z powodów mogło być to, że trafił im się “zły dzień”. Ale jak wcześniej omówiliśmy, zły dzień pojedynczej osoby nie ma dużego wpływu na projekt. A raczej ciężko uwierzyć, że wszystkie 10 osób w zespole cierpiało na epidemię złych dni przez całe 3 miesiące.
Więc może cały zespół się obijał?
To faktycznie mogłoby poważnie wpłynąć na projekt. Biorąc jednak pod uwagę jaką rzadkością są “obiboki”, to bardzo nieprawdopodobne. A nawet jeżeli w jakiś zdumiewający sposób udało Ci się zbudować 10 osobowy zespół, składający się w większości z obiboków (włączmy ponownie nasze zawieszenie niewiary), to masz naprawdę poważny problem organizacyjny, który zdecydowanie nie jest winą tego zespołu.
A więc CO zawiodło?
W końcu zaczynamy spoglądać we właściwym kierunku.
Niepowodzenia projektów zawsze mają korzenie w organizacyjnych, systemowych problemach. Wyrastają ze słabej komunikacji, nieodpowiedniej metodyki, zbyt dużej presji, zaniedbywania jakości – a najczęściej z połączenia wielu tego typu czynników. Jeżeli pragniesz zapobiec podobnym niepowodzeniom w przyszłości, wskazywanie ludzi palcem tego nie załatwi.
Jeżeli wydaje Ci się, że to czyjaś osobista wina, to wyraźny znak że skupiasz się jedynie na symptomach, nie przyczynach.
Musisz spojrzeć głębiej.
Doskonałym sposobem jest przeprowadzenie Analizy Problemu Źródłowego (Root Cause Analysis). Jeżeli nigdy tego nie robiłeś, polecam wypróbować metodę “5 Whys” (“5 Dlaczego”). Jest prosta i łatwa do przyswojenia, a przy tym efektywna. Nie będę tu wchodził w szczegóły, ale w telegraficznym skrócie pytasz się wielokrotnie “dlaczego”, dopóki nie dotrzesz do sedna problemu (wg. anegdotycznej statystyki jest to zazwyczaj 5 razy, stąd nazwa).
Nie ważne, czy wybierzesz “5 Whys”, jakąś inną odmianę Root Cause Analysis czy zupełnie odmienną metodę poszukiwania przyczyny problemu. Kluczową sprawą jest skupienie się na faktach i unikanie osądzania lub szufladkowania ludzi.
Spójrzmy na przykład analizy “5 Whys” przeprowadzonej źle:
Problem: Zespół wdrożył wadliwą wersję aplikacji.
- Dlaczego? Ponieważ jedna z kluczowych funkcjonalności nie została zintegrowana z główną bazą kodu.
- Dlaczego? Ponieważ Tom zapomniał tego zrobić.
- Dlaczego? Bo był niedbały.
Wniosek: Tom powinien się następnym razem bardziej postarać.
Czy uważasz, że taka analiza pomoże zapobiec pojawieniu się problemu ponownie?
Może Tom będzie odtąd bardziej uważny. Co jednak, gdy będzie bardzo zmęczony lub będzie miał wyjątkowo zły dzień? A co z pozostałymi członkami zespołu? Tom nie jest jedyną osobą odpowiedzialną za integrację funkcjonalności. Może reszta zespołu brała udział w analizie i wzięła sobie przykład Toma do serca, a może nie. A co z nowo zatrudnionymi osobami, które nie są nawet świadome, że taka sytuacja miała miejsce?
Porównaj to z analizą przeprowadzoną właściwie:
Problem: Zespół wdrożył wadliwą wersję aplikacji.
- Dlaczego? Ponieważ jedna z kluczowych funkcjonalności nie została zintegrowana z główną bazą kodu.
- Dlaczego? Ponieważ Tom zapomniał tego zrobić.
- Dlaczego? Bo musiał to robić “ręcznie”.
- Dlaczego? Ponieważ nie ma możliwości wylistowania wszystkich funkcjonalności oczekujących na integrację.
- Dlaczego? Bo nie ma odpowiedniego filtra w naszym narzędziu do zarządzania projektami.
Wniosek: Dodajmy nowy, niestandardowy filtr. Co więcej – podłączmy go do naszego serwera Ciągłej Integracji, żeby integrował odpowiednie funkcjonalności z naszą główną bazą kodu automatycznie.
Dostrzegasz różnicę? Teraz problem został rozwiązany na dobre. Sprawiliśmy, że przeoczenie funkcjonalności stało się niemożliwe – i niezależne od zawodnego czynnika ludzkiego.
Rozglądaj się za obiektywnymi, systemowymi przyczynami, a nie ludźmi, na których możnaby zrzucić winę. Gdy zmienisz w ten sposób swoje nastawienie, znajdziesz dużo lepsze rozwiązania swoich problemów, stworzysz w firmie o wiele zdrowszą kulturę i zapewnisz wysoką motywację zespołu.
Jakie jest Twoje zdanie na ten temat? Podziel się nim w komentarzach poniżej!
