Dlaczego programiści nie lubią szacować czasu wykonania zadania?

Do zadania tytułowego pytania i próby udzielenia na nie odpowiedzi skłonił mnie ten artykuł: https://wedlugplanu.pl/zarzadzanie-projektami/noestimate-manifest-wycen/ , w którym autor odnosi się do idei #noestimate, czyli postulatu porzucenia wyceny zadań, Dla wielu osób zabrzmi to pewnie, jak zgrzyt paznokci na tablicy i wierutna bzdura, ale prawdę mówiąc coś jest moim zdaniem na rzeczy.

Programiści oczywiście wiedzą, czemu nie lubią wyceniać zadań. Wydaje mi się jednak, że osoby z biznesu mogą nie do końca rozumieć tę awersję do deklarowania szacowanego czasu wykonania pracy…

Wstyd i poczucie winy

Zacząłbym od tego, że spora część programistów jest dobrymi, pracowitymi ludźmi. Taka osoba nie lubi rzucać słów na wiatr. Jeśli mówi, że coś zajmie tydzień, a okazuje się, że nie da się go wykonać, odczuwa negatywne emocje. Wstyd, poczucie braku wymaganych umiejętności, wrażenie, że się kogoś zawiodło. Rozwiązania w tej sytuacji są dwa – odmowa udzielania kolejnych wycen lub ich zawyżanie.

Zadanie niemożliwe

Fundamentalny problem polega na tym, że w wielu przypadkach prawidłowe wykonanie wyceny, oszacowanie czasu wykonania zadania jest po prostu niemożliwe.

Kiedy ktoś zapyta nas, ile czasu zajmie nam przygotowanie kotleta schabowego, jesteśmy w stanie odpowiedzieć w miarę konkretnie. Zakładamy przy tym, że mamy wszystkie składniki i nic się nie wydarzy oraz że już kiedyś to robiliśmy.

Zwróćmy uwagę na te założenia. Zastanówmy się, co się dzieje, gdy nie są spełnione.

Zaczynamy pracę nad schabowym. Oszacowaliśmy ją na 30 minut. Otwieramy lodówkę i okazuje się, że mięso jest zepsute. Idziemy więc do mięsnego. Po 45 minutach wracamy z mięsem. Mówimy sobie – powinniśmy o tym pomyśleć. Nauczeni na błędzie rozglądamy się po kuchni i zastanawiamy się, co jest nam niezbędne. Tłuszcz, patelnia, kuchenka, panierka, tłuczek, deska, jajka. Wydaje się, że wszystko mamy. Zaczynamy raz jeszcze. I nagle okazuje się, że mimo dobrego terminu przydatności do spożycia wszystkie cztery jajka, jakie mieliśmy w domu są zepsute. Oczywiście powinniśmy mieć ich więcej, może dwie paczki, myślimy. Idziemy do sklepu i kupujemy jajka. „Zmarnowaliśmy” kolejne 30 minut, a jeszcze nie zaczęliśmy smażyć mięsa…

Mamy nowe jajka. Mamy mięso. Mamy wszystko. Ubiliśmy mięso tłuczkiem, obtoczyliśmy w panierce. Zaczynamy smażyć. I nie wierzymy własnym oczom. Wyłączono prąd.

Na szczęście tylko na 15 minut. W końcu udało się coś ugotować. Z początkowych 30 minut zrobiło się jednak… ponad dwie godziny.

Rzetelna wycena

Zakładając, że chcielibyśmy wykonać rzetelną wycenę musielibyśmy mieć:

  • kompletną specyfikację zadania, bez żadnych niespodzianek i improwizacji
  • doświadczenie w wykonywaniu analogicznych zadań
  • znamy narzędzia i zależności oraz system
  • wszystkie nasze zależności już istnieją i są niezawodne

Doświadczenie uczy, że nie tylko nie wszystko powyższe udaje się spełnić, lecz zwykle wręcz nic. Co więcej zrealizowanie tak rzetelnej wyceny zajmuje ogrom czasu i jest po prostu dysfunkcjonalne.

Współczynnik fi

Patrząc na powyższe problemy próbujemy zatem wycenę zawyżyć. Niektórzy mnożą przez dwa, inni przez współczynnik fi, czy inne pi albo stałą Plancka. Nic to nie daje, bo jak nieskończoność mnożona przez stałą daje nieskończoność, tak iloraz – czy choćby iloczyn – niepewności przez dowolną liczbę również równa się niepewności.

Czy jest na tym bożym świecie zadanie estymowalne?

Rozkładając już ręce w żałosnym geście zadajemy sobie powyższe pytanie. I w zasadzie odpowiedź brzmi: tak. Owszem, w wielu scenariuszach da się sensownie wyceniać. Kiedy robimy kolejną stronę wizytówkę w tej samej technologii, kiedy po edycji produktu tworzymy feature edycji kategorii w tym samym projekcie itp.

Niestety jednak sposobu wyceny projektów nowych, nowych feature’ów, implementacji w nieznanych frameworkach, wykonywanych przez nowo powstałe zepoły – nie ma. Po prostu nie ma.

Po co zatem szacować?

Na koniec odniosę się znów do wspomnianego na początku artykułu. Wyjaśnia on dobrze do czego – mimo ich pozornego braku logiki i ich niedokładności – potrzebne są wyceny. Warto rzucić okiem: https://wedlugplanu.pl/zarzadzanie-projektami/noestimate-manifest-wycen/

W wielkim jednak skrócie, by nie powtarzać niepotrzebnie argumentów, potrzebne są do planowania biznesu, budżetowania i alokacji zasobów. Możemy się w wycenie pomylić, choćby i dwukrotnie, ważne tylko, by nie o rząd wielkości, by z dwóch godzin nie zrobiło się godzin dwieście. Warto o tym pamiętać zarówno będą programistą, jak i zarządzając projektem.

Comments

  1. Fundamentalny błąd w przygotowaniu merytorycznym.
    1. Ile czasu zajmuje dojazd z Łodzi do Warszawy?
    Tu padną rozmaite odpowiedzi. Ale załóżmy, że jest bardzo ważne spotkanie, punktualnie o 09:30 w poniedziałek. O której wyjechać? Zależy czym. I zależy gdzie jest to spotkanie, bo trzeba zaparkować, itd. A co jeżeli będzie korek? A jeżeli pociąg się zepsuje? No właśnie… NIGDY NIE MAMY PEWNOŚCI. Nigdy. Możemy jedynie dokładać bufora, czasem do absurdu.

    2. Ale tu nie o to chodzi. Inżynier musi wiedzieć ile czasu zajmie koparce wykopanie wykopu. MUSI I JUŻ. A co jeśli koparka się zepsuje? A co jeśli tam będzie zakopany magazyn amunicji? A nico, to są nieprzewidywalne utrudnienia. Jeżeli zaś jajek nie ma, a mięso jest zepsute, to znaczy, że zamiast pracowników mamy przedszkolaków, a zamiast koparki jest atrapa. Jednak inżynier opiera się na pewnych założeniach, zaś kierownik budowy ma wynająć koparkę, a nie atrapę. I dlatego można oszacować czas budowy osiedla mieszkaniowego. Naprawdę. Można też oszacować czas projektu nowej linii produkcji pancerzy czołgu T-72. Wystarczy się na tym znać.
    O!
    I tu jest sedno. Trzeba się znać.
    Informatyka nie jest tutaj wyjątkiem.

    1. @SRSK – zasadniczo mogę się zgodzić co do setek nieskomplikowanych, powtarzalnych projektów typu excel/CRUD przy założeniu że masz w pełni wyszkolony zespół. Tutaj jest inżynieria.

      Praktyka pokazuje, że mało jest chętnych i wyszkolonych osób do pracy w takich projektach, więc pracuje się z tymi, którzy są. Bardziej kompetentni i obrotni już dawno pracują na własnej działalności i realizują bardziej skomplikowane projekty, które nie są już tylko „linią produkcyjną”, gdzie klient chce zrobić coś innowacyjnego aby przegonić konkurencję.

      Co w przypadku setek projektów RnD(-ish), gdzie „budujesz narzędzia, z materiałów których jeszcze nie wynaleziono, na planecie bez infrastruktury, do statku kosmicznego, którego jeszcze nikt nie zaprojektował”.

      To nie jest budowa mostu, która zawsze będzie podlegał tym samym prawom.

      1. I tu jest sedno. Piszesz o rakiecie kosmicznej, tylko że znakomita większość inżynierów zajmuje się budową domów, mostów, koparek (bo inżynier budowlaniec), czy suszarek do włosów.
        I podobnie jest z programistami – większość pracuje w tzw. biznesie, czyli nie zajmuje się zimną fuzją, ani podstawami systemów operacyjnych, a właśnie aplikacjami do rezerwacji biletów, kupowania bułek i udzielania kredytów. Taka robota.

        Podkreślam: tysiąc inżynierów przy budowie mostów na drogach gminnych (i suszarek) nie przeczy istnieniu grup zajmujących się tworzeniem rakiet, ale tych drugich jest naprawdę znacznie mniej.

        1. Korekta: miało być inżynier NIE RÓWNA SIĘ budowlaniec, ale znaki nierówności wcięło.
          Trudno. I tak dobrze, że wycięło wszystkie przekleństwa 😉
          (Tutaj był emotikon, może też go wytnie)

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *