Z tego artykułu dowiesz się co można zrobić, kiedy po wdrożeniu wszystko się sypie. Jak takie doświadczenia wykorzystać, by w przyszłości poprawić swój komfort pracy. #estimation | #release | #rootcause | #improvments | #bugfree | #softwaretesting

Zarys sytuacji

Kiedyś brałem udział w projekcie, który został wstępnie wyestymowany. Następnie informacja o szacowanym czasie potrzebnym na realizację trafiła do klienta. Wraz z estymacjami zespół przekazał informację, że jest bardzo zgrubna wartość o dużym poziomie niepewności. Tylko taką mogliśmy w krótkim czasie dostarczyć. Jasne było, choć może nie dla wszystkich oczywiste, że trzeba to będzie dokładniej wyestymować i że ten czas z pewnością ulegnie zmianie.

Klient wybiera datę release’a

Stało się jednak tak jak to zwykle w życiu. Na podstawie wstępnej wartości klient wyznaczył datę wdrożenia*. Po dokładniejszym przeanalizowaniu tego co mamy do zrobienia wartość finalna była około dwukrotnie większa. Projekt nie był specjalnie duży. Był realizowany przez 2 miesiące przez ok. 8-10-osobowy zespół.

*W ramach ciekawostki dodam, że był to klient brytyjski. Był to też czas kiedy klient wybierał termin wdrożenia zwykle w dni kiedy w Polsce wypadało święto lub długi weekend. Zastanawialiśmy się nad czym z czego to wynika i doszliśmy do pewnych wniosków. Prawdopodobnie sugerował się polskim kalendarzem, w którym dziwne daty były zaznaczone na czerwono. Idealnie pasowały na wdrożenie. Już je ktoś tak pięknie zaznaczył.

Skąd taki rozjazd w estymacjach?

Tak jak wspomniałem wcześniej, przede wszystkim pierwsza wycena była bardzo zgrubna, przygotowywana w bardzo ograniczonym czasie – jak to zwykle bywa w projektach IT, czyli na wczoraj. Podczas dokładniejszej analizy podjęte zostały pewne decyzje co do wprowadzenia dużych zmian, które miały by przyśpieszyć kilka następnych planowanych projektów, o których już wiedzieliśmy. System był stary i wiele rzeczy było na sztywno zdefiniowanych w kodzie, co powodowało duże koszty zmian. Podjęliśmy decyzję o przeniesieniu części zahardcodowanych rzeczy do plików czy tabel konfiguracyjnych, co skutkowało większymi zmianami w kodzie i większą czasochłonnością. Te zmiany miały przyśpieszyć i zmniejszyć koszty kolejnych projektów.

Dywizjon 303

Projekt trwał około 2 miesięcy i dzięki dużemu zaangażowaniu zespołu wszystko dowieźliśmy. Było to możliwe jednak nie tylko dzięki dużemu zaangażowaniu wszystkich członków zespołu, ale także dzięki pracy w nadgodzinach i w weekendy. W sumie zespół wypracował 303 nadgodziny w ciągu 2 miesięcy trwania projektu i został później ochrzczony przeze mnie jako Dywizjon 303.

Wszystko dowiezione, ale jaki efekt?

Projekt został wdrożony w pierwotnie wyznaczonym terminie na bazie estymacji, która później została podwojona. Efektem release’u było 16 zgłoszeń – klient zgłosił tylko 2 z nich. Większość rzeczy zostało wykryte przez zespół i nie miało większego wpływu na biznes. Release dość mocno odbił się bardzo głośnym echem u klienta. Także w mojej ówczesnej organizacji wieść o nieudanym wdrożeniu zatoczyła szeroki krąg, łącznie z eskalacją od klienta do CEO w trakcie jego urlopu.

Nie ma tego złego, co by na dobre nie wyszło

Jaka jest nauka z tej historii? I czy

„każda klęska jest nawozem sukcesu”

jak mówi klasyk w jednej z polskich komedii?

Nawiązując do obrazka powyżej oraz cytatu zawartego w tytule, według mnie trzeba uczyć się na błędach. Inaczej sukcesu na tych doświadczeniach nie zbudujemy. Porażki można ponosić i jest normalny element życia i nauki, ale od nas zależy czy coś z tego się nauczymy czy nie. Należy zatem zatrzymać się na chwilę i odrobić lekcję, która powinna składać się z:

• przeanalizowania tego co się stało,
• zrozumienia dlaczego coś się wydarzyło,
• wyciągnięcia wniosków na przyszłość,
• wprowadzenia usprawnień.

Tylko odrobienie tej lekcji może pomóc wykorzystać to doświadczenie w przyszłości.

Hasło „a nie mówiłem” może nie być dobrze zrozumiane, kiedy odnosimy się do zgłaszanych wcześniej ryzyk, z którymi klient nic nie zrobił. Jednak odwołanie się do faktów i przywołanie pewnych złych doświadczeń zwykle działa całkiem nieźle. Przydaje się to gdy zgłaszane są kolejne ryzyka, albo kiedy ktoś oczekuje dostarczenia pewnych informacji asap jak na przykład estymacji. Łatwiej jest wtedy być usłyszanym i można w ten sposób podnieść komfort pracy zespołu.

Root cause analysis

W ramach tego projektu przygotowana została analiza root cause, której wynikami podzieliliśmy się z klientem. Kilka błędów, które się pojawiły po wdrożeniu wynikały z braku testowej infrastruktury. Chodziło o wysyłanie i pobieranie plików z sFTP. Nie zdołaliśmy przekonać klienta do przygotowania tej infrastruktury w trakcie trwania projektu mimo zgłaszania ryzyk. Najwidoczniej klient doszedł do wniosku, że ryzyko nie jest duże i był w stanie je zaakceptować. Po pojawieniu się błędów na produkcji bardzo szybko dostaliśmy potrzebne dostępy do testowych sFTP. Było to jednak możliwe dzięki podzieleniu się z klientem wynikami naszej analizy błędów.

Jak wykorzystać takie przypadki opisywałem już także w jednym z moich wcześniejszych artykułów. O przygotowywaniu estymacji możesz też przeczytać tutaj.

Masz podobne doświadczenia? Podziel się nimi w komentarzu.