Kiedy przestaje Ci zależeć

Jeśli śledzisz mojego bloga od jakiegoś czasu to być może wiesz, że pod koniec zeszłego roku zmieniłem w firmie projekt. Na początku mocno skrytykowałem to czym musieliśmy się zajmować przez pierwszy miesiąc. Jednak ostatecznie zaczęliśmy pracę nad nową aplikacją. Dla wielu programistów sytuacja brzmi jak spełnienie marzeń – pracujemy nad aplikacją od podstaw i po części sami decydujemy jakich bibliotek używany, a struktura kodu to już w 100% nasz wymysł. Jednak gdyby było tak różowo to nie pisałbym tego wpisu.

Będzie to smutna historia o tym jak klient potrafi zgasić absolutnie cały zapał programisty rzucając mu kłody pod nogi i pokazując, że nie zależy mu na jakości projektu. Bo dokładnie to się stało w tym wypadku.

Dobre złego początki

Zaczęło się niewinnie, bo rozpoczynając projekt mieliśmy czas na spokojne wymyślenie jak to ma się razem kleić i czego dokładnie chcemy użyć. Wymaganie było proste – dodać nieskomplikowany ekran logowania i jedną stronę z podstawionymi danym. Tak żeby pokazać, że aplikację da się uruchomić.

Jeszcze nie przeczuwałem tragedii chociaż coś mi śmierdziało w tym, że właściwie za bardzo nikt się nie interesuje co dokładnie robimy. Ot dostaliśmy maila z jednym plikiem PDF i polecenie „róbcie”.

Dodatkowo, hej! Płacili mi za uczenie się Angulara! Czy można sobie wyobrazić lepszą sytuację? Przychodzisz do pracy, gdzie nikt nie stoi Ci nad głową i w dodatku mówią, że w czasie tej pracy możesz się spokojnie uczyć nowej technologii, którą chciałeś poznawać po godzinach. Wtedy uważałem, że w sumie to bardzo dobrze, że zgodziłem się przejść do tego projektu. Same korzyści.

Poziom zaangażowania w projekt: 9/10

Pierwsze zgrzyty

Jednak taka sielanka nie trwała zbyt długo. Po około miesiącu w naszych kalendarzach pojawiły się regularne spotkania z klientem na Skype. Niby nic dziwnego. Kiedyś trzeba zacząć się do siebie odzywać.

Tylko, że te spotkania za każdym razem były takie jakieś nijakie. Niby pytali co robimy i jak nam idzie. Ale przez to, że nikt za bardzo nie wysyłał szczegółów co powinniśmy dokładnie robić to i odpowiedzi były rozmyte. A to coś poprawialiśmy. A to pojawił się nowy pomysł. A to testy dopisujemy.

W tym miejscu już pojawiły się pierwsze oznaki zniechęcenia. Bo o ile brak bata nad głową jest przyjemy to jednak brak celu i takie powolne dryfowanie w nieznanym kierunku powodują, że człowiek zaczyna się zastanawiać. Np. zaczyna się zastanawiać nad tym po co to właściwie robi. Czy przypadkiem następnego dnia nie będą chcieli mieć gotowej aplikacji. Czy może coś przeoczył i myśli, że zrobił wszystko, a tak na prawdę czeka pełno roboty, która zaginęła w mailach? Te pytania burzą wewnętrzny spokój.

Ale cały czas się staraliśmy. Chcieliśmy żeby wszystko było zrobione porządnie. W końcu sami to zaczęliśmy i sami byliśmy odpowiedzialni za kod. Nie można pokazać, że się coś robi na mniej niż 100%. Dzięki temu znajdowaliśmy zawsze zajęcie i okazję do dyskusji.

Poziom zaangażowania w projekt: 7/10

Wymagania? Jakie wymagania?

Prawdziwe problemy zaczęły się kiedy projekt zaczął nabierać rozpędu. Skoro aplikacja się rozwija to znaczy, że dokładane są do niej kolejne funkcjonalności. A skąd wiadomo jakie funkcjonalności dodać? Z wymagań dostarczonych przez klienta. Problem w tym, że z tymi wymaganiami był problem. W trakcie rozmowy słyszeliśmy, że naszym następnym zadaniem będzie funkcjonalność A, jutro będą gotowe wymagania. Jednak ani jutro, ani przez kolejne dni się one nie pojawiały. Więc się upominałem (sprawa dotyczyła głównie frontendu, którym to ja się zajmowałem).

Kiedy w końcu coś przychodziło na maila to raczej dalece temu było do czegoś co bym nazwał wymaganiami funkcjonalnymi. Dwa screeny w PDFie. Zero opisu. Domyśl się. Więc właściwie dostanie wymagań oznaczało, że dopiero trzeba się dowiedzieć co tak naprawdę będzie się robić. Dodatkowo terminy były mało precyzyjne. Niby pytali czy gotowe. Ja się wtedy pytałem kiedy dostanę odpowiedzi na pytania. Wtedy dopiero coś dostawałem. Na koniec się okazywało, że to co ja robiłem na frontendzie i to co kolega miał zrobić w API tak średnio do siebie pasowało. Bo i wymagania miały się wzajemnie w dupie. Brakujące pola albo brakujące dane. Brak potrzebnych mi funkcji. Inne formaty. Wszystko się rozjeżdżało przy integracji. Co oczywiście było zgłaszane.

To był ten moment kiedy fala niezadowolenia zaczęła wzbierać. Zaczęło się przepychanie. Był to też moment kiedy dosyć często zgłaszaliśmy uwagi do naszego dyrektora, który co jakiś czas kontaktował się z klientem. Praca to było głównie wróżenie z fusów czego tak naprawdę potrzebują i jak to zrobić.

Oczywiście nie wiedziałem co będę miał do zrobienia po aktualnym zadaniu. W końcu jeszcze nie było wymagań. To z kolei prowadziło coraz częściej do sytuacji kiedy coś co do tej pory zrobiłem w aplikacji musiało być przerabiane bo nagle dochodził jeden drobny szczegół, który burzył dotychczasowe założenia. Więc i czas robienia zadań się wydłużał. A przerzucanie się pytaniami kiedy będzie gotowe trwało.

Z powodu ciągłego oczekiwania na nowe wymagania jakoś dawaliśmy radę porządkować to co było na szybko zmieniane w poprzednim zadaniu. Karuzela jeszcze się jakoś powoli kręciła.

Poziom zaangażowania w projekt: 6/10

Biurokracja naszą specjalizacją

Po wysyłaniu pseudo-wymagań mailem, opóźnieniach w odpowiadaniu na wiadomości i raczej średnim zainteresowaniu projektem dostaliśmy w twarz biurokracją. Bo w końcu kiedy coś nie działa to procedury na pewno to naprawią. Nie naprawiły. Ale o tym za moment.

Produkt scrumopodobny

Pewnego pięknego poniedziałku wpadło nam nagle do kalendarza spotkanie. Założyliśmy, że po prostu przenieśli środowe albo piątkowe na poniedziałek bo powody. Jednak na callu dowiedzieliśmy się, że to nie zwykłe nudne spotkanie tylko planning połączony z groomingiem. A właściwie parodia tych dwóch.

Teoretycznie zespół pracuje w Scrumie. Także po połączeniu się na Skypie została nam pokazana lista funkcjonalności, które muszą być zrobione przez następne miesiące. Nawet już czas dla każdej z nich był wpisany. Mimo, że my, jako osoby, które miały to robić nawet nie wiedzieliśmy wcześniej o tych zadaniach. Całość sprowadziła się do tego, że przechodziliśmy po każdej pozycji, która zawierała nazwę funkcjonalności, klient mówił dwa zdania typu „no to będą dwa ekrany” i pytał czy x dni jest ok na to.

Nie wiedząc kompletnie co w tym zadaniach ma być zrobione i czego dokładnie wymagają protestowaliśmy mówiąc, że nie jesteśmy w stanie powiedzieć czy jest ok. Jednak upierali się, że mamy powiedzieć bo to tylko „high level estimates”. W takim wypadku nie mając wyboru potwierdziliśmy terminy, które wydawały się być aż nad to wystarczające (np. 5 dni na funkcjonalność zawierającą wg nich jeden prosty formularz i listę). Wymagania do kolejnych zadań oczywiście nadal nie były robione w terminie. Informacje o sytuacji szły do dyrektora – w końcu każą nam się zgadzać na terminy, które równie dobrze moglibyśmy wybierać rzucając kostką.

Ale zdążycie?

 

Pojawił się rozpisany dokładnie plan pracy z zaplanowanymi co do dnia datami releasów i testów. Ambitnie jak na „high level estimates”. Czyli jednak to nie były estymacje tylko konkretne terminy. Więc konkretnie zgłosiliśmy to do dyrektora, powtarzając, że nie dajemy żadnej gwarancji, że cokolwiek będzie zrobione na czas. Zwłaszcza jak na czas nie wiadomo nawet co ma być zrobione.

Od razu po naszych wątpliwościach co do sposobu wyceny zadań wytoczone zostały działa ciężkiego kalibru – biurokracja ostateczna. Codziennie upominanie się o uzupełnianie zadań w Jirze mimo, że nawet nie zostało powiedziane gdzie to dokładnie robić (dopiero przypadkiem trafiłem na backlog z zadaniami). Każde zamknięcie nawet 10-minutowego zadania wymaga godziny spędzonej na uzupełnianiu wszystkich możliwych pól, łącznie z robieniem dokumentu ze zrzutami ekranów tego co się zrobiło.

Im więcej durnych rzeczy karzą robić naokoło tym bardziej się człowiek zniechęca do pracy. Zwłaszcza w sytuacji kiedy nas gonią o każde nieuzupełnione zadanie, a w Jirze wisi pełno zadań reszty zespołu, które nie wiadomo kiedy powstały i kiedy zostaną zrobione.

Podsumowaniem tej parodii niech będzie to, że nie mamy tablicy w Jirze, bo żeby nie dodawać drugiego backlogu po prostu zaczęli wrzucać nasze zadania do backlogu nadrzędnego projektu. Do tego utworzyli kilka sprintów jednocześnie, a Jira pozwala wyświetlić board tylko dla pierwszego otwartego. Także mamy listę sprintów, które nie wiadomo kiedy się zaczęły i kiedy się kończą. W tych sprintach są zaś zadania, których statusu nie widać dopóki się nie kliknie w nie (bo nie ma boarda ze statusami). Każde zadanie ma kilka stanów, połowy nie rozumiem i wymaga uzupełniania kilku pól i wstawiania w czasie review kilku tabelek w komentarze, których też nie rozumiem.

W tym momencie każde zapytanie o to czy uzupełniłem Jirę powoduje, że kompletnie przestaje mnie obchodzić zrobienie aktualnego zadania w terminie. Po prostu przełączam się na Jirę i poświęcam godzinę lub dwie na przejrzenie wszystkich zadań (bo nie widać ich statusów) i uzupełnienie pól, których nie rozumiem. Ale będą zadowoleni. Bo tabelki się zgadzają. Terminy nie muszą najwidoczniej.

Poziom zaangażowania w projekt: 3/10

Wincyj tasków!

Na koniec dochodzimy do momentu obecnego. Sytuacja wygląda tak, że zarządzanie projektem to po prostu ustawianie jako priorytet ostatniego dodanego buga. Więc nie jest niczym dziwnym, że rano każą uzupełnić Jirę, w południe pytają kiedy feature będzie gotowy, a chwilę później zostaje się zasypanym zgłoszeniami o mniejszych i większych błędach, których nie wychwycili przez ponad miesiąc czasu i zostały odkryte dopiero po wdrożeniu wersji na serwer docelowy. Do tego co chwilę zaczepianie mailowo lub na Skype, jednak ten problem na razie dotyczy głównie kolegi, którego z jakiegoś powodu obrali za cel.

W tym momencie mój poziom przejmowania się losami projektu jest bliski zeru. Nie czuję potrzeby nadmiernego testowania aplikacji. Nie wdaję się w dyskusje kiedy słyszę jakieś głupoty. Jeśli w połowie zadania mówią, żebym zajął się innym mimo, że poprzednie było przed chwilą bardzo ważne to nie widzę w tym problemu, ich sprawa. Byle dociągnąć to do końca. Tzn. mojego końca, bo po wakacjach już mnie w tym projekcie nie będzie, ale on sam będzie istniał bo wdrożenie ostateczne jest zaplanowane na późniejszy termin. Nie staram się zrobić czegoś szybciej. A skoro wyrazili swoje zdanie dotyczące testów, które mówiło, że raczej się nimi nie przejmują to i na tym polu po kilku miesiącach walki dostosowałem się do poziomu zarządzania. I to jest miejsce kiedy projekt stał się takim trochę chodzącym trupem. Niby wszyscy widzą, że się rusza ale w sumie to wewnątrz jest pusty i skostniały.

Wróciło to co było w pierwszym miesiącu pracy dla tego klienta kiedy wrzucili nas w stare gówno. Kompletnie nie czuję chęci chodzenia do pracy, a zadania nie są pierwszą rzeczą za jaką chcę się zabrać. Gdyby teraz ktoś powiedział, że projekt zamykają to właściwie byłoby mi wszystko jedno.

Poziom zaangażowania w projekt: 1/10

Nie przeszkadzaj

Wniosek jest taki, że jeżeli chcesz żeby ktoś zrobił coś dla Ciebie to mu tego nie utrudniaj. W sytuacji kiedy nasze starania nie są dostrzegane, a wręcz się je uznaje za wady nie ma co oczekiwać, że będziemy się starać w nieskończoność. Każdy człowiek w końcu ma dosyć walki z wiatrakami i zaczyna mu być wszystko jedno co się stanie dalej.

W tym momencie dzięki organizacji projektu jest to jeden z gorszych projektów w jakich pracowałem. Mimo, że aplikacja pisana od podstaw przeze mnie.

Po pierwsze nie wiadomo do czego dążymy. Nie wiemy jak wszystko ma docelowo działać, kolejne funkcjonalności poznajemy dopiero zabierając się za nie. Powoduje to również, że nie możemy zaplanować działań tak, żeby móc dodawać nowe rzeczy sprawniej. W końcu jeśli nie wiesz, że coś będzie wymagało innego podejścia to tego podejścia nie zastosujesz. Z resztą nawet jak już powiedzą co masz robić to jest to nadal zabawa we wróżkę i zgadywanie co z czym się łączy.

Po drugie dostajemy do zrozumienia, że nie powinniśmy skupiać się na jakości. Właściwie jakość naszym wrogiem.

Po trzecie jakiekolwiek nasze sugestie kończą się na tym, że ok, jeśli sami to zrobimy bez dodatkowego czasu na to. Zero refleksji czy jakaś sugestia nie poprawiłaby jakości lub nie spowodowała, że inne rzeczy będą szły prościej jeśli teraz poświęcimy na nie więcej czasu. Nikt się też nie zastanawia jak to wpłynie na późniejsze utrzymanie. Jednak na tym polu walczyliśmy do końca i po cichu modyfikowaliśmy architekturę tak żeby była spójna, prosta i przejrzysta.

No i ta sinusoida wykorzystania czasu. Praktycznie w każdym zadaniu wygląda to tak, że czeka się na wymagania, szybko implementuje widok, czeka kilka dni na API (które jest zaplanowane na kilka dni później, widocznie takie są dobre praktyki planowania zadań dla jednej funkcjonalności i kilku osób), po czym trzeba szybko przerabiać wszystko bo już następne zadanie czeka.

Zero współpracy, zero dbania o projekt. Zero zaangażowania.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *