Polityka surwiwalowa w upadającym projekcie

W życiu projektowym czasem dochodzi do sytuacji, gdzie nic nie idzie zgodnie z planem. Przez “nic” mam na myśli wszystko. Kontekst jest taki: przeciągający się projekt ma wiele niedoskonałości, jesteśmy kilka miesięcy po deadlinie, analitycy ciągle coś nowego wymyślają, a kierownictwo wariuje, bo końca nie widać.

Mariusz Walczak. Tech lead w Softfin. Absolwent Warszawskiej Wyższej Szkoły Informatycznej. Pasjonat inżynierii oprogramowania, swoje aplikacje tworzy w PHP i językach opartych na ES6/7. Prywatnie miłośnik futrzanych czworonogów, oraz winiarstwa i nalewkarstwa. Wszystkie jego teksty znajdziecie pod tym adresem.

Byłem w takim projekcie tech liderem i jedyne co mogłem zmienić, to głośniej krzyczeć, że tak się nie robi. Uważałem, że mimo wszystko kierownik projektu rozumie z czym musimy się mierzyć. Niestety, byłem w błędzie. Nastały mroczne czasy, bo kierownik przejął projekt. Spadł mi kamień z serca, bo widziałem, że niestabilny analitycznie projekt, który zmienia się szybciej, niż robimy zadania, nie ma szans zaistnieć, o czym mówiłem kilkukrotnie.

Mroczne czasy nadeszły, bo osoba nietechniczna, nie znająca problemów projektowych, zaczęła dysponować zadaniami, na zasadzie człowiek – zasób. W ten właśnie sposób kilka kluczowych modułów zostało bez opieki, a wymagało dużo pracy. Kolejna decyzja, która wzbudziła kontrowersje: klient sam to przetestuje, wtedy będziemy poprawiać. Ostatnia kontrowersyjna decyzja: czas poszukać oszczędności, bo prezes się wkurzy…

Gdzie kierownik poszukał oszczędności? W naszych pensjach, co było gwoździem do trumny tego projektu. Okręt od miesięcy powoli tonął, ale na wszystkie sposoby staraliśmy się dopłynąć do brzegu. Wtedy kierownik zatopił silniki, aby zyskać trochę wyporności i czasu.

Zaufanie to podstawa

Warto porozmawiać o motywacji i budowaniu zespołu. Wyznaję zasadę, że programisty nie da się zmotywować pieniędzmi, to nie działa na dłuższą metę, w zasadzie w mojej opinii wcale nie działa. Programista musi czuć identyfikację z zespołem i czuć wagę projektu. To oczywiście płytkie twierdzenie, później sobie je głębiej omówimy.

Jeżeli ufamy, to pracujemy wydajniej, w przypadku braku zaufania, zaczyna się polityka i w wielu przypadkach szukanie nowej pracy. Dlatego uważam, że zaufanie jest fundamentem budowania zespołu. Jeżeli nawzajem sobie ufamy, to czujemy się pewnie i możemy swobodnie pracować. W przypadku braku zaufania, koncentrujemy się raczej na tym żeby przetrwać. Nie liczy się dla nas projekt, tylko zabezpieczenie siebie.

Z punktu widzenia projektu, kiedy zniecierpliwiony prezes żąda oszczędności, kierownik musi podjąć pewne kroki. Jego celem jest znalezienie pieniędzy, co zasługuje na pochwałę. Z punktu widzenia zespołu, podważanie kompetencji i karanie za błędy “góry” burzy zaufanie. Taki zespół przestaje istnieć. Z “my” robi się “ja”, z celowania w zakończenie projektu robi się polityka surwiwalowa, czyli jak przeżyć i nie dać się ściąć.

Co zrobić jeżeli naciskają z góry?

Dokładnie to samo, co zrobiłem. Usłyszałem, że będzie weryfikacja zadań pod kątem efektywności. Choć kierownik zapewniał nas, że będzie robiona jak najlżej, atmosfera podczas weryfikacji mówiła jednak co innego. Z resztą niech powiedzą to liczby. Zaliczyli mi wszystkie godziny, ale zespołowi tylko 50%. Wszelkie argumenty, które przedstawiałem nie przyniosły skutku, bo prawie nic nie dało się ugrać. Stanąłem za wszystkimi członkami zespołu, bez względu na to czy się zgadzam z ich powodami, czy nie. Moi programiści do końca projektu mi ufali, a ja im. To bardzo zaskoczyło naszego kierownika.

Polityka surwiwalowa

Zbudowałem szereg procedur, które nie miały nic wspólnego z dobrymi zasadami projektowymi, ale pozwalały produkować seryjnie dowody naszej pracy. Zespół zgodnie potwierdził, że pracujemy do końca miesiąca. Obietnicy też dotrzymaliśmy. Co dalej z projektem? Nie wiemy, to już nie nasz problem.

Osobiście uważam, że gdyby kierownik projektu miał taką postawę wobec prezesa i był wobec nas od początku do końca szczery, to wiele złego by się po prostu nie stało. A tak niestety dostaliśmy olbrzymi cios w plecy. Pokazaliśmy jednak, że jesteśmy profesjonalistami nie obraziliśmy się i zrobiliśmy co do nas należało do końca okresu rozliczeniowego, bo po takim chwycie baliśmy się, że niedługo popracujemy za darmo.

Polityka surwiwalowa sprawiła, że wykonywanie zadań stało się wolniejsze. Musieliśmy wszystko bardzo dokładnie dokumentować, wręcz przesadnie, aż do bólu. W tej jednej chwili przestał się dla nas liczyć projekt, tylko zbieranie dowodów na pracę, a wszystko to przez brak zaufania do kierownictwa

Co nas motywuje?

W skrócie każdego co innego. Jest kilka podstawowych rzeczy, po pierwsze rozwijanie się w swojej dziedzinie, nauka nowych technologii, poczucie wpływu na projekt, patrzenie na to jak powstaje coś z niczego. To tylko główne ogólne rzeczy jakie motywują programistów. Zauważyliście, że nie wspomniałem o pieniądzach?

W przypadku prac poznawczych, lub na stanowiskach gdzie pracuje się umysłem, motywacja pieniędzmi jest raczej demotywatorem. Inaczej jest w przypadku pracownika fizycznego, który np. jest murarzem. Kiedy powiemy mu, że jak zbuduje tę ścianę do końca dnia, to dostanie premie — zrobi wszystko, by ją dostać. Jeżeli zrobimy to w przypadku pracy poznawczej, to może to pomóc, ale zazwyczaj wzbudzi frustracje, bo nie obrażając nikogo budowanie ściany to kilka reguł, ale zapoznanie się na czas z tematem, wymyślenie rozwiązania, może zająć więcej czasu.

Przykład z życia wzięty: jeżeli połączymy nasza apkę z zewnętrznym API do końca dnia to dostaniemy premię, patrzymy na kwotę i widzimy dużą sumę. Ruszamy, natrafiamy na pierwszy problem, dokumentacja, czytamy jak najszybciej, okazuje się, że nie jest aktualna, przebijamy się przez kilka błędów, potem wyskakują nam bad requesty i inne złe rzeczy. Poprawiamy i to, uff już prawie, jeszcze kilka innych szczegółów, ale coś nie działa jak powinno i patrzymy na zegarek, a tu 22:10. Zmęczeni, wkurzeni, bo nie działa jak należy, patrzymy w kod, płakać się chce, a premii nie będzie, wysiłek poszedł więc na marne.

Oczywiście motywacja pieniężna daje kopa energetycznego, ale jest dobra od czasu do czasu. Tak trzeba po prostu robić profile motywacyjne, czyli pogadać, popytać co kogo cieszy z pracy, co go motywuje, co sprawia, że czuje się dobrze i postarać się to zapewnić.

Oferty pracy z

Co demotywuje?

Demotywuje gdy kierownik, czy prezes nie respektuje warunków umowy lub nam nie ufa. Jeżeli nie mamy zaufania i widzimy, że osoba nad nami kombinuje jak nas oszukać, to przestaje się chcieć. Zauważcie, że z każdym innym demotywatorem poradzimy sobie, źle dobrane zadania przeczołgamy jakoś. Ze złym kierownictwem nauczymy się żyć. Natomiast jeżeli nie ma zaufania, nie ma zespołu, a jeżeli nie ma zespołu, to nie ma projektu.

Ludzie to nie zasób

Wielu kierowników myśli, że jest programistami, jest task i można sobie nim ot tak delegować. Niestety sprawia to, że ludzie odchodzą. Programista to człowiek, każdy chce się czuć ważny, dlatego jako lider daję każdemu głos, decyzję podejmujemy zawsze wspólnie w rozmowie opartej na argumentach. Widząc, kto w jakim typie zadań czuje się dobrze, takie dostaje.

Niektórzy uwielbiają pisać API, inni wolą kosić bugi, jeszcze inni lubią kombinować z trudnymi rzeczami. Każdy z nich wykonując swoje ulubione zadania, sam będzie się w tym nakręcał i będzie bardziej efektywny w tym co robi.

Gdy wszystko dzieje się źle

Pamiętajmy o jednym: projekt to nie jest kwestia życia lub śmierci. Po pierwsze, projekt jest najważniejszy, więc trzeba odpowiednio zmotywować pracowników. Bez tego ani rusz. Po drugie, trzeba sporządzić listę zadań, które musimy mieć, lista ta musi być wykonywalna. Po trzecie, trzeba uzgodnić kto jest za co odpowiedzialny, zrobić krótkie przepływy informacji, jeżeli ktoś ma z czymś problem, to musi mieć od razu osobę, która mu pomoże.

Z resztą opisywałem to w artykule o ratowaniu projektu, niemniej jeżeli nasze kierownictwo robi wszystko, aby nasze starania się nie udały. Np. tnąc koszty obniżając pensje, nie zmieniając nic w dysfunkcyjnym środowisku, to wtedy należy się postawić. Uważam, że życie zgodnie z własnym sumieniem jest najważniejsze. Jeżeli szef kazałby mi ściąć zespołowi połowę wynagrodzenia, odparłbym, że ma moją całą, bo w tej szopce brać udziału nie będę. Zespołowi przekazałbym otwarcie powód rezygnacji, chciałbym aby wiedzieli, że to nie przez nich.

W każdej nawet najtrudniejszej sytuacji, musimy być fair wobec nas samych i wobec zespołu. Jeżeli ktoś wykonuje rozkaz egzekucji, to jest to ostatnia szuja. Nie powinien być na swoim miejscu. Tech lider, jak i kierownik projektu, są po to, aby się wzajemnie osłaniać i stworzyć tarczę bezpieczeństwa w zespole. To oni mówią kto się nadaje w zespole, a kto nie, ale to pozostaje między nimi. Natomiast jeżeli prezes wymaga obcięcia pensji, lub zwolnienia kogoś, trzeba powiedzieć wprost. Jeżeli to zrobimy teraz projekt utonie i w zasadzie całe wysiłki pójdą na marne. Jeżeli jednak nadal się upiera to trzeba porozmawiać otwarcie w zespole o sytuacji, może ktoś i tak zmieniał pracę. Jeżeli jednak nikt nie zmieniał, ani nic nie da się zrobić. W mojej ocenie tech lider powinien albo umyć ręce, albo zrezygnować z funkcji. Poprzez umycie rąk rozumiem taką sytuację, w której techlider mówi zespołowi co się święci i mówi otwarcie, że on nie bierze w tym udziału, tylko czeka na wyrok.

Wykorzystanie swojej pozycji do ratowania własnego odwłoku jest poniżej standardów. Zarówno kierownik, jak i techlider powinien stać murem za zespołem, bo zespół podąża za ich poleceniami.

Zdjęcie główne artykułu pochodzi z pexels.com.