Jak oszacować ile programista popełni błędów?

Wielokrotnie w Kursie Dokładna Wycena Projektów IT wspominałem o tym jak ważne jest, żeby w wycenie uwzględnić czas, który poświęcimy na Testowanie i Poprawki błędów. Jest to ważne żeby nie wrzucać tego etapu jako „+30% do developmentu” lub upychać w bufor bezpieczeństwa, lub co gorsza – nie uwzględniać go w wycenie. Musimy go wycenić bo to, że błędy w projekcie będą jest prawie pewne.

Dlaczego wycena Testów i poprawek jest ważna?

Wycena testów i poprawek jest ważna przede wszystkim dlatego, że w prawie wszystkich projektach występują błędy. Wiele osób nie wycenia tego etapu – podejrzewam, że dlatego bo nie wiedzą jak.

To, że coś pominiemy w wycenie nie zwolni nas z obowiązku wykonania tego. Czyli jeśli nie wycenimy fazy projektowej związanej z testami i poprawkami błędów to będzie to jedna z przyczyn, przez którą twój projekt może się opóźnić a ty będziesz zrzucał winę na programistów, że nie są kompetentni technicznie bo robią błędy.

Innym podejściem (błędnym) często stosowanym jest dołożenie do wyceny buforu (o losowej wartości) – czasami 20%, czasami 40% – zależy co palec w Excel przyniesie.

Ja jestem zwolennikiem tego, żeby bufor projektowy był na rzeczy NIEPRZEWIDZIANE, które nam wyskoczą. Natomiast to, że w projekcie będą błędy wiemy zanim zaczniemy go realizować, więc nie ma sensu zakłamywać rzeczywistości.

Jak oszacować ile błędów popełnimy?

Przedstawię ci prostą metodę, którą sam często stosuję w praktyce wyceniając nowe projekty. Założeniem tej metody jest to, że masz przypisane zasoby projektowe i współpracujesz już z nimi „jakiś czas”.

Kluczem jest retrospekcja projektów pod względem statystycznym. Nie wiem jakiego systemu do zarządzania projektami używasz, dlatego przedstawię ci tą metodę generycznie, abyś mógł ją odnieść do siebie.

0. Weź pod lupę projekty, w którym uczestniczyły twoje zasoby projektowe, które chcesz przypisać do nowego projektu.

1. Sprawdź ile każdy z nich przepracował godzin na danym projekcie.
   Na przykład: Józek pracował realizując nowe funkcjonalności nad projektem XYZ przez 600 rbh.
   
2. Sprawdź ile błędów zostało zdiagnozowanych do elementów, które realizował dany zasób.
   Na przykład: W Józka kodzie znaleziono 30 błędów.
   
3. Podziel liczbę pracochłonności przez ilość popełnionych błędów.
   W naszym przykładzie 600 / 30 = 20. Oznacza to, że na każde 20 RBH Józek popełnia średnio 1 błąd.
   Dodatkowo możesz sprawdzić ile godzin Józek poświęcił na ich naprawę.
   Na przykład: Na poprawę 20 bugów poświęcił 60 RBH. Znaczy to, że średnia naprawa jednego błędu to 3 RBH.

Na tym etapie powinieneś mieć już obliczony współczynnik popełnianych błędów i średni czas naprawy błędów.

Kolejnie powinieneś sprawdzić ile RBH z nowego projektu chcesz przydzielić do danego zasobu i przeliczyć wyniki dla współczynników.

Jeśli dla naszego przykładowego Józka chcesz przydzielić zadań na łączną pracochłonność 300 RBH, to możesz się spodziewać około 10 błędów, które naprawi w około 30 RBH.

Takie obliczenia powinieneś wykonać dla wszystkich zasobów, które chcesz przypisać do projektu.

a co z nowymi programistami?

Tu sprawa jest trudna bo nie mamy żadnych danych historycznych. Ja wtedy robię tak, że obliczam średnią liczbę popełnianych błędów i czas realizacji dla mojego zespołu i zakładam, że nowy programista jest w tej średniej.

Czasami ten współczynnik modyfikuje w zależności od poziomu zaawansowania programisty i doświadczenia w podobnych projektach.

Jest jeszcze trudniej jeśli nie logujecie czasu realizacji w zadania, lub nie używacie jakiegoś oprogramowania z historią. Nie jestem sobie w stanie np. wyobrazić jak taką rzecz wygodnie sprawdzić w Trello – natomiast wiem, że wiele zespołów namiętnie korzysta z tego narzędzia.

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

Podsumowanie

Musisz pamiętać, że to wszystko są szacunki, które pozwolą ci „założyć jakąś liczbę”. Powinieneś ją jeszcze poddać tzw. „expert judgement” czyli swojej ocenie eksperta. Ale to na pewno dobry punkt wyjścia.

Sposób, który prezentuje jest generyczny – możesz do zastosować do każdego systemu zarządzania projektem, który gromadzi odpowiednie dane. Nawet do Excela jeśli się uprzesz 🙂

Jeśli tematyka wycen projektów jest ci bliska to zapraszam cię do kursu – Dokładna Wycena Projektów IT. Zdradzam w nim różne smaczki i sekrety Wycen Projektów IT.