Etap Discovery czy też po prostu etap „odkrywania” to jeden z naturalnych etapów procesu rozwijania produktów lub testowania nowych pomysłów. Samo discovery nigdy właściwie się nie konczy, ale często mamy ograniczony czas na podjecie najwazniejszych produktowych decyzji. I tu może przydać Ci się poprowadzenie warsztatów w formule Discovery Sprintu.

Discovery sprint to intensywny, krótkoterminowy proces mający na celu walidację pomysłów na nowe produkty lub funkcjonalności przed rozpoczęciem ich pełnego rozwoju.

Główne cechy discovery sprintu:

• Czas trwania: od kilku dni do 2 tygodni

• Cel: Szybka walidacja pomysłu biznesowego i określenie zakresu produktu

• Uczestnicy: Multidyscyplinarny zespół

Autorem poniżego podejścia i artykułu jest Mateusz Jędraszczyk - Lead Product Designer w Edisonda.

Odkrywamy proces na nowo

W ciągu ostatni 20-30 lat powstało wiele opracowań opisujących ten sam etap Discovery na liczne sposoby. To co jest jednak znamienne, to fakt, że technika Design Thinking a zatem także jej pierwszy element czyli etap discovery, nie zmieniły się za bardzo od 30 lat!

W tym krótkim przewodniku chciałbym w związku z tym od razu przejść do konkretnych kroków, metod i technik, które można wykorzystać aby przejść przez etap discovery. Jako kontekst i moją gorącą poradę warto przyswoić sobie pierwszą zasadę:

Piszę o tym tylko dlatego, że sam miałem często wątpliwości jak podejść do discovery oraz tego jak mocno trzymać się wskazówek z setek artykułów rozsianych po internecie. Po paru latach zrozumiałem wreszcie, że najważniejsze jest skupienie się na celu a nie metodach. A jeśli o tym mowa to celem tego poradnik jest dostarczenie bardzo konkretnych wyników Twoich (naszych) poczynań. 

Wynikiem zaś powinno być dostarczenie informacji wystarczających do tego aby zespół mógł podjąć świadomą decyzję o kontynuacji lub anulowaniu projektu (tak też się zdarza). Jeśli zatem czujesz, że ćwiczenia z tego poradnika nie rezonują z Twoim wewnętrznym “Ja” spróbuj zmodyfikować szablon bądź technikę tak aby otrzymać wymagany rezultat a nie iść w zaparte z szablonem. 

Poniżej znajdziesz mój przepis na warsztat Discovery:

• 1️⃣ Przygotowania przed WARSZTATAMI (3-5 dni)

• 2️⃣ Warsztaty Discovery (2 dni)

  • Dzień 1

  • Dzień 2

• 3️⃣ Po warsztatch (3-5 dni)

• 🎁 Korzyści z warsztatów

1️⃣ Przygotowania przed WARSZTATAMI (3-5 dni)

1. Zanim zaczniesz Sprint upewnij się, że wiesz co musisz wiedzieć.

Moja rada jest prosta. Zanim zaczniesz radzić innym jak ma wyglądać system/rozwiązanie z którego będą mieli korzystać przez wiele lat najpierw stań się chociaż juniorem w tym co chcesz stworzyć. Przykładowo Managerowie Biedronki muszą spędzić trochę czasu na kasie i na sklepie zanim będą pracowali w centrali. Musisz wiedzieć o czym będziecie mówić i poczuć “ból” osób których problemy starasz się rozwiązać.

2. Zrozum komu próbujesz pomóc

Zastanów się dla czego to robisz, jeśli odpowiedź brzmi dla pieniędzy lub nic nie przychodzi Ci do głowy to nie startuj z Discovery Sprintem. Wypisz sobie tzw. persony czyli w skrócie napisz kto jest modelowym odbiorcą. Możesz nawet zrobić ćwiczenie w zespole i poprosić o wypisanie tego przez każdą osobę w zespole przed wspólnymi warsztatami aby później porównać czy są spójne. Ważne jest aby te persony powstawały na podstawie konkretnych danych rynkowych. Jeśli ich nie masz wciąż wykonaj to ćwiczenie ale bądź gotowy na zmiany w trakcie projektu - bez danych wszystko co zapiszesz to tylko założenia.

3. Zbierz benchmarki

Nawet jeśli zdobędziesz wiedzę na poziomie juniora to nadal nie będzie to wystarczające aby w pełni zrozumieć potrzeby różnych osób korzystających z tego co wspólnie z zespołem spróbujecie stworzyć, dlatego zrób dobry research. Znajdzie coś co może być rozwiązaniem na problem, który chcecie rozwiązać, sprawdź jak inne firmy sobie z nim radzą. Nawet pierwszy lot w kosmos był rywalizacją, jestem przekonany, że Twój projekt również nią będzie.

4. Zbierz zespół

Unikaj przy tym teatru korporacyjnego. Discovery Sprint to jedna z metoda któtrej celem jest uzyskanie konkretnych efektów. Jeśli masz to zrobić sam lub zaprosić jakieś osoby jako publiczność to nie startuj z etapem discovery. Nie da się zbudować rozwiązania/produktu na kartonowych podstawach. Potrzebujesz konkretne osoby. Ja polecam skorzystać z listy osób z discovery sprintu czyli:

1. Osoba decyzyjna (Product Owner)

2. Osoba od strony IT (ktoś kto wie co można zbudować)

3. Osoba od strony Designu (Ktoś kto może zmienić to jak to ma wyglądać)

4. Ekspert (Ktoś z pierwszej linii, ktośdla kogo budujecie to rozwiązanie)

5. Facilitator (najlepiej ktoś z zewnątrz kto nie ma powiązań z członkami zespołu aby uniknąć robienia się ”grupek”)

6. Krytyk - ktoś kto potencjalnie może nawet zatrzymać projekt jeśli się go nie wysłucha

5. Agenda spotkania i materiały

Nie zlicze ile razy ja sam wysłałem link na spotkanie bez opisu lub wysłałem maila za późno. Od tamtej pory mam zasadę aby zawsze wysyłać maila z informacjami co się wydarzy na warsztatach co najmniej tydzień przed ich rozpoczęciem. Jest to o tyle ważne, że osoby, które będą w nim uczestniczyć też muszą się jakoś przygotować mentalnie i merytorycznie. Przykładowo przed warsztatmi (mniej więcej tydzień przed) warto poprosić ludzi o zebranie inspiracji z zewnątrz i przyniesienie ich na warsztaty. Nie zapomnij także o przygotowaniu materiałów na warsztaty (fizycznych lub elektrocznych)

6. Dobry humor i pozytywne nastawienie

Wydawać się może, że to najmniej ważny element warsztatu a tymczasem według mnie jest najważniejsze. Jeśli facylitator i osoby na spotkaniu złapią wspólny rytm i zrozumienie to cała reszta staje się niemal nie ważna. Daj ludziom mówić o swoich pomysłach swobodnie bez wyśmiewania, w razie ciekawej dyskusji daj ją dokończyć. Czasami 5 minut dłuższej rozmowy zaoszczędzi Ci pare dni popelniania błedów.

2️⃣ Warsztaty Discovery (2 dni)

Połowa suckesu za Tobą. Do tego momentu powinieneś/naś wiedzieć jaki problem i dla kogo próbujecie rozwiązać. Moja agenda zazwyczaj podzielona jest na 2 dni warsztatów po 4h (z przerwami) i wygląda tak:

Dzień 1

1. Przywitanie i rozgrzewka - poznajemy narzędzia z których będziemy korzystać

2. Problem i cele warsztatu - Od razu na wstępie mamy już wypisany problem ale każdą osobę proszę o wypisanie celów tego konkretego etapu discovery i celu długofalowego (gdzie chcemy być za 1 lub 2 lata)

3. Wypisujemy Persony - Korzystam z person na podstawie danych przed Discovery Sprintem lub tworzymy je wspólnie na warsztatach z klientem. Jeśli Persona tworzona jest na podstwie przekonań to de-facto ejst to proto-persona, którą z czasem należy dodefiniować.

4. Mapa procesu - Mając persony/proto-persony spróbujcie wspólnie z zespołem wypisać proces jaki zachodzi pomiędzy różnymi aktorami procesu tzn. kto robi, co i kiedy. Przykładowo jeśli szukacie lepszego sposobu na obieg dokumentów to sprawdź gdzie, kiedy i komu są one przesyłane. Narysuj prostą mapę aby zwizualizować ten proces.

5. Features backlog - Proszę, każdą osobę o wypisanie pomysłów na rozwiązanie problemu. Zawsze na tym etapie podaje przykład np. Jak szybciej rozwozić pizze? -> można wykorzystać drony. Czasami nie są to innowacje na skalę światową ale w skali firmy mogą otwierać nowe horyzonty. Celem tego ćwiczenia jest wyjęcie pomysłów które ludzie zaproszeni na ten warsztat często już mają w głowach.

Dzień 2

Zazwyczaj dzień drugi nie następują po dniu 1 tylko po 1 lub 2 dniach od pierwszego warsztatu. Robię tak aby każdy miał czas na przemyślenie tego co wypisał. Pomiędzy tymi warsztatmi mam też sporo spotkań aby dowiedzieć się jak najwięcej o specyfice pracy osoby której problem staram się rozwiązać.

1. Red Routes - Tu zaczynają się schody ponieważ zazwyczaj to co robimy to pewne założenia i hipotezy i to jest OK! Celem discovery sprintu, jest sprawdzenie co ludzie mają w głowach i zaprojektowanie tego a następnie podjęcie decyzji czy warto w ten pomysł inwestować więcej czasu i energii. Testowanie z użytkownikami przyjdzie później! Red Routes to dosyć prosta matryca, jedna oś pokazuje jak często, ktoś może korzystać w przyszłości z rozwiązani a druga pokazuje jak ważna jest dla użytkowników dana funkcjonalność. Unikam przy tym prostych funkcjonalności jak logowanie aby skupić się na unikatowych pomysłach.
   
   

2. Skup się na 2 lub 3 kluczowych funkcjonalnościach - skorzystaj z głosowania - To metoda, której warto użyć zawsze gdy zespół nie jest zgodny lub gdy część osób może bać się wyrazić swoją opinię. Zasada jest prosta jeśli masz już listę funkcjonalności to  poproś o anonimowe oddanie głosu na funkcjonalności, które powinny zostać naszkicowane najpierw. Głosy można oddawać korzystając z kolorowych naklejek lub cyfrowo korzystając ze stempli (FigJam) lub natywnych rozwiązań do głosowania (Miro). Na koniec poprosić o opisanie pomysłów na trzech wygranych karteczkach.
   
   

3. Job Stories - Ostatnie ćwiczenie. Dla wybranych kluczowych funkcjonalności (a później kolejnych z wypisanych na red routes) zapisz job stories. Przykładowo
   
   „Gdy dokonuje przelewu chcę móc skorzystać z komendy głosowej aby przelać środki do wybranej osoby z mojej listy kontaktów na telefonie”

Dzięki job stories będziesz miał dobry początek do dalszych warsztatów po etapie Discovery a jednocześnie nie wprowadzasz czegoś co mogłoby być zbyt trudne do zrobienia w tak krótkim czasie. Product owner we wczesnym etapie może mieć problem w zrozumieniu konotacji pomiędzy różnymi personami potrzebnymi do stworzenia User Stories.

3️⃣ Po warsztatch (3-5 dni)

1. Upewnij się, że wszystko jest zrozumiałe z warsztatów. Jeśli nie do od razu dopytaj o to czego Ci brakuje - bądź przy tym szczery/a.

2. Na podstawie warsztatów sprawdź czy Twoje benchmarki zebrane przed warsztatami nadal są aktualne, jeśli nie to poszukaj takich, które są bardziej zbliżone do wizji zespołu. Możesz zrobić małą dogrywkę w postaci krótkiego spotkania, na którym każdy w 15 minut opowie o swoich inspiracjach z zewnątrz.

3. Spróbuj narysować pierwsze szkice na podstawie benchmarków. Staraj się nie wymyślać koła na nowo. Jeśli nie wiesz od czego zacząć to zacznij od najgorszej rzeczy jaka może powstać czyli systemu z tylko jedną funkcjonalnością. Jak narysujesz ten pierwszy szkic zadaj sobie pytanie jaki jest kolejny krok, który mógłby nawet odrobinę polepszyć doświadczenia użytkownika.

4. Po narysowaniu 5-10 szkiców spróbuj narysować jedną makietę. Polecam korzystać przy tym z gotowych i darmowych design systemów aby przyśpieszyć sobię prace. Nie skupiaj się przy tym na Designie, na ten moment nie to jest ważne!

5. Stwórz prezentację biznesową prezentującą produkt lub nową funkcjonalność. Wstaw do prezentacji makiety i opisz funkcjonalności. Przedstaw prezentację przed zespołem.

Możesz użyc mojej prezentacji jako inspiracji:

🎁 Korzyści z warsztatów

Discovery sprint pozwala w krótkim czasie zweryfikować potencjał pomysłu biznesowego, zdefiniować kluczowe założenia produktu oraz stworzyć podstawy do dalszego rozwoju.

Najważniejsze korzyści z tej metody:

• Szybka walidacja pomysłu przy stosunkowo niskim koszcie

• Minimalizacja ryzyka tworzenia produktu niedopasowanego do potrzeb rynku

• Uspójnienie wizji produktu wśród interesariuszy

• Oszacowanie budżetu potrzebnego na realizację

🔗 Dodatkowe Materiały

• “Testowanie pomysłów biznesowych. Biblioteka technik eksperymentacyjnych” - Osterwalder Alexander, David J. Bland

• “Pięciodniowy sprint. Rozwiązywanie trudnych problemów i testowanie pomysłów” - Jake Knapp Braden Kowitz

• Discovery Sprint Edisonda

• Mapowanie historyjek użytkownika. Przepis na produkt idealny. Książka opisująca tworzenie mapy historyjek użytkowników.

• Replacing The User Story With The Job Story. Artykuł opisujący różnice pomiędzy user stories i job stories.

• Red Routes - artykuł opisujący czerwone ścieżki jedno z ćwiczeń z discovery sprintów pomagających w priorytezacji zadań.

• Prezentacja biznesowa na zakończenie Discovery Sprintu