W literaturze przedmiotu można wyróżnić trzy nurty myślenia o zarządzaniu projektem o dużym stopniu niepewności, którego celem jest przede wszystkim dostarczenie wiedzy:
Product discovery – głównymi przedstawicielami tego nurtu są Marty Cagan, Jeff Gothelf, Josh Seiden, Eric Ries, David Bland, Alexander Osterwalder, Teresa Torres, Itamar Gilad. Na starcie jest niezbadana potrzeba klientów oraz założenie, że dany produkt będzie w stanie ją zaspokoić, zakresem takiego projektu staje się zatem seria eksperymentów na zachowaniach klientów, które pozwolą zdefiniować, jak powinien wyglądać docelowy produkt. Pojawia się ciekawa koncepcja dual track, czyli dwóch równoległych ścieżek. W ten nurt wpisuje się również PMI z jednym z cykli życia projektów opisanych w koncepcji Disciplined Agile Delivery oraz cała koncepcja Design Thinking i Lean Startup. Pobieżne elementy tego podejścia można również znaleźć w metodyce PRISM oraz SAFE.
Testowanie technologii – tutaj można spotkać takich autorów, jak Katherine Radeka, Barry Boehm, David Ullman. Celem tego nurtu jest zorganizować projekt, który ma sprawdzić użyteczność, realizowalność, ekonomiczność wybranej technologii w jakimś zastosowaniu. Ten nurt skupia się na iteracyjnym przygotowywaniu prototypów w małej skali, testowaniu i wyciąganiu wniosków. Widać tu dużo inspiracji Scrumem.
Projekt ekstremalny – reprezentantami tego nurtu są Robert Wysocki, Doug DeCarlo, Jonathan Brill. Ten nurt ma najmniej wspólnego z tytułowymi projektami eksploracyjnymi mimo użytego terminu “ekstremalny”. Autorzy w tym nurcie skupiają się na podkreślaniu, jak ryzykowne są projekty ekstremalne i jak ważne jest w nich zarządzanie ryzykiem. Natomiast niewiele jest mowy o specyficznym podejściu do takich projektów. Generalizując, można stwierdzić, że projekty ekstremalne to standardowe projekty, które są bardzo ryzykowne.
Model został opisany przez Barry’ego Boehma w książce The Incremental Commitment Spiral Model. Został skonstruowany na bazie wieloletnich doświadczeń autora w sektorze lotniczym, telekomunikacyjnym, rakietowym.
Model spiralny stara się jak najbardziej skrócić czas od momentu pojawienia się potrzeby to jej zaspokojenia, albo do świadomej rezygnacji z danego rozwiązania. Pięknie ilustruje to diagram przedstawiony w książce Boehma.
Dual Track Development
Marty Cagan wypromował odmienne podejście do systematycznego eksplorowania nowych idei. Określił je terminem podwójnej ścieżki, gdzie górna ścieżka odpowiada za odkrywanie, a dolna za dostarczanie. O ile górna ścieżka to seria eksperymentów, o tyle dolna to produkowanie rozwiązania w tradycyjnych sprintach. Z tą tylko różnicą, że regularnie, gdy zostanie dokonane nowe odkrycie, wnioski przeciekają z górnej do dolnej, wpływając na zakres prac produkcyjnych. Dobrze ilustruje to poniższy diagram.
Kluczową rolą w tym podejściu jest menedżer produktu. To w założeniach osobach o dużych kompetencjach zarówno biznesowych, jak i technicznych oraz mająca autorytet u kluczowych decydentów w organizacji. Ta rola pokrywa swoim zakresem odpowiedzialności również rolę product ownera ze scrum, natomiast wykracza daleko poza nią.
Druga rola występująca w zespole odkrywczym to projektant produktu. To osoba, która stara się przez odpowiednią konstrukcję cech produktu zrealizować założone cele biznesowe. Może projektować interfejs użytkownika, ale może wchodzić głębiej, w całe procesy obsługowe lub funkcje techniczne. Przeprowadza równie testy prototypów na klientach.
Wreszcie trzecią rolą jest inżynier, czyli specjalista, który zna się przede wszystkim na technologii i jest w stanie wyprodukować założone wymagania funkcjonalne. W produktach IT to będą programiści, w produktach fizycznych, elektronicy, projektanci opakowań, mechanicy itd.
Oprócz tych ról w zespole odkrywania produktu mogą pojawić się testerzy, analitycy danych, graficy, marketingowcy itp.
Co prawda w książce Zainspirowani Cagana nie jest w bezpośrednio opisane, ale można dojść do konkluzji, że zespół w pierwszej kolejności powinien postawić sobie pytania o istotność problemu klienta, zasadność produktu, przewagę na rynku, wykonalność rozwiązania, zgodność ze strategią i aby odpowiedzieć na nie powinien zaplanować eksperymenty.
Efektem działań kreatywnych oraz eksperymentów jest stworzenie listy wymagań funkcjonalnych w postaci mapy historyjek (user storymap). Mapa to podstawowe narzędzie do planowania i koordynacji wykonywania zakresu projektu. Mapa ma postać dwuwymiarowego arkusza, na którym rozmieszczone są historyjki (user stories), czyli w pewnym uproszczeniu wymagania funkcjonalne w projekcie. Oś pionowa reprezentuje kolejność ich realizacji, a oś pozioma ich kategorie. To odróżnia storymapę od tablicy kanban, która jest jednowymiarowa.
Rapid Learning Cycles
Katherine Radeka opisała w swojej książce podejście do realizacji innowacyjnych projektów w obszarze hardware nazwane RLC. Podobnie jak inni autorzy zwraca uwagę na to, że projekty urządzeń są specyficzne w porównaniu do programistycznych, czy organizacyjnych, bowiem wytwarzanie i testowanie prototypów jest kosztowne, prototypy w małej skali nie zawsze dobrze oddają zachowanie produktów w dużych skalach, produkty są wytwarzane w inny sposób i w innych miejscach niż tam, gdzie są projektowane.
Podejście promowane przez autorkę stoi w opozycji do tradycyjnego podejścia, któremu najbliżej jest do kaskadowego, gdzie koncepcję produktu przeprowadza się krok po kroku przez kolejne etapy. Głównym problemem jest rosnąca konieczność redukcji czasu wypuszczania na rynek, o czym już wielokrotnie wspominałem.
Odpowiedzią na ten problem jest zdefiniowanie projektu jako sekwencji eksperymentów, które przede wszystkim prowadzą do szybszego uczenia się, a przy okazji do stworzenia prototypu produktu. Tak można by podsumować ideę Rapid Learning Cycles. Moim zdaniem to paradygmat eksploracji w najczystszej postaci.
Projekt podzielony jest na sprinty, jednak różnica w stosunku do agile jest to, że sprinty mogą trwać nawet do kilkunastu tygodni. Autorka sugeruje dla projektów hardware’owych do sześciu tygodni, a dla farmaceutycznych do dwunastu tygodni na sprint.
W ramach pojedynczego cyklu zespół realizuje wiele pętli według schematu: Design – Experiment – Capture. Intencją tworzenia prototypu nie jest zbudowanie produktu, a zdobycie wniosków z eksperymentu To duża różnica, bo oznacza akceptację przez zespół tymczasowości swoich prac.
RLC zakłada zdefiniowanie na starcie projektu kluczowej hipotezy, która mówi o tym, czego się spodziewamy i co zakładamy odnośnie projektu. Kluczowa hipoteza składa się z trzech części: klienta, technologii i biznesu. Część dotycząca klienta odpowiada na pytanie, jakie ma on potrzeby, jakie wartości oczekuje, jak klient zamierza korzystać z rozwiązania, kim wreszcie jest klient. Część odnosząca się do technologii przyjmuje założenia, w jakim aspekcie technologia zadziała, czy spełni oczekiwania, jaką technologię zamierzamy wybrać dla rozwiązania. Ostatni element związany z biznesem stawia założenia co do tego, jak zamierzamy zarabiać na rozwiązaniu i jak utrzymać przewagę nad konkurencją.
Zdefiniowanie kluczowej hipotezy prowadzi do zidentyfikowania kluczowych decyzji w projekcie. Decyzje to sytuacje, w których zespół stoi na rozdrożu i mam możliwość wyboru spośród więcej niż jednego wariantu działania. Termin kluczowe oznacza, że chodzi nam tylko o te sytuacje decyzyjne, które albo skasują nam potencjalnie projekt, albo doprowadzą do zmiany kluczowej hipotezy. Tradycyjne projekty planowane są z tezą, że plan się uda, czyli nie potrzebujemy wariantów działania. Istnieje jeden harmonogram, jeden budżet. Natomiast dobrą praktyką projektów eksploracyjnych jest myślenie wariantywne, na które wskazuje Radeka i które również zostało szerzej opisane w rozdziale na temat drzewa eksperymentów. Właśnie owe kluczowe decyzje są rozgałęzieniami planu. Świadome planowanie eksploracji oznacza, że zespół z góry wie, że za kilka tygodni stanie przed dylematem wyboru drogi i że te najbliższe tygodnie mają doprowadzić do podjęcia jak najlepszej decyzji.
Scrum for hardware
Scrum for hardware jest adaptacją metodyki Scrum do projektów, w których wytwarza się fizycznie istniejące obiekty.
Tak więc mamy podział projektu na sprinty od dwóch do czterech tygodni. Mamy regularne spotkania planistyczne, na których ustalamy zakres na najbliższy sprint. Istnieją spotkania przeglądowe zespołu, tzw. Standupy, które niekoniecznie są organizowane codziennie. Ulman przytacza przykład zespołu budujące sztuczne ramię, który organizował standupy dwa razy w tygodniu.
Są spotkania odbiorowe sprintu nazywane review i wreszcie spotkania retrospektywne, na których zespół doskonali sposób prowadzenia projektu.
Różnicą jest wprowadzenie kroku przed projektem, w trakcie którego ustalane są cele projektu i organizowany jest zespół. Zespół ma od 4 do 9 członków i pokrywa wszelkie kompetencje potrzebne do wytworzenia produktu finalnego.
W tradycyjnym scrum zakłada się szacowanie historyjek za pomocą estymowania względnego. To jest takiego, które nie odnosi się do jednostek pracy ani czasu, tylko względnej wielkości. To mogą być koszulki (S, M, L, XL) lub story pointy. Takie podejście wynika z niepewności estymacji i próby unikania fikcyjnie precyzyjnych wycen. Pewnym zaskoczeniem dla mnie w metodyce scrum for hardware jest to, że zakłada się estymowanie kaskadowe, żywcem zapożyczone z PMBOK Guide (Ulman, rozdział Plan the project) oparte na wzorze estymacji trójpunktowej średniej ważonej. W zderzeniu z niepewnością takich projektów bardzo mi to zgrzyta.
Scrum for hardware za to stara się wypełnić lukę, którą pozostawił scrum – definiowanie wymagań. Scrum zakłada, że na podstawie już zebranych wymagań, przedstawionych przez product ownera, zespół planuje zakres w tzw. Backlogu.
Jednak zebranie wymagań to złożony i osobny krok w projekcie, któremu trzeba poświęcić osobną uwagę, a nie stwierdzić tylko, że product owner skądś przyniósł wymagania.
W tym miejscu proponuje się użycie techniki Quality Function Deployment, nazywanej po polsku domkiem jakości. Domek jakości powstaje w trakcie spotkań przedstawicieli biznesu i technologii i jego celem jest skompletowanie wymagań biznesowych w perspektywie działań konkurencji, strategii firmy, oczekiwań rynku, możliwości technologicznych i finansowych. Następnie te wymagania iteracyjnie są dekomponowane na coraz bardziej techniczne. Po drodze identyfikuje się relacje między wymaganiami oraz priorytetyzuje je.
Domek jakości kończy się zdefiniowaniem rozbudowanych tabel, które zawierają informacja o wymaganiach technicznych i ich współzależnościach.
W scrum for hardware proponuje się pójście jeden krok dalej i zdefiniowanie historyjek na podstawie wymagań z QFD. Tak więc QFD może być wstępem do zaplanowania product backlogu.
Przeglądając całą metodykę w poprzek, można zarysować taką hierarchię komponentów składających się na zakres projektu:
Cel projektu
Wymaganie z QFD
Historyjka
Zadanie w sprincie
Kluczowa dla powodzenia projektu hardware’owego jest modularyzacja zakresu. Oznacza to wczesne podzielenie koncepcji na części, które można rozwijać niezależnie. I tu pojawia się nowe wyzwanie – punkty styku poszczególnych modułów, czyli interface’y. Muszą one być niezmienne w czasie, aby integracja wielu modułów nie była złożona.
Eksploracja -> Iteracje
To podejście spotkałem w kilku dużych organizacjach o randze korporacji. W skrócie zakłada ono, że najpierw realizowany jest krótki i względnie tani projekt eksploracyjny, który ma potwierdzić główne wymagania techniczne i biznesowe, a potem dopiero planowany i uruchamiany jest projekt kaskadowy, gdy już wiadomo przy jakich założeniach go zaplanować.
Rys, Cykl życia projektu w podejściu eksploracja -> iteracje.
Ten schemat relacji między odkrywaniem a produkowaniem jest zbieżny z filozofią działania dużych organizacji. Potrzebują one innowacji i wkraczania na grząski grunt, ale jednocześnie chcą zapewnić sobie bezpieczeństwo rozwiązań, przewidywalność struktur organizacyjnych i ekonomiczną skalowalność.
Powołuje się zespół eksploracyjny, którego zadaniem jest badanie i generowanie prototypów. Taki zespół rekrutuje się z dedykowanego departamentu innowacji, strategii, technologii, albo menedżer wyznacza lider spośród swoich ludzi, a ten na bieżąco będzie organizował sobie potrzebne zasoby sprzętowe i ludzkie.
Czasem taki zespół ma nawet zgodę na działanie na granicy jakości i prawa. Stąd jego rozwiązania albo służą jedynie demonstracji możliwości, albo dedykowane są do małej skali, wewnętrznego użytku lub wykorzystania ograniczonego czasowo.
Po potwierdzeniu, że proof of concept lub demo ma wartość, jest ono archiwizowane, a wnioski służą jako podstawa do zaplanowania standardowego projektu, który może być zwinny lub kaskadowy.
Nie spotkałem utartej metodyki realizacji projektu eksploracyjnego w tym duchu. Pojawia się tu dużo inspiracji Scrum i Kanban oraz otwartość na pomysły prowizoryczne i eksperymentowanie.
Negatywnie do tej formuły odnoszą się zwolennicy dual track, argumentując, że wydłuża ona czas od hipotezy do wdrożenia oraz ogranicza innowacyjność na etapie produkowania.
Trochę w tym duchu zaprojektowana jest koncepcja design sprint omówiona chwilę wcześniej. Bowiem po takim sprincie rozpoczyna się planowanie “dorosłego” projektu.
Projekt eksploracyjny wewnątrz kaskadowego
To podejście przebija się pod powierzchnią modelu dojrzałości technologicznej (technology readiness level) oraz jest często wymuszane przez instytucje finansujące badania takie, jak NCBIR.
Rys. Cykl życia w projekcie kaskadowym zawierającym projekt eksploracyjny.
Symbolicznie prostokątami pokazano zadania kaskadowe w projekcie, w które co jakiś wpleciono podprojekt eksploracyjny.
W takie sytuacji formalnie organizacja prowadzi projekt kaskadowy z wyznaczonym budżetem i harmonogramem. Często również z góry planuje się wnioski, które zostaną odkryte w trakcie projektu. Następnie wyznaczony kierownik prowadzi dokumentację takiego projektu. Jego rolą jest stanowić bufor między kaskadowymi rygorami, jak data kamienia milowego, zakres prac w budżecie, regularne raportowanie, a zespołem odkrywców, który działa maksymalnie autonomicznie, jak to możliwe.
W takich warunkach bardzo dużo zależy od talentów i władzy kierownika projektu. Aby pogodzić ogień z wodą zespoły stosują szereg sztuczek takich, jak:
Realizacja finansowanego zakresu przed projektem – ta technika polega na tym, że w poprzednim projekcie dochodzi się do odkrywczych wniosków, jednak się ich nie publikuje, zachowując na potrzeby bieżącego projektu. W bieżącym projekcie planuje się “odkrycie” tychże wniosków a warunkiem koniecznym dokonania tego “odkrycia” jest zakup i instalacja drogiego sprzętu oraz wykonanie innych prac. I tak prowadzi się projekty na zakładkę. Bo w bieżącym też okaże się, że zespół dojdzie do odkrywczych wniosków, które zachowa dla kolejnego projektu.
Bardzo ogólne wymagania – cele i wymagania definiuje się na możliwie ogólnym poziomie, najlepiej w sposób niemierzalny, aby przy odbiorach dało się obronić to, co naprawdę udało się osiągnąć.
Stosowanie nierealnych buforów na czasie i koszcie – zakłada się nadmiarowe koszty i czas na projekt, co ma pozwolić na konsumpcję ewentualnych ryzyk.
Wyjęcie z zakresu projektu rzeczy niepewnych a pozostawienie tylko źródeł kosztów – w tej technice w zakresie projektu pozostawia się jedynie niezbędne minimum, czyli komponenty, dla których projekt musi być nadzorowany. Chodzi przede wszystkim o drogie pozycje kosztowe. W ten sposób projekt może mieć cel polegający na kupieniu zaawansowanej aparatury i pokazaniu, że została zainstalowana, natomiast faktyczne prace eksploracyjne będą prowadzone już po jego zakończeniu.
To podejście pasuje do wspomnianego na początku rozdziału modelu spiralnego. Z góry inwestycję nadzoruje się za pomocą modelu spiralnego, a na dole realizowany jest projekt kaskadowy z wklejonymi w niego eksperymentami.
W literaturze przedmiotu można wyróżnić trzy nurty myślenia o zarządzaniu projektem o dużym stopniu niepewności, którego celem jest przede wszystkim dostarczenie wiedzy:
