Jak wygląda problem estymacji w praktyce?

Parę pytań na start

Spróbuj odpowiedzieć na poniższe pytania zanim przejdziesz dalej. Zastanów się nad każdym z nich około 10 sekund. 

  1. Ile czasu zajmie Ci zaparzenie czarnej herbaty dla czterech osób w Twoim mieszkaniu?
  2. Ile czasu zajmie mi przejście do kuchni z pokoju w moim mieszkaniu?
  3. Ile pizz trzeba zamówić na małe spotkanie dla 20 osób?
  4. Ile czasu zajmie mi zrobienie specjalnej herbaty typu Touareg dla 4 osób?
  5. Ile czasu zajmie remont generalny kuchni w Twoim domu od momentu podjęcia decyzji do zakończenia?
  6. Ile czasu zajmie Ci zbudowanie z klocków Lego budynku o wielkości prawdziwego budynku?

Dlaczego Cię o to poprosiłem? Na własnej skórze poczujesz, dlaczego estymacja w praktyce jest tak trudna - a resztę artykułu będziemy rozpatrywać przez pryzmat tych pytań. 

Przyjrzyjmy się bliżej odpowiedziom na te pytania.

Pytania oczywiste

Dwa pierwsze pytania czerpią bezpośrednio z naszej wiedzy o świecie i z tego co wiemy o rzeczywistości. Co więcej, są to rzeczy proste, bardzo intuicyjne dla nas jeśli daną czynność wykonywaliśmy choć raz.

Najprawdopodobniej nie masz żadnych problemów z odpowiedziami na te pytania. 

  1. Zagotowanie wody + wrzucenie torebki + 3 minuty zaparzania. Najpewniej około 5-10 minut.
  2. Nie wiesz jak wygląda moje mieszkanie, ale na pewno nie mieszkam w wielkim pałacu. Poniżej minuty.

Pytania wymagające analizy

Odpowiedzi na dwa kolejne pytania nie są już oczywiste, ale da się je wydedukować – wymaga to jednak pewnej analizy i znajomości domeny w której się poruszam.

  1. Spotkanie dla 20 osób. Celem pizzy na spotkaniu nie jest to, by ktoś się najadł a to, by sobie pojeść.
    1. Zatem można założyć 2 kawałki na osobę. 
    2. Niech przeciętna pizza w miejscu, w którym zamawiam jest krojona na 8 kawałków.
    3. Policzmy: 20*2/8 = 5 pizz. Jeśli ważnym jest to, by każdy zjadł co najmniej 1 kawałek, 6 pizz (by była rezerwa).
  2. Możesz nie mieć pojęcia, co to jest herbata typu Touareg, ale google pomoże. Internet pokazuje, że to jest herbata zielona parzona na wywarze z mięty.
    1. Tak więc, wpierw zaparzam miętę. 96 stopni, 8 minut.
    2. Następnie, czekam aż woda wystudzi się do 70 stopni. Od wrzątku będzie to około 10 minut.
    3. Następnie, zalewam zieloną herbatę Gunpowder wywarem z mięty o temperaturze 70 stopni. Zaparzam około 3 minuty.
    4. Skończone. Czyli: ~5 minut na podgrzanie wody, ~8 na zaparzenie mięty, ~2 dodatkowe na odczekanie i kolejne ~3 na zaparzenie Gunpowder. W sumie: około 20 minut.

Pytania wymagające próbkowania i testów

Odpowiedzi na dwa ostatnie pytania nie są możliwe do sensownego oszacowania. 

Tu nie wystarczy sama analiza. Zbyt dużo rzeczy jest poza naszą kontrolą, zbyt dużej ilości rzeczy po prostu nie wiemy. Za dużo trzeba przetestować i sprawdzić. Co gorsza, wielu rzeczy „nie wiemy, że nie wiemy” i dowiemy się czego nie wiemy dopiero podczas robienia rzeczy.

  1. Co to znaczy „remont generalny” kuchni? Załóżmy, że skupiam się jedynie na jednym elemencie – wymianie kafelków w podłodze (zakładam, że masz kafelki).
    1. W jakim okresie będzie dostępna ekipa budowlana? Dopóki nie zapytam, nie wiem.
    2. Ile czasu zajmie pozyskanie odpowiednich kafelków?
    3. Kiedy mogę wyłączyć kuchnię z użytkowania przez, powiedzmy, miesiąc bez bardzo negatywnych konsekwencji dla rodziny? 
    4. Innymi słowy, bez sprawdzenia dużej ilości rzeczy nie jestem w stanie oszacować, czy całość remontu kuchni zajmie 3 tygodnie czy pół roku.
  2. Jakie problemy mogą pojawić się przy budowaniu budynku w skali 1:1 z klocków Lego?
    1. Czy klocki Lego poradzą sobie z naprężeniami wynikającymi z tego, że będzie tam mnóstwo kilogramów klocków? Zgodnie z internetem, dało się zbudować wieżę o wielkości 34 metrów, ale nie miała pustych przestrzeni w środku.
    2. Czy struktura budynku w ogóle może być taka sama gdy jest budowana z Lego jak gdy jest budowana z normalnych materiałów? Czy trzeba będzie innej konstrukcji?
    3. Co z fundamentami? Czy są w ogóle potrzebne?
    4. Duży budynek złożony z klocków Lego nie ma nic wspólnego z małymi konstrukcjami złożonymi z klocków Lego. Skala całkowicie zmienia typ wyzwań. Bez sprawdzenia i prototypowania nie jesteśmy w stanie nawet odpowiedzieć na pytanie „czy się da”.

Nie przez przypadek podzieliłem te pytania na trzy kategorie. Te kategorie pochodzą z narzędzia opracowanego przez Dave’a Snowdena o nazwie Cynefin Framework.

Przyjrzyjmy się mu bliżej.

Cynefin – czyli typy problemów

Cztery kategorie

Dave Snowden podzielił problemy na cztery kategorie:

  1. Oczywiste, które są nam dobrze znane i można je łatwo przekształcić w procedury. Przykład: wystawianie faktur. Jest to coś wymagającego precyzji, ale powtarzalne.
  2. Skomplikowane, które są większe i wymagają analizy, ale można je zdekomponować i opanować. Analiza pomaga w opanowaniu problemu i znalezieniu zależności. Przykład: budowanie szopy.
  3. Złożone, które są gigantyczne albo mają liczne zależności – nie wiemy, czego nie wiemy, więc nie pomoże nam sama analiza. Co ważniejsze, w Złożonych problemach otoczenie cały czas się zmienia. Tak więc nadmiar analizy jest szkodliwy – odpowiedź mogła się przedawnić. Przykład: wypuszczenie nowego produktu na rynek – bez przetestowania MVP na grupie docelowej nie wiemy, czy to w ogóle się uda.
  4. Chaotyczne, które są niebezpieczne i wymagają natychmiastowej reakcji. Np. awaria przez którą tracimy 1 mln dolarów na godzinę czy pożar w budynku. Najpierw działamy by usunąć problem, potem próbujemy zrobić to dobrze.

Oczywistości - wiemy co wiemy, statyczne, dobre praktyki. Skomplikowane - wiemy czego nie wiemy, stabilne, analiza i dekompozycja, wiedza ekspercka. Złożone - nie wiemy czego nie wiemy, płynne i zmienne, prototypy, adaptacja i hipotezy. Chaotyczne - nie jesteśmy w stanie się dowiedzieć, burzliwe, szybkie działania, adaptacja i konieczność opuszczenia niebezpiecznego obszaru.

Cynefin framework, źródło: rysunek własny

Cztery kategorie a pytania z początku

Czwartą kategorię pomijam w perspektywie estymacji (bo gdy problem jest typu Chaotycznego trzeba działać, a nie estymować), ale trzy pozostałe mapują się na zadane przeze mnie pytania:

  1. Ile czasu zajmie Ci zaparzenie czarnej herbaty dla czterech osób w Twoim mieszkaniu? – Oczywiste (wiesz jak działa zaparzanie herbaty)
  2. Ile czasu zajmie mi przejście do kuchni z pokoju w moim mieszkaniu? – Oczywiste (mimo niewiedzy o moim mieszkaniu, bo wiesz jak wyglądają mieszkania)
  3. Ile pizz trzeba zamówić na małe spotkanie dla 20 osób? – Skomplikowane (dekompozycja pomaga to opanować)
  4. Ile czasu zajmie mi zrobienie specjalnej herbaty typu Touareg dla 4 osób? – Skomplikowane (analiza pomaga to opanować)
  5. Ile czasu zajmie remont generalny kuchni w Twoim domu? – Złożone (bez prototypowania, analizy i kilku telefonów nie da się tego oszacować)
  6. Ile czasu zajmie Ci zbudowanie z klocków Lego budynku o wielkości prawdziwego budynku? – Złożone (bez analizy, prototypowania i sprawdzenia jakie są problemy nie da się tego oszacować)

Nie umiemy się zgodzić w której kategorii jest Problem

Ciekawostka – jednym z zarzutów wobec Cynefin jest to, że trudno określić czy problem jest Oczywisty, Skomplikowany czy Złożony. Snowden nigdy nie odpowiedział na to pytanie – i nic dziwnego:

  • Dla mnie stworzenie szkolenia ze wzorców projektowych w C# jest problemem Oczywistym (robiłem to wielokrotnie, mam to sproceduralizowane). Dla większości ludzi nie siedzących w tym temacie jest to problem Skomplikowany lub Złożony.
  • Dla mnie napisanie komponentu w React jest dzisiaj problemem Skomplikowanym. Dla każdego doświadczonego frontendowca jest to problem Oczywisty.

W zależności od tego jakie ludzie mają doświadczenia i z czym się spotkali będą klasyfikować problemy inaczej – i będą mieli rację. Da się jednak wyprowadzić ogólną, przybliżoną heurystykę jak na to patrzeć – pamiętaj jednak, by brać pod uwagę swoją wiedzę i doświadczenie.

  • Jeżeli mam zależności których nie mogę kontrolować i które bardzo zmieniają mi sytuację, jest to problem Złożony.
  • Jeżeli otoczenie się szybko zmienia i muszę się adaptować, jest to problem Złożony.
  • Jeżeli nie wiem dużej ilości rzeczy o otoczeniu i sporo energii muszę włożyć w poszukiwania, jest to problem Złożony (np. znajdowanie bugów).
  • Jeżeli problem jest przytłaczająco wielki i nie mam pojęcia jak go ruszyć / co może pójść nie tak – jest to problem Złożony.
  • Jeżeli problem jest duży, ale wszystko jest pod moją kontrolą – jest to problem Skomplikowany.
  • Jeżeli problem jest duży, ale rozwiązanie jest stosunkowo powtarzalne – jest to problem Skomplikowany lub Oczywisty.
  • Jeżeli dokładnie wiem co zrobić i jest to typowa sytuacja, jest to problem Oczywisty.

Cynefin a estymacja w projektach

Jak estymować rzeczy Oczywiste?

Dane historyczne. Wiedza o świecie. Rzeczy podobne do tych, które robiliśmy. Zadania analogiczne z przeszłości. Z doświadczenia, niewiele osób ma problemy z estymowaniem rzeczy Oczywistych.

Kluczem jest właściwe skategoryzowanie problemu – do jakiego innego Oczywistego problemu ten jest podobny. „Ile przeciętnie zajmuje mi parzenie czarnej herbaty”, „Ile zwykle czasu zajmuje napisanie testów jednostkowych dla bezstanowych funkcji przy znanej dokumentacji”.

Jak estymować rzeczy Skomplikowane?

Pozwól, że posłużę się przykładem.

Prowadziliśmy z Bartkiem warsztat z motywacji i naprawy symulowanego dysfunkcyjnego zespołu. Mieliśmy do dyspozycji 3 godziny.

Wiemy, że chcemy wprowadzić trzy ćwiczenia do tego warsztatu. Ale jak upewnić się, że zmieścimy się w czasie?

Wspólnie zdekomponowaliśmy 3 godziny warsztatu na następujący zakres:

  1. Wstęp (10 min)
  2. Pokazanie Sytuacji z dysfunkcyjnym zespołem (10 min)
  3. Blok Total Motivation
    1. ToMo z przykładem od nas (10 min)
    2. ToMo – oni diagnozują Sytuację; my pomagamy prywatnie (20 min)
  4. Blok – poszerzenie o Sources of Influence
    1. Sources of Influence z przykładem od nas (10 min)
    2. SoI – oni diagnozują Sytuację; my pomagamy prywatnie (20 min)
  5. Blok – poszerzenie o Nagrody
    1. Nagrody z przykładem od nas (10 min)
    2. Nagrody – oni wprowadzają interwencje: Nagrodami, Akcjami jak i Usuwaniem Barier; całość do kupy (60 min)
  6. Refleksja całościowa – widzieliście coś takiego w projektach? (10 min)
  7. Co z tego dla Was? (15 min)
  8. Podsumowanie (10 min)

Analiza przykładu

Nie jesteśmy w stanie wiarygodnie wyestymować „ile czasu zajmie nam warsztat z motywacji”, ale jesteśmy w stanie bez problemu oszacować „ile czasu zajmie poszczególny klocek”. Po zsumowaniu tych elementów osiągnęliśmy około 3 godzin. Jako, że mamy tam wbudowane bufory – mamy wystarczającą płynność działania.

Dlaczego warsztat jest problemem Skomplikowanym a nie Złożonym? Przecież nie mam kontroli nad tym, jak szybko przyswajają wiedzę uczestnicy?

Ponieważ to my – prowadzący – decydujemy o czasie poszczególnych elementów warsztatu. Jest to zależność, ale jest to zależność pod naszą kontrolą. Najwyżej nie osiągniemy założonego celu w zakresie jednego z modułów.

Jakie elementy analityczne wykorzystaliśmy

Analiza. Wiemy, co chcemy osiągnąć tym warsztatem i co musimy zrobić, by to się stało.

Dekompozycja. Rozbicie problemu Skomplikowanego do problemów Oczywistych. Wykrycie zależności, o których nie wiemy (w powyższym przypadku – nie kontrolujemy prędkości przyswajania uczestników warsztatu, więc tam mamy większą nieoznaczoność niż w rzeczach pod naszą kontrolą).

Dobre praktyki i wiedza ekspercka. Wiemy, że wpierw my musimy pokazać mechanizm a potem oni muszą wykonać ćwiczenie. Wiemy, że jeśli pomagamy prywatnie każdej grupie, to zajmie to mniej czasu niż jeżeli poprosimy o podsumowanie publiczne.

Wiedza ekspercka. Wiemy, ile zajmie przeprowadzenie ćwiczenia i ile my musimy wyjaśniać.

Jak estymować rzeczy Złożone?

Pozwól, że zacznę od dowcipu.

Przychodzi manager do programisty i prosi go o wyestymowanie ile czasu zajmie mu napisanie programu takiego jak Microsoft Word. Programista w odpowiedzi prosi Managera, by ten wyestymował, ile czasu zajmie mu rozładowanie samochodu.

  • Programista: ile czasu zajmie rozładowanie samochodu?
  • Manager: około 10 minut
  • Programista: samochód jest wypełniony piaskiem
  • Manager: około 30 minut
  • Programista: to jest ciężarówka typu Kamaz
  • Manager: około 3 godzin
  • Programista: nie masz łopaty
  • Manager: …około dnia…
  • Programista: Kamaz jest pod wodą, pod zamarzniętym jeziorem, 10 kilometrów od magazynu
  • Manager: daj mi spokój z tymi durnymi gierkami, pytałem Cię tylko o to byś wyestymował jak długo zajmie Ci napisanie programu takiego jak Microsoft Word… czy to takie trudne podać mi liczbę?

To jest najlepsza odpowiedź jaką znam na pytanie „jak estymować rzeczy Złożone”. 

Czemu estymacja rzeczy Złożonych jest taka trudna

Wszystko zależy od tego:

  • Po co nam odpowiedź na to pytanie (co zrobię z tą odpowiedzią)
  • Jakie mamy zależności
  • Co dokładnie mamy zrobić
  • Jako, że „nie wiemy, czego nie wiemy” – jak bardzo nas to, czego nie wiemy ugryzie

Innymi słowy - dopóki nie zaczniemy działać, nie jesteśmy w stanie tego dobrze wyestymować. Z uwagi na zależności nawet dane historyczne nam nie zawsze pomogą – remont kuchni w chwili, w której mamy sensowną ekipę remontową potoczy się zupełnie inaczej niż remont z niekompetentną ekipą która dodatkowo zrezygnuje z pracy w połowie remontu.

Istnieją specjalne techniki obliczeniowe które pozwalają nam na przybliżone określenie ile nam coś zajmie (opisane m.in. w książce Software Estimation Steve’a McConnella) ale wszystkie estymacje rzeczy Złożonych są skazane na ogromną nieoznaczoność. 

Jeżeli nie masz zdecydowanych korzyści z estymacji rzeczy Złożonych, najlepiej po prostu nie marnować na to czasu.

Jeśli tego bardzo potrzebujesz – każdy przypadek estymacji będzie zupełnie inny, co wynika właśnie z zależności, zmiennego otoczenia i tego do jakiej decyzji potrzebna Ci ta estymacja. Wiedz jednak, że ta estymacja będzie droższa i mniej precyzyjna niż w wypadku problemów Oczywistych lub Skomplikowanych.

Jak tego wszystkiego użyć?

Cynefin pokazuje, że nie ma możliwości użycia jednej procedury do rozwiązywania wszystkich problemów: 

  • Oczywistości powinno się proceduralizować i automatyzować. Na pewno nie powinno się poświęcać za dużo czasu na analizę ani – tym bardziej – na prototypy.
  • Dla rzeczy Skomplikowanych szukamy frameworków, dobrych praktyk lub wiedzy eksperckiej. Na pewno nie powinno się rzucać na problem z optymizmem.
  • Rzeczy Złożone wymagają próbkowania i sprawdzenia bojem; nie ma co zaplątać się w nadmiar analizy – acz trochę analizy się przyda.
  • Rzeczy Chaotyczne wymagają natychmiastowego działania.

To sprawia, że nie da się zbudować jednej procedury dla wszystkich typów zadań w projekcie, jeśli nie będziemy po drodze mieli podziału zadań na różne kategorie.

Jak odróżnić rzeczy Skomplikowane od Złożonych? W wypadku Złożonych mamy albo przytłaczającą skalę albo zależności (i zależności tych zależności). Skomplikowane – więcej analizy. Złożone – więcej próbkowania, sprawdzania i adaptacji.

Teraz – różnica między rzeczami Oczywistymi i Skomplikowanymi. Najpewniej zauważyliście, że rzeczy Oczywiste mają dużą zgodność estymacji z faktycznym wynikiem a rzeczy Skomplikowane niekoniecznie.

Tak więc – jeśli mamy coś większego, warto podzielić to na mniejsze części. Dekompozycja. W ten sposób jeżeli mamy kontrolę nad otoczeniem i nad sytuacją, możemy osiągnąć dużo lepsze estymaty – i dużo lepsze zrozumienie sytuacji.

Dekompozycja ma jeszcze jedną zaletę – można zdekomponować problem Złożony by odkryć zależności i zobaczyć czy nie da się gdzieś zrównoleglić pracy. Np. jeśli czekasz na odpowiedź od klienta w sprawie X, możesz być w stanie pracować nad Y.

Podsumowując

Kiedy estymacja jest precyzyjna? Gdy dotyczy rzeczy Oczywistych lub zdekomponujemy rzeczy Skomplikowane na Oczywiste i zsumujemy wyniki (uwzględniając bufory).

Kiedy estymacja jest nieprecyzyjna? Gdy: 

  • nie kontroluję zależności
  • gdy otoczenie się przesuwa
  • im większa skala i im większa złożoność, tym mniejsza szansa, że moja estymacja będzie poprawna 
  • z każdym dziesięciokrotnym zwiększeniem skali budujemy nowy system, bardziej Złożony niż poprzedni

Cynefin pokazuje, że nie wszystkie problemy jestem w stanie rozwiązać przy użyciu dogłębnej analizy. W wypadku problemów Złożonych trzeba przeprowadzić pobieżną analizę i wstępną dekompozycję, a potem się adaptować do tego co dostaniemy po odpowiedzi systemu.

Sama estymacja to coś więcej niż „ile czasu zajmie Ci napisanie tego zadania”. Estymacja to narzędzie, dzięki któremu jestem w stanie prowadzić szkolenia kończące się o terminie lub dzięki któremu wiem, czy mogę wziąć zlecenie od klienta.

Dekompozycja jest techniką, dzięki której jestem w stanie rozbić Skomplikowane problemy na coś, z czym jestem w stanie pracować – i rozbić problemy Złożone by ujawnić ukryte zależności.

Samemu stosuję te techniki bardzo często (co, mam nadzieję, pokazują przykłady). Wierzę, że przy odrobinie praktyki Tobie także się przydadzą.

Powodzenia!