Jak (dokładniej) wyceniać zadania IT?

Wycena czasu na realizacje zadań jest kluczowa bo wyznacza termin ukończenia projektu. Jednak wycena w jednym wymiarze (czasu) może okazać się zbyt mało miarodajna. Do wyceny warto wprowadzić dodatkowe parametry takie jak pracochłonność i skomplikowanie. Z tego wpisu dowiesz się czym różni się pracochłonność od skomplikowania w kontekście zadań IT. Zrozumiesz dlaczego poszczególne zadania się opóźniają, a przed wszystkim jak zminimalizować to ryzyko poprzez wprowadzenie dodatkowych parametrów do wyceny.

Niezbędne jest zrozumienie, że dla każdego zadania możemy określić skomplikowanie/trudność oraz pracochłonność. Ta metoda często jest spotykana podczas wyceny user stories. Do każdej historyjki przypisujemy dwie zmienne – np skomplikowanie (w skali 1-9) oraz pracochłonność (w skali 1-9). Dwie wartości łączy się, dzięki temu mamy ogólne pojęcie nad tym jakiej skali trudności jest zadanie. Punkty do zadania mogą mieć wartość np „19” – gdzie pierwsza z cyfr (1) oznacza skomplikowanie, a druga (9) trudność.

#Przykład pracochłonnego zadania
Przepisanie danych z kartki do Excel [19] – nic trudnego, ale przepisanie zajmie nam wiele czasu.

#Przykład skomplikowanego zadania
Użycie biblioteki XYZ do rozwiązania skomplikowanego problemu [91] – pracochłonność (1) w tym zadaniu jest mała. Dołączenie biblioteki do aplikacji jest prostą czynnością. Skomplikowanie (9) jest duże, ponieważ developer nigdy nie używał tej biblioteki i jej konfiguracja jest trudna.

Powstało wiele hybryd tworzenia user pointów – ja opisałem wybrany przez siebie.

Pracochłonność i skomplikowanie to pojęcia względne. Kluczem w opóźnieniach jest poziom skomplikowania dla developera. Do oceny pracochłonności wymagana jest dokładna znajomość zakresu (wiedzy co trzeba zrobić) – inaczej nie jesteśmy w stanie podać szacunkowego czasu tylko „strzał”. Znajomość zakresu jest oczywiście naszym skomplikowaniem.

1. Czym mniej wiemy jak rozwiązać dany problem, tym poziom skomplikowania jest wyższy
2. Czym wyższy jest poziom skomplikowania tym bardziej niedokładna jest pracochłonność (bo zadanie jest dla nas eksperymentem)
3. Czym bardziej niedokładna jest pracochłonność, tym bardziej czas realizacji jest różny od zakładanego.

Można powiedzieć, że pracochłonność jest naszą obietnicą (jak długo), a skomplikowanie ryzykiem (jak bardzo możemy się mylić) z jaką deklarujemy naszą obietnicę.
Tak jak wcześniej wspomniałem; skomplikowanie jest pojęciem względnym. W określaniu skomplikowania zadania nie powinno się brać pod uwagę „ogólnej trudności zadania” tylko poziom wiedzy osoby wykonującej względem zakresu.

Przykład:

Aktorem będzie doświadczony programista zajmujący się na co dzień programowaniem sztucznej inteligencji w C++.

Zadanie: Napisać program rozpoznający koła na zdjęciu.

Algorytmika nie jest łatwą częścią programowania. Mimo to, wycena zadania przez programistę to – skomplikowanie – 1, pracochłonność – 3. Wynika to z tego, że mimo ogólnej wysokiej trudności zadania – zakres dla programisty jest doskonale znany. Np wykonywał w przeszłości zadanie „rozpoznawania trójkątów na zdjęciu”. W związku z tym jest w stanie przewidzieć jakie mogą wystąpić problemy i ile czasu zajmie ich rozwiązanie. Prawdopodobnie zadanie nie ulegnie opóźnieniu – w skrócie mówiąc „wszystko jest jasne”. Prawdopodobnie gdy programista wykonywał pierwszy raz zadania związane z rozpoznawaniem kształtów na zdjęciu dałby wycenę: skomplikowanie – 9, pracochłonność – 9 (jedna wielka niewiadoma). Z każdym kolejnym wykonaniem podobnych zadań stopień skomplikowania dla programisty malał.

Jeśli przed tym samym programistą postawimy zadanie: Napisz program do prowadzenia księgowości działalności gospodarczej. Sztuczna inteligencja w „ogólnym stopniu trudności” jest bardziej skomplikowana niż program do księgowości, gdzie wszystko skupia się głównie na dodawaniu/odejmowaniu i mnożeniu. Mimo to wycena przez naszego programistę jest zupełnie inna niż w przypadku pierwszego programu. Skomplikowanie – 5, pracochłonność – 4. Powodem jest brak doświadczenia programisty w dziedzinie finansów – z trudem odróżnia netto od brutto. Żeby zrealizował aplikację będzie musiał włożyć dużo wysiłku by zapoznać się z metodami prowadzenia księgowości. Jest dużo niewiadomych, stąd ocena wyższa niż w przypadku sztucznej inteligencji, gdzie był to dla niego „chleb powszedni”.

Jak zapobiegać opóźnieniom?

Prawa Murphy’ego istnieją i nie jesteśmy w stanie wszystkiego przewidzieć. Możemy zminimalizować ryzyko opóźnienia starając się uzyskać jak najmniejszy poziom skomplikowania zadania (w oczach programistów). Warto żeby zadanie wyceniał (określał pracochłonność i skomplikowanie) developer, który będzie nad nim pracował. Podczas gdy wycenia zadania dla całego zespołu team leader lub ktokolwiek inny – może mieć różną percepcję trudności zadania bo bazuje na uśrednionym poziomie kompetencji swoich developerów. Zdaję sobie sprawę, że nie zawsze jest to możliwe. Istnieją różnego rodzaju ograniczenia biznesowe gdy np musimy podać wycenę, nie znając zasobów projektów. Często też zasoby są dodawane/odejmowane od projektu w trakcie jego trwania – developerzy muszą bazować na szacunkach swoich kolegów mimo woli.
W celu redukcji ryzyka podejdź do wyceny zadań iteracyjnie. Jeśli skomplikowanie jest wycenione na 9, zapytaj co konkretnie może stanowić problem. Spróbuj rozbić zadania na mniejsze elementy i na temat tych trudniejszych zrób research/proof of concept. Po tych czynnościach podejdź ponownie do wyceny. Całą iterację powtarzaj do momentu kiedy czas wykonania zadania jest szacunkiem, a nie „strzałem”. Dlatego R&D oznacza „research and development”. Dokładnie w tej kolejności. Jeśli robimy w odwrotnej – możemy mieć problem 😉

Sprawdź jak mogę Ci pomóc osiągnąć Twoje cele 🎯

Podsumowanie

Skomplikowanie ocenia ryzyko opóźnienia zadania, nie jego pracochłonność. Wysoki stopień skomplikowania zadań może świadczyć o źle sprecyzowanych wymaganiach projektu w zakresie jego działania lub niekompetencji zespołu wyceniającego. Staraj się dążyć do sytuacji, gdy w zadaniach poziom trudności jest jak najniższy; możesz to osiągnąć poprzez podejście iteracyjne do wyceny i starać się by nad zadaniami pracowały osoby, które je wyceniały. Mimo takiej minimalizacji ryzyka, możliwość opóźnienia zadania wciąż istnieje bo nie jesteśmy w stanie przewidzieć trudności obiektywnych.

Jeśli wpis ci się spodobał, udostępnij go lub śledź mnie na facebooku, twitterze lub LinkedIn lub subskrybuj mój kanał YouTube – twoja interakcja motywuje do dalszego pisania! Jeśli interesują cię podobne treści, dopisz się do newslettera (na górze strony) :).