🛠️ Jak planować dostarczanie funkcjonalności2023-04-19Cześć! W poprzednim newsletterze dowiedziałe(a)ś się jak dzielić funkcjonalność na mniejszą. A więc masz już ją w odpowiedniej wielkości. Teraz trzeba ją dowieźć. Żeby to zrobić trzeba mieć jednak jakiś plan 🤔A więc w dzisiaj mam dla Ciebie: Miłego czytania 😀 O czym pamiętać tworząc planJak to powiedział kiedyś Mike Tyson:
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:
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 celuLudzie 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 zadaniaNawet 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:
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:
Brzmi prosto, prawda? 🤨 Ale zadaj na koniec rozbijania otwarte pytanie:
A zobaczysz, że coś się jeszcze znajdzie!
🕸️ Zdefiniuj i monitoruj zadania zależneRzadko 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:
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:
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 potrwaJeś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ę:
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:
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 adaptujJak to nawijał Diox w piosence “Kryzys”:
Ż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. PodsumowanieSpisał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. Modularyzacja z Event Storming - warsztatBardzo możliwe, że kojarzysz Oskara Dudycza. Jest to osoba, która prowadzi kilka inicjatyw: W ramach społeczności Architecture Weekly odbywają się comiesięczne webinary. I w ramach kolejnego webinaru wystąpię z mini-warsztatem:
Aby się dostać na webinar i zadawać pytania musisz być subskrybentem Architecture Weekly. Jeśli jednak nie jesteś, to wyślę w kolejnym newsletterze link do nagrania 😊 Skalowanie organizacji produktowej - draftNiektóre artykuły powstają relatwynie szybko. Siadam, spisuję co mam w głowie. Druga iteracja na korekę. I idzie na proda 🛫 Jednak niektóre artykuły tworzą się powoli. Zbieram na nie informacje. Artykuły przechodzą wielopiętrowe review. Niekiedy do artykułu powstają dodatkowe, wstępne materiały by przybliżyć temat. I tak jest teraz. Piszę artykuł “Skalowanie organizacji produktowej za pomocą celów”. Zawarłem w nim:
Zachęcam do przeczytania i przekazania feedbacku 😎 Możesz go przekazać w formie PR na Githubie, lub odpowiadając na tego maila. 📧 Prześlij dalejDzięki, że doczytałeś(aś) do końca. 😊 Wszystkie poprzednie wydania newslettera są dostępne tutaj. Jeśli spodobał Ci się mój newsletter, prześlij go proszę osobom, którym też mógłby się spodobać. Z góry dziękuję. A jeśli nie jesteś jeszcze w newsletterze, to zachęcam do zapisania się. Polecam się na przyszłość!  "Inżynierskie podejście do produktów cyfrowych." P.S. Co myślisz o tym newsletterze? Odpisz :) |
