Moja sekretna technika szacowania projektów

Czy słyszałeś o #YesEstimates oraz #NoEstimates ruchy? Od 2012 roku w świecie IT toczy się wielka debata.

Woody Zuill, Vasco Duarte oraz Neil Killick to trzej z najbardziej krzykliwych zwolenników #NoEstimates podejście. Po drugiej stronie ogrodzenia znajduje się stara szkoła #YesEstimates ruch przyjazny dla biznesu z wieloma zwolennikami. Sprawdźmy tezy obu stron.

#NoEstimates:

1. Szacunki są zawsze niedokładne i dlatego nie mają sensu.
2. Szacunki to strata cennego czasu. Zamiast rozpocząć pracę, deweloperzy są zaangażowani w bezużyteczny proces szacowania.
3. Szacunki istnieją w świecie IT, ponieważ są częścią procesu od tak dawna, że cała społeczność zakłada, że jest to konieczne.
4. Szacunki prowadzą do dysfunkcji projektu, takich jak niska jakość, nadgodziny lub marnowanie czasu.

#YesEstimates:

1. Możliwe jest dokonanie prawidłowej i wartościowej wyceny.
2. Oszacowanie kosztów jest bardzo istotne dla powodzenia projektu.
3. Brak szacunków izoluje ludzi biznesu - nie są w stanie przydzielić budżetu.

W tym wpisie na blogu nie będę podążał za #YesEstimates ani #NoEstimates debaty, ponieważ tezy obu stron są bardzo rozsądne. Chciałbym opisać moje doświadczenia i przemyślenia.

Gotowy do startu?

Czy kiedykolwiek myślałeś o własnym domu z ogrodem lub zbudowałeś swój wymarzony dom od podstaw? Ja to zrobiłem!

Teraz wyobraź sobie sytuację, w której masz spotkanie z deweloperem, który mówi:

Hej! Nie wiem ile to będzie kosztować, zobaczymy. Zacznijmy od najcenniejszych rzeczy, takich jak ściany, dach, okna, a skończymy, gdy budżet zostanie przekroczony.

Czy jesteś na tyle odważny, żeby się z nim zgodzić? Ja nie jestem, bo muszę wiedzieć, ile to będzie kosztować, jak duży powinien być kredyt hipoteczny, a nawet nie wiem, czy deweloper mnie nie oszukuje. Odpowiedź mogłaby być inna, gdybym był milionerem.

Podobnie jest w przypadku projektów IT. Zawsze jest inwestor, który musi zapłacić za produkt i zespół programistów, który musi dostarczyć system. Jeśli miałeś okazję być na spotkaniu biznesowym z inwestorami i jeśli zaproponowałeś metodologię Scrum lub Kanban, wiesz, co mam na myśli 🙂 W 99% przypadków ostatnie pytanie na tym spotkaniu brzmi: ILE TO BĘDZIE KOSZTOWAĆ?

Porozmawiajmy teraz o tworzeniu oprogramowania na zamówienie!

Zamiast toczyć przegraną bitwę, po prostu spróbuj zrozumieć ludzi biznesu i przygotuj dobre oszacowanie. Poniżej znajduje się lista potencjalnych technik:

• Struktura podziału pracy
• 3-punktowa technika szacowania testów oprogramowania
• Szerokopasmowa technika Delphi
• Analiza punktu funkcyjnego / punktu testowego
• Metoda punktu użycia
• Rozkład procentowy
• Planowanie pokera
• Metoda ad-hoc.

Techniki szacowania projektów. Jak to zrobić?

Podczas mojego 15-letniego doświadczenia w branży IT, opracowałem swoją technikę będącą hybrydą struktury Work Breadown, 3-punktowej techniki szacowania testów oprogramowania i metody Use-Case Point.

Aby przygotować dobre oszacowanie techniczne, zawsze postępuję zgodnie z poniższymi krokami:

1. Zrozumienie potrzeby biznesowej. Bez względu na to, czy jest to mała funkcja, czy cały system do stworzenia, zasada jest zawsze taka sama - pomyśl o tym wymaganiu z perspektywy biznesowej i spróbuj odkryć czynniki biznesowe, takie jak znaczenie funkcji, innowacyjność, grupa docelowa, jaki rodzaj problemu rozwiąże. Rezultatem tego kroku powinien być krótki opis projektu zrozumiały dla nietechnicznego znajomego oraz lista podobnych produktów znalezionych w Internecie.
2. Ocena specyfikacji biznesowej i wiedzy o kliencie. Na tym etapie należy określić ryzyko związane z projektem, w szczególności
   • luki w wiedzy,
   • luki w wiedzy klientów.

   Wynikiem tego kroku powinna być lista pytań do klienta na temat niejasnych wymagań. Może to być również sugestia zorganizowania spotkania w celu zebrania wszystkich wymagań. Technika event storming to dobry sposób na współpracę z klientem.

3. Zidentyfikuj punkty integracji, w szczególności wyodrębnij interfejsy wejściowe i wyjściowe w systemie, na przykład integrację z bramką płatności lub eksport danych do innego systemu. Wynikiem powinna być lista interfejsów integracyjnych, a także prognoza ryzyka, zwłaszcza jeśli nowo utworzona funkcja czeka na rozwój innego dostawcy.
4. Zdekomponuj wymagania biznesowe na małe fragmenty, takie jak funkcja logowania, funkcja rejestracji użytkownika, koszyk i inne.
5. Przejrzyj wymagania z punktu 4 i przypisz jedną z poniższych kategorii wiedzy do każdego punktu:
   • FULL jeśli cały zespół wykonał podobną funkcję i wszyscy wiedzą, jak to zrobić.
   • PARTIAL jeśli ktoś z członków zespołu wykonał podobną funkcję.
   • RARE jeśli ktoś z firmy wykonał podobną funkcję, możesz go o to zapytać.
   • NEW jeśli nikt nie wykonał podobnej funkcji w Twojej organizacji.
6. Prześledź wymagania jeszcze raz i spróbuj z grubsza rozłożyć każde wymaganie na kroki techniczne. Na tym etapie należy zebrać wszystkie pomysły techniczne i potencjalne frameworki/biblioteki do wykorzystania. W tym momencie należy również opisać złożoność jednej z tych wartości:
   • SIMPLE,
   • MEDIUM,
   • COMPLEX.
7. Teraz nadszedł czas na oszacowanie! Moją ulubioną techniką jest formuła średniej ważonej PERT. Przejrzyj swój dokument, przeanalizuj po kolei każdy krok techniczny i sprawdź odpowiedź z punktu 5:
   • jeśli Twoja kategoria to FULL lub PARTIALbędziesz w stanie precyzyjnie oszacować czas trwania
   • jeśli Twoja kategoria to RARE, będziesz w stanie z grubsza oszacować czas trwania z ryzykiem. Dodaj 10-30% czasu na transfer wiedzy.
   • jeśli Twoja kategoria to NEWSpróbuj przekonać klienta lub swojego przełożonego do wdrożenia prostego Proof of Concept, aby zweryfikować jakiś pomysł, framework lub rozwiązanie. Jeśli nie jest możliwe wykonanie PoC, dodaj dodatkowy czas do szacunków.
8. Zatwierdź oszacowanie i przekaż je zarządowi projektu, który dokona przeglądu, doda dodatkowy czas na zarządzanie i testy. Omów z interesariuszami projektu swoje wątpliwości i znalezione zagrożenia.

Twoje oszacowanie może wyglądać jak na poniższym obrazku:

Możesz pobrać plik Excel, aby zobaczyć całą metodę w praktyce. Miłego oglądania i daj mi znać, czy ta technika jest dla Ciebie przydatna.