Troy Magennis: używanie danych do szybkiego prognozowanie i podejmowanie decyzji.

Take away

  1. Nie ma jednego wyniku prognozy.
  2. Obniżenie czasu dostarczenia o 20% zwiększa przepustowość systemu aż o 33%.
  3. Przez większość czasu realizacji zadania nikt aktywnie nad nim nie pracuje.

 

 

Prognoza odpowiada na pytania dotyczące zdarzeń, które jeszcze nie miały miejsca (na kiedy będzie dostarczone, ile osób potrzebujemy w zespole, ile to będzie kosztować, jaki jest koszt opóźnienia).

Nie ma jednego wyniku prognozy. Zawsze będzie kilka możliwych wyników, niektóre bardziej prawdopodobne od innych.

Praca nad skróceniem Cycle Time ma bardzo realne uzasadnienie. Obniżenie czasu dostarczenia o 20% zwiększa przepustowość systemu aż o 33%. Każde skrócenie Cycle Time ma przełożenie na cash flow projektu (zmniejsza się koszt developmentu + wcześniej zaczynamy zarabiać).

W trakcie powstawania oprogramowania przez większość czasu zadanie znajduje się w stanie oczekiwania – nikt realnie nad nim nie pracuje. Sprawdź, jak to wygląda w Twoim projekcie – Troy obserwuje, że aktywna praca nad zadaniem to tylko 15% czasu jego faktycznej realizacji.

Prognozowanie projektu czy funkcjonalności to praca z dużą ilością niepewności: jakie były dotychczasowe dane, jaki zespół będzie pracować, jak bardzo zmieni się zakres rzeczy do zrobienia (tak na prawdę, to nawet powinien się zmienić z uwagi na zmienność otoczenia biznesowego).

Użycie średniej wartości Cycle Time daje tylko 50% prawdopodobieństwa co przy pracy nad projektami nie jest wartością wystarczającą. Użycie modelu Monte Carlo pozwala na zwiększenie tego prawdopodobieństwa do wystarczająco dobrego poziomu (przyjmuje się 85% prawdopodobieństwo za właściwy poziom pewności).

Kolejnym krokiem w podejmowaniu decyzji powinna być spojrzenie na biznesowy wpływ prognozy.  Dla danego prawdopodobieństwa mamy określoną datę dostarczenia rozwiązania. Możemy do tego dodać koszt dewelopmentu i koszt opóźnienia (Cost of Dely – ile $ zarobimy lub nie stracimy po wdrożeniu danego rozwiązania). Pozwala to zobaczyć biznesowe konsekwencje różnych scenariuszy i podejmować na tej podstawie racjonalne decyzje. Przykładowo zwiększając siłę zespołu deweloperskiego zwiększają się jego koszty, ale równocześnie zmniejsza się koszt opóźnienia – pytaniem więc jest co daje większe korzyści biznesowe.

Koszt opóźnienia (Cost of Delay) jest dobrą miarą do ustalania kolejności pracy nad funkcjonalnościami lub projektami. (przeczytaj też dlaczego tak nie jest). Chcemy zmaksymalizować cash flow i zminimalizować ryzyko. Koszt opóźnienia składa się z przychodów z funkcjonalności (nowych lub brak ich utraty) oraz kosztów wytwarzania (koszt zespołu i wszelkiego rodzaju opłaty). To na co trzeba zwrócić uwagę – bardzo często jest to pomijane – to zależności pomiędzy funkcjonalnościami, co powoduje, że funkcjonalność A wpływa na koszt opóźnienia funkcjonalności B.

Przeczytaj również notatkę z podobnego wystąpienia Troya Magennisa w która uzupełni Twoją wiedzę z tego wykładu.

Źródło: