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.
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.
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).
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.
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ę
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.
➊ 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ę.
➋ 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!
➌ 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ą!
➍ 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?
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.
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!
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.
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
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…
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!).
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
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.
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
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.
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.
To co ważne, to że zakres nie musi oznaczać estymowanie każdego zadania, a bardziej liczbę tych zadań.
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.
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
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.
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.
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ę.
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.
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.
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.
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%!
5. No i pamiętajmy, że estymacje to nie teleturniej, a praca zespołowa. Zespołowe zgadywanie.
Materiały
A na koniec garść materiałów:
- O estymacjach według kadry zarządzającej
- Estymacje rzedko są tylko, żeby poznać tylko czas, dlatego warto myśleć o nich w kontekście takich narzędzi jak RICE albo MoSCoW.
- 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.
- Lista błędów poznawczych.
- Śledzenie statusu projektów z użyciem hill charts – od Basecampa.
- Paint done vs definition of done.
- Dan Mall rozmawia z Jeffem Veen o wycenianiu proijektów.
- Ta prezentacja, jako PDF. (Do golądania, nie do prezentowania, oraz rysunki sa moje, więc zapytaj przed ich wykorzystaniem.)
lukasz.co 