[V#5] 🙊 Sekret dokładnego planowania zadań

Wspomniane w odcinku:

https://pl.wikipedia.org/wiki/Prawo_Parkinsona

Transkrypcja

[00:00:01.690] Cześć! To co - w drogę?

[00:00:09.860] Kolejny tydzień, kolejny spacer. Dzisiaj porozmawiamy o temacie powiązanym z tym wczorajszym. Wczoraj było o produktywności, dzisiaj co nieco o planowaniu. Ale nie takim zwykłym, bo nie będę cię uczył różnych technik planowania; takich, żeby znać kiedy to się skończy, kiedy najlepiej coś zacząć. Nie. Tu nie chodzi o wykresy Gannta, ani o nic takiego. Dzisiaj coś prostszego. Coś prostszego i dającego lepsze i dokładniejsze wyniki. O czym mowa? O tym zaraz.

[00:00:52.160] Tak mi się spodobał ten Las Tyniecki, że teraz praktycznie codziennie tutaj jestem. Fajna sprawa.

[00:00:58.490] Można spokojnie pochodzić, pooddychać świeżym powietrzem i trochę odpocząć. I pogadać do kamery. No to w takim razie - o co chodzi, jeśli nie o te wykresy Gannta? Jeśli nie o jakieś Excele, plany dokładne. Chodzi o zmorę programistów, czyli estymację zadań. Masz zadanie… dostajesz zadanie no i masz wyestymować “ile Ci to zajmie”. I jak to zrobić? Prawda jest taka, że nie da się. Każdy programista, którego znam, nie potrafi tego zrobić dokładnie. Niektórzy strzelają, niektórzy estymują na podstawie poprzednich zadań (poprzednich podobnych zadań), a niektórzy po prostu wpisują cokolwiek.

[00:01:53.870] Nie przejmują się tym, bo wiedzą, że i tak to nic nie da. I tak każde planowanie, każda taka sytuacja będzie niedokładna. A dlaczego?

[00:02:14.140] Po prostu nie ma bata, żeby przewidzieć przyszłość. Nieważne ile zadań zrobisz wcześniej. Może być dokładnie takie samo zadanie. A możesz to zadanie tylko wyestymować. Kiedyś słyszałem o świetnym sposobie na estymację. Pomyśl sobie, ile zajmie ci dane zadanie i pomnóż razy 3.14. To jest metoda planowania “PI”.

[00:02:39.690] No dobra. Powiesz: “ale przecież są różne Scrumy, różne Agile, różne metodyki planowania. Nawet jakieś tam wzory magiczne. Czy nic nie dają?”

[00:02:50.240] Czy rzeczywiście nic nie dają? Według mnie trochę dają, ale czas potrzebny do takiej estymacji jest nieopłacalny. Mógłbyś zrobić już pół jakiegoś zadania zanim byś w miarę dokładnie wyestymował ile Ci coś zajmie. Tak naprawdę nie wiesz co cię czeka po drodze. Nie wiesz na jakie problemy trafisz po drodze. Nie wiesz co inni robią. Bo najczęściej nie działasz w odizolowanym ekosystemie. Nie działasz w innym systemie niż inni. To jest właśnie plus i minus pracy w zespole.

[00:03:33.320] Pracujecie razem nad jedną rzeczą, ale tak naprawdę możecie sobie, albo pomagać, albo przeszkadzać. Ale mimo nawet najlepszej komunikacji, ciężko jest dojść do takiego etapu, że w którymś momencie się nie jedziecie.

[00:03:52.620] I tak nawet same metodyki Agile’owe zakładają, że działasz na żywym organizmie. Że nie planujesz z góry na rok, dwa lata. Tylko działasz w ciągle zmieniającym się środowisku. Tak właśnie - jeśli Ty robisz jakieś zadanie i kolega z zespołu robi podobne zadanie w tym samym systemie (w tym samym module, w tej samej części systemu), to jest duża szansa, że będziecie musieli później, albo rozwiązywać konflikty, albo będziecie musieli się dogadać. Ale i tak jakiś czas na to pójdzie. Jakiś czas, nieprzewidziany przez was. Dlaczego?

[00:04:33.840] Bo po prostu to jest życie. Nie macie magicznej kuli. Nie jesteście wróżbitami. Nie potraficie przewidzieć przyszłości. I to jest normalne. Tak naprawdę, mimo że biznes, mimo że menedżerowie, scrum masterzy liczą na to, że wycenisz im zadanie na ileś czasu, to tak naprawdę mega ciężko jest wycenić to dokładnie. Bo albo się rozjedziesz w jedną stronę, albo w drugą. To jakie jest rozwiązanie tego problemu? Według mnie nie ma dobrego. Tak, czy inaczej, prędzej czy później się rozjedziesz ze swoimi planami. Według mnie najlepiej oszacować na oko.

[00:05:16.890] Ale jest jeszcze lepszy sposób, który pomaga w takim szacowaniu. Oprócz szacowania różnych zadań, warto jest podzielić te zadania na mniejsze bloki. Tak samo w tym odcinku, w którym mówiliśmy o nauce. Im mniejsza porcja wiedzy, tym łatwiej ją przyswoić. Tak w zadaniach. Im mniejsze zadanie, im mniejsza cząstka do zrobienia tym łatwiej ci to wyestymować. Bardziej wiesz, co zrobić. Jakie przeszkody mogą cię czekać. I tym dokładniej to wycenisz. I właśnie takie cięcie zadań na mniejsze kawałki pomaga nie tylko zaplanować to wszystko lepiej (bo zawczasu widzisz ile pracy cię czeka, tak z grubsza). Zamiast jednego tematu do zrobienia, masz dziesięć, ale 1/10 tego dużego. I dzięki temu widzisz dokładniej, że jest dużo (albo mało) do zrobienia. Dodatkowo, jeśli wykonujesz jakieś zadanie, to mózg dostaje małe zastrzyki dopaminy. Po prostu mózg się cieszy, że coś zostało zrobione.

[00:06:38.470] No i dalej, w idealnym świecie nie trzeba by takich zadań wyceniać w ogóle. Ale niestety nie żyjemy w idealnym świecie. W takim razie łatwiej wyceniać takie małe klocki. Bo w idealnym świecie po prostu masz stos zadań. Bierzesz jedno. Robisz. Odhaczasz. Bierzesz następne ze stosu, itd.

[00:07:02.130] Jednak przy większych projektach ktoś musi te zadania zaplanować. Ktoś musi mniej więcej widzieć, co łatwiej, a co trudniej zrobić. Co zajmie więcej czasu, a co będzie szybsze. No i na podstawie tego planuje czas. Robi te swoje wykresy Gannta. Robi arkusze w Excelu. Po prostu robi grafiki - kiedy mniej więcej dana funkcjonalność będzie zrobiona. Tutaj mam oczywiście największe doświadczenia ze światem programowania, ale tak naprawdę takie podejście rozbijania zadań na mniejsze sprawdzi się w wielu branżach (jeśli nie we wszystkich). Po prostu warto spróbować dzielić zadania na mniejsze. Zamiast próbować szacować taki wielki klocek, warto rozbijać na mniejsze. Jakbyś miał przenieść stukilowy głaz kontra 10 dziesięciokilowych. Takiego stukilowego praktycznie nietkniesz. A 10 dziesięciokilowych już prędzej. Poprzenosisz po jednym. No i będzie z głowy. Efektem ubocznym jest to, że takie mniejsze zadania łatwiej poukładać w bloki czasu. Jeśli planujesz sobie czas, to łatwiej wcisnąć takie mniejsze zadanie, niż takie ogromne zadanie, przy którym stwierdzisz że: “ło matko, tyle czasu, tyle trzeba zaplanować. Zamiast dziesięciu minut, to dwie godziny”. I od razu ciężej wcisnąć w twój grafik. Takie duże zadanie.

[00:08:40.650] Dodatkowo jeszcze w świecie programowania warto wypuszczać takie małe zadania od razu jak je zrobisz. Zamiast kisić i łączyć kilka mniejszych zadań w większe, warto wypuścić jedno. Tylko ukryte, żeby funkcjonalność nie była od razu dostępna. Odkryjesz jak zrobisz całą funkcjonalność. A tak to wypuszczasz małe klocuszki, które na początku są ukryte. Po prostu niedostępne z poziomu aplikacji. Dzięki temu od razu będą w aplikacji - już będą przetestowane, gotowe. I będą czekały na resztę klocków. Tak samo jeślibyś budował dom. To nie budujesz go gdzieś na boku. I nie przenosisz całego domu na swoją działkę, tylko budujesz bezpośrednio na działce. Po kawałku, dobudowujesz, aż będzie cały dom gotowy. I tak właśnie jest z tymi mniejszymi zadaniami. Masz gotowe zadanie małe - dopychasz je. Jedziesz z następnym. Budujesz drugie zadanie - jedziesz dalej. Tyle, że ukryte, niedostępne z poziomu aplikacji.

[00:10:02.480] To, że ci mówię, że ciężko zaplanować cokolwiek, to nie znaczy, że nie warto planować w ogóle. Wręcz przeciwnie. Im więcej zaplanujesz, tym więcej zrobisz. Nie pamiętam jakie to jest prawo, ale jest takie prawo, że zadanie zajmuje tyle czasu ile na niego przeznaczysz. I ile dla niego założysz. I to w miarę często się sprawdza. A to, że mówię, że ciężko wyestymować cokolwiek, to nie znaczy, że nie warto estymować. Tylko znaczy, że ciężko jest wyestymować. A im mniejsze jest zadanie tym łatwiej oszacować.

[00:10:49.040] Idealnie by było nieestymować, ale tak najczęściej się nie da. Najczęściej po prostu są takie polityki, takie ustalenia. Biznes musi mieć jakąś wiedzę, jakieś szacunki, kiedy może się czegoś spodziewać. Tak samo jak przy budowie domu nie bierzesz robotników, a oni ci nie mówią, że “będzie jak będzie zrobione” tylko mniej więcej ustalasz z nimi - na kiedy ma być zrobione. A to, że potem się pojawiają jakieś obsuwy - to jest naturalne. To jest przy produkcji każdej rzeczy, w każdej branży. Podsumowując, warto planować, ale warto też rozbijać zadania na mniejsze.

[00:11:36.540] Dzięki temu będziesz wiedział dokładniej co jest do zrobienia i ile mniej więcej zajmie to czasu. I jak to duże zadanie się rozkłada na mniejsze. Jakie kroki musisz zrobić, żeby wykonać duże zadanie. Dodatkowo, to że robisz mniejsze zadania, to bardziej widzisz postęp.

[00:12:03.360] To już tyle na dzisiaj. Opowiedz o swoich metodach planowania i estymacji. Czego używasz? Co się sprawdza, a co nie? I dlaczego? Podziel się - tutaj, w komentarzach. A tymczasem ja lecę sobie dalej pospacerować. I pewnie do kolejnego spaceru. Trzymaj się. Cześć.