Cykl życia projektu
Podstawowym celem zarządzania projektem eksploracyjnym jest skracanie pętli uczenia się od zdefiniowania problemu do dostarczenia wniosków. Tym samym skracaniem przepaści wykonalności (feasibility chasm), czyli czasu między zdefiniowaniem wymagania przez klienta, a udzieleniem odpowiedzi, czy w ogóle da się i jak je zrealizować.
Artykuł jest fragmentem książki Bardziej niż Agile będącej w trakcie druku: https://onepress.pl/ksiazki/bardziej-niz-agile-marcin-zmigrodzki,baragi.htm#format/d
Podstawowym celem projektu jest zdobycie wiedzy na zadany temat i na odpowiednim poziomie wiarygodności.
Głównym priorytetem projektu jest czas-czas-czas. W przeciwieństwie do projektu kaskadowego, w którym negocjuje się kompromis między wszystkimi wymiarami i projektu zwinnego, w którym celem jest satysfakcja użytkownika.
Projekt eksploracyjny warto podzielić na kilka podstawowych etapów. Poniżej przedstawiam ich schemat. Odniesienie do tego modelu znajdziesz również przy okazji kolejnego rozdziału na temat wygrywania hackathonów.
Poniżej zostały omówione poszczególne etapy z diagramu cyklu życia projektu eksploracyjnego.
Inicjacja
Inicjacja projektu jest terminem zaczerpniętym z podejścia kaskadowego. Na tym etapie osoba nadzorująca projekt podejmuje decyzję o zainwestowaniu w niego. To może być dyrektor innowacji w korporacji, prezes, szef jednostki naukowej, zewnętrzna instytucja finansująca badania lub założyciel startupu.
Inicjacja powinna zakończyć się podpisaniem dokumentu, tzw. karty projektu, który konstytuuje projekt, głównych jego uczestników i ogólne założenia wymagań, kosztów i czasu. Inicjacja powróci jeszcze przy okazji omawiania wyższego poziomu zarządzania projektem eksploracyjnym.
W odróżnieniu od karty tradycyjnego projektu w tym wypadku warto zdefiniować nie tyle zakres, co zestaw ograniczeń i założeń, które następnie zostaną zamienione na hipotezy a nie cele. Można w zamian wyznaczyć obszar, który będzie podlegał badaniu. Jest to dobry wstęp do zarządzania projektem z perspektywy ograniczeń. Przypomnij sobie termin SBCE – set-based concurrent engineering i wymiarowanie projektu, a także koncepcję drzewa eksperymentowania, bo o ile posiadana wiedza na to pozwala, warto już na tym etapie zdefiniować drzewo eksperymentowania, o którym mowa w poprzednich rozdziałach.
Zatem na starcie sponsor projektu wypełnia kartę projektu, która zawiera informacje o uzasadnieniu projektu, głównym problemie badawczym, ramach projektu czasowych i kosztowych, sposobie wykorzystania zdobytej wiedzy w działalności organizacji i dalszych potencjalnych planach wynikających z uzyskanych efektów projektu, i przekazuje ją zespołowi. Przykład takiej karty zaprezentowany jest poniżej.
Karta jest podstawą do zawiązania zespołu i rozpoczęcia prac planistycznych. Kluczowe dla zespołu, który ma badać nową wiedzę jest świadomość, co dalej w perspektywie strategicznej, organizacja zamierza zrobić tą wiedzą. Projekt eksploracyjny nie powinien być uruchamiany wyłącznie dla zaspokojenia czyjejś ciekawości, tylko powinien łączyć się z planami strategicznymi organizacji.
Ponadto zrozumienie szerszego kontekstu przez zespół, może pozwolić uwolnić ich kreatywność i przyjść z kierunkami eksploracji, o których sponsor nawet sobie nie śnił.
Techniki: karta projektu, drzewo eksperymentowania, lista ograniczeń.
Analiza wymagań klienta, identyfikacja i eksploracja źródeł wiedzy
Ten i następne dwa etapy często są realizowane w ramach jednej fazy, wówczas przypomina ona fazę planowania z tradycyjnych projektów. Jednak występują istotne różnice.
Pierwsza z nich dotyczy gromadzenia wiedzy. Projekty eksploracyjne są adresowane do bardzo niepewnych obszarów, co oznacza, że zespół działa po omacku. Wielu z moich rozmówców wskazało, że pierwsze, co robią po usłyszeniu celów projektu, to szukają istniejącej wiedzy. Ktoś już na pewno testował dany układ elektroniczny, algorytm, próbkę danych, pomysł na biznes etc. W przypadku oprogramowania takim źródłem nowej wiedzy są serwisy w stylu Papers with Code, Hugging Face, czy Kaggle. W przypadku badań naukowych mamy na przykład Research Gate i Academia. Dla studenckich projektów hardware’owych znalazłem serwis Nevon Projects.
Jeżeli firma wdrożyła kulturę eksperymentowania, o czym więcej w kolejnym rozdziale, to prawdopodobnie dysponuje bazą wiedzy zawierającą doświadczenia z przeszłych projektów. Warto do niej sięgnąć.
W trakcie analizy wymagań i eksploracji wiedzy następuje rozproszenie się zespołu na wiele wątków. W tym etapie ważna jest różnorodność przynoszonych przez członków zespołu spostrzeżeń, pomysłów i konkluzji. Im bardziej szeroko drużyna rozwinie swoje poszukiwania, tym lepiej dla projektu. Pamiętacie zapewne koncepcję naprzemiennej dywergencji i konwergencji, albo podwójny diament.
Efektem analizy wymagań jest albo spisanie ich na ogólnym poziomie, np. w przypadku nowych produktów z użyciem modelu Kano lub Design Thinking. Albo stworzenie rejestru wymagań w postaci dokumentacji lub tabeli wymagań.
Techniki i metody: biała tablica, warsztaty definicji produktu, lektura źródeł naukowych, techniki analizy wymagań, firmowa baza wiedzy, baza ekspertów.
Tworzenie koncepcji
Kolejnym etapem w ramach planowania projektu jest stworzenie wstępnej koncepcji. Koncepcja to pomysł, jak zabrać się za rozwiązywanie problemu. Składa się z mnóstwa założeń, które w trakcie projektu będą potwierdzane lub obalane. Jednak ważnym czynnikiem przyszłego sukcesu jest rozpoczęcie z przemyślaną koncepcją.
Na etapie tworzenia koncepcji następują zawężenie obszaru zainteresowań zespołu. Jest to odwrotność podejścia w porównaniu do poprzedniego etapu analizy i poszukiwania wiedzy. Ludzie odrzucają obszary merytoryczne, które nie rokują, albo nie będą przydatne. Koncentrują się wokół wybranej koncepcji.
Koncepcja początkowo może składać się z kilku luźno powiązanych koncepcji. Na start mogą między nimi istnieć sprzeczności, ale zespół wierzy, że zostaną z czasem wyeliminowane w toku kolejnych prototypów w duchu metody SBCE.
Techniki i metody: biała tablica, burza mózgów, analiza systemowa, drzewo eksperymentowania, baza ekspertów eksperci.
Strukturalizacja koncepcji
W tym etapie koncepcja jest “cięta” na mniejsze części zgodnie z obszarami merytorycznymi lub zainteresowaniami członków zespołu. W przypadku projektu hardware’owego to może być na przykład obudowa, mechanika, elektronika, oprogramowanie, marketing. W przypadku projektu programistycznego to może być podział taki, jak: backend, baza danych, moduł sztucznej inteligencji, frontend, grafika, marketing.
Celem jest stworzenie głównych obszarów zadań w projekcie. W projekcie kaskadowym powiedzielibyśmy o tworzeniu struktury podziału prac (WBS). W projekcie eksploracyjnym zwykle wystarcza podział na kilka poziomów: najpierw moduły koncepcji, a potem ich zadania. Do pewnego poziomu faktycznie widoczna jest struktura charakterystyczna dla WBS, zaś liśćmi tego drzewa są zadania i wymagania opisane podobnie jak w projekcie zwinnym. Zatem mamy tu do czynienia ze struktura hybrydową.
Strukturalizacja koncepcji obejmuje również strukturalizację odpowiedzialności, czyli jednoznaczne przypisanie, kto robi co. Charakterystyczną cechą dla projektu eksploracyjnego jest niska wymienność kompetencji między członkami zespołu. Na ogół dysponujemy wąskim specjalistami z rozłącznych dziedzin. Oni muszą się dogadać, ale niekoniecznie muszą się zastępować. Stoi to w sprzeczności z założeniami Scrum, gdzie zespół grupowo analizuje zakres i wycenia zadania, co implikuje posiadanie wiedzy na temat wszystkich zadań u wszystkich członków zespołu. W projekcie eksploracyjnym ekspert A często nie rozumie, co robi ekspert B. Zatem raczej przypisujemy jednoosobowo odpowiedzialność za produkty projektu.
Techniki i metody: tablica kanban, szablon WBS/backlog, dekompozycja zakresu, baza ekspertów.
Eksplorowanie
Jeff Gothelf i Josh Seiden w książce Lean UX proponuję cykl życia projektu odkrywczego składającego się z czterech etapów: postawienie hipotez, przeprowadzenie badań, stworzenie MVP, zaprojektowanie rozwiązania. To podejście implikuje, że cały projekt podlega globalnej pętli, która rozwija się jednym rytmie. Sądzę, że jest jednak inaczej, że takich pętli w ramach eksplorowania jest wiele, mają różną długość, nakładają się na siebie i nie prowadzą do stworzenia jednego MVP, tylko metodą kolejnych przybliżeń nakierowują projekt na coraz doskonalsze rozwiązanie.
Wreszcie, gdy mamy zebrane wymagania, przeglądnęliśmy źródła wiedzy, mamy całkiem atrakcyjną koncepcję, którą właśnie podzieliliśmy na moduły i rozdzieliliśmy kompetencyjnie, to możemy przystąpić do realizacji projektu eksploracyjnego.
Ten etap skupia się na planowaniu i realizacji eksperymentów. Z reguły jest podzielony na mniejsze kroki, czyli iteracje, o których mowa dalej. Iteracje jednak, powtórzę to po raz kolejny, są bardzo nieregularne i nakładające się na siebie.
Może wystąpić sytuacja, kiedy w jednym module prowadzi się eksperyment trwający miesiąc, w drugim trwający tydzień, a w trzecim od jednego do trzech dni. Zatem termin iteracja raczej odnosi się do poszczególnym modułu zakresu, a nie całego projektu.
Każdy eksperyment podąża podobnym cykle: hipoteza, planowanie eksperymentu, przeprowadzenie eksperymentu, zebranie wyników. Kolejność eksperymentów układa się według niepewności hipotez. Najpierw te wywracające potencjalnie cały projekt, a na końcu te jedynie modyfikujące nieznacznie parametry rozwiązania.
Techniki i metody: tablica kanban, baza wiedzy, prototypowanie, drzewo eksperymentowania, SBCE.
Metodykę prowadzenia projektu eksploracyjnego podzieliłem na dwa poziomy: poziom nadzoru projektu i poziom jego realizacji.
