Jak (dokładniej) wyceniać zadania IT?

Udostępnij

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 😉

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) :).

deadline


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


Udostępnij

7 thoughts on “Jak (dokładniej) wyceniać zadania IT?

  • 9 listopada 2016 at 07:52
    Permalink

    Dobre! Od jakiegoś czasu zastanawiam się co zrobić z szacowaniem historyjek. Jeden zespół u nas w ogóle odszedł od szacowania (co w sumie nie wychodzi źle, zakłada się tylko, że US są “podobnej wielkości”) a drugi szacuje standardowo story pointsami, które są jednak mocno abstrakcyjne (albo odwrotnie – są obietnicą ile zajmie to czasu). Szacowanie dwoma wartościami zaproponowanymi przez Ciebie wydaje się być dobrym pomysłem, punkty przestają być abstrakcyjne a zyskują konkretne znaczenie. Idealny jest ten przykład z Excelem 😉

    Reply
    • 9 listopada 2016 at 09:46
      Permalink

      Cieszę się, że pomogłem 🙂 Miary muszą być mierzalne, inaczej tracą sens 🙂

      Reply
  • Pingback: webMASTAH.weekly.027 - Jak (dokładniej) wyceniać zadania IT? - webMASTAH

  • 29 listopada 2016 at 19:27
    Permalink

    Mam zastrzeżenie. Co – że tak powiem – klienta obchodzi, czy zadanie jest nowe dla programisty? To chyba problem programisty, nie klienta? Jeśli coś jest “rynkowo łatwe”, no to dlaczego programista ma wycenić wysoko? Poza tym brakuje tu wartości biznesowej. Taki case: programista robił już wcześniej rzecz, która jest bardzo, bardzo zaawansowana biznesowo, rynkowo. Wyceni to nisko, bo zrobi szybko, dobrze, bez problemów? A co z wartością pracy?

    Reply
    • 29 listopada 2016 at 22:17
      Permalink

      Dzieki za komentarz.
      Klienta obchodzi ile zajmie zadanie. Szczególnie jeśli płaci za czas programisty (time&materials). Jeśli wycena jest dokładna to ma możliwość przygotować sie na koszt realizacji – np odrzucić jeśli jest zbyt wysoka. Zawsze lepiej podawać dokładniejsze wyceny niż mniej dokładne – to jest wlasnie wartość biznesowa bo mozna zabudzetowac projekt. Jeśli wyceny są mniej dokładne to finalny koszt jest loteria.

      Jeśli programista zrobił bardzo trudna rzecz szybko to bardzo dobrze. Zawsze mozna podnieść stawkę za godzinę (chyba o to ci chodziło). Imho bez sensu byłoby zrobic szybko i udawać ze to trwa dłużej – nikt na tym nie zyskuje. Wartość pracy powinna byc nagradzana stawka wynagrodzenia. Jeśli masz programistę, który pracuje szybciej o 20% niż “przeciętny” to taniej i korzystniej bedzie budować zespół z takich ludzi nawet za wyższe stawki bo dowiozą wiecej funkcjonalności w tym samym czasie co “przeciętni”. Time is money 🙂
      Podsumowując: wycena zawsze powinna byc dokładna, nie ma sytuacji w ktorej lepiej cos wycenić niedokładnie.
      Pozdrawiam!

      Reply
    • 5 maja 2017 at 18:14
      Permalink

      R&D kosztuje. Jeśli firma/programista nie robiła pewnej rzeczy to jasne jest, że będzie to droższe niż u konkurencji. Zawsze można zmienić wykonawcę na takiego który ma opracowaną technologię. Wolny rynek 😉

      Reply
      • 5 maja 2017 at 21:46
        Permalink

        Nawet jeśli robimy coś któryś raz warto robić analizę – w tym przypadku jest o tyle łatwiej, że większość może być copy&paste.

        Reply

Dodaj komentarz

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