utworzone przez Marcin Żmigrodzki
Na wyjściu procesu wdrażania nowej kultury nie chodzi jednak o to, aby wykazać, jak wiele dni spędzono na szkoleniach, albo ile wydano na celebrytów / mówców motywacyjnych. Chodzi o to, aby ludziom się chciało eksperymentować, aby zadawali niewygodne pytania, aby non stop uczyli się nowych rzeczy, aby rozróżniali fakt potwierdzony twardymi dowodami od hipotezy.
Innowacyjność pracowników w dużym stopniu zależy od ich poczucia bezpieczeństwa i motywacji wewnętrznej. Po prostu musi im się chcieć i nie mogą martwić się tym, że mimo starań im coś nie wyjdzie.
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
Po wdrożeniu kultury eksperymentowania oznacza, że ludziom bardziej się chce zmieniać otoczenie, że drażni ich, gdy jakiś obszar nowej technologii, czy produktu jest niesprawdzony eksperymentalnie, że swędzi ich, jeżeli organizacja nie wykorzystuje pełni swojego potencjału, że są głodni nowych gadżetów, rynków, sektorów biznesu, teorii naukowych.
Wdrażanie kultury eksperymentowania jest programem długotrwałym. Ludzie powoli zmieniają swoje nawyki i wyznawane wartości. Dostarczyć wiedzę można w kilka dni. Nauczyć stosowania tej wiedzy można w podobnym czasie. Wykształcić nawyki samorzutnego stosowania nabytej wiedzy w nowych sytuacjach można dokonać w kilka tygodniu, regularnie konfrontując człowieka z takimi sytuacjami i zmieniając jego instynktowne zachowania.
Jednak spowodować, aby pracownik uwierzył, że warto robić coś inaczej, wywołać w nim wewnętrzną niezgodę, gdy ktoś w jego otoczeniu łamie nowe wartości, zajmuje znacznie dłużej. Taka przemiana zachodzi nawet wiele lat i często oznacza zwiększoną rotację ludzi. Jedni zniechęcą się do nowej sytuacji, inni przestraszą nieznanego, jeszcze innych zmęczy chaos związany z transformacją. Jack Welch, gdy wdrażał kulturę Six Sigma w General Electric zwolnił wielu menedżerów nie dlatego, że byli nieefektywni, ale dlatego, że nie podzielali nowych wartości.
Za to, jeżeli organizacja skutecznie będzie zmieniać się w bardziej innowacyjną, przewidującą oczekiwania rynku i badającą nowej dziedziny wiedzy, to przyciągnie nowych ludzi tych, którzy właśnie poszukują przygody. Akurat kultura eksperymentowania mocno stawia na posiadanie motywacji wewnętrznej, co oznacza, że nagle mamy szansę pozyskać ludzi, którzy są tak nakręceni na badanie, rozwój i odkrywanie, że motywację wewnętrzną otrzymamy podaną na tacy.
To tak, jakbyśmy pokazali na mapie świata białą plamę gdzieś za oceanem i jednocześnie ogłosili, że właśnie nabyliśmy flotyllę szybkich statków, a brakuje nam tylko załogi. Odkrywcy zjawią się głodni przygód intelektualnych.
Chcąc uniknąć trzesięsienia ziemii w całym przedsiębiorstwe i jednocześnie skutecznie zacząć zaszczepiać kulturę eksperymentowania, proponuję zacząć od wdrażania bąbla innowacji. W myśl zasady zrób to w małej skali, ale zrób tak, aby naprawdę działało. Świadomość, że to, co robimy naprawdę daje wartość, buduje poczucie sprawczości u ludzi i wpływa z kolei na motywację wewnętrzną. Stosując bąbel innowacji łatwiej też otoczyć ochronnym parasolem innowatorów zanim nowy mindset rozprzestrzeni się. Ryzykujemy też mniej z perspektywy finansowej, strategicznej i reputacji osobistej.
Gdy bąbel innowacji utrwali się, gdy zademonstruje pierwsze sukcesy, możemy myśleć o jego rozszerzaniu. To jak daleko można zajść, rozszerzając zasięg bąbla, będzie wynikało z gotowości ludzi do przyjęcia nowej kultury oraz jej adekwatności wobec różnych działań organizacji. W wielu miejscach eksperymentowanie nie jest najefektywniejszym podejściem. Znam dyrektorów finansowych, którzy nie życzyliby sobie kreatywnej księgowości. W centrach obsługi klienta albo na produkcji powtarzalnych detali również pożądaną kultura jest kultura kontroli i efektywności, a nie eksplorowania.
Budowanie kultury eksperymentowania obejmuje kilka obszarów organizacji:
- Wizja strategiczna – kierownictwo organizacji powinno wiedzieć, w którym kierunku ma zmierzać aktywność innowacyjna pracowników. Czy chodzi o grupę klientów, technologię, czy wybrany produkt? Wizja musi mieć potencjał, zaproponowanie pracownikom stworzenia innowacji dla trzech użytkowników, którzy co prawda strasznie narzekają, ale ich segment rynkowy składa się tylko z tych trzech ludzi, szybko zostanie negatywnie ocenione przez ludzi i odrzucone.
- Przykład osobisty lidera – zgodnie z koncepcją lidera autentycznego, to on najpierw musi wierzyć w przemianę organizacji i pokazywać swoją determinację zachowaniem. Wieszanie plakatów, opowiadanie na spotkaniach o szumnych ideach, gdy jednocześnie na co dzień lider skupia się na sprawach przyziemnych, nie będzie odebrane wiarygodnie. Statystycznie połowa pracowników jest inteligentniejsza od prezesa, więc szybko się zorientuje, że ktoś tu opowiada jedno a robi drugie. Przykłady słynnych technologicznych liderów pokazują ich wielkie zaangażowanie w innowacje aż do poziomu mikro.
- Standardy, rytuały, procesy, dokumenty – kiedy już ludzi przekona się, aby podążali za nową wizją, trzeba koniecznie pokazać im, co mają robić od poniedziałku rana. Tak zwana metodyka służy operacjonalizacji wizji i utrwaleniu właściwych zachowań na różne sytuacje. Masz fajny pomysł? Zgłoś go w bazie wiedzy. Klienci proszą o nową usługę w zgłoszeniach reklamacyjnych? Idź do dyrektora innowacji. Na rynku pojawiła się ciekawa technologia? Wypełnij kartę i aplikuj o stypendium na jej przetestowanie. Zablokowałeś się w projekcie z powodu braku kompetencji albo pomysłu? Udaj się do firmowego bibliotekarza, ustal, kto ma odpowiednia wiedzę i zapytaj tą osobę. Metodyka powinna być zbudowana na poziomie prowadzenia projektu, o czym pisałem w rozdziale szóstym i na poziomie portfela, opisany w rozdziale siódmym model faza – bramka.
- Rekrutowanie dla postaw – najszybszy sposobem na wymianę postaw jest wymiana ludzi, jednak z oczywistych względów taka rewolucja byłaby zabójcza dla firmy. Jak pokazały moje rozmowy z praktykami innowacji i badania naukowe, budowanie motywacji wewnętrznej jest szalenie trudne, długotrwałe i nie ma jednej procedury, która gwarantowałaby sukces. Bycie dobrym eksperymentatorem zależy od właściwego mindsetu, który wynika z naszych doświadczeń życiowych i osobowości. Często łatwiej jest znaleźć ludzi, którzy takie nastawienie już mają i ich pozyskać do firmy.
- Motywowanie przez demonstrowanie sprawczości i nagradzanie uczenia się – mimo, że budowanie motywacji wewnętrznej jest mozolne, to jednak jest wykonalne. To, co pomaga, to dobra atmosfera, zadania będące wyzwaniem i powiązany z ich wykonywaniem rozwój, autonomia, poczucie misji, wyższego dobra, dla którego człowiek pracuje. Są jest jeszcze dwa krytyczne dla kultury innowacji czynniki – poczucie sprawczości oraz nagradzanie rozwoju. Po pierwsze, gdy pracownik zgłasza pomysł, musi mieć pewność, że coś się z nim zadzieje, że nie utonie w biurokratycznej studni i że przynajmniej, ktoś oceni ideę i da mu krytyczną informację zwrotną. Po drugie, gdy pracownik zaczyna eksperymentować, musi mieć pewność, że nawet negatywne wyniki zostaną docenione. One też mają wartość, bo eliminują ślepe uliczki i budują kompetencje.
- Zapewnienie zasobów do eksperymentowania – pracownicy mają tendencję do ograniczania własnej innowacyjności, jeżeli widzą, że organizacja niechętnie inwestuje w nowe pomysły. Być może kierownictwo obwieszcza, jak ważne są nowinki, ale gdy przychodzi do wydania pieniędzy, to decyzje są odwlekane, pojawiają się kolejne warunki, które trzeba spełnić i pomysł grzęźnie. Zasobem jest też czas. Jeżeli pracownik chce poświęcić część etatu na nowy projekt, ale jego kierownik zasypuje go bieżącymi działaniami, to w pewnym momencie się podda. Słynne w biznesie są przykłady 3M, który ponoć zapewnia 15 czasu na projekty własne i Google, który daje 20% czasu na innowacje. To olbrzymi koszt dla tych organizacji, ale najwyraźniej się zwraca skoro ta polityka istnieje już kilkadziesiąt lat.
- Komunikacja zmiany – wreszcie o zmianie kultury trzeba poinformować ludzi. Celowo dałem to na koniec listy, bo uważam, że daleko ważniejsze są czyny niż słowa, czyli zachowania menedżerów, właściwe decyzje i danie ludziom zasobów. Jednak komunikacji trudno pominąć, bo pomaga ona ludziom zrozumieć, do czego dąży kierownictwo. Komunikacja bez faktycznej zmiany to obiekt kpin członków organizacji, ale zmiana bez komunikacji może ugrzęznąć w nieporozumieniach.
utworzone przez Marcin Żmigrodzki
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.
utworzone przez Marcin Żmigrodzki
W projektach hardware’owych, czyli takich, w których przedmiotem jest stworzenie fizycznie istniejącego urządzenia pojawia się problematyka ograniczeń. W angielskiej literaturze używa się terminu dimensioning, który przetłumaczyłem wprost na wymiarowanie projektu. Takim projektem często zarządza się przez ograniczenia, ale od początku.
Zarządzanie wymaganiami bywa szalenie istotne, ale i pomijane. Istotne, gdy nie wiemy, jak wymagania osiągnąć, bo nie znamy odpowiedniej technologii bądź istnieją konflikty wymagań, których nie potrafimy rozwiązać z marszu. Bywa też krytyczne, gdy istnieje ryzyko, że zamawiający nie dogada się z wykonawcą i dzieło, które powstanie na końcu nie spełni właśnie wymagań. Taka sytuacja występuje w tak odległych branżach, jak budownictwo i programowanie.
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
Wymagania mają naturę hierarchiczną. To znaczy, gdy klient je podaje mogą na początku wyglądać niczym lista życzeń i zażaleń, ale w miarę ich analizy wyłania się zwykle struktura.
Rolą zespołu projektowego jest zebranie wymagań i skonstruowanie na ich podstawie struktury, która będzie wykonalna, uzasadniona biznesowo, optymalna kosztowo, wartościowa dla klienta.
Jednak na ogół, gdy zespół buduje rozwiązanie ze znanych klocków technologicznych, to wiele rzeczy staje się oczywistych w momencie zdefiniowania wymagań – albo coś się da zrobić, albo nie, albo zadziała tak, jak chce tego klient, albo nie.
Sytuacja wygląda inaczej w projekcie eksploracyjnym. W tym wypadku zespół odkrywa często, co się da, a co nie. Więc moment między udokumentowaniem wymagań, a stwierdzeniem, że tak może dostarczyć rozwiązanie, które je uwzględnia jest często bardzo odwleczony w czasie. Przez długi okres życia projektu wiadomo, jakie są wymagania i nie wiadomo, czy uda się je dowieźć. Aby zapadło w pamięć, określę to zjawisko przepaścią wykonalności (feasibility chasm).
Z tych powodów formalne dokumentowanie wymagań i śledzenie, na ile zespołowi udaje się zasypać przepaść wykonalności staje się krytyczne akurat w trakcie odkrywania.
Wymagania dzielimy w gigantycznym uproszczeniu na:
- Biznesowe – jakie rezultaty biznesowe mają być osiągnięte dzięki rozwiązaniu, np. produkt powinien sprzedawać się w ilości 100 stuk miesięcznie, firma dzięki nowym kompetencjom powinna wygrać przetarg.
- Funkcjonalne – co rozwiązanie ma oferować dla użytkownika, w jaki sposób ma wchodzić z nim w interakcję, np. system musi wyświetlać określone dane, detektor ma wykrywać zdefiniowane zachowanie, użytkownik powinien móc wykonać z urządzeniem określoną pracę,
- Niefunkcjonalne – wszystkie pozostałe, np. rozwiązanie ma mieć pobór prąd mniejszy niż założony pułap, rozwiązanie musi stosować określone zabezpieczenia.
W najprostszym przypadku może mieć formę listy wymagań zapisanych w postaci product backlogu inspirowanego Extreme Programming i Scrum. Backlog się szczególnie sprawdzi, gdy owa lista nie jest za długa, wymagania są mocno niezależne, czyli zależności między nimi nie destabilizują prowadzenia projektu i gdy większość wymagań jest funkcjonalna (zwykle zapisywana w postaci historyjek). Siłą takiego podejścia do dokumentacji wymagań jest to, że łatwo zarządzać priorytetami, lista (o ile krótka) jest przejrzysta i wymagania automatycznie reprezentują zakres prac. Słabością jest brak uwzględnienia zależności między wymaganiami oraz przy bardziej złożonych rozwiązania utożsamienie wymagań z zadaniami, podczas gdy relacja między nimi może mieć charakter wiele do wielu. Przykładowo mogę mieć wymaganie, że każdy dokument ekran systemu musi mieć możliwość pobrania w formacie PDF. To wymaganie będzie zrealizowane za pomocą całej listy zadań powiązanych z poszczególnymi ekranami. Z drugiej strony zadanie indeksowania i wyszukiwania dowolnych treści może spełnić wymagania dotyczącej wyszukiwania klientów, ofert, dokumentów, raportów, obrazków itd.
Rejestr wymagań może mieć też formę słownego opisu, jaki na przykład oferuje oprogramowanie Confluence, Nuclino, Notion lub po prostu Word lub tabelka w Excel. Mocną stroną takiego podejścia jest utrzymywanie dokumentacji wymagań, która z czasem może stać się dokumentacją rozwiązania. Łatwiej jest śledzić zmiany i śladować (tak, śladować, od angielskiego terminu tracing) pochodzenie wymagań. Słabością natomiast jest to, że wymagania nie stają się zadaniami w projekcie. Aby zaplanować zadania, trzeba najpierw z wymagań stworzyć koncepcję rozwiązania, a potem zdekomponować ją na prace. No i taka lista nie przeliczy automatycznie zależności między wymaganiami.
Wreszcie rejestr wymagań może być bazą wiedzy, w której poszczególne rekordy zawierają pojedyncze wymagania, a pomiędzy nimi występują zależności. Takie podejście sprawdza się, czy występuje bardzo wiele powiązań między wymaganiami oraz pilnować trzeba ograniczeń rozwiązania. Przykładowo każdy moduł rozwiązania może dodawać masę do całości, a ogólne ograniczenie narzuca na projekt limit wagi. Jeżeli chcemy tak podejść do dokumentowania wymagań, to musimy zastosować dedykowane rozwiązanie, jak Valispace. Można w nim zdefiniować siatkę zmiennych ograniczających produkt finalnych w różnych obszarach, a następnie przeprowadzić modelowanie matematyczne różnych kombinacji wymagań. Istnieje pewna klasa projektów innowacyjnych, w których poszczególne elementy rozwiązania są tak ciasno powiązane, że trudno rozwija się je bez wpływu na kształt całości. Wyobraźmy sobie konstrukcję satelity albo łazika marsjańskiego.
Finalny produkt powinien spełniać szereg parametrów takich, jak: maksymalna masa, wielkość całego urządzenia, pobór prądu, wielkość panelu słonecznego, pojemność baterii, czułość anten itd. Te parametry często są narzucane na starcie i wynikają z celów strategicznych danego programu, a czasem zespół dąży po prostu do maksymalizacji parametru.
Przykładowo z grubsza mikrosatelitę można zdekomponować na kilka głównych elementów, np.: system zasilania, komputer, elektronika, napęd, ładunek, czujniki, oprogramowanie, układ komunikacyjny. Czasem, jak w przypadku projektu skonstruowanego przez studentów z Imperial College, z którymi miałem szansę współpracować, pojawiają się dodatkowe elementy, jak na przykład żagiel słoneczny.
Zaprojektowanie dowolnego elementu natychmiast wpływa na kształt pozostałych. Mniejsza bateria będzie miała mniejszą masę, ale będzie głębiej się rozładowywać i może nie zapewnić prądu do czasu kolejnego obrotu satelity wokół Ziemi. Większy panel solarny szybciej naładuje satelitę, ale zajmie więcej miejsca i dociąży cały ładunek. Zauważmy, że takie przeciąganie za krótkiej kołderki wymagań nakłada się na tradycyjne ograniczenia projektowe, jak czas, koszt, kompetencje zespołu, czy jakość.
Tego typu sytuacja pojawia się częściej w projektach wytwarzających tzw. hardware, niż oprogramowanie lub projektach nowych produktów i usług, gdzie głównym wyzwaniem jest satysfakcja potencjalnego klienta, a wydajność, skalowalność, czas reakcji, SLA są wykładnikami kosztu rozwiązania. Na potrzeby projektów o dużej liczbie wewnętrznych powiązań między wymaganiami opracowano podejście nazwane SBCE.
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.
