Wycenianie projektów jest jak łowienie ryb
Wycenianie projektów IT to przewidywanie przyszłości – bardzo trudna umiejętność. Istnieją jednak warunki, które sprawiają, że jesteśmy w stanie oszacować koszt danego przedsięwzięcia – istnieją również sytuacje, gdy jest to niemożliwe. Wbrew pozorom wycenianie projektu ma wiele wspólnego z łowieniem ryb – jeśli nie domyślasz się o co chodzi, zapraszam do lektury.
Pssst… mam dla Ciebie prezent 🙂
Od jakiegoś czasu hobbystycznie wędkuję, wspominałem o tym na moim Snapchat. Zanim zacząłem łowić ryby uważałem, że skuteczność wędkarza to czysta losowość. Myślałem, że ważniejsze od umiejętności jest „mieć szczęście” – no bo co to za problem zaplątać robaka na haczyk, później pozostaje tylko czekać 😉 Dziś wiem jak bardzo byłem w błędzie. Na podstawie mojego krótkiego doświadczenia w wędkowaniu mogę stwierdzić, że żeby złapać rybę muszą być spełnione poniższe warunki:
- ryba musi znajdować się w okolicy twojej przynęty – ciężko łowić gdy ryby są na drugim końcu zbiornika 🙂
- twoja przynęta musi być na odpowiedniej wysokości względem dna – dokładnie na tej, na której pływają ryby. Warto dodać, że ryby pływają na różnej głębokości od dna – w zależności od pogody, ciśnienia, pory dnia etc.
- ryba musi żerować – jeśli nie jest głodna, nie skusi się na twoją przynętę.
- ryby mają preferencje smakowe – musisz mieć nabite na haczyk to, na co akurat ryba ma ochotę.
Jeśli powyższe warunki są spełnione, istnieje szansa, że złowisz rybę. Pozostają jedynie umiejętności „zacinani” i wyławiania.
Żeby skutecznie łowić ryby dodatkowo należy znać dany zbiornik. To, że konkretny gatunek ryb żeruje o danej godzinie na zbiorniku A, nie znaczy, że żeruje o tej samej na zbiorniku B. Podobnie jest z innymi parametrami – można powiedzieć, że zachowanie ryb w każdym zbiorniku jest unikalne (ale ma wspólne cechy). Dlatego dla wędkarza bardzo istotna jest znajomość konkretnego zbiornika.
Co to ma wspólnego z IT?
Według mnie – wiele. Gdybyś zapytał wędkarza:
ile potrzebujesz czasu na złowienie karpia w zbiorniku A?
Jeśli wędkarz nie zna zbiornika – nie będzie znał odpowiedzi na to pytanie. Do podania szacunkowego czasu potrzebuje spędzić trochę czasu nad zbiornikiem i „nauczyć się” tamtejszych ryb. Natomiast jeśli chodzi o zbiornik, który jest nam znany (łowi na nim regularnie karpie) – możemy podać przybliżony czas w zależności od warunków jakie panują.
Często analogiczne pytanie zadajemy programistom:
ile potrzebujesz czasu na ukończenie projektu?
Sytuacja jest bliźniacza do tej powyższej – jeśli programista nie zna projektu (powierzchowne założenia i lakoniczne opisy nie są znajomością – to mówi tyle samo co – „w zbiorniku są ryby”) nie jest w stanie oszacować czasu. Inaczej wygląda sytuacja, w której programista zna projekt i np musi go rozszerzyć o nowe funkcje, lub została wykonana dokładna analiza i każdy detal jest zaprojektowany. Wtedy jesteśmy w stanie podać czas (przybliżony) ukończenia projektu.
Podobnie jak wędkarz, programista musi znać dokładnie zakres z analizy (u wędkarza są to właściwości zbiornika) – by podać czas mający związek z rzeczywistym czasem realizacji. Zaskakuje mnie, że w innych dziedzinach życia łatwiej nam zaakceptować to, że nie zawsze jesteśmy w stanie przewidywać przyszłość (szacować ile nam zajmą czynności). Jeśli sprawa nie dotyczy IT, łatwiej nam też zrozumieć, że potrzebujemy czasu żeby coś zbadać i móc później wycenić. W IT często trudno zrozumieć klientowi, że analiza przedwykonawcza oszczędza czas podczas realizacji. Podejrzewam, że niechęć klientów do analizy bierze się stąd, że jej efekt nie jest namacalny. O tyle o ile na stworzoną stronę możemy się np zalogować, „dotknąć” – to w analizie klient może jedynie przeczytać to o czym myślał mówiąc nam o zakresie (często nie zauważając rozwiązań problemów, które występują w projekcie). Jest to oczywiście krótkowzroczne, jednak praktykując takie podejście możemy stwierdzić, że etap analizy jest zbędny.
Jeśli chodzi o projekty IT, często zakłada się pewność na niepewność (wycenę nie poprzedzoną analizą) – później wszyscy są zdziwieni, że czas realizacji jest różny od planowanego. Mimo, iż programista nie zawsze jest w stanie wycenić projekt – nakładając presję wymaga się tego.
Podsumowanie
Wycenianie projektów to przewidywanie przyszłości – bardzo trudna umiejętność. Jeśli wycena ma mieć wiele wspólnego z rzeczywistością musi być poprzedzona analizą przedwykonawczą projektu. Inaczej jesteśmy jak wędkarz na obcym zbiorniku, zapytany „w ile czasu złowisz karpia?”.
Jeśli oczekujesz wyceny od programisty do projektu nie poprzedzonego analizą, zrozum, że ta wycena może znacznie odbiegać od faktycznego czasu realizacji (lub może też być trafiona). Z drugiej strony należy też zrozumieć m.in. klienta, który chce w jakiś sposób zaplanować budżet na projekt – nie bójmy się „strzelać”. Warto jedynie, żeby dwie strony pamiętały, że strzał bez analizy nie może być wiążący.
Dziękuję, że przeczytałeś ❤️
Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍
