Roland i Złote Kiwi – o co w tym chodzi?

Ten wpis jest posłowiem Rolanda i Złotego Kiwi, interpretacją autora, wyjaśnieniem całej tej historii, począwszy od metafor. Jeżeli cię ta historia ani metafory w niej zawarte nie do końca interesują, to nic straconego, przeskakuj niżej i tam są już konkrety.

Metafory

Roland – zespół, wieloosobowy czy jednoosobowy, nieistotne Dostaje nowy projekt. Nie do końca jest do niego przekonany, nie wie, po co on powstał i o co w nim chodzi, jest trochę nieufny, ale w końcu podejmuje wyzwanie. Gdy dostaje pytanie: “Ile potrzebujesz czasu?”, pewny siebie odpowiada po krótkim namyśle.

Bóg Zniszczenia – klient, uwięziony w pułapce niewiedzy, zapomniany, potrzebujący. W końcu zjawia się zespół, który może mu pomóc – jesteśmy w tym zespole. Ważny jest dla niego termin. Może być jakikolwiek, ale musi zostać dotrzymany.

Złote Kiwi – projekt, marzenie, którego Bóg Zniszczenia nie potrafi sam zdobyć. Potrzebuje firmy, zespołu.

Pierwsze puste świątynie – pierwsze dni, rozpoczęcie pracy, lekkie rozleniwienie i odpoczynek po poprzednim projekcie. Gdy rozpoczynamy i widzimy, że idzie gładko, odpuszczamy. Przecież skończy się szybko.

Świątynia Wodnika i Panny – pierwsze lekkie bugi i problemy, które napotykamy. Jedne zwykłe, wykryte przez testy, inne trudniejsze, związane z wyścigami, wątkami, asynchronicznością.

Świątynia Bliźniąt – pierwsze poważne problemy. Coś nie wyszło. Coś trzeba zmienić. Trwa to jakiś czas, bo trzeba pomyśleć. Problem nie jest trywialny. Debugowanie trwa.

Świątynia Raka – znowu błędne założenie na początku projektu. Nie możemy skorzystać z technologii, której byliśmy pewni. Klient nalega na inną, klient nie ma pieniędzy, okazało się, że jednak nie pasuje – powody mogą być różne. W każdym razie, bez niej będzie o wiele trudniej. Dobrze ją znaliśmy, ale jakoś musimy sobie poradzić bez niej.

Świątynia Lwa – zignorowany, utajony, pozostawiony na później problem. Z pozoru wyglądał na nieistotny, przeskoczyliśmy go. Załatwi się go później. Nie został nigdzie zgłoszony i dlatego o nim zapomnieliśmy. Gdy zaczyna brakować czasu, na samym końcu projektu, przed samym releasem uderza w nas niespodziewanie i nagle. Z reguły wtedy, gdy jest już za późno.

Świątynia Skorpiona – czas workaroundów. Kolejne wyzwanie, kolejny problem, którego nie przewidzieliśmy. Jest na tyle poważny, że całość projektu może się nie udać, możliwe, że zmienić trzeba byłoby same fundamenty – architekturę, przyjęte technologie. Próbujemy workaround, działa. Coś innego przestało. Próbujemy kolejny, działa. Lecz znowu coś innego się popsuło. Walczymy z tym problemem – raz nam idzie lepiej, raz gorzej. Szala przechyla się to na korzyść totalnego fuckupu, to na naszą. W końcu, naładowani napojami energetycznymi, zarywając nocki rozwiązujemy problem łatą, która trzyma.

Świątynia Koziorożca – przez pisanie w pośpiechu, przez kolejne workaroundy, kolejne łaty, kod niestety nie jest najlepszej jakości. Jesteśmy coraz bardziej zestresowani, pracujemy pod presją, a kolejne wyzwania i wymagania nie są wcale łatwiejsze. Tracimy skupienie i big picture zaczyna nam uciekać. Kod jest kiepski, więc znajdują się w nim absurdalne błędy. Tak było właśnie na tym etapie. Niespodziewanie coś się popsuło. Debugowanie i szukanie problemu. Został znaleziony tam, gdzie nikt się tego nie spodziewał.

Świątynia Ryb – system jest domkiem z kart, kruchy, wrażliwy w wielu miejscach. Wszystko stanęło na głowie, nie wiadomo już co jest czym. Niby działa, ale czy przez przypadek, czy dlatego, że wszystko jest ok?

Bieg ku świątyni Złotego Kiwi – ostatnie dni i godziny. Zaraz release, wdrożenie na produkcję. Już prawie. Poszło. Jednak system się wywala. Nie działa. Dostajemy zgłoszenie. Nic nie jest tak jak miało być. To ten bug, którego zostawiliśmy na później. Nie naprawiliśmy go. Czy to był bug wydajnościowy? Czy był to brak testów end to end? Czy był to brak testów w ogóle? Nie ważne. Wiedzieliśmy, że należało to zrobić, zignorowaliśmy to i dokładnie przez ten problem, w połączeniu z niestabilnym systemem, wszystko rozsypało się w drobny mak.

Zniszczenie krainy, uwięzienie w studni – wkurzony klient. Zerwanie umowy. Utrata dobrego imienia. Zwolnienie z pracy.

Rozmowa z samym sobą

– Mateusz, wyluzuj.

No dobrze. Zgodzę się z tym, że nieco drastycznie opisałem historię tego releasu. Jednak niestety takie sytuacje się zdarzają. Od wielu lat już programuję i nie stykałem się z nimi tylko w trakcie pierwszego roku.

– Mateusz, no zdarza się, wiadomka, ale przecież klient nie może brać estymacji za jakiś pewnik.

Zdarza się, że mamy dobre relacje z klientem, pracujemy już razem długo i dobrze się rozumiemy, ALE zdarza się też coś zupełnie odwrotnego – jesteśmy w miarę nowym zespołem, klient również jest nowy, poznajemy się dopiero i docieramy. Możemy nie mieć jeszcze opracowanej sprawnej komunikacji. W związku z tym, gdy klient usłyszy od nas podczas spotkania, że “powinno być gotowe na piątek”, to stwierdzi po prostu, że “fajnie, jesteście super” i uruchomi działania marketingowe. Czasami też się zdarzają terminy nie do przeskoczenia, np. data konferencji, na której nasz produkt będzie pokazywany, albo uruchomienie loterii z nagrodami w naszym ecommerce, gdzie marketing wyprzedza release o miesiąc czy dwa. Wtedy lepiej, żeby te nasze strzały estymacyjne były jednak bliżej środka tarczy.

– Mateusz, no tak, jasne, może coś nie wyjść w trakcie pisania kodziku, ale przecież spokojnie o tym wtedy powiemy klientowi i będzie mógł sprawnie zareagować.

Jeżeli faktycznie klient dowie się o problemach o wiele wcześniej, to jeszcze pół biedy. A teraz tak z ręką na sercu, czy zawsze informowałeś/informowałaś swojego klienta o każdym przestoju? Albo czy twój zespół go o tym informował? Albo inne zespoły? Z jakiegoś powodu dajemy sobie tę godzinkę więcej. Jeden dzień więcej. Może jeszcze jeden, nic się przecież nie stanie. Tak pomyślą również inni programiści. Na koniec sprintu okazuje się, że połowa niedowieziona, a sprint był miesięczny. Odpowiedzialność rozmyta, tłumaczy się lider, więc za bardzo się tym nie przejmujemy.

Wiele czynników może się składać na niepowodzenie projektu. Tutaj, w tej historii, w tym wpisie chciałem się skupić tylko na jednym, na estymacjach. Roland na pewniaka powiedział, że potrzebuje dwunastu dni. Nie zastanowił się, nie skupił, nie przeanalizował, nie dopytał. Nie odszedł na bok (nie skonsultował się z zespołem), nie poprosił o czas do namysłu. Nie wiedział jeszcze dokładnie, z czym ma do czynienia. Założył i krótko mówiąc, pomylił się.

Skoro już musimy coś wyestymować, powiedzieć klientowi, co będzie gotowe na dany termin, albo do kiedy dowieziemy całość, to warto się w spokoju nad tym pochylić, zastanowić i to przeanalizować. Nie żeby wyznaczyć dokładny dzień i godzinę, ale żeby przynajmniej postarać się skończyć jak najbliżej tych naszych estymacji.

Estymacje muszą pochodzić z głowy, nie z dupy.

Gdy już musimy estymować, przyłóżmy się do tego. Nie zgadujmy. Mam swoje proste i sprawdzone metody.

Gdy podczas spotkania z klientem pada pytanie: “Czy będzie to gotowe na przyszły piątek?”, albo jakiekolwiek podobne, to nie odpowiadam. Nigdy. Na takim spotkaniu możemy nie mieć swobody dyskusji, jest niepotrzebny stres, timebox – po prostu nie sprzyja ono przeanalizowaniu zadania. Na takie pytanie zawsze odpowiadam wtedy: “Przeanalizujemy po spotkaniu i damy znać.”. W 99,9% usłyszymy: “Ok”. Rzadko kiedy zdarzają się tak pilne sprawy, że godzina czy dwie zwłoki robią różnicę. Z reguły okazuje się, że możemy nawet spokojnie wyestymować te nowe funkcjonalności na naszym cyklicznym spotkaniu estymacyjnym kilka dni później i jeszcze mamy czas, żeby dopytać i rozwiać wątpliwości.

Gdy już siadamy do tych estymacji, spotykamy się, to róbmy je na spokojnie. Czasami stajemy się więźniami timeboksów. Tak, zgadzam się, że jeżeli spotkanie było zaplanowane na jedną godzinę, to powinno tyle trwać. Natomiast, jeżeli w ciągu tej godziny nie uda nam się przeanalizować i przegadać wszystkich zadań, to nie przyspieszajmy pod koniec spotkania. Pierwsze dziesięć zadań w pięćdziesiąt minut, a drugie dziesięć zadań w ostatnie dziesięć minut. Nic dobrego z tego nie wyjdzie, na pewno, bo jesteśmy przesadnymi optymistami. Prędzej na szybko przypiszemy pięć mendejów, czy pięć Story Pointów, niż osiem czy dziesięć – żeby się potem nie tłumaczyć, czemu aż tyle. Przecież nie wiemy czemu, bo tego zadania nie przeanalizowaliśmy. Widocznie na tyle zadań jedno spotkanie to za mało. Trudno, niestety. Musimy spotkać się znowu i zrobić to dobrze.

Gdy czegoś nie wiemy, to dopytujemy. Zawsze. Nie zakładamy. Nawet, jeżeli mamy pewne podejrzenia, albo jesteśmy pewni na 90%. Dopóki nie jesteśmy pewni na 100%, to tak, jakbyśmy nie wiedzieli. Ile razy zdarzyło ci się założyć, że na pewno klientowi chodziło o A i B, a potem okazywało się, że istnieje jeszcze C? Biznes nie zawsze jest logiczny, możemy go też po prostu nie rozumieć, dlatego warto dopytywać. Wiem, nie chce nam się. Bo trzeba komentarz napisać do zadania, albo zadać pytanie na komunikatorze czy podczas spotkania. Jest to angażujące, to prawda, ale musimy tak robić. Może znajdzie się w naszym zespole osoba, która lubi takie zadania i jest chętna – dlatego warto mieć różnorodny zespół o różnych talentach. Czasami zdarza się taka sytuacja, że musimy coś założyć. Zadanie jest do zrobienia na jutro, wyszły niespodziewanie jakieś niejasności, klient znajduje się w innej strefie czasowej i nie ma go jak zapytać. Dobrze, wtedy coś załóżmy, ale to założenie spiszmy i kolejnego dnia upewnijmy się, że to o to właśnie chodziło.

Gdy już estymujemy w Story Pointach, to estymujmy w Story Pointach. Relacyjnie. Gdy mówimy: “To jest taka piątka.”, to musi ona wynikać z porównania tego zadania do innych, nie z przeliczenia w głowie godzin na SP. Przeliczanie niestety często dzieje się z automatu i to nie nasza wina. Jak możemy sobie pomóc? Tworzymy projekt w Trello, każda kolumna to kolejna wartość SP. Proste? Proste. Teraz tylko wystarczy dla danego zadania stworzyć kartę, wkleić do niej tytuł i przenieść ją do odpowiedniej kolumny. Nie pytamy wtedy: “Ile SP nam to zajmie?”, tylko “Gdzie to przenosimy?” – patrzymy na pozostałe zadania i porównujemy. Wszystko elegancko widoczne czarne na białym.

Gdy już wyestymowaliśmy, wracamy na spotkanie z klientem i znowu pada pytanie: “Czy będzie to gotowe na przyszły piątek?”, to co robimy? Nie odpowiadamy! Ależ zaskakujący obrót wydarzeń! Żartuję. Odpowiadamy, ale nie wprost. Takie pytania zawierają pewną pułapkę – odpowiedzialność za wszystkich i za wszystko. Piszę to z perspektywy programisty mobilnego. Zdarza się, że dana funkcjonalność zależy od: urządzenia (IoT), softu na tym urządzeniu, backendu oraz grafik, nawigacji itd. Nie zapominajmy o innych zespołach. Mogą być one rozproszone po różnych firmach czy nawet krajach. Nie możemy brać za nich odpowiedzialności. Takie pytania są podchwytliwe, ale w końcu musimy na nie odpowiedzieć i wtedy warto zaznaczyć, że mówimy o naszej pracy: “Nasz zespół potrzebuje dwóch tygodni, żeby skończy tę funkcjonalność. Natomiast jeżeli wystąpią jakieś opóźnienia wśród innych zespołów, to mogą one mieć wpływ również i na naszą pracę. Są to czynniki niezależne od nas.”. Chodzi przede wszystkim o wytłumaczenie klientowi, jak to działa, na czym polega taka współpraca i co musi zostać wykonane, żeby na ekranie swojego telefonu mógł zobaczyć to, o co nas poprosił. Bierzmy odpowiedzialność wyłącznie za swoją pracę, dbając jednocześnie o dobro projektu i pomagając innym zespołom, za każdym razem, gdy tylko takiej pomocy będą potrzebować.

– Mateusz, czy nie mogłeś od razu powiedzieć, o co ci chodzi? Trzeba ci było pisać całą tę historię z Rolandem?

Oczywiście, że mogłem, ale wtedy nie bawilibyśmy się tak dobrze. A tak, to były strzały z dupy, wyścigi, czopki, Bóg Zniszczenia. Czyli to, co lubię najbardziej.

Dodaj komentarz

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