Ratowanie tonącego projektu. Najgorszy jest czwarty poziom

W naszym zawodowym życiu czasem bywa tak, że trafiamy do ekipy ratunkowej. Jakiś super ważny projekt, który miał być gotowy na za tydzień, leży i kwiczy. Wtedy firma rzuca wszystkie dostępne siły, aby dojechać z projektem do końca i zmieścić się w terminie. Jak osiągnąć ten cel?

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.

W takich sytuacjach terminy są zazwyczaj bardzo krótkie. Całość operacji ratunkowej przypomina wtedy wydarzenia z Somalii — gdy grupa 160 us marines została uwięziona w mieście, w którym delikatnie mówiąc nikt nie darzył amerykańskich żołnierzy sympatią. My jako deweloperzy, staramy się wyprowadzić projekt na prostą, ale problemy rosną geometrycznie, dodatkowo menedżerowie i szefostwo co chwila chce raportów. Ekipa ratunkowa broni się więc przed nacierającymi błędami z każdej strony, oraz niedziałającymi modułami, a wszyscy Ci którzy powinni nas wspierać, nagle są przeciwko nam. Jak poradzić sobie w takiej sytuacji?

Założenia wstępne

Określamy z osobami odpowiedzialnymi za zarządzanie projektem kilka wersji.

1. Wersja must have, lub wersja minimum, aby klient mógł coś mieć i nie było wstydu.

2. Wersja should have, lub wersja powinno być, czyli spełnienie wszystkich wymogów klienta.

3. Wersja „win win”, lub wersja maksimum, czyli mamy wszystko co chce klient, plus w takiej jakości jakbyśmy sobie tego życzyli.

Pomiędzy tymi wersjami, mogą być jeszcze podwersje, na szybko estymujemy % szans na wykonanie ich w terminie. Mówimy czego nam brakuje, aby móc mieć trzy razy 100%, nie bójmy się powiedzieć, że aby mieć 3 na 100% to potrzeba 3 tygodni więcej czasu na pracę, bo czas też jest do kupienia. Chodzi o to, aby dać biznesowi pogląd tego co go czeka. Już widziałem kilka razy taką sytuację, że termin ostateczny określono na piątek, ale dzięki magii, voo-doo i innym takim, klient powiedział: dajcie mi tylko wersje minimum do piątku, a na wersję drugą poczekam dwa tygodnie. Także o czasie też warto powiedzieć: jak podacie czas, to musicie się w tym terminie wyrobić. Nie ma przestawiania, dlatego bądźcie precyzyjni i podawajcie czas, za który ręczycie.

Jak już mamy ustalone co ma się znaleźć w wersji minimum i mamy ogólny zarys problemu, przystępujemy do wprowadzania reguł.

W przypadku ratowania projektu, żaden kanban, scrum nie zda egzaminu. Mamy przecież projekt, który może nas zaskoczyć w każdej sekundzie, ma olbrzymi dług technologiczny, a co najgorsze: lada chwila musi się zakończyć. Wtedy ktoś musi po prostu przejąć dowodzenie. Ten ktoś, przejmuje także całą odpowiedzialność za projekt, oraz komunikację z szefostwem. Ogólnie ma zasuw, że hej. Ta osoba, najczęściej słownie zleca zadania, lub opisuje je ogólnikowo i słownie doprecyzowuje. Chodzi o to, aby zespół miał jak największą wydajność, wtedy też zwalniamy członków zespołu z niektórych zadań, np. estymacji. Zawsze wtedy powtarzam, że jak zakończysz zadanie, to napisz to samo w estymacji i ile spędziłeś na tym, nie baw się w estymowanie ich na początku.

Gdy przychodzi PM do nas i pyta, ile jeszcze, odpowiadam: tyle ile będzie trzeba. Przykro mi, to jest wojna, tutaj nie ma idealnie wyliczonych czasów, ile co zajmie. Z doświadczenia wiem, że zadania proste mogą okazać się zabójcze, a te trudne, już są zrobione, tylko ktoś ugrzązł na jakimś etapie. W skrócie, robimy tak wiele jak się da, dajemy z siebie 150%, aby móc dojechać z terminem. Natomiast jak pytają o konkretne wyliczenia zadań, mówmy, że nie wiemy.

Szefostwo wtedy do końca nie wie na czym stoi, więc zawsze w połowie dnia i na koniec, daje listę zadań jaka została wykonana i jaka jeszcze przed nami, z szacunkowym poziomem trudności. Nie podaję celowo czasu, bo jak szefostwo widzi potem w programie do śledzenia zadań, że ktoś zrobił 7 zadań o poziomie 5-8 i nagle zadanie o poziomie 6 zeszło mu o godzinę dłużej niż przeciętnie, to myślą sobie, pewnie tam był jakiś haczyk. Ilość zrobionych zadań i pozostających do zrobienia też daje wyobrażenie, ile to może zająć i pokazuje też, że ciężko nam jest cokolwiek oszacować.

Dzięki wytypowaniu jednej osoby do zarządzania, zespół jest odciążony z odpowiedzialności za projekt, dodatkowo nie musi przejmować się spotkaniami z menedżerami i wszystkimi innymi. Osoba dowodząca operacją odciąga wszystkie rozpraszacze od zespołu, to zwiększa ich wydajność.

Dobór zadań do ludzi

Do dowódcy całej operacji należy obowiązek przydzielania zadań, nie ma tutaj samowolki. Dowódca musi znać zespół i wiedzieć, kto jest w czym dobry. Zadania należy podzielić na kilka kategorii.

1. Zadania związane z wyglądem aplikacji.

2. Zadania administracyjne.

3. Zadania algorytmiczne.

4. Zadania bazodanowe.

5. Zadania związane z logiką biznesową.

6. Zadania integracji z innymi API.

Każdy członek zespołu powinien być oceniony w tych pięciu kategoriach od 0-10, czasami, można rozszerzyć listę o jakieś szczególne umiejętności. Jeżeli nie znamy do końca zespołu, to niech każdy jego członek sam się oceni. Wtedy na podstawie tego programista dowodzący przydzieli zadania na zasadzie: wykona je najlepiej pasująca osoba, która ma teraz czas.

Ocena zadań, zadania oceniamy wg ważności

Czerwone – muszą być zrobione

Żółte – powinny być zrobione

Zielone – fajnie jakby były zrobione

Dla najlepszych i najbardziej doświadczonych zostawiamy czerwone zadania, nie dawajmy tych zadań nikomu, kto może ich nie wykonać do końca. Powiem wprost: z tej listy niezrobione zadanie, to awantura u szefa, a źle zrobione, to nawet zwolnienie. Klient będzie się denerwował, że czegoś nie ma, natomiast jak dostanie coś niedziałające, to będzie miał powód, aby zaskarżyć firmę, lub pójść z tym do mediów, że zapłacili a dostali syf. Z mojego doświadczenia, lepiej czegoś nie dostarczyć, niż dać to złe.

Pokażę to na innym przykładzie: kupiliście mega wypasiony aparat. Macie teraz do wyboru: nie odebranie tego aparatu na wyjazd tylko dlatego, że obiektyw nie działa. Druga opcja: dostaniecie ten aparat, ale z uszkodzonym obiektywem. W obydwu przypadkach nie macie tego aparatu na wyjazd, a w którymś z nich pozostanie Wam większy niesmak.

Żółte zadania dajemy osobom średniozaawansowanym, a zielone juniorom. Żółte zadania powinny działać, ale mogą być wadliwe. Zielone, mogą w ogóle nie działać.

Teraz mając ludzi musimy zrobić tak, że wszystkie zadania z czerwonej listy muszą zostać zrobione, z żółtej listy postarajmy się zrobić jak najwięcej, a z zielonej tyle, ile wyjdzie. Czemu stworzenie strony z regulaminami jest na zielono? Bo można na szybko dodać pdfa do strony i dać link, operacja trwa 3 minuty, a spełnia zadanie. Także nawet jak nasza ładna strona nie będzie działać, to jakoś to ujdzie w tłumie.

Jako dowódcy musimy mieć wszystko pod kontrolą, pamiętajcie, to wy rozmawiacie z szefostwem, to wy personalnie mówicie co kto ma robić, to wy podejmujecie wszelkie ważne decyzje architektoniczne, czy technologiczne. Jesteście w tym momencie dosłownie dyktatorami, ale jak coś się nie powiedzie, to tylko wy jesteście winni, nie ma że za późno grafiki, że czegoś nie macie itd. Jak nie macie, to trzeba szefostwu powiedzieć, że nie zaczniecie tych zadań – tutaj pokazać których – bez grafik i już, to w tym momencie ich problem.

Pisanie w pośpiechu a jakość kodu

W operacjach ratunkowych działamy tylko z jedną myślą: ma działać. Przepraszam, że to powiem, ale nie jest istotne jak ma działać. Wprawny dowódca nie pozwoli sobie na zbyt wiele bałaganu, ale ten bałagan na pewno powstanie, nie łudźcie się, gdy opadnie kurz bitewny, trzeba będzie zrobić porządny refaktor. Starajcie się więc trzymać jakiś poziom, ale pamiętajcie, że ilość zadań z czerwonej listy ma być równa zero, gdy wybije godzina deadline’u i to jest wasz cel nadrzędny.

Jak utrzymać zespół w dobrej atmosferze?

Przede wszystkim jako dowódca, musimy odizolować, maksymalnie nasz zespół od szefostwa, zróbmy tablice, gdzie raz na jakiś czas piszemy, ile zadań już spadło, ile pozostało, niech ludzie widzą, że coś się dzieje, jest ruch. Im mniej będą widzieli kogokolwiek z przełożonych, tym lepiej. To nasze zadanie, aby udobruchać przełożonych i sprawić, by nie chcieli z nami siedzieć w jednym miejscu.

Poziom spartolenia projektu

Kolejną rzeczą z jaką przyjdzie nam się mierzyć, to stan początkowy projektu i to co wie klient. Możemy rozróżnić 4 poziomy.

1. Wiemy, że projekt może nie wypalić – klient nie.

2. Wiemy, że projekt może nie wypalić – klient też wie.

3. Wiemy że projekt na pewno nie wypali – klient nie.

4. Wiemy, że projekt na pewno nie wypali – klient wie, że może się nie udać.

5. Wiemy, że projekt na pewno nie wypali – klient też i mu to obojętne.

Zacznijmy wyjątkowo od końca. Pisałem o czterech poziomach, a podałem ich pięć. Ostatni poziom to ciekawe zjawisko, które nazywam „dotacjami z UE”. Są to ciekawe projekty, które mają założenia, najczęściej z palca. UE sprawdza tylko czy wszelkie założenia są spełnione, jak tak, to płaci, jak nie to jest problem. W tym konkretnym przypadku sprawą nieistotną jest to czy działa, czy nie — bo mają zostać spełnione tylko punkty umowy. Czyli de facto jest to poziom drugi, bo może czegoś nie dowieziemy z umowy, ale poza tym.

Poziom pierwszy. Charakteryzuje się względnym spokojem, klient nie wie, my wiemy i staramy się, aby się nie dowiedział. Ważne jest to, aby ktoś zrobił rekonesans, co jest dla klienta najważniejsze. Wszystkie te elementy muszą się tam bezwzględnie pojawić. Kiedyś uratowałem projekt, bo wycentrowałem wszystkie wpisy w tabelce, bo jak się okazało, to było najważniejsze, aby wszystko było schludne, a sprawą drugorzędną była poprawność danych. Wtedy realizujemy najpierw to co klienta ucieszy, potem robimy resztę. Jak się okaże, że coś nie wyszło, jakoś klienta się przebłaga, lub sam klient machnie ręką, bo w końcu ma co chciał i pomyśli, że pewnie coś źle wytłumaczył.

Poziom drugi. To już trudniejsza sytuacja, wtedy zależy od tego jaki jest klient. Dobry klient przy kryzysowej sytuacji ograniczy funkcjonalności, zły każe zrobić wszystko i będzie czepliwy każdego niuansu. Wtedy musimy zrobić jak najwięcej i skoncentrować się na głównej funkcjonalności… Pamiętajmy, że w tej sytuacji dużo musi załatwić osoba, która prowadzi projekt, może zaproponować coś co przebłaga klienta, jak nie, to szykujmy się na najgorsze… nadgodziny.

Poziom trzeci. Tutaj sytuacja jest podbramkowa, musimy wyrzucić wszystko to co może sprawić, że nie dowieziemy. Pamiętajmy, lepiej nie mieć funkcjonalności z czerwonej listy, niż mieć ją zepsutą. Trzymajmy się tej reguły, a gdy przyjdzie godzina oddania, przygotujmy się na wszystko. W tej sytuacji nasze kierownictwo musi bezwzględnie wiedzieć o problemie najwcześniej jak się da. Niech zaczną kombinować co zrobić z klientem, który nie dostanie tego co chciał. Naszym zadaniem jest zrobienie jak najwięcej zadań z czerwonej listy.

Poziom czwarty. Najgorszy z możliwych, tutaj trafiamy do piekła. Nasze zadania są identyczne, jak z poziomem trzecim, ale mamy też klienta na głowie. Tutaj nic nie zależy od nas. My robimy swoje, a i tak wiemy, że oberwiemy, mądre kierownictwo będzie starało się sprawę załagodzić. Najgorsze co może nam się przytrafić, to gdy wiemy, że potrzebujemy jeszcze dwa tygodnie, a szef ugrał tylko jeden tydzień. Nie dość, że wkurzony klient przedłużył czas, to jeszcze wiemy, że na pewno z tym nie dojedziemy. Jedyne co możemy zrobić to wykonać tak wiele zadań jak zdołamy i informować o problemach na bieżąco szefów, nawet 4 razy dziennie, tylko po to, że jak przyjdzie ten czas, kiedy pokażemy, że nie mamy nic co by satysfakcjonowało klienta, to żebyśmy mogli chociaż pokazać maila „ostrzegałem”…

Jeżeli 3, 4 poziom zdarza się zbyt często i nikt z tym nic nie robi, zmieńcie pracę, szkoda nerwów…

Gdy opadnie kurz

Jak przejdziemy przez taki projekt, w końcu opadnie kurz. Teraz musimy poprosić naszego szefa o tydzień czasu, aby móc posprzątać po nas, abyśmy mogli to zrefaktoryzować, tak jak powinno to być od początku pisane, abyśmy mogli dokończyć wszystkie zadania. Oczywiście otrzymacie decyzję negatywną, bo po co? Klient zapłacił, nie ma co w tym się babrać. To największy błąd jaki możemy popełnić. Gdy napiszemy projekt jak należy, to warto gdzieś go schować. Gdy trafi nam się podobny projekt, co w obecnych czasach jest bardzo częste, będziemy mieli gotowca, którego możemy spokojnie wykorzystać.

Przykład ile to oszczędza. Pracowałem sobie na projekcie x. Zrobiliśmy go, zostawiliśmy mnóstwo syfu, ale na 4h przed oddaniem był gotowy i pachnący. Prosiłem o refaktor tego, otrzymałem decyzje negatywne, od Team leadera, od kierownika działu, oraz od kierownika technologii, pozostał tylko zarząd firmy. No nic, zapomniałem o sprawie, ale pięć tygodni później dostaliśmy projekt bliźniaczy. Niestety baza kodowa tamtego już zniknęła z naszego repo, bo projekt sprzedany, miał działać dwa tygodnie, a potem przestał być potrzebny.

Miałem co prawda na dysku kopię, ale okazało się, że mam 10 dni na postawienie tego sam, jak policzyłem sam refaktoryzację zrobię w około pięć dni, pozostanie mi więc 5 dni na zrobienie reszty, czyli na pewno się nie wyrobię, chyba, że napiszę projekt niechlujnie. W trakcie projektu doszło do kilkunastu zmian i przeróbek i czas potrzebny wydłużył się do 1,5 miesiąca. Nie było czasu na to, aby poprawić starą wersję, bo co dwa dni miałem dawać dowód, że idziemy do przodu.

Po tym projekcie zrobiłem rachunek sumienia. Gdybyśmy wtedy zrobili w 3 osoby ten refaktor i przygotowali do ponownego użycia, stracilibyśmy 15 osobodni, ale nawet z tymi zmianami sam wyrobiłbym się w 11 osobodni. Na drugi projekt przepaliliśmy w sumie 52 roboczodni, więc gdzie ta strata czasu? Poświęcenie go na początku oszczędziłoby 50% czasu, a mówiąc biznesowo, ponad 12 tysięcy złotych. Teraz tego błędu nie popełniam. Zawsze robię porządki po takich projektach, jak kierownictwo nie wyraża zgody to szybko tłumaczę, ile na tym zyskają i nagle dostaje zgodę, niestety pierwszy raz był najgorszy, bo nie miałem argumentu.

Podsumowując

Prowadzenie zagrożonych projektów z krótkim czasem należy do trudnych zadań. Klient i szefostwo chcą mieć ciągłą kontrolę nad projektem, dodatkowo ilość zadań jest zazwyczaj tak duża, że nie ma opcji wykonać ich wszystkich, błędy atakują z każdej strony. Zespół widząc zamieszanie zaczyna się niepokoić i morale spadają. Dodatkowo systemy prowadzenia projektów nie są przygotowane na tego typu zadania.

Wtedy musimy wprowadzić dyktaturę, stajemy się głównodowodzącymi na tych projektach, bierzemy na klatę kierownictwo, oraz morale zespołu. Rozdzielamy zadania, podejmujemy wszelkie kluczowe decyzje. To od nas zależy, co i kiedy ma być zrobione, oraz co dowieziemy do ostatecznego terminu. My odpowiadamy przed kierownictwem i przed zespołem. Jeżeli się uda, to jest to sukces zespołu, jeżeli się nie uda, to tylko nasza wina, bo nie wykorzystaliśmy potencjału jaki otrzymaliśmy i zawiedliśmy zarówno zespół, jak i naszego chlebodawcę.

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