utworzone przez Marcin Żmigrodzki
W grudniu 2019 Chiny poinformował WHO o nietypowej chorobie płuc, jaką zaobserwowano u kilkudziesięciu pacjentów w mieście Wuhan. Niecały rok później zaszczepiono pierwszego pacjenta na COVID-19. Takie tempo miał projekt “lightspee”.
Kiedy Pfizer zawiązał alians z Biontechem, którego celem było wyprodukowanie szczepionki na nowy szczep grypy, zespół nie miał zadanego z góry terminu. Ale dla wszystkich było jasne, że trzeba się spieszyć. Dziesiątki tysięcy zgonów dziennie, globalna izolacja, spowolnienie gospodarcze były dostatecznie silnymi czynnikami motywującymi do pośpiechu.
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
Dostarczenie nowego specyfiku na rynek nie składa się tylko z prac badawczych, ale i regulacyjnych, logistycznych i produkcyjnych. Na ogół poszczególne etapy następują po sobie. Kiedy już wypracowana jest skuteczna i bezpieczna substancja, rozpoczyna się poszukiwanie potencjalnych dostawców. Po zakończonych pracach R&D można zdefiniować wymagania procesów logistycznych i technologicznych. Można wreszcie wycenić produkcję, jeżeli potrzeba zaangażować podwykonawców zewnętrznych.
W przypadku szczepionki na SARS-CoV-2 taka współpraca z zewnętrznymi partnerami była konieczna. Bowiem jak najszybciej po uzyskaniu działającej substancji należało rozkręcić produkcję na olbrzymią skalę, aby dotrzeć do pacjentów na całym świecie.
Ten pośpiech dobrze ilustruje uzgodniony sposób finansowania projektu między Pfizer i Biontech. Otóż koszty miały być dzielone po połowie, ale Pfizer zgodził się zapłacić za całość prac z góry, czyli wziąć na siebie ryzyko niepowodzenia. Zaraz po podpisaniu umowy między spółkami od razu przelał 72 miliony dolarów na startowe koszty oraz zabudżetował kolejne 562 miliony dolarów na dalsze wydatki w projekcie. Planowanie niemal miliardowego projektu i negocjowanie kontraktu inwestycyjnego zajęło raptem około miesiąca.
Normalnie taki projekt prowadzony jest w skrajnie kaskadowy sposób. Etap po etapie od cząsteczki po testy kliniczne realizuje się badania, analizuje wyniki zatwierdza kolejny krok i dopiero rusza dalej.
Teraz przyjęto założenie, że co tylko można będzie realizowane równolegle. Jak wspominają pracownicy Pfizera uzgadniano wymagania technologiczne, gdy nie wiadomo było jeszcze, czym będzie owa substancja, bo wciąż trwały badania. Podejmowano zobowiązania biznesowe na podstawie większej liczby znaków zapytania, niż odpowiedzi. W marcu 2020 roku ruszyły prace badawcze Pfizera i Biontech, a już 3 miesiące później rozpoczęto przygotowania do produkcji. Trzeba było zaprojektować i wyprodukować specjalistyczne opakowania na szczepionki. Wymyślono, że szczepionki będą przesyłane w pudłach wypełnionych suchym lodem, co zapewni temperaturę -70 stopni nawet do dwóch tygodni. Pudło miało być dodatkowo wyposażone w termometr, GPS i czujnik światła i przesyłać te dane w czasie rzeczywistym do Pfizera.
Aby zrównoleglić prace nie tylko nakładano etapy na siebie, tzw. fast-tracking, ale i prowadzono wiele równoległych badań w różnych kierunkach (patrz rozdział na temat drzewa eksperymentowania). Naraz testowano różne kombinacje związków, w różnych dawkach, aby zebrać wyniki w tym samym czasie. Szybko uzyskiwano informację, które kombinacje rokują, a które nie i ponownie przechodzono do masowych testów z najlepszym kandydatem z poprzedniej fazy. Na przemian dywergencja i koncentracja i w tak wiele razy. Główne zagrożenia były dwa: po pierwsze takie podejście będzie wyjątkowo dużo kosztować, ale siła wyższa w postaci zbliżającej się epidemii i rządowego finansowania to kompensowało, po drugie możliwe, że do kolejnych etapów przejdzie nieoptymalny kandydat.
Dlaczego warto było inwestować w zrównoleglenie prac? Bo przykładowo już na początku badań było wiadomo, że kandydaci do szczepionki będa wymagali przechowywania i transportu w wyjątkowo niskiej temperaturze, co rodziło spore wyzwania logistyczne.
To w konsekwencji mogło prowadzić do nadmiernych kosztów, nadmiarowej pracy, ale priorytet był jeden – czas, czas, czas.
W 9 miesięcy opracowano i wypuszczono na rynek skuteczną szczepionkę na Covid 19, wydając po drodze 3 miliardy dolarów. Dla porównania typowy czas przy poprzednich szczepionkach wynosił 10 lat przy koszcie od 1 do 2 miliardów dolarów (Bourla 2021).
Jedną z praktyk, których celem jest kompresja czasu trwania projektu jest tzw. Fast-tracking. Polega on na tym, że dwa zadania, które powinny następować po sobie są realizowane częściowo przynajmniej równolegle. Symbolicznie prezentuje to poniższy rysunek.
utworzone przez Marcin Żmigrodzki
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.
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
Model spiralnie rosnącego zaangażowania
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:
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.
utworzone przez Marcin Żmigrodzki
Jeden z głównych problemów, przed którym stoją twórcy nowych produktów można zdefiniować w ten sposób. Mamy technologię, której chcielibyśmy użyć, ale nie wiemy, jaka grupa klientów chciałaby z niej skorzystać, w jaki sposób i za co chciałaby płacić.
Historia mojego nieudanego projektu aplikacji mobilnej do quizów Quattro Quiz oraz udanego projektu Word Wall, o których wspomniałem w rozdziale na temat drzewa eksperymentowania zainspirował mnie do rozwinięcia prostej techniki grupowego rozwiązywania problemów. Technika ta jest inspirowana analizą morfologiczną wymyśloną przez Fritza Zwicky, astrofizyka pracującego w Caltech, który użył jej do rozwiązywania problemów technicznych związanych z konstrukcją silników odrzutowych.
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
Zgodnie z tamtą techniką należało stworzyć tabelkę, w której kolumnami byłyby krytyczne funkcje danego systemu, a wartości kolejnych wierszy – sposoby zrealizowania tych funkcji. Zakres produktu powstawałby przez tworzenie kombinacji różnych rozwiązań dla każdej z funkcji. Ilustracyjnie obrazuje to poniższa tabelka.
Przykład analizy morfologicznej funkcji.
Uczestnicy warsztaty tworzą warianty systemu z wszelkich kombinacją rozwiązań i dyskutują od nich. Odrzucają te, które nie spełniają wymagań i finalnie wybierają najlepszą kombinację.
Adaptacja analizy morfologicznej do tworzenia propozycji wartości polega na zdefiniowaniu każdej z kolumn tabelki według schematu: grupa klientów, problem, wartość, zadanie do wykonania. Nie ukrywam inspiracji w tym przypadku również techniką value proposition canvas stworzoną przez Osterwaldera i innych.
Najlepiej będzie, jeżeli posłużę się przykładem własnego projektu, aby zaprezentować użycie tej techniki.
Przykład zastosowania value proposition mix dla projektu Quattro Quiz.
Pierwszy wiersz w poniższej tabelce pokazuje propozycję wartości, którą wybrałem, projektując aplikację Quattro Quiz. Gdy po latach ją czytam, jasne jak słońce staje się dla mnie, jak niszowy produkt wymyśliłem. To nie miało prawa się udać. Bowiem, ilu jest na świecie ludzi przygotowujących się do egzaminu PMP, dla których problemem jest fakt, że rycie terminów jest nudne i w zamian chcieliby skorzystać ze swojego telefonu komórkowego oraz “zabawnej” aplikacji mobilnej. Heh…
Drugi wiersz powyższej tabelki reprezentuje mutację mojej aplikacji, jaką wypuściliśmy niedługo po zrozumieniu, że pierwsza wersja to katastrofa. Zmieniliśmy temat na filmy oraz drinki i obserwowaliśmy, co się dzieje. Niestety nic się nie działo. Dlaczego? Bo jak później wykazała analiza aplikacji mobilnych do quizów brakowało nam trzech elementów w korzyściach: rywalizacji z innymi graczami, ładnej grafiki, która by “nagradzała” gracza za sukcesy oraz dużej bazy quizów. Gdy rozwiązuję test dla zdobycia certyfikatu, to jego wygląd i ozdobniki nie mają znaczenia. Jednak gdy robię to dla zabawy i zabicia czasu, te aspekty stają się krytyczne.
Ostatni wiersz w powyższej tabelce prezentuje propozycję wartości, jaką wyobrażam z sukcesem sobie realizuje Word Wall. Dzieciom dostarcza atrakcyjne formy sprawdzania wiedzy, w tym grę w wisielca, czy quattro quiz, które mają na celu przyswojenie porcji wiedzy zadanej przez nauczyciela.
Koncepcja Value Proposition Matrix (VPM) zakłada jednak pójście dalej z generowaniem wariantów propozycji wartości. W omawianym tu przykładzie pierwszy podział, jaki rzuca się w oczy, to na użytkowników dorosłych i dzieci. Drugi podział to na urządzenia mobilne i komputery. Trzeci to robienie nietypowych quizów dla edukacji i dla zabawy. Na tej podstawie możemy wygenerować 8 wariantów propozycji wartości.
Aby stworzyć tabelkę VPM do kolumny grupy klientów wpisujemy wszystkie zidentyfikowane segmenty. Do kolumny problem wpisujemy, jakie problemy mogą mieć wymienione wcześniej segmenty, które to można by potencjalnie rozwiązać posiadaną technologią. Do kolumny zadanie wpisujemy, co potencjalny segment użytkowników miałby robić z użyciem naszej technologii.
Otrzymujemy w ten sposób trójwymiarową przestrzeń możliwych propozycji wartości, w której możemy konstruować różne propozycje wartości dla różnych kombinacji klientów, problemów i zadań. Przykład takich propozycji wartości ilustruje poniższa tabelka.
Do tematu analizy alternatyw wrócimy jeszcze przy okazji dyskusji o zarządzaniu projektami z perspektywy ograniczeń, wymiarowaniu projektów i set-based concurrent engineering.
Przykładowa tabelka Value Proposition Matrix.
Według tej techniki propozycja wartości to sposób wykorzystania naszej technologii do wsparcia wykonywania zadań adresujących określony problem lub potrzebę wybranej grupy klientów. W ramach burzy mózgów bierzemy przykładową kombinację cech z trzech pierwszych kolumn i zastanawiamy się, czy nasza technologia może im coś zaoferować. Jeżeli tak, to wpisujemy dla tej kombinacji Grupa klientów + Problem + Zadanie wymyśloną propozycję wartości. Propozycja wartości nie jest opisem idealnego stanu zadowolenia danej grupy klientów, tylko sugestią, w jaki sposób nasze rozwiązanie mogłoby odnaleźć się w problemie i zadaniach tej grupy. Ograniczeniem, jakie towarzyszy nam przy stosowaniu VPM jest technologia, z której chcemy skorzystać, aby wesprzeć klientów.
W powyższym przykładzie wpisałem, jak się okazało później nieudaną, propozycję wartości realizowaną przez PMP Quattro Quiz. Przedstawiłem również propozycję wartości, którą realizuje podobną technologią Word Wall. Dodałem jest drugą wersję ich propozycji wartości, która adresowana jest do nauczycieli. Word Wall zbudował bowiem bogaty w treści edukacyjne portal, na którym nauczyciele mogą znaleźć gotowe ćwiczenia ze swojego programu edukacyjnego.
Celowo też zostawiłem kilka komórek pustych, np. szkoleniowców biznesowych. Param się szkoleniami w przedsiębiorstwach i po kilkunastu latach w tym zawodzie mam poważne wątpliwości, czy atrakcyjne narzędzie edukacyjne z zastosowaniem komputerów lub urządzeń mobilnych jest biznesowo atrakcyjną propozycją wartości dla trenerów. I nie chodzi mi tutaj o pojedynczy scenariusz symulacji szkoleniowej, tylko o narzędzie do tworzenia atrakcyjnych ćwiczeń w stylu quattro quiz. Nie znalazłem dotąd takiej usługi, która odniosłaby sukces na swoim rynku.
utworzone przez Marcin Żmigrodzki
Poziom gotowości technologicznej
NASA w 1989 roku oficjalnie opublikowała model dojrzałości technologicznej. Przez lata rozwijany dziś stał się standardem w analizie i finansowaniu projektów badawczo-rozwojowych. Jest na przykład stosowany w DARPA, w Europejskiej Agencji Kosmicznej ESA, w polskim NCBiR dla definiowania celów projektów i oceny ich realizacji i wielu innych instytucjach. Powstało wiele wariacji na temat TRL. Jednak oryginalna koncepcja składała się z następujących poziomów:
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
- Zaobserwowano podstawowe założenia i zależności – przeprowadzono studia nad założeniami teoretycznymi technologii i przytoczono argumenty potwierdzające, że założenia technologiczne są poprawne..
- Sformułowano koncepcję techniczną i ewentualnie sposobu wdrożenia rozwiązania – zaproponowano ideę działania technologii, ale nie ma jeszcze żadnych praktycznych dowodów na nią.
- Stworzono Proof of Concept, który potwierdził eksperymentalnie wykonalność głównych funkcji rozwiązania – rozpoczęły się badania wykonalności rozwiązania, spłynęły pierwsze wyniki z eksperymentów i są pozytywne. Powstało pierwsze potwierdzenie koncepcji.
- Zwalidowano komponenty rozwiązania w laboratorium – pierwsze fragmenty rozwiązania zbudowano i połączono w całość w laboratorium. Testy potwierdzają wykonalność koncepcji.
- Zwalidowano komponenty rozwiązania w odpowiednich warunkach środowiskowych – komponenty przetestowano w warunkach odpowiadających tym, w których będzie funkcjonowało rozwiązanie. Wstępnie przetestowano również integrację rozwiązania z otaczającymi je systemami.
- Zademonstrowano technologię w odpowiednich warunkach środowiskowych – stworzono niemal skończone rozwiązanie i potwierdzono, że będzie działać jako całość w rzeczywistych warunkach. Dopuszcza się jest niewielkie modyfikacje w odpowiedzi na wyniki badań.
- Zademonstrowano prototyp całego rozwiązania w środowisku produkcyjnym – stworzono ostateczny prototyp oferujący tą samą funkcjonalność, co produkcyjne rozwiązanie i został on przetestowany w rzeczywistych warunkach.
- Rozwiązanie kompletne i po testach na Ziemi lub w kosmosie – produkcyjne rozwiązanie jest po dogłębnych testach i nie wymaga dalszego rozwoju ani modyfikacji. Zademonstrowano jego produkcyjne funkcjonowanie i potwierdzono brak istotnych problemów.
- Rozwiązanie działające produkcyjnie zweryfikowane w rzeczywistych misjach – finalne rozwiązanie przeszło pierwsze misje i zademonstrowało swoją wartość. Dostrzeżono co najwyżej drobne problemy możliwe do usunięcia. Jakiekolwiek udoskonalenia w tym momencie będą traktowane jako powrót do poziomu 1.
Model dojrzałości technologicznej jest narzędziem przydatnym przy zarządzaniu portfelem projektów eksploracyjnych w metodyce zakładające tzw. gate check, czyli bramki, przez które okresowo projekt musi przejść, aby uzyskać dalsze finansowanie. Więcej o tym przeczytasz w kolejnych rozdziałach.
Cele stawiane projektom odzwierciedlają pożądane poziomy dojrzałości. Przykładowo może to być zademonstrowanie Proof of Concept nowego napędu, czyli poziom 3, po którym zlecający podejmie decyzję, czy inwestować dalej w poziom 4, czyli przetestowanie całego rozwiązania w laboratorium, czy nie warto.
Wraz ze wspinaniem się rozwiązania na kolejne poziomy może zmieniać się sposób zarządzania i zespoły. Przykładowo poziomy od 1 do 3 mogą realizować naukowcy w ramach sponsorowanych badań, poziomy 4 do 6 komercyjne laboratoria i startupy, a do wykonania poziomu 7 do 9 wymagana jest już duża inwestycja i zaplecze technologiczne wielkich organizacji.
Analogiczne modele pojawiły się między innymi w obszarze projektów dotyczących zdrowia w USA, projektach wojskowych również USA, czy wspomniana wcześniej ESA. Wszędzie tam, gdzie mamy do czynienia z odkrywaniem nieznanego, przydaje się podzielenie twórczej drogi na etapy. Można też pokusić się o stworzenie modelu dojrzałości projektów eksploracyjnych w biznesie.
Dojrzałość przemysłowa
Na potrzeby przetargów organizowanych przez między innymi Departament Obrony USA, Government Accountability Office (odpowiednik polskiego NIK) opracowało model dojrzałości przemysłowej (Manufacturing readiness level). Zakłada on istnieje kilku poziomów:
- Podstawowe założenia wytwarzania zdefiniowane – badania podstawowe rozwijają założenia naukowe wspierające potencjalne wytwarzanie, trwają badania.
- Koncepcja wytwarzania opisana – opisano potencjalny sposób wytwarzania, zidentyfikowano materiały i procesy produkcyjne, powstają studia wykonalności.
- Proof of concept zweryfikowany – przeprowadzono eksperymenty laboratoryjne, aby zweryfikować założenia koncepcji, wytworzono eksperymentalne narzędzia, materiały, procedury, wymagana jest weryfikacja dostępności materiałów i narzędzi.
- Zademonstrowano zdolność do produkcji technologii w laboratorium – zidentyfikowano konieczne inwestycje, zrealizowano procesy wytwórcze w warunkach laboratoryjnych, zidentyfikowano ryzyka produkcyjne, zmierzono wskaźniki związane z produktywnością, zidentyfikowano również wymagane narzędzia, maszyny, infrastrukturę i umiejętności.
- Potwierdzono zdolność do produkcji prototypowych komponentów technologii w rzeczywistym środowisku produkcyjnym – zdefiniowano procesy produkcyjne, potrzebne technologie, zademonstrowano prototypowe materiały, narzędzia, przetestowano wyposażenie i umiejętności operatorów. Rozpoczęto przygotowania do finalnej produkcji, przeanalizowano koszty produkcji i mapę strumienia wartości.
- Potwierdzono zdolność do produkcji prototypu całej technologii w rzeczywistym środowisku – wyspecyfikowano procesy produkcyjne, zaprojektowano wstępną wersję projektu technologicznego komponentów, zaplanowano pilotażową produkcję, wszystkie procesy produkcyjne zadziałały w środowisku produkcyjnym. Potwierdzono gotowość materiałów, narzędzi, procesów wytwórczych, infrastruktury i kompetencji ludzi do finalnej produkcji. Stworzono szczegółowy plan kosztów produkcji, ustalono również, które komponenty wymagają długiego okresu oczekiwania na dostawę.
- Zademonstrowano zdolność do produkcji technologii w środowisku rzeczywistym – przygotowano szczegółowy projekt, wyspecyfikowano i zatwierdzono szczegółowe wymagania materiałowe, pokazano produkcję w technologii w rzeczywistych warunkach. Zaktualizowano estymacje kosztowe. Przeanalizowano dostępność dostawców, a dla części, na które trzeba długo czekać przygotowano plany zakupowe. Rozpoczęto produkcję narzędzi.
- Uruchomiono pilotażową produkcję, gotowość do produkcji na małą skalę – szczegółowa dokumentacja zatwierdzona i gotowa do użycia przy produkcji na małą skalę. Wszystkie materiały dostępne lub dostarczane zgodnie z harmonogramem. Procesy wytwórcze uruchomiono, nie ma istotnych ryzyk dla produkcji. Model kosztowy zwalidowany.
- Zademonstrowano produkcję na małą skalę, gotowość do produkcji wielkoskalowej – główne funkcje technologii przetestowane i zwalidowane po produkcji, materiały dostępne do produkcji, procesy produkcyjne zapewniają poziom trzech sigma w produkcji na małej skali. Poziom kosztów zgodny z założeniami.
- Produkcja na dużą skalę rozpoczęta – mała liczba zmian w procesach wytwórczych, technologia spełnia wszelkie wymagania, powtarzalność procesów jest na poziomie sześciu sigma, koszt produkcji są zgodne z założeniami. Uruchomiono praktyki ciągłego doskonalenia na procesach produkcyjnych.
W projektach eksploracyjnych, w których przedmiotem jest wytworzenie prototypów urządzeń oraz ich przygotowanie do produkcji powyższy model może pomóc precyzyjnie formułować cele dla kolejnych iteracji. Wyobrażam sobie, że projekt w pierwszy kroku może dostać finansowanie na przejście z poziomu 1 do 3, a potem w razie pozytywnych rezultatów z poziomu 3 do 7 i tak dalej.
Dojrzałość projektu biznesowego
Serwis Crunchbase gromadzący dane o setkach tysięcy startupów z całego świata oferuje podział firm ze względu na rundę finansowania. I tak, mamy rundę: preseed, seed, kolejne serie finansowania, aż po wejście na giełdę (IPO). To, czy startup jest na etapie preseed, czy rundy B dużo mówi nam o dojrzałości modelu biznesowego.
Typowe etapy w cyklu życia startupu można podsumować w ten sposób:
- Dopasowanie rozwiązania do problemu.
- Rozwiązanie o minimalnej satysfakcji (MVP).
- Dopasowanie produktu do potrzeb rynkowych.
- Skalowanie.
- Dojrzałość.
Jednak warto zauważyć, że eksplorowanie raczej zachodzi na wczesnym etapie istnienia produktu, czyli gdy testuje się rozwiązanie, odkrywa, jakie cechy powinno mieć MVP i identyfikuje rynek na dane rozwiązanie.
Na potrzeby eksperymentów w Labspace wypracowaliśmy model hipotez, który opisywałem w poprzednim rozdziale. Bazując na nim można by przyjąć model dojrzałości pomysłu na produkt taką, jak poniżej:
- H0 spełnione (pozyskanie) – na rynku jest dostatecznie duża liczba klientów, którzy są zainteresowani danym produktem. Aktywnie go poszukują lub jeżeli nie, to przynajmniej poinformowani o jego istnieniu potwierdziliby zainteresowanie.
- H1 spełnione (leady) – klienci są dostatecznie zmotywowani do znalezienia produktu, że rejestrują się i zostawiają swoje dane. Zgłaszają chęć kontaktu z dostawcą celem rozmowy o produkcie.
- H2 spełnione (retencja) – klienci powracają do produktu i chcą dalej z niego korzystać, albo dowiedzieć się więcej w ciągu obserwowanego okresu.
- H4 spełnione (transakcje) – klienci są skłonni zapłacić nawet niewielką kwotę za skorzystanie z produktu, co jest potwierdzone pierwszymi transakcjami.
- H3 spełnione – klienci są zadowoleni z korzystania z produktu, potwierdzają, że daje im wartość i polecają go na rynku. Jeżeli istnieje konkurencja, to wskazują wyższość danego produktu nad rywalami.
W ten sposób każdy kolejny poziom stawał się bramką, przy której decydowaliśmy, czy pomysł przechodzi dalej, czy go zabijamy.
utworzone przez Marcin Żmigrodzki
Gdy projektowano pierwszą bombę atomową w ramach projektu Manhattan, jedną z kluczowych kwestii było, jaka ma być jej konstrukcja. W 1942 roku przygotowano całą serię równoległych koncepcji: metoda implozji, pistoletowe, autokatalityczna i kilka innych. Następnie w trakcie dyskusji wybrano spośród nich najlepszą.
Projekt Manhattan był realizowany w totalnej niepewności nie tylko technologii, ale i wiedzy naukowej. Gdy zapytano badaczy, jak precyzyjne są ich obliczenia, to odparli, że na 1 do 10. Dla większości wyzwań technologicznych nie istniały żadne dane eksperymentalne, które by opisywały podobne sytuacje. Niepewne było nie tylko to, jak ma działać taka bomba, ale i jaki zastosować materiał radioaktywny, jak ów materiał wyprodukować i jaki będzie rezultat eksplozji. Mimo, że wybrano metodę pistoletową do produkcji, to i tak niewielki wydzielony zespół dalej opracowywał alternatywną metodę implozji, która z resztą przydała się przy drugiej bombie atomowej zrzuconej na Nagasaki. Niezależnie też oczyszczano zarówno pluton, jak i uran.
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
Równoległa, a więc i nadmiarowa prac w projekcie Manhattan, dała gigantyczne korzyści, gdy okazało się, że jest problem z ekstrakcją uranu i jednocześnie pluton, który dało się produkować nie działa z wybraną metodą pistoletową. W pewnym momencie zespół miał materiał rozszczepialny bez bomby i bombę bez materiału.
Dzięki realizacji projektu na wielu równoległych ścieżkach, zespół mógł szybko dokonać rekonfiguracji koncepcji. Zmieniono architekturę z pistoletowej na implozyjną i zaczęto optymalizować proces produkcji uranu.
Pracując przy startupach w ramach Labspace, przeanalizowaliśmy około 400 pomysłów. Źródłem tych pomysłów oprócz naszej wyobraźni były startupy z innych krajów opublikowane na serwisie Crunchbase. Bowiem jednym z narzuconych kryteriów selekcji było potwierdzenie, że gdzieś na świecie ktoś już coś takiego zrobił.
Odrzucenie nierokujących pomysłów spośród 400 nie jest łatwe i doszliśmy do wniosku, że potrzebujemy uniwersalnego modelu. Ów model odzwierciedlał uwarunkowania rynkowe oraz nasze postrzeganie źródeł niepewności. Wyglądał on mniej więcej tak:
Model startupu.
Model składa się z 8 kategorii hipotez, które można by opisać następująco:
- H0 – nowi klienci wejdą na stronę w odpowiedzi na reklamę, PR lub inne komunikaty. W ramach tej hipotezy były hipotezy o skali tego ruchu oraz koszcie pozyskania jednej wizyty.
- H1 – klienci, którzy wejdą na stronę zostawią kontakt do siebie (tzw. lead), najlepiej ze zgodą marketingową. Podobnie jak przy H0, tutaj też analizowaliśmy efektywność i koszt leada.
- H2 – klienci powrócą na stronę w zakładanym czasie, czyli retencja. Retencja była dla nas ważna, bo mogła znacząco obniżyć koszty pozyskania leada.
- H3 – klienci będą zadowoleni z usługi lub produktu. To rzecz jasna miało mieć wpływ na H2 powracanie i H5 ucieczkę klientów. Mogło też się zmaterializować w poleceniach i reklamacjach.
- H4 – klienci zaakceptują cenę usługi lub produktu. W ramach tej hipotezy sprawdzaliśmy, czy w ogóle klienci chcą wykonać jakąkolwiek transakcję, jak i jaka jest ich wrażliwość cenowa.
- H5 – klienci nie będą rezygnowali z usługi. To szczególnie mogło być istotne przy modelach subskrypcyjnych.
- H6 – w niektórych przypadkach startup był tzw. Marketplace, czyli łączył dostawców z klientami. W ramach tej hipotezy weryfikowaliśmy, czy dostawcy są w stanie dostarczyć jakościowo dobrą usługę, czy są lojalni i czy w ogóle chcą współpracować oraz ile nas to kosztuje.
- H7 – klienci poszukują określonych cech produktu.
Mając zestaw hipotez, należało je uporządkować według kryteriów: najbardziej niepewne, wywracające pomysł na biznes na początku i najtańsze do sprawdzenia na początku. Ze względu na naturę internetowych startupów, na których skupiliśmy się, za najważniejsze uznaliśmy pozyskanie i utrzymanie klientów oraz zdolność do osiągnięcia dodatniej marży operacyjnej, czyli po prostu zarabiania na pojedynczym kliencie.
Przykładowy model dla jednego z naszych biznesów, poradni psychologicznej online, wyglądał tak:
Przykładowy model hipotez dla poradni psychologicznej online.
Zmienną, którą śledziliśmy była rentowność pojedynczej sesji psychologicznej oraz możliwa do osiągnięcia liczba sesji miesięcznie. Celem biznesu było stworzenie platformy łączącej pacjentów z psychologami z całej Polski za pośrednictwem witryny internetowej. Na witrynie pacjent umawiałby się z wybranym specjalistą na sesję wideo, płaciłby, a następnie brałby udział w sesji.
W pierwszej kolejności musieliśmy sprawdzić, czy propozycja wartości zdefiniowana jako porada psychologiczna online (to działo się na rok przed Covidem) jest atrakcyjna dla wystarczająco dużej grupy ludzi – H0. Szybko okazało się, że jest duże zainteresowanie i koszt wejścia jest akceptowalny. W kolejnym kroku sprawdziliśmy, czy klienci zostawią kontakt do siebie – H1. Przygotowaliśmy szczegółową ankietę i w ciągu kilku dni okazało się, że tu też nie ma problemu. Poznaliśmy przy okazji koszt ankiety – 0,5 zł. / 10% = 5 zł. Schody pojawiły się przy H4, bo tylko 1% wykupił sesję. Ale kolejne miesiące pokazały, że mamy wzrostowy potencjał, bo konwersja z 1% skoczyła do ponad 4%. Tak więc koszt sprzedania pierwszej sesji psychologicznej wyniósł najpierw 500 zł. a po trzech miesiącach 240 zł.
Nie mogliśmy eksperymentować z ceną sesji psychologicznej, bo uznaliśmy, że wyznacza ją rynek w postaci dziesiątek poradni psychologicznych w Polsce, więc hipoteza H4 nie znalazła się w modelu celowo. A typowa cena wynosiła około 100 zł. Pamiętajmy też, że do kosztu trzeba dopisać koszt psychologa oraz koszty administracyjne firmy.
Zatem startup o wdzięcznej nazwie Onia utknął w martwym punkcie. Po trzech miesiącach mieliśmy około 70 sesji miesięcznie, ale każda była nierentowna. Nadzieją była retencja, wszak za powracającego klienta nie musieliśmy płacić. Terapia dla swojej skuteczności powinna trwać wiele sesji, jednak okazało się, że przeciętny klient kupował mniej niż 2 sesje.
Zatem postanowiliśmy sprawdzić hipotezę H6 w kontekście lojalności psychologów. Szybko niestety okazało się, że rutynową praktyką jest umówienie się na pierwszą sesję na naszej Oni, a przy drugiej zaproponowanie przejścia pacjentowi na prywatny kanał. H6 została odrzucona. Za wyjątkiem chlubnych wyjątków, ludzi których znaliśmy osobiście, retencja pacjentów u psychologów była podejrzanie niska.
Pomysł na poradnię psychologiczną online mógł naszym zdaniem zadziałać tylko, gdybyśmy kontrolowali przychody, na przykład przez podpisanie umów ramowych z korporacjami lub ubezpieczalniami albo gdybyśmy mieli dostawców na wyłączność, czyli etaty dla psychologów. To był warunek brzegowy dla rentowności biznesu. Nasz inwestor niestety miał inne cele, chciał zbudować marketplace.