Faza Discovery i jej DoD dla projektu Fixed Price

Faza Discovery

Karolina w swoim artykule poruszyła kryterium gotowości czyli Definition of Ready jako prerekwizyt, aby zadanie mogło wejść do fazy realizacji. Kryterium to stoi na straży tego, aby zadania były jasno zdefiniowane. Po drugiej stronie stoi drugi strażnik, czyli Definition of Done, które musi zostać zrealizowane, aby uznać zadanie za wykonane. Jest to kryterium stosowane do powtarzalnych czynności na etapie implementacji.

W projektach typu Fix Bid/Fixed Price, gdzie mamy ustaloną cenę, zakres oraz czas, zanim zostanie podpisany kontrakt istnieje coś takiego jak faza Discovery, na podstawie której dostawca dowiaduje się co trzeba zrobić (zakres), oraz określa cenę, dogadując się z klientem co do terminów (i kar za przekroczenie tychże). O ile DoD oraz DoR są strażnikami pilnującymi jakości wejścia do fazy implementacji oraz wyjścia, kluczowe zwłaszcza w projektach o z góry określonej cenie jest jest również posiadanie takiego strażnika po krytycznym dla powodzenia projektu etapie, jakim jest faza Discovery.

Potem (jeśli dostawca oczywiście wygrał) podpisywana jest umowa i jeśli coś pójdzie nie tak, to obie strony zechcą do tej umowy zajrzeć (oczami swoich prawników). Jak widać faza Discovery ma olbrzymie znaczenie, dlatego zastanówmy się co powinno być na jej wyjściu. Dodatkowo ważne jest, aby się do niej porządnie przygotować i z góry ustalić jakie będziemy mieli kryteria akceptacji ważne dla nas – czyli dostawcy. Oznacza to, że należy również jasno postawić kryterium Definition of Done dla fazy Discovery. Ma ona zwykle postać kilku spotkań osób od dostawcy z osobami po stronie klienta. Często praktykowana jest forma warsztatów.

Aktorzy:

  • Klient – zwykle jest to wiele osób reprezentujących różne działy firmy, co często oznacza – różne interesy

Po stronie dostawcy, kluczowymi osobami podczas fazy Discovery będą:

  • Account Manager – osoba odpowiadająca za cały etap sprzedaży
  • Project Manager – kluczowa osoba biorąca po stronie dostawcy odpowiedzialność za powodzenie projektu
  • Analityk Biznesowy – osoba, której celem będzie zrozumienie biznesu klienta i zebranie jego wymagań, a także przeniesienie ich do świata developmentu
  • Architekt – osoba, która na podstawie pracy Analityka zaprojektuje rozwiązanie techniczne, uwzględniając wszystkie wymagania klienta (również te niefunkcjonalne)

Kryteria Definition of Done dla fazy Discovery można podzielić według odpowiedzi na proste, lecz bardzo zasadnicze pytania, które odzwierciedlają zarazem podejście PMBOK’owe.

Dlaczego?

  • Domena biznesowa jest dla nas zrozumiała i opisana
  • Potrzeba biznesowa jest zidentyfikowana
  • Opisana jest jasna wizja produktu, który zaspokaja potrzebę biznesową

Kto?

  • Interesariusze po stronie klienta są zidentyfikowani i wiemy jakie moce decyzyjne posiadają (możemy do tego wykorzystać np. macierz interesariuszy Władza / Zainteresowanie lub Salience Model)
  • Zidentyfikowane są niezbędne zasoby ludzkie potrzebne do wykonania zadania
  • Mamy wybranych podwykonawców (jeśli są potrzebni)

Jak?

  • Zbudowany jest plan komunikacji
  • Ryzyka są zidentyfikowana, oszacowane (prawdopodobieństwo oraz wpływ) oraz strategia zarządzania dla każdego ryzyka jest utworzona
  • Wybrana jest metodyka zarządzania projektem lub wytworzenia produktu (waterfall / agile)
  • Proces zmiany wymagań jest ustalony z klientem
  • Mamy plan na zapewnienie jakości w projekcie
  • Posiadamy zasoby niezbędne do realizacji projektu lub plan ich nabycia (np. serwery, licencje, domeny itp.)

Co?

  • Lista wymagań, włączając w to wymagania niefunkcjonalne (dostępność, czasy odpowiedzi, maksymalny czas potrzebny na instalację na środowisku produkcyjnym, wymagane licencje itp.) jest zdefiniowana
  • Kryteria akceptacji są znane
  • Praca jest rozbita na zadania (Work Breakdown Structure) wraz zależnościami między nimi

Gdzie?

  • Potencjalnie istniejące już środowiska programistyczne, takie jak testowe, akceptacyjne czy produkcyjne już istnieją oraz jest ustalone gdzie praca zespołu projektowego będzie się wirtualnie odbywała, czy w strukturze informatycznej dostawcy czy klienta
  • Czy zespół projektowy zlokalizowany będzie w biurze klienta czy w biurze dostawcy oraz czy związane z tym są dodatkowe wymagania (np. infrastruktura)

Kiedy?

  • Są znane wszelkie ramy i ograniczenia czasowe
  • Kamienie kontrolne są zdefiniowane (zarówno wewnętrzne, jak i zewnętrzne)
  • Zadania z WBS mają oszacowaną czasochłonność oraz czas trwania

I na koniec najważniejsze: Za ile?

  • Mamy zaplanowany budżet, uwzględniający koszt pracy naszego zespołu, zakupy zewnętrzne, koszt podwykonawców

Pomimo, że faza Discovery jest wysiłkiem jednokrotnym, warto dla niej ustalić kryterium Definition of Done. Ułatwi nam to dopilnowanie, aby odpowiedzi na powyższe pytania były udokumentowane, dzięki czemu łatwiej będzie projekt wycenić oraz łatwiej będzie nam spełnić oczekiwania klienta. Może znacząco podnieść nasze szanse w ukończeniu projektu na czas, budżecie oraz w zakresie, a przede wszystkim w dostarczeniu wartości biznesowej dla klienta, jednocześnie minimalizując ryzyko porażki. Dlatego warto tą fazę przygotowawczą zrobić rzetelnie, bo jak mawiał Benjamin Franklin “By failing to prepare – you are preparing to fail”.

Więcej wpisów autora: Jakub Dudek

Shame Driven Development – zarządzanie przez wstyd

W roku 2009 Robert C. Martin, współautor Agile Manifesto, napisał książkę „Clean...
Czytaj dalej

1 komentarz

  • To jest raczej świat idealny niż realny, gdzie zespoły się rozpadają/zmieniają, wymagania klienta lub środowiska produkcyjne zmieniają, a kary egzekwują.

Dodaj komentarz

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