🛠️ Jak planować dostarczanie funkcjonalności
Poprzednio opisywałem jak dzielić funkcjonalność na mniejszą. A więc masz już ją w odpowiedniej wielkości, co dalej? Teraz trzeba ją dowieźć. Żeby to zrobić trzeba mieć jednak jakiś plan 🤔
O czym pamiętać tworząc plan
Jak to powiedział kiedyś Mike Tyson:
Każdy ma jakiś plan, dopóki nie dostanie pięścią w twarz.
I jest to prawdziwe - w każdym planie coś nie wypali. Ale nie po to się tworzy plany. Posłużę się drugim cytatem, tym razem prezydenta Eisenhowera:
Przygotowując się do bitwy, zawsze odkrywałem, że plany są bezużyteczne, ale planowanie jest niezbędne.
To znaczy, że akt planowania jest równie ważny jak sam plan. Plan możesz zmienić. Żeby to jednak zrobić, musisz zgromadzić odpowiednie informacje i przewidzieć potencjalne problemy.
A więc o tym, jak planować, aby zaplanować 😀
🎯 Zacznij od wyznaczenia celu
Ludzie potrafią kłócić się godzinami, co powinno zostać zrobione. Ale jak pytam się, jaki jest dokładny cel, to nie ma jasnych kryteriów.
To się nigdy nie zgodzicie 😅
Dyskusja o dokładnych zadaniach jest wartościowa. Jednak dopiero wtedy, gdy wiesz co chcesz osiągnąć. Inaczej nie umiesz ocenić potencjalnych zadań.
Nawet jeśli wyznaczyliście funkcjonalność do dostarczenia, to warto dla niej zdefiniować rezultaty (outcomes). Pozwoli to łatwiej określać, czy dane zadanie jest wymagane, czy nie. Część zadań może kompletnie wylecieć, bo nie dowozi pożądanej wartości.
Cel upraszcza też zmianę planu w trakcie. Załóżmy, że zmieniło się twoje otoczenie biznesowe i musisz zmienić istniejący plan. Wtedy wystarczy, że odniesiesz się do celu. Pomoże Ci on określić, które zadania zmienić, a które pozostawić.
Trudno w tym momencie nie polecić kultowego nagrania z TED Simona Sinka How great leaders inspire action. Zdefiniowanie celu potrafi zmotywować zespół do pracy. Nadaje “wyższy sens” pracy. Jeśli będziesz taki cel posiadać, to zaręczam, że będzie się pracowało przyjemniej.
🔪 Rozbij funkcjonalność na mniejsze zadania
Nawet jeśli podzieliłeś funkcjonalność na mniejszą, to raczej nie jest ona do dowiezienia w dzień. Zwykle można wydzielić w ramach niej mniejsze zadania. Tylko jak to zrobić?
Możesz rozpocząć od opisania typowych obszarów zadań. Taka lista pomaga, aby określić co się musi zmienić. W przypadku aplikacji webowej mogą to być zadania:
Bazodanowe
Infrastrukturalne
Kontraktów API
Backendowe
Frontendowe
Testów
Pewnie będziesz w stanie dopisać kilka od siebie.
Zadania też będą się dzielić na mniejsze. Tutaj pomaga myślenie metaforą WBS:
WBS to skrót od Work Breakdown Structure. Rozdzielasz sobie zadania na mniejsze, tworząc drzewo zależności. Im głębiej schodzisz w dół, tym mniejsze zadania.
No dobra, ale powstaje pytanie: Jak mocno dzielić zadania? Praktyka dookoła ruchu No Estimates mówi o około +/- 1 dniu. Możesz to wziąć za podstawę do dyskusji. Niekiedy zadań nie da się podzielić na tak małe, warto próbować. 😉
Pytanie czy dzielenie zadań na tak małe nie jest overkillem? Rozbijanie zadań ma być przede wszystkim miejsce do dyskusji. Chodzi o to, aby obie strony rozumiały zakres i potencjalne problemy. A te dostrzeżesz dopiero, gdy masz odpowiednio małe zadania. Dodatkowo, łatwiej jest nie pominąć czegoś istotnego.
Jedna uwaga w ramach tworzenia zbioru zadań. Warto, aby spełniał on regułę MECE:
Mutually exclusive - elementy planu nie powinny na siebie nachodzić.
Collectively exhaustive - elementy planu powinny wypełniać całą przestrzeń dowiezienia.
Brzmi prosto, prawda? 🤨 Ale zadaj na koniec rozbijania otwarte pytanie:
Czy to na pewno wszystkie zadania, aby dowieźć tą funkcjonalność?
A zobaczysz, że coś się jeszcze znajdzie!
🕸️ Zdefiniuj i monitoruj zadania zależne
Rzadko kiedy jest tak, że pracujesz w próżni. Posiadasz zależności w ramach pracy nad poszczególnymi zadaniami. Niekiedy również masz zależności poza-zespołowe, allbo nawet poza-organizacyjne.
Warto rozpocząć od opisania rodzajów zależności:
Logiczna - Zadania następują po sobie - Najpierw Baza, później Backend.
Zasobów - Wykorzystujesz współdzielone zasoby - Zmiany na infrastrukturze.
Zespołowa - Zadania wymagają pracy innego zespołu - Zespół X musi stworzyć API.
Zewnętrzna - Zadania wymagają pracy zewnętrznych dostawców - Firma A tworzy bibliotekę.
Preferowana - Zespół chce realizacji w danej kolejności - Bo tak lubią. 😀
Zależność logiczną warto określić, ponieważ ma ona wpływ na ostateczne tempo dostarczenia. Tutaj pomaga rozumienie pojęć dookoła łańcucha krytycznego.
Z definicji:
Zadania, które zależą od siebie wzajemnie tworzą graf. Najdłuższa ścieżka po tym grafie tworzy łańcuch krytyczny.
Łańcuch krytyczny to ciąg takich zadań w grafie, że opóźnienie któregokolwiek z nich opóźni zakończenie całej funkcjonalności.
Co to oznacza dla Ciebie? Jeśli nie wiesz, jak wygląda łańcuch krytyczny, to nie wiesz które zadania są istotne pod względem opóźnień. I skupiasz się na każdym małym opóźnieniu. Jak masz wiedzę o łańcuchu krytycznym, to wiesz, gdzie nie ma sensu się spinać 😎
Z drugiej strony, zależności pomiędzy zespołami i organizacjami z natury są bardziej problematyczne. Tutaj masz mniejszy wpływ na to, co się dzieje. Zwykle nie da się przypisać zadania do osoby - np. nie należy do naszego zespołu.
Jednak mam tutaj dla Ciebie pewien trick. Określ osobę od monitorowania zadań w innym zespole / organizacji. To pozwoli cały czas być na bieżąco z tym, jak idą te zadania. Będziesz miał więcej informacji jak przebiega realizacja, i czy nie ma jakichś opóźnień.
🗓️ Mów na kiedy będzie, a nie ile to potrwa
Jeśli nie musisz podawać dat dostarczania, np. działasz w ramach ruchu No Estimates, to możesz pominąć ten fragment. Ale niestety nie wszyscy mają taką przyjemność pracy. 😒
Czasu trwania prac nad funkcjonalnością nie da się określić bez zdefiniowania zależności zadań. Dlatego też ten punkt umieściłem powyżej. Czas trwania poszczególnych zadań nie jest czasem dowożenia. Zależności potrafią zwielokrotnić ten czas. Np. czekasz z zadaniem B, ponieważ A się nie skończyło. Więc estymuj czas zadań, ale bierz pod uwagę jak te zadania wpływają na siebie.
Jednak dużym błędem jest skupienie się jedynie na tym, ile to potrwa. Sprawdź taką konwersację:
Ty: Ta funkcjonalność zajmie nam 5 dni.
Biznes: OK, czyli w następnym tygodniu ona wejdzie, tak?
Ty: Niby tak, ale mamy jeszcze…
Biznes: To w takim razie na koniec następnego tygodnia, uzgodnione.
Samemu na siebie zastawiłe(a)ś pułapkę - przesuwasz na innych zarządzanie twoim czasem. Dlatego kluczowe jest, abyś to Ty rządził(a) twoim kalendarzem realizacji.
Mówienie na kiedy to będzie jest trudniejsze. Musisz:
Znać plan zadań swojego zespołu.
Brać pod uwagę ad-hoci, faktyczne tempo dostarczania.
Określać potencjalny dzień startu prac.
Priorytetyzować i odbywać trudne rozmowy o przesuwaniu.
Jednak 100% lepsze jest, abyś to Ty zarządzał(a) planem. Inaczej tworzy się chory, organizacyjny ping-pong. Ludzie, którzy nie rozumieją złożoności pracy zespołu produktowego wchodzą z buciorami i zmieniają kierunek działań. To się nie może udać.
Na koniec - nie zakładaj, że ludzie pracują 8 godzin dziennie. Plany wybuchają już po kilku dniach. W zależności od stanu zespołów praca efektywna to 4-6 godzin dziennie. Reszta idzie na ad-hoci, niefunkcjonalne zadania. That’s life, jak śpiewał Sinatra 😀
🐾 Iteruj, monitoruj i adaptuj
Jak to nawijał Diox w piosence “Kryzys”:
Miałem plan, jak z każdym planem
Trzeba będzie wprowadzić zmianę
Żaden plan nie wytrzyma wprowadzenia go w życie. Dlatego co jakiś czas trzeba dyskutować jak idzie wdrażanie funkcjonalności. W zależności od organizacji prac, możesz to robić synchronicznie (ala daily Scrumowe), albo asynchronicznie (pisząc z określonym interwałem na wspólnych kanałach).
Dyskusja o postępie zadań ma jedną dużą zaletę - masz mniejszą szansę, że Ty, bądź ktoś w zespole, zakopie się na czymś błahym. Również jest łatwiej rozwiązywać randomowe problemy, zanim eskalują.
Jednak jeśli odrobisz powyższą lekcję, to masz na tyle informacji, że możesz swobodnie modyfikować plan. Wiesz, co jest istotne. W ramach celu dobierasz i zmieniasz priorytety zadań. Po to się planuje, aby mieć przestrzeń do działania.
Musisz też pamiętać kogo powiadomić, jeśli nie dotrzymasz założonego terminu (jeśli taki masz). Nie ma nic gorszego dla interesariusza, jak dowiedzieć się w ostatni dzień, że funkcjonalność nie zostanie dowieziona. Tym bardziej, że wiedziałe(a)ś o tym od dwóch tygodni.
Ten problem możesz zmniejszyć, jeśli przygotujesz wcześniej Mapę Interesariuszy:
Na tej podstawie wiesz, kogo powiadomić, kiedy coś się obsunie. Zwykle ludzie nie mają problemu z przesunięciem terminu, jeśli odpowiednio wcześnie im o tym powiesz. Ale trzeba to zrobić. Andrzej Krzywda pisał o podejściu overcommunication - komunikowaniu dużo, często. W świecie zdalnym to właściwie wymóg.
Podsumowanie
Spisałem o planowaniu ponad 1200 słów. A dalej czuję, że ledwie liznąłem tematu planowania. 😂 Ale to może na kolejne newslettery.
Więc jeśli masz jeszcze jakąś ciekawą poradę w tym temacie to chętnie posłucham więcej 😊
Ten temat pogłębiam na szkoleniach:
ponieważ uważam, że dobry TL / EM powinien mieć umiejętności ustalania i wdrażania planów w życie.