Interaktywne notatniki – narzędzia projektów discovery

utworzone przez Marcin Żmigrodzki

Pierwsza była Wikipedia. Bowiem internetowa encyklopedia to nie tylko almanach wiedzy utrzymywany przez społeczność redaktorów, ale i rozbudowany system do wspólnej edycji dokumentów. Potem zaczęły się pojawiać komercyjne odpowiedniki takie, jak Confluence.

Z czasem koncepcja wyewoluowała do systemów, w których pojedynczy dokument jest zbiorem wierszy, a każdy wiersz to odrębna sekcja, którą można edytować, zmieniać jej pozycję lub typ.

Przykładem takich edytorów, w których każdy wiersz to osobny rekord, których kolejność można płynnie zmieniać są Notion oraz Nuclino.

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

Korzyścią z takiej koncepcji jest to, że można predefiniować szablony strony, czyli zbiór sekcji oraz to, że wielu użytkowników może zmieniać treści dowolnej sekcji naraz. Dla porządku przypomnę, że warunek równoległej edycji spełniają również programy biurowe takie, jak Google Drive i MS Office.

Aktualnie następuje wysyp rozwiązań notatnikowych i do najbardziej popularnych można zaliczyć Notion oraz Nuclino, które zyskały szczególnie dużą atencję wśród studentów. Dostępne są też inne rozwiązania jak Obsidian, GetGuru, Evernote, Roam oraz GitBook.

Dostęp do wiedzy w notatniku następuje na kilka sposobów: przez przeglądanie katalogu stron, przez wyszukiwanie, przez wędrowanie po mapie linków (poniżej przykład) albo przez wyświetlanie kontekstowej do zadanego obszaru merytorycznego listy wpisów.

Intencja użycia, która stoi za tymi systemami zakłada, że pracownicy planowo poświęcają czas na napisanie wirtualnej encyklopedii na zadany temat, np. dokumentacji systemu. Wymaga to zaplanowania struktury wiedzy i napisania wymaganych stron tekstu. Ten sposób użycia zakłada inwestycję w tworzenie uporządkowanej wiedzy, aby później pracownik, który z niej będzie korzystał nie ponosił dużego kosztu dotarcia do niej.

Alternatywnie można założyć, że pracownik w chwili, w której wpada na ciekawą informację lub pomysł notuje sobie ją w takim systemie. System gromadzi te chaotyczne informacje i pozwala na ich późniejsze uporządkowanie. Ten sposób użycia zakłada redukcję kosztu tworzenia nowej wiedzy przez pracownika, aby go nie zniechęcać do archiwizowania jej. Przyjmuje się, że system będzie na tyle wygodny, że ktoś, kto będzie chciał skorzystać z tej wiedzy zdoła ją znaleźć.

Szczególnym przykładem interaktywnego notatnika jest Jupyter i Google Colab, który oprócz równoległej edycji pozwala na wstawianie kodu do środka tekstu i uruchomienie go. W przypadku projektów eksploracyjnych software’owych to gigantyczna wartości.

Notatniki laboratoryjne

Tego typu systemy stosowane są na uniwersyteckich laboratoriach oraz w działach badawczo-rozwojowych. Przykładem takich narzędzi są LabArchives, Dotmatics i Revvity Signals. Przypominają nieco notatniki opisywane w poprzednim rozdziale jednak charakteryzują się dużo większą liczbą narzędzi specjalistycznych oraz nastawione są na gromadzenie, porządkowanie i prezentacje dużych ilości danych liczbowych.

Struktura takiego systemu jest następująca. Użytkownik może założyć eksperyment w postaci wydzielonej strony. Każda strona składa się z sekcji różnych typów od czystego tekstu przez tekst sformatowany, wczytane dokumenty z dysku, po luźne rysunki, aż po matematyczne wzory i chemiczne równania modelowane w specjalnych aplikacjach.

Każda strona może być komentowana, wyszukiwana, załączana do innych stron. Zbiór stron tworzy notatnik na zadany temat.

W efekcie, gdy zespoły badaczy regularnie wpisują notatki ze swoich eksperymentów, firma może wejść w posiadanie stale rosnącej bazy wiedzy, która może okazać się przydatna do przygotowywania kolejnych badań lub wniosków patentowych.

Celem użycia takich notatników jest gromadzenie wiedzy z przeprowadzanych eksperymentów i zbieranie know-how, który może przydać się nawet za kilka lat zupełnie innym zespołom.

Moja osobista opinia z przeglądu trzech wymienionych wyżej notatników laboratoryjnych jest taka, że daleko im do ergonomii systemów takich, jak Notion, czy Nuclino. Może to interesująca luka rynkowa, którą wypełni jakiś startup.

Budowanie kultury eksperymentowania

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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. 

Idealny projekt discovery

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.

Wymiarowanie projektu

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.