Fuzzy Frontend, a w moim kreatywnym tłumaczeniu Rozmyty Rozruch, to cecha, która wymusza nieco inne podejście do realizacji projektów niż agile albo waterfall. Fuzzy Frontend oznacza, że na starcie mamy tylko niejasne wrażenie, co powinno być dostarczone. Zamiast jednej wizji końca, na podstawie której zespół może przejść do planowania kaskadowego lub zwinnego, mamy zbiór alternatyw, chmurę, w której musimy odkryć, jaki kształt wizji oferuje największą wartość. Ten termin został ukuty na określenie projektów wdrażających nowe produkty na rynek (NPD – new product development), ale ma również zastosowanie dla projektów naukowych i opracowujących nowe technologie.
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
Dobrze ilustruje to lejek niepewności, pokazany poniżej.
Rys. Lejek niepewności w projekcie eksploracyjnym.
Zaczynamy od znaków zapytania i pomysłów, które wymagają weryfikacji. Stopniowo zamieniamy najciekawsze pomysły na hipotezy (nie cele!) i planujemy sposób ich zbadania, na przykład przez przeprowadzenie eksperymentu, obserwacji, wywiadu. Niepewność nam maleje. Odrzucamy nieistotne obszary i fałszywe założenia. Z czasem coraz więcej wyników eksperymentów daje podstawę do zaplanowania zakresu, który złoży się na przyszłe rozwiązanie. Niepewność redukuje się jeszcze bardziej.
Na eksplorację i produkcję w projektach można spojrzeć z perspektywy pewności realizacji komponentów składających się na zakres. W momencie planowania projektu kaskadowego bądź zwinnego zakłada się, że dany element zakresu ma sens, jest potrzebny oraz da się go wykonać. To niekoniecznie jest prawdą, ale tak się w ukryty sposób zakłada.
Gdy projektujemy drzwi, zakładamy, że ktoś będzie przez nie przechodził, że ich sposób otwierania będzie akceptowalny dla ludzi. Gdy stawiamy nową linię technologiczną, zakładamy, że zamówione maszyny spełnią wymagania jakości i wydajności, że będziemy mieli wystarczającą liczbę zamówień, aby uzasadnić ich kupno i że materiały będą odpowiednie do obróbki przez te urządzenia. Gdy programujemy sklep internetowy, zakładamy, że klienci przyjdą i będą kupować, że oczekuję, iż sklep będzie miał funkcjonalności związane z podpowiadaniem produktów i określonym sposobem wyszukiwania. Na podstawie optymistycznych założeń buduje się zakres.
Natomiast świadomość eksperymentatora podpowiada, że nie wszystkie komponenty zakresu są pewne. Co do niektórych warto zadać pytanie, czy na pewno są potrzebne, czy na pewno ktoś z tego skorzysta, czy na pewno ktoś to zamówi, czy na pewno to zadziała. Wszędzie tam, gdzie świadomie podważamy zasadność produkcji, wchodzi w obszar eksploracji. Jak będę starał się wykazać to na kartach niniejszej książki, wybór podejścia eksploracyjnego zależy od modelu mentalnego decydentów i zespołu.
Innymi słowy część zakresu z backlogu lub struktury podziału prac może mieć dopisane znaki zapytania, jeżeli zespół ma pokorę i świadomość swojej niewiedzy. Te znaki zapytania implikują hipotezy, które należy zweryfikować eksperymentalnie.
W danym projekcie liczba elementów zakresu, przy których zespół wstawił znaki zapytania może być różna i w dużej mierze zależy od subiektywnej świadomości, na ile rzeczywistość jest nieprzewidywalna. Zespoły bardzo pewne siebie nie postawią żadnego pytajnika, z resztą nie wybiorą pewnie ścieżki eksploracyjnej. Zaś zespoły w organizacjach o wysokiej kulturze eksperymentowania tych znaków zapytania zapewne postawią wiele.
Ta świadomość niepewności później determinuje naturę projektu. Zdarzyło mi się widzieć projekty planowane z precyzją do pojedynczego dnia, które na końcu okazywały się całkowicie bezużyteczne.
W pewnej firmie finansowej został zbudowany system dla klientów. Po kilku miesiącach od wdrożenia okazało się, że żaden klient się nawet nie zalogował. Powodem było to, że klienci nie widzieli wartości w zakładaniu konta do kolejnego systemu, woleli o bieżące sprawy nadal pytać konsultantów. Tylko, że na początku projektu przyjęto założenie, że taki system jest niezwykle potrzebny i na tej podstawie zaplanowano zakres bez żadnych znaków zapytania.
Inny przykład, w pewnym startupie właściciel zamierzał stworzyć usługę i narzędzie informatyczne do współpracy z partnerami. Zaczął od szczegółowego planowania wymagań. Wyszedł z tego projekt na kilka miesięcy. Zrobiliśmy jednak sesję warsztatową, której głównym celem było “wciśnięcie” znaków zapytania do tego projektu. Szybko okazało się, że wcale nie ma pewności, że partnerzy będą zainteresowani współpracą, że oferta będzie dla nich interesująca i pojawiło się ryzyko, że mogą wręcz nadużyć zaufania tego startupu dla swoich korzyści, zabierając klientów. Projekt zwinny zamieniono na eksploracyjny. Postawiono kilka hipotez takich, jak: czy firma pozyska 50 partnerów w ciągu miesiąca, czy skuteczność pozyskiwania partnerów będzie na poziomie 50%, czy każdy z 50 partnerów przyniesie jednego klienta. Nagle okazało się, że wartość projektu wcale nie jest taka pewna. Jednocześnie ujawniły się obszary, na których najpierw należało się skupić. Okazało się, że zakres prac potrzebny do potwierdzenia tych hipotez jest dużo mniejszy i nie ma konieczności budowania całego narzędzia informatycznego, aby sprawdzić, czy rynek jest gotowy na nową usługę. Wielokrotnie szybciej ów startup mógł uzyskać wartościowe odpowiedzi. W dalszej części książki wskażę, ci Drogi Czytelniku, wagę słowa “najpierw” w eksplorowaniu nieznanych terenów.
Zatem ten sam projekt w zależności od postaw, albo inaczej ujmując rzecz kultury eksperymentowania, może być traktowany jak tradycyjny, albo jak eksploracyjny.
Podejście kaskadowe (ang. waterfall) ma w tle wmalowane unikanie ryzyka. Tworzy się szczegółowe plany, przygotowuje procedury, w skrajnej sytuacji promuje przekazywanie wyłącznie pozytywnych komunikatów w projekcie (dobrym pomysłem jest strzelanie do posłańców złych wieści), aby stworzyć wrażenie kontroli.
Połowa z 49 procesów projektowych wymienionych przez PMBOK Guide 6, to procesy planowania. Kolejnych kilkanaście to procesy kontroli. Zostaje jeden proces, który wprost odnosi się do uczenia. Jeden! Nazywa się Manage Project Knowledge i niewiele mówi, jak faktycznie to robić. To tak, jakby założycielowi startupu mentor dał radę “idź zarobić pieniądze”, niby prawda, ale niczego to nie zmienia.
Tradycyjne podejście działa, ale pod warunkiem, że poziom wiedzy o materii projektu i jego otoczeniu jest wystarczająco wysoki. Tak buduje się mosty, czy kanały żeglugowe, niekiedy systemy informatyczne albo migruje produkcję między fabrykami.
Projekty eksploracyjne biorą inną perspektywę za punkt wyjścia. Zakładają, że to poznanie ryzyka jest celem samym w sobie, bo niesie wiedzę. Tam, gdzie jest najbardziej grząsko, najwięcej się nauczymy. Im więcej nie wiemy, tym jest ciekawiej. Zatem w podejściu eksploracyjnym szukamy najpierw najbardziej bagiennych miejsc i wbijamy tam kijek.
W podejściu kaskadowym zarządza się zmianą jako odchyleniem od zamierzeń. Czyli domyślnie przyjmuje się, że zmiana jest niekorzystną sytuacją, która powinna była zostać przewidziana na samym początku. Kontrola kondycji projektu opiera się sprawdzaniu wykonania oraz prognoz i porównywaniu ich do zatwierdzonego planu, tzw. planu bazowego. Metoda wartości wypracowanej wywodzi swoje wskaźniki zdrowia projektu z odejmowania od wartości wykonania wartości planu (współczynniki CV, SV, TV) albo dzielenia tychże parametrów przez siebie (CPI, SPI) albo jedno i drugie (TCPI, EAC). Podobnie analiza ścieżki krytycznej sprowadza się do porównywania dat rzeczywistych do planowanych oraz wyliczania, czy jeszcze mamy bufor czasowy, czy już opóźnienia nie da się ukryć. W metodzie łańcucha krytycznego analizuje się, czy tempo konsumpcji bufora jest zgodne z założeniami.
To implikuje, że w podejściu kaskadowym zakłada się, że wiedza o projekcie na jego początku jest niemal kompletna. Niepewność, która pozostaje może spowodować niewielkie odchylenia na koszcie, czy terminie wykonania, ale generalnie plan na koniec projektu zgodzi się z rzeczywistością. W kontraktach używa się terminu “fixed price”, a w rozmowie o terminach “deadline”. To pokazuje, jak bardzo filozofia, która zakłada wysoką pewność wiedzy o przyszłości przenika myślenie kaskadowe. W efekcie zespół bywa zniechęcany do eksperymentowania, bo to powoduje zejście z wytyczonej drogi, podważanie status quo decydentów i branie na siebie ryzyka.
W podejściu eksploracyjnym projekt zaczyna się od stwierdzenia “nie wiemy” i jego celem jest zdobycie tej wiedzy. To utrudnia kontrolę przez odchylenia, ale w sytuacji wysokiej niepewności jakikolwiek plan skazany byłby na porażkę. Tutaj zespół sam wytycza nową ścieżkę przez las.
Pamiętajmy, że poziom niepewności nie zależy od woli sponsora projektu, tylko od tego, co naprawdę wykonujemy w projekcie. Możemy, niczym pewne instytucje nadzorujące badania, wymusić na zespole zadeklarowanie, co odkryją w wyniku swoich eksperymentów. Jednak to nie zmieni sytuacji, że te zespoły wcale mogę takich odkryć nie dokonać. Wprost przeciwnie, mogą odkryć coś zupełnie innego, być może jeszcze ciekawszego.
Warto podkreślić, że podejście zwinne (ang. agile) wychodzi naprzeciw niepewności, bo zakłada, że zespołowi trzeba zaufać w aspekcie sposobu realizacji projektu. Klient musi z grubsza wiedzieć, czego chce, powinien postawić cele, a w razie pytań doprecyzować swoje wymagania, taka jest rola product ownera. Zaś zespół na bieżąco analizuje, jak jeszcze lepiej zrealizować te cele. Niekiedy podpowiada, jak je również zmodyfikować.
Aby móc zapewnić takie wsparcie zespół musi czuć się zmotywowany i odpowiedzialny. To zapewnia się przez danie mu autonomii. Oczekuje się, że ludzie będą samodzielnie kombinować, jak tu dostarczyć większą wartość. Scrum, najpopularniejsza z metodyk zwinnych, świetnie działa, w sytuacji, gdy mamy zmotywowany i kompetentny zespół, który rozumie wizję końca, ale jednocześnie ma swobodę i cieszy się zaufaniem w aspekcie modyfikacji szczegółów.
Jednak agile zatrzymuje się, gdy dochodzi do postawienia celów projektu na głowie, gdy trzeba dokonać pivota. Zwinny projekt świetnie działa, gdy zespół ma zadanie cały czas podnosić swoją sprawność, aby dotrzeć do wskazanego celu. Nawet wtedy, gdy ten cel trzeba nieznacznie przesunąć, aby zwiększyć wartość projektu, agile nadal wykazuje swoją wartość. Natomiast w momencie rewolucji, rezygnacji z celu i zastąpienia go innym, w startupach na określenie takiej sytuacji stosowany jest termin pivot, pojawia się opór w zespole. Opór wynika z poczucia autonomii zespołu, która tym pivotem jest zabierana. Wynika też z chęci bycia konsekwentnym. Im więcej zainwestowaliśmy, tym bardziej chcemy brnąć w to bagno. W agile ciężko jest zrobić nagły zwrot o dziewięćdziesiąt stopni. Bardziej naturalne jest wchodzenie w łagodny zakręt w efekcie stopniowych uzgodnień, głosowań i wzajemnego przekonywania się.
A już podjęcie jednoosobowej decyzji o zmianie marszruty, jaką często dokonują liderzy zespołów badawczych, czy założyciele startupów, stoi w zupełnej sprzeczności do zasady przywództwa służebnego. Wszak przywódca wspierający powinien jedynie zachęcać swoich ludzi do znalezienia właściwego rozwiązania, a nie narzucać im cokolwiek. To odebrałoby im poczucie właścicielstwa i naraziło motywację wewnętrzną. Więc zespół wykonuje łuk o dużym promieniu i stopniowo skręca, tracąc czas.
