Poradniki

[Z cyklu wycena skrojona na miarę] Jak efektywnie wycenić projekt w zależności od jego fazy.

13.08.2018, Krzysztof Grześkowiak

Startujesz z nowym projektem? Chcesz zrobić wycenę nowych funkcji dla już budowanego produktu? A może klient zgłosił jedynie Change Request do istniejącego produktu?

Każda z tych sytuacji wymaga innego przygotowania i przeprowadzenia spotkania. Niektóre z zadań można wycenić “z marszu”, inne wymagają wprowadzenia czy nawet wcześniejszego opracowania koncepcji. Poniżej opisałem cztery główne typy wycen, które wyróżniam w swojej pracy.

Rozszerzenie do zakończonego produktu

W produkcie, z którym pracuję, bardzo często spływają prośby o wycenę zmian do obszaru, który często działa produkcyjnie od wielu miesięcy. Prośby wynikają ze zmian organizacyjnych lub dalszych optymalizacji po stronie biznesu zamawiającego. Z tego powodu największym wyzwaniem jest fakt, że zespół nie jest na bieżąco z produktem.

Warto, aby podczas spotkania obecny był programista lub zespół, który programował daną funkcję lub brał udział przy opracowywaniu koncepcji. Kolejnym zagadnieniem jest ocena wpływu na resztę produktu.

Dobrym sposobem na minimalizację ryzyka jest przedstawienie mapy produktu pokazującego daną funkcję w kontekście całości. Załączona ilustracja przedstawia fragment naszej mapy. Przystępując do modyfikacji obszaru “Moje dokumenty” wiemy o funkcjach, które są tam dostarczone oraz ich ewentualnych powiązaniach z innymi obszarami systemu. Przechowujemy też link do dokumentacji tego obszaru oraz notatki z ewentualnymi uwagami.

Zmiana do aktualnie budowanego produktu

Nierzadko zdarza się, że w trakcie oddawania kolejnych elementów produktu klient oczekuje wprowadzenia pewnych zmian do pierwotnych założeń (Change Request). Aby oszacowanie takich zmian zostało przeprowadzone sprawnie i na niskim ryzyku, należy zadbać o kilka elementów:

  • Przed spotkaniem skonsultuj propozycję zmian z autorem koncepcji / architektem / senior developerem, który był odpowiedzialny za projekt. Opowiedz mu o powodach zmiany, jej konsekwencjach biznesowych oraz produktowych. To mu pomoże w jej ocenie. Być może okaże się, że ważny element techniczny nie jest gotowy na tę zmianę i przed spotkaniem trzeba przeprowadzić dodatkowe rozpoznanie.
  • Przygotuj wszystkie mapy biznesowe, mapy myśli czy story mapping, które posiadasz i pokaż, których obszarów dotyczy zmiana. Zastanów się wspólnie z zespołem nad potencjalnymi konsekwencjami zmiany. Ustalenie wpływu na pozostałe obszary aplikacji jest kluczowe i bardzo często niedoceniane.
  • Powiedz o powodzie zmiany i o tym, jak wygląda sytuacja u klienta. Część osób może myśleć, że wykonała złą pracę, której klient nie odebrał. Inni mogą odnieść wrażenie, że wykonują pracę, która idzie do kosza z powodu nieprecyzyjnych analiz biznesowych. Nie pozostawiaj w tym obszarze niedopowiedzeń.
  • Jeśli zgłoszeń jest wiele – ustal dedykowane spotkanie, na którym wyceniane będą tylko zadania z danego projektu. Pozwoli to łatwiej pozostać w kontekście.

Nowy produkt

O tym jak oszacować koszt zbudowania nowego produktu można z pewnością napisać całą książkę, jednak ten akapit chciałbym sprowadzić do kilku podstawowych obserwacji skupionych na procesie samej wyceny:

  • Nie ulegaj presji terminów. Nawet jeśli zbieranie wymagań trwało zbyt długo, to jest to najgorszy moment aby przyspieszać kosztem jakości. Pamiętaj, że wykrycie błędu na tym etapie będzie kosztować najmniej – za kilka sprintów koszt zmiany będzie odczuwalne wyższy.
  • Zbuduj i zbierz na spotkaniu zespół scrumowy. Sprawdź, kto może i chce budować produkt. Upewnij się, że w projekcie będziesz miał ludzi reprezentujących cały wachlarz kompetencji potrzebnych do zbudowania produktu lub omawianego fragmentu produktu.
  • Zrób krótką prezentację o tym, jaki produkt, dla kogo, na jakich warunkach i przy jakich założeniach budujecie. O tym, jak zrobić fajne uruchomienie projektu i zaangażować ludzi, napiszę w osobnym artykule 😊
  • Pozwól, aby tech-leadzi lub architekci opowiedzieli o założeniach technicznych i zadbaj o to, aby na sali byli ludzie, którzy są wstanie zrealizować projekt w określonej technologii.
  • Zaprezentuj w formie mapy wszystkie User Stories oraz Epics, które są znane w projekcie. Jeśli jakiś obszar nie jest znany lub ulegnie zmianie – opowiedz o tym. Do zaprezentowania możesz się posłużyć techniką Story Mappingu, Mind Mapę lub pokazać Road Mapę.
  • Ustal wraz z zespołem kolejność realizacji kilku pierwszych Epiców. Jest to potrzebne, aby nie wyceniać zadań, które będą realizowane pod koniec projektu. Możesz posłużyć się diagramem sieciowym. Wstępne ustalenia w tym zakresie możesz poczynić przed spotkaniem z techleadami / architektami.
  • Najbliższe zadania wyceniaj dokładnie (Poker Planning), natomiast dalsze prace (powyżej 4-8 sprintów) możesz wycenić w przybliżeniu i to na poziomie Epica. Do wyceny Epiców możesz posłużyć się wyceną koszulkową. Informacja, którą otrzymasz poprzez Poker Planning na poziomie Epica, nie będzie bardziej wiarygodna od koszulkowej, a zajmie więcej czasu.
  • Przypomnij wnioski z poprzednich retrospektyw dotyczące budowania nowych produktów, które mogą być pomocne w spotkaniu.

W przypadku produktów bardzo złożonych, realizowanych przez kilka zespołów należy najpierw podzielić produkt na odpowiednie części i omawiać ich fragmenty zespołem.

Wyceny sprzedażowe

Nie każde zadanie, które wyceniamy na pewno trafi do backlogu. Część zadań wyceniamy dla naszej sprzedaży aby mogła przygotować dla klienta ofertę. W związku z tym opracowaliśmy tryb wyceniania inicjatyw sprzedażowych. Główna różnica polega na tym, że każdy członek zespołu tylko raz podnosi kartę z wysokością wyceny, a Project Manager zapisuje ilość wystąpień każdej wartości co daje pogląd na rozpiętość. Oprócz tego czas na wycenę jest ograniczony, a decyzja ma być szybka. Efekt? Wiemy jaka jest rozpiętość wycen, a także która wartość występuje najczęściej. Dzięki temu możemy poinformować klienta o wstępnym budżecie. Oczywiście po złożeniu zamówienia zadanie trafia do ponownej wyceny, którą wykonujemy zgodnie ze sztuką.

Podsumowując: pamiętaj, aby dla każdego zadania przedstawiać jego szerszy kontekst i umiejscowienie w ramach całego produktu.  To pomaga ocenić wpływ na jego pozostałe obszary i znacząco poprawia dokładność samej wyceny oraz niweluje ryzyko wystąpienia błędów w testach regresyjnych. Oprócz tego pokazywanie szerszego kontekstu zwiększa zaangażowanie członków zespołu w sam proces wyceny – nie pracujemy na samej treści i oderwanym fragmencie a kontekście całości, który najpewniej współtworzyli. Mimowolnie pokazujesz też postęp projektu oraz kierunek tego co będzie budowane. Wykorzystaj tą okazję najlepiej jak się da.

#contmanway
Więcej w kategorii >
23.05.2018, Autor: Magdalena Tuchowska
Zmiana pracy to jedno z bardziej stresujących wydarzeń w naszym życiu. Przejście przez pierwsze trzy miesiące w nowej firmie bez opieki przewodnika jest jak ...
Czytaj więcej
Aktualności
Więcej w kategorii >
31.07.2018, Autor: Piotr Szpakowski
W ostatnich dniach w sieci pojawiło się kilka wpisów m. in na portalu forsal.pl czy też cashless.pl przypominających o planowanym na październik przejęciu cz...
Czytaj więcej
Case Studies
Więcej w kategorii >
31.07.2018, Autor: Piotr Szpakowski
W ostatnich dniach w sieci pojawiło się kilka wpisów m. in na portalu forsal.pl czy też cashless.pl przypominających o planowanym na październik przejęciu cz...
Czytaj więcej
Po godzinach
Więcej w kategorii >
13.09.2016, Autor: Dawid Tomaszewski
Ansel Adams kiedyś powiedział: „prawdziwa fotografia nie musi być wyjaśniana, ani nie może być zawarta w słowach”. Każdy z nas widział zdjęcie, na które pier...
Czytaj więcej
04.09.2018, Autor: Krzysztof Grześkowiak
Na przeprowadzenie refinementu składa się nie tylko dobre opisanie czy omówienie zadania, ale też sprawne moderowanie spotkania. Po właściwym wprowadzeniu pr...
Czytaj więcej