Dekomponowanie zadań

Umiejętność dekomponowania zadań uważam za kluczową, jeśli chodzi o zarządzanie czasem. W różnych momentach prowadzenia szkolenia z tego tematu, starałem się formułować mniej lub bardziej zjadliwe procedury do przeprowadzania owej dekompozycji. W końcu mnie oświeciło i wpadłem na tę, jak sądzę, najprostszą, elegancką i skuteczną:)

Definiuj zadania maksymalnie czterogodzinne

Wiem, że brzmi to jak magiczna formułka na wszystkie problemy. Aczkolwiek to proste zdanie to tylko wierzchołek czegoś większego. Zauważyłem, że gdy wyodrębniając zadanie skupiamy się na tym, aby zajęło cztery godziny, przebiegamy w myślach przez kilka procedur i kryteriów dekomponowania, które tak usilnie starałem się wcześniej sformułować.

Trik polega na tym, że fiksując się na owych czterech godzinach, musisz wykonać eksperyment myślowy i dość szczegółowo wyobrazić sobie to, co ma być efektem zadania i jak to wykonasz. Czyli właśnie to, czego nie robią osoby mające kłopot z dekomponowaniem, a w konsekwencji i z dotrzymywaniem szacowań.

Cztery godziny to dość krótka perspektywa czasowa, którą w dodatku, jako homo sapiens, potrafisz dość dobrze percypować (@see Nie myj zębów, rób retrospekcje). Żeby więc to czterogodzinne zadanie wykonać, musisz być pewny, że da się je wykonać i formułujesz je bardzo konkretnie (przechodzi Test Copy-Paste). I to jest druga zaniedbywana sprawa.

Cztery godziny to, rzecz jasna, wartość umowna. Chodzi o to, aby perspektywa czasowa, była na tyle bliska, aby ze spokojem się na niej skupić i realnie o niej myśleć. Poeksperymentuj z godziną, dwoma, trzema - sprawdź, co będzie. Czy z większymi liczbami też? Moim zdaniem - nie.

Sądzę, że raczej nie jesteśmy w stanie wiarygodnie oszacować na np. 8 godzin. Wiarygodnie tzn. ze powtarzalną trafnością.No, może z wyłączeniem zadań typu: przybij tysiąc stempli na kopercie, napisz walidację not null dla pięćdziesięciu textfieldów na stronie, gdzie obowiązuje proste mnożenie.

Zachęcam gorąco do eksperymentowania i postępowania wg własnego uznania:)

---

UPDATE 30/08/13
Komentarz do posta uświadomił mi, że powinienem jeszcze kilka słów dodać:)

Moja teza nie brzmi "szacuj na max, 4h bo powyżej tego źle oszacujesz", lecz "jeśli wyodrębniasz zadanie z wystarczająco krótką perspektywą czasową, to zrobisz to konkretnie, gdyż wymusi to przemyślenie przedsięwzięcia i być może utrzymasz szacowanie - lecz nie z powodu szacowania, a konkretności właśnie"

Tak jak napisałem, 4h przyjąłem arbitralnie. Co do trafienia w większe oszacowanie, to różnie bywa (por. "Szacowanie oprogramowania", Steve McConnell). Jednakże zwróciłem uwagę, że gdy szacujemy, to zazwyczaj szacowania wyglądają np. tak: 8, 8, 24, 16, 8, 12, 24.

Gdy położyłem przed sobą wiele takich szacowań, to zaważyłem, że niemal wszystkie to wielokrotności jakiejś bazowej liczby: często 8 bądź 6.

Wnioski były dla mnie takie:

• szacując operujemy jakimiś tam idealnymi interwałami (osobodniami, efektywnymi dniami), za pomocą których próbujemy odwzorować czasochłonność zadania
• raczej nie szacujemy czasu, lecz rozmiar zadania - jak duże ono jest

Gdyby chcieć podawać rzeczywiste oszacowania, trzeba by zaprzęgnąć jakaś metodę analityczną np. PERT.

Wg mnie sensowna metoda szacowania polega na retrospektywnej analizie zadań. Najpierw musisz popracować, zobaczyć z czym masz do czynienia, szacować na wyczucie. A potem zaprzęgasz statystykę, analizujesz dane, wyodrębniasz klasy zadań i estymujesz przyszłość z założonym prawdopodobieństwem.

Wtedy dopiero wychodzi, jak bardzo szacowanie wrażliwe jest na zmiany kontekstu, środowiska. Innymi słowy, gdy nie mogę sobie zbudować jakiegoś punktu odniesienia i wszystko absolutnie wszystko się zmienia, to szacowanie jest tylko złudzeniem. Lubimy wierzyć w to złudzenie, bo to łatwiejsze, niż przyznanie, że jednak przyszłość nie będzie wyglądać tak, jakbyśmy chcieli.