Troy Magennis: Prognozowanie z wykorzystaniem danych w praktyce

Co robi Troy? Zmienia matematykę w informacje dla osób zarządzających. Dzięki temu mogą oni podejmować lepsze decyzje w oparciu o dane.

Używając średniej statystycznej lub mediany zawsze tracimy część informacji o tym co się dzieje w obserwowanym zbiorze. Zawsze jest możliwość pojawienia się ekstremalnie niezwykłego wyniku na jednym lub drugim końcu skali po której się poruszamy.

W prognozowaniu statystycznym bierzemy te wszystkie niepewne dane i informacje aby znaleźć możliwe wyniki i określić które z nich są bardziej a które mniej prawdopodobne od innych.

Po prostu chcemy częściej mieć rację niż jej nie mieć 😉

Kiedy zaczynasz pracę nad nowym projektem:

  1. Określ datę startu projektu ponieważ to może być ważny czynnik – potrzebujemy mieć zespół, który może pracować dla danego projektu, zespół musi mieć odpowiednie narzędzia oraz ogólną wiedzę o tym nad czym będą pracować.
  2. Oszacuj ilość rzeczy do zrobienia.
  3. Przyjmij jakąś skalę możliwego podziału rzeczy w backlogu. Rzeczy, które się tam znajdują nigdy nie są jedynymi, które trzeba zrobić w projekcie. Pojawiają się defekty, niektóre zadania trzeba podzielić na kawałki.
  4. Określi ile rzeczy uważamy, że możemy zrobić w jakiejś jednostce czasu, np w ciągu tygodnia.

Po starcie projektu, kiedy zaczynamy mieć prawdziwe dane, możemy zacząć ich używać. Możemy dzięki temu zobaczyć czy idziemy szybciej czy wolniej od początkowej prognozy. Informacja nie musi być przesadnie precyzyjna czy idealna – wystarczy, że będzie lepsza niż zgadywanie lub opieranie się na opiniach. Wcześnie uzyskana informacja, że np. jesteśmy poza planem z realizacją projektu daje możliwość reakcji i dostosowania działań.

W trakcie pracy zdarzają się jednak rzeczy nieprzewidziane, które wpływają na wielkość pracy do wykonania. W procesie przewidywania możemy je również oszacować identyfikując możliwe ryzyka na jakie możemy się natknąć podczas pracy. Możemy symulować różne scenariusze i rozmawiać o ryzyku i jego poziomie, który świadomie akceptujemy. Jednocześnie będzie możliwość odkrywania i poznawania zależności pomiędzy ryzykami oraz tym co mamy do zrobienia.

Posiadając te informacje (nawet oparte na założeniach) możemy rozmawiać o koszcie opóźnienia i sposobach działania, które go zminimalizują. Przykładowo jeżeli nie dostarczymy jakiejś funkcjonalności na czas Świąt to stracimy milion dolarów zysku. W związku z tym znając koszt opóźnienia możemy podejmować różne działania by zwiększyć prawdopodobieństwo realizacji na czas.

Estymowanie wszystkich zadań tylko w celu ustalenia daty dostarczenia wydaje się zbyt dużym wysiłkiem w porównaniu z otrzymanymi rezultatami. Jeżeli estymowanie służy zainicjowaniu rozmowy pomiędzy członkami zespołu, jest działaniem jak najbardziej wartościowym.

Podczas trwania projektu powtarzaj estymację w miarę jak się uczysz, ponieważ w projekcie nic nie jest stałe. Dzięki temu możesz przybliżać wyniki do rzeczywistości oraz sprawdzać poprawność przyjętego modelu.

Do przeprowadzania prognozowania wcale nie potrzeba dużej ilości danych – jesteśmy daleko od wymagań Big Data. Tak na prawdę posiadanie 7 próbek powoduje, że prawdopodobieństwo, że każda kolejna będzie w znanym nam już zakresie wynosi 12,5%. W przypadku 11 próbek prawdopodobieństwo pewności wynosi 92% co możemy potraktować jako zdarzenie całkowicie pewne.

Kiedy ktoś pyta: „Na kiedy to będzie?” – odmawiaj odpowiedzi. Pytający najczęściej i tak ma już jakąś datę w swojej głowie. Lepszym podejściem jest próba ustalenia daty startu – ponieważ chcemy ustalić, kiedy musimy zacząć pracę aby mieć jak największe prawdopodobieństwo, że dostarczymy coś na wymagany przez biznes czas. Patrząc na dane możemy rozmawiać o tym co jest a co nie jest możliwe w danym czasie a co za tym idzie ustalać wymaganą kolejność pracy nad zadaniami.

To czego nie wiemy na początku projektu to ilość defektów jakie mogą się zdarzyć. W trakcie prac można zrobić eksperyment i podzielić testujących na 2 grupy. Jeżeli obie znajdą taką samą liczbę i rodzaj błędów – można założyć, że zostało znalezione prawie wszystko. Jeżeli obie grupy znajdą różne ilości lub rodzaje błędów, mówi nam to, że możemy się spodziewać określonej liczby nieodkrytych jeszcze błędów, które „wyjdą” później. Dzięki temu można określić potencjalne występowanie bugów w naszym projekcie, co też jest przydatne podczas aktualizacji projektowych prognoz.

Źródło: