Estymacje dla osób projektujących

Transkrypcja i rozwinięcie wystąpienia w ramach spotkania Wiedza Babel #3: Estymacja projektów i zadań, które odbyło się 31 maja 2019 w Metaforma Cafe w Krakowie.

Zdjęcie z wystąpienia w Metaforma Cafe. Prezentuje Łukasz Tyrała.
📸 Zdjęcie: Ada Bochenek. Więcej zdjęć

O estymacjach będzie z perspektywy osoby projektującej. Nie chcę wchodzić w szerszy kontekst rentowności projektów, efektywności pracy zespołowej, ani innych ról, czy za dużo odwoływać się do agila. Przez lata pracy wiele razu musiałem odpowiadać na pytania o estymacje, robić takie samemu, więc wszystko wynika z doświadczenia – nie oczekujcie zatem inżynierii rakietowej.

Wyobraźcie sobie Waszą oazę spokoju. Ta oaza to Wasza kuchnia, a tam brudne gary, naczynia nieumyte, sztućce, kubki, szklanki, garnki.

Obrazek przedstawia kuchnię z mnóstwem naczyń do umycia poukładanych w stosy

Ile Wam zajmie ich umycie?

Pewnie nasuwa się Wam kilka pytań i kilka odpowiedzi wymijających. Zależnie od tego, jak dużo tych naczyń sobie wyobraziliście, to pewnie mniej więcej wiecie (dużo, to 20 minut, mało to 5 minut), albo wiecie dokładnie (bo zmywarka i wiadomo ile trwa program).

Na obrazku pytanie ile zajmie umycie naczyń. Widać dwa stosy brudnych naczyń. Jeden duży, drugi mały.

W każdym razie, jak odpowiedzieliście ile zajmie, to dokonaliście estymacji. Oszacowaliśmy ile to czasu może zająć. Nawet, jeżeli chodzi o zmywarkę, to jest to szacunek, bo ten program może i jest stały, ale naczynia trzeba jeszcze do zmywarki włożyć, a potem wyjąć. A może już coś do wyjęcia w zmywarce czeka.

Na obrazku otwarta zmywarka, strzałeczka wskazująca na wnętrze zmywarki ma opis Załadować, a druga strzałka Wyładować z grotem za zawnątrz zmywarki.

Całe nasze życie to mniejsze lub większe estymacje – każdy to robi. Naturalne zatem, że w pracy też trzeba.

Natura estymacji

Estymacje, to nie tyle określanie ile coś będzie trwać, co zgadywanie ile może. 

Opera w Sydney miała być w 1963, a była w 1973, i zamiast 7 mln kosztowała 102 mln.

To zgadywanie jest też obarczone ogromnym błędem – przez błędy poznawcze, które nam towarzyszą – nie tylko przez samą niepewność zdarzeń i sytuacji. Błędy poznawcze są jednak kluczowe, bo możemy starać się nimi zarządzić:

  • błąd nadmiernego optymizmu (always look at the bright side of life),
  • egocentryzm atrybucyjny (skłonność do wyjaśniania konsekwencji własnych zachowań w taki sposób, by zwiększyć pozytywne, a zmniejszyć negatywne znaczenie dla własnej samooceny), czyli ja super szybko myję naczynia, a dziś mi nikt nie przeszkadza,
  • błąd normalizacji (przypisujemy katastrofom mniejszą szanse wystąpienia i mniejsze skutki), czyli na pewno nie rozbiję talerza, a jak już do od razu do kosza wpadnie,
  • prawo Brooka (dodawanie ludzi do zespołu, szczególnie na późnych etapach) – 2 osoby przy jednym zlewie to nie optymalizacja, a raczej chaos,
  • prawo Hofstadtera (zawsze będzie dłużej, nawet jak uwzględnisz prawo Hofstadtera).

To znamy już naturę estymacji – zgadywanie, nawet w kwestii mycia naczyń, która jest powtarzalną, częstą, nieskomplikowaną czynnością. 

Dodatkowo my w tym zgadywaniu nie pomagamy, bo dążymy do upraszczania, zaniżania i pomijania negatywnych aspektów pracy.

Pytania o estymację

Dialog: — Ile zajmie Ci umycie naczyń? — A co? — A nic, tak tylko pytam bez powodu…

No dobrze, ale po co w ogóle pytania o estymacje padają? Zwykle odpowiedzi nie dotyczą wprost tego ile czasu osoba projektująca potrzebuje i już. 

Nikt nie pyta, a ile zajmie Ci umycie garów? A co? A nic, tak tylko pytam. Zawsze o coś chodzi.

Hasło wycena, czyli koszt działania i ilustracja z klepsydrą oraz sakiewką pieniędzy i znakiem nierówności między nimi.

Może chodzić o wycenę (określenie kosztu działania). Przeliczenie na hajs. Wycena od estymacji się różni, co chyba najlepiej pokazuje anegdota o Picasso, do którego, podeszła kiedyś kobieta w parku i poprosiła o portret.

Picasso namalował, a Pani zapytała ile. On powiedział tyle, że wydawało się dużo, więc padło pytanie dlaczego tak drogo, przecież trwało to tylko chwilę. Picasso powiedział, że nie, że to trwało całe jego życie.

Rzadko czas, który poświęcamy na coś jest jednoznaczny z wartością. Dziś nie chce mówić o wycenach, a o szacowaniu czasu, bo osoby projektujące rzadko odpowiadają za budżet, ale zawsze odpowiadają za swoją pracę.

Hasło Przetłumaczenie zadań na timeline lub mapę drogową projektu z rysunkiem kolejnych etapów projektu.

➋ Może też chodzić o przetłumaczenie zadań na timeline lub roadmapę. Jak dopasować ze sobą etapy projektu. Kto kiedy i co może robić. Warto o to wszystko zapytać. Wiedzieć, które terminy są nie do ruszenia, kto i kiedy może być dostępny. Bo w projektach najczęściej rzeczy czekają. Więcej czeka niż ich robimy!

Hasło nasze obłożenie pracą w szerszym kontekście: zespołu, firmy, innych projektów lub klientów z abstrakcyjnym rysunkiem pokazującym zbiory kropek.

➌ Albo chodzi o zrozumienie naszego obłożenia w szerszym kontekście (zespołu, firmy, innych projektów i klientów). Wtedy warto pamiętać o innych projektach i zobowiązaniach względem nich. Trzeba umieć powiedzieć czasem nie. Bo ta nowa rzecz najczęściej nie jest jeszcze uruchomiona, te które się toczą już tak. I najczęściej wszystkie cierpią!

Hasło oszacowanie skali problemu z rysunkiem deskorolki i samochodu i znakiem pytajnika między nimi.

Oszacowanie skali problemu, lub skomplikowania zadania, kiedy pyta ktoś, kto sam nie może takiej oceny dokonać. Wtedy szczególnie musimy być otwarci i zrozumiale komunikować naszą pracę.

To co robimy, jak ktoś do nas przychodzi?

Komiks z owcą. Owca siedzi przed ekranem komputera. Z offu pytanie: „Ile potrzebujesz na to zadanie czasu?”. Owca odpowiada: „ASAP.”

Mała dygresja o ASAPie (ang. As Soon As Possible, tak szybko, jak to możliwe). W zasadzie to zawsze nam samym powinno zależeć na robieniu ASAP. To jedyny efektywny sposób pracy.

Wkrada się definicja tego possible – i to kluczowe, ale dążeniem jest do kończenia zadań jak tylko szybko możemy to zrobić. Ważne, żeby mieć kontrolę nad tą ostatnią literką P.

Hasło P, czyli jak tylko to możliwe i rysunek literki P.

Jeżeli działa prawo Parkinsona, czyli, że zadania trwają dokładnie tyl;e ile na nie zaplanowano czau, to oznacza to dysfunkcyjne organizacje i zespoły!

Na rysunku hasła: Zawalony termin, nieoczekiwana sytuacja, niezrozumienie procesu (P), indywidualne interesy oraz skrót ASAP napisany wielkimi literami.

Ale pod ASAP, jako oczekiwaniem zwykle kryje się: zawalony termin, jakaś nieoczekiwana sytuacja, niezrozumienie procesu (czyli kontrolowanie P przez osobę, która nie może ocenić możliwości), indywidualne interesy innych.

Na te pytania trzeba reagować inaczej i musimy pamiętać, że to cześć naszej pracy i część pracy zespołowej.

Starając się odkryć motywację, możemy też dotrzeć do całkiem niemiłych intencji oceny naszych kompetencji ➎ – to lampka ostrzegawcza.

Dialog: — Ile zajmie Ci umycie naczyń? — 30 minut — No, jak bym to zrobił w 20 minut!

Wtedy mówimy, o to super, nie wiedziałem, że można szybciej, czy możecie mi pokazać, jak to zrobić – chętnie Was poobserwuję i nauczę się od Was.

Wymiary estymacji

Żeby móc odpowiedzieć, zrobić estymację, kilka rzeczy musimy brać pod uwagę: ➊ narzędzia, zasoby, pre-rekwizyty, ➋ doświadczenie, ➌ standard (jakość), ➍ proces, ➎ zakres.

Narzędzia, zasoby i prerekwizyty

Hasło narzędzia, zasoby, pre-rekwizyty oraz rysunek szczotki, gąbki, drucianki i płynu do mycia naczyń

To introspekcja i też powalczenie o swoje. Zużytą gąbką dłużej poczyścimy niż nową. Bez drucianki nie umyjemy przypalonego garnka. Żeby umyć wszystkie naczynia, ktoś musi odnieść stosik kubków ze swojego pokoju, albo w trakcie mycia dostaniemy yyy, jeszcze to…

Rysunek obrazujący donoszenie brudnych naczyń, kiedy ktoś inny już kończy zmywanie

Doświadczenie

Doświadczenie, czyli ile razy już to robiliśmy. Jak robiliśmy dużo, to mamy dane historyczne, nawet jeżeli tylko w pamięci (która jest zawodna i pamięta tylko to co dobre – błędy poznawcze!).

Hasło doświadczenie oraz rysunek pokazujący kolejne stosy naczyń, sugerując wiele iteracji

Najciekawsze jest, że wystarczy znać start i koniec zadań w dniach. Nie trzeba nawet umieć nazwać tych zadań, znać ich tylko liczbę (skalę). Tak samo jest z typami projektów. E-commerce na Shopify na kupionej skórce? 3 tygodnie. Od zera? Minimum 6 miesięcy.

Ale też trzeba pamietać, że wiele naszych projektów to zupełnie nowe rzeczy, wtedy i statystyka może być myląca, jak z wyborem Trumpa na prezydenta.

Doświadczenie mnie nauczyło, że nikt nie pracuje 8 godzin. Nie pracujecie nawet 5. Jak ktoś zakłada, że zadanie zajmie 16 godzin, to to nie są 2 dni. To jest tydzień.

W zasadzie, to z doświadczenia uważam, że estymować warto tylko w dniach/tygodniach/miesiącach/kwartałach/latach.

Godziny zarezerwujmy na opis zadań, które robimy już teraz, albo są krytyczne i pilne, na szybko i na już.

Doświadczenie podpowie nam też, najczęstsze błędy w estymacjach: branie pod uwagę tylko dobrych scenariuszy dla interfejsów, zapominanie o zadaniach towarzyszących, nie dawanie sobie czasu na eksplorację, ideację, prototypowanie i testowanie.

Standardy

Hasło standardy oraz dwa talerze. Strzałka wskazuje na brud na spodzie talerza

Standardy są kluczowe, bo każdy ma swoje standardy mycia i podejście do tematu – standardów (jakości) poświęcać nie można, proces jest po to, abyśmy mogli działać zgodnie z naszą pamięcią mięśniową – jak robimy rzeczy inaczej, to rośnie ryzyko, że coś nie wyjdzie. Ja zawsze myję z drugiej strony talerze i na zewnątrz. Tak jak przy projektowaniu zawsze szkicuję. Zostawiam czas na ułożenie się koncepcji w głowie, na krytykę projektową i działanie z innymi. Nigdy nie oddawałem też makiet ze źle rozmieszczonymi elementami, albo niespójnym systemem.

Proces

Przy estymacjach warto zaznaczać, jakie są etapy.

Hasło proces oraz rysunek pokazujący stos brudnych naczyń rozdzielony na kategorie: sztućce, talerze, kubki, garnki

Mi zawsze pomaga zrobienie listy rzeczy, pogrupowanie ich. Tak jak przy zmywaniu porządkuję sztućce do kubka, talerze ze sobą. Tak samo z procesem projektowym. Nie można do niego podchodzić dogmantycznie, ale to jedyna rzecz, nad którą mamy kontrolę, i która jest powtarzalna między projektami – to nasze rusztowanie!

Zakres

Hasło zakres oraz kilka (mały, duży, ogromny) stosów brudnych naczyń

Im większa złożoność projektu tym trudniej go estymować. Kubek: 10 sekund, stos talerzy: 5 minut, garnki: 10 minut, a cały blat to już pewnie półgodziny, i jeszcze będzie trzeba go posprzątać i umyć zlew – tak samo w projektach.

Hasło trudno zgadnąć, który będzie jaki oraz rusunek dwóch identycznych talerzy ze znakiem nierówności między nimi oraz podpisami: talerz (okruszki) pod jednym talerzem i talerz (tłuszcz) pod drugim

Talerz talerzowi nie równy. Taki z okruszkami wystarczy przetrzeć. Taki po pierogach z masłem i śmietaną, który stał całą noc, to pewnie więcej roboty. Ale jak zapiszemy umyć jeden talerz, to pewnie weźmiemy pod uwagę ten optymistyczny przypadek.

Dwa stosy naczyń z zaznaczonymi wszystkimi talerzami z osobna. Mniejszy stos ma podpis: mało talerzy, trudnych do umycia, a duży stos ma podpis: dużo talerzy, łatwych do umycia

To co ważne, to że zakres nie musi oznaczać estymowanie każdego zadania, a bardziej liczbę tych zadań. 

Duży i mały stos talerzy. Oba wzięte w ramkę. Obie ramki mają podpis: zadanie.

Pomyślmy o instrukcjach LEGO, albo IKEA. Szacując czy to dużo składania, wystarczy popatrzeć na ilość kroków. Nie trzeba ich estymować osobno.

Jak z formularzami logowania (prosty) i logowania (ten z yeti). Trzeba  – tu to kwestia standardu, ale też i doświadczenia, dodatkowej mili – jak wypolerowanie kieliszka po wyschnięciu. Teoretycznie estymujemy mycie garów, ale dochodzi też czas na suszenie i polerowanie.

Ilustracja interfejsu logowania. Pe lewej stronie prosty formularz z dwoma polami. Po prawej stronie ten sam formularz z animowanym yeti nad polami, który reaguje na interakcje użytkownika (np. zasłaniając oczy w trakcie wpisywania hasła)
Obrazek autorstwa dsenneff. Zobacz na CodePen

Ten kontekst, czyli nie sama czynność. też czasem daje popalić, o nie wiadomo co tak pod tą stertą talerzy się kryje. Wtedy trzeba sobie zostawi czas na nieoczekiwane rzeczy.

Rozmowy o estymacjach

Kuchnia z zasłoniętymi stosami naczyń i wielkim wypajnikiem

Bez znajomości zakresu, trudno nawet zgadywać. No bo jak Was bym zapytał ile Wam zajmie mycie garów, a nie wiadomo ile ich jest, to nic mi nie powiecie! A w złożonych projektach tego od siebie oczekujemy.

Hasło: ASAPy? Dopytujemy, pogłębiamy, jesteśmy ciekawi

1. Na ASAPy i inne pilne rzeczy zawsze reagujemy dopytując co potrzebne, bo może potrzebna jest filiżanka, a nie całe gary umyte. Nie reagujmy z pozycji obronnej. Opowiadajmy dlaczego, jakie są konsekwencje.

Hasło: Definition of done na jednej połowie slajdu i paint done na drugiej

2. Definition of done nie wystarcza – Brené Brown mówi o paint done. Dopytujmy o to! Umyte gary, to co innego niż porządek w kuchni, bo przychodzą znajomi i chcemy, żeby było czysto, bo przyniosą składniki na pizzę.

Hasło: Zawsze informujemy, kiedy estymacje się nie sprawdzają

3. Trzeba informować, jak nie możemy dowieźć. Ale to trudne, sam wiele razy w karierze stawałem przed takim zadaniem. Wtedy zjada nas wstyd, że nie dowozimy, że źle powiedzieliśmy. Zwykle jednak, to dlatego, że nam zależało.

Na dole slajdu: Cele projektu, komunikacja, standardy. Na górze slajdu: Modelowanie, MVP, MVF…

4. Każdy projekt ma jakieś ograniczenia. Budżetowe, czasowe, zasobowe. Wtedy najważniejsze jest: pamiętanie o celach projektów, informowaniu o koniecznych rzeczach i trzymaniu się standardów. Ale też modelowanie zakresem. Wtedy właśnie trzeba podejmować decyzje o Minimum Viable Feature. To powinna być dyskusja. To umyjemy tylko talerze, a kubki wyrzucimy. Ale uwaga! To co innego niż, a to nie myjmy płynem (nie róbmy researchu). Na krótką metę to się sprawdza, ale zawsze wybucha w twarz.

My i estymacje

1. Wstyd – pamietajmy, żeby nie wstydzić się, że coś źle estymowaliśmy – róbcie listę założeń na start, notujcie zmiany w trakcie – nie żeby się bronić, tylko żeby zapewnić sobie spokój dyskusji o zmieniających się estymatach.

Hasło: Nietrafionych estymacji nie trzeba się wstydzić

2. Perfekcjonizm – standardy i dokładność to jedno, ale perfekcjonizm to zło. Jak jest ociekacz, to nie każde naczynie trzeba jeszcze szmatką wypolerować! Niektóre warto, dla efektu dodatkowej mili, ale nie wszystko.

Hasło: Perfekcjonizm zawsze działa na niekorzyść

3. Delegując zadania, nie możemy mówić innym ile im ma zająć – tak jak byśmy nie chcieli tego od innych. Mój syn często mówi, ej, to nie sprawiedliwe, że Ty myjesz sobie naczynia, a ja muszę sprzątać – to ja mówię, dobra to się zamieńmy, ale mycie garów zajmie mi 20 minut, a sprzątanie 5. Chcesz? Nie.

4. Nie poddawajmy się ciśnieniu robić nie myśleć. Einstein mówił, że woli poświęcić 95% czasu na myśleniem problemie, a 5% na rozwiązanie, ale to nie oznacza, że designer ma mieć 95% czasy w projekcie a deweloper 5%!

Cytat z Alberta Einsteina: If I had an hour to solve problem I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solution.

5. No i pamiętajmy, że estymacje to nie teleturniej, a praca zespołowa. Zespołowe zgadywanie.

Hasło: estymacje to nie teleturniej, a praca zespołowa. Jako ilustracja rysunek koła fortuny.
Obrazek autorstwa: Germanname1990 – Praca własna, CC BY-SA 3.0

Materiały

A na koniec garść materiałów:

  1. O estymacjach według kadry zarządzającej
  2. Estymacje rzedko są tylko, żeby poznać tylko czas, dlatego warto myśleć o nich w kontekście takich narzędzi jak RICE albo MoSCoW.
  3. Artykuł Pawła Brodzińskiego, o tym jak w Lunar Logic podchodzą do estymacji, dlaczego doświadczenie (dane historyczne się przydają), jako to jest z tym pokerem agilowym – super ważne i poza estymacjami w programowaniu, bo talerz talerzowi nie równy.
  4. Lista błędów poznawczych.
  5. Śledzenie statusu projektów z użyciem hill charts – od Basecampa.
  6. Paint done vs definition of done.
  7. Dan Mall rozmawia z Jeffem Veen o wycenianiu proijektów.
  8. Ta prezentacja, jako PDF. (Do golądania, nie do prezentowania, oraz rysunki sa moje, więc zapytaj przed ich wykorzystaniem.)

Published by Łukasz Tyrała

I think, draw and code/write. In loops.