Desing Sprinty, czyli metoda do szybkiego projektowania i testowania nowych pomysłów spopularyzowana przez Google. Większość kojarzy czym są Design Sprinty, sporo „ekspertów” o nich odpowiada, ale... niewielu realnie stosuje i ma praktyczne doświadczenia.

Najpierw podzieliłem się własnym wstępem teoretycznym i moimi doświadczeniami z Design Sprintów. Potem miałem okazję porozmawiać o nich w podcaście Product Vision z ekspertem i praktykiem - Marcinem Chyłą (ma na swoim koncie ma już kilkanaście Design Sprintów).

Podczas podcastu oraz naszych rozmów z Marcinem pojawiło się tak dużo praktycznych pytań i wątków, że żebraliśmy je w formę 💬 dodatkowe FAQ o design sprintach:

1. Kiedy pierwszy raz wykorzystałeś Design Sprint w praktyce?

2. W jakich sytuacjach warto wykorzystać Design Sprint? Kiedy sam go wykorzystywałeś najczęściej?

3. Jak przekonywać firmę, interesariuszy do wykorzystania Design Sprintów?

4. Jaki najczęstszy błąd widzisz przy realizacji Design Sprintów?

5. Design Sprint, a Product Discovery - czy warto je łączyć?

6. 🔐 Czy powinniśmy zakładać znalezienie rozwiązania problemu w jednym Design Sprincie, czy od razu powinniśmy planować wiele iteracji?

7. 🔐 Jak przygotować zespół do Design Sprintu? Czy zespół powinien poznać rozwiązywany problem wcześniej?

8. 🔐 AI przy Design Sprintach - jak wykorzystać?

9. 🔐 Gdzie szukać więcej info o Design Sprint? Co polecasz?

ℹ️ Więcej wartościowych treści od Marcina znajdziesz na jego profilu LinkedIn oraz blogu DesignSprinter.pl

3-4 lata temu wpadła mi w ręce książka J.Knapp’a pt.: „Pięciodniowy sprint. Rozwiązywanie trudnych problemów i testowanie pomysłów”. Przeczytałem i bardzo chciałem wypróbować tę metodę.

Byłem wtedy Product Managerem. Pracowałem ze świetnym zespołem developerskim. Zaprosiłem ich do tego eksperymentu.

Dostarczaliśmy wtedy API dla pewnej usługi, ale parę razu pojawiła się sugestia stworzenia interfejsu użytkownika. Tematy UI-owe są dość wdzięcznymi tematami dla sprintów. Ale nie jedynymi.

Sprint zakończył się prototypem i testami. Aplikacja działa do dziś! Pierwszy Sprint nie był jednak idealny. Co zrobiłbym inaczej? Teraz zadbałbym o większe zróżnicowanie w zespole Sprintowym.

Kiedyś policzyłem koszt jednego ze Sprintów. Było to około 150 h. Kiedy przemnożymy to przez stawkę godzinową specjalisty IT okaże się, że Sprint nie jest tanim procesem.

Dążę do tego, że Sprint warto uruchamiać dla perspektywicznych inicjatyw, które mają potencjalnie duży IMPACT. Nowa opcja czy nowy ficzer w istniejącym już produkcie może nie być warta zainwestowanego takiego czasu.

Sprinty świetnie sprawdzają się w warunkach dużej niepewności. Dzięki zaangażowaniu wielu różnych ról pozwala holistycznie podejść do problemu czy pomysłu biznesowego. Właśnie ta mnogość ról umożliwia nam dostrzeżenie i mitygację różnych ryzyk, tych technicznych, kosztowych, użytecznościowych.

Sprinty polecam także wszystkim startupowcom - dla nich poniekąd ta metoda została przygotowana w Goole Ventures. 

Często używam argumentu, że lepiej po 4-5 dniach „zaorać” jakiś pomysł przy zaangażowaniu 6-7 osób, niż dowiedzieć się braku zasadności realizacji tego produktu po 4 czy 5 miesiącach developmentu w 2 zespołach developerskich.

Warto czasem także odwołać się do kultury naszej organizacji. Jeśli organizacja, na sztandarach niesie wartości „Eksperymentowanie”, „Szybkie uczenie się i wyciąganie wniosków” czy „Innowacyjność” to można tych fraz użyć podczas negocjacji: „Skoro to są nasze wartości, to sprinty idealnie się w nie wpisują.”

Na koniec klasyczne argumenty praktyczne - dzięki Sprintowi:

• w 4-5 dni, połączymy siły różnych ról i specjalistów, aby przygotować innowacyjne rozwiązanie problemu (ko-kreacja, współtworzenie),

• dzięki makiecie i badaniu szybko wyciągniemy wnioski;

• i oczywiście skrócimy pętlę zwrotną od użytkowników i interesariuszy - szybciej będziemy wiedzieli czy nasz pomysł ma sens.

Wskazałbym tutaj to, że największym błędem jest nietraktowanie Sprintu z należytą powagą. Sprint odniesie sukces tylko, gdy zespół będzie w 100% zaangażowany w ten proces. Oznacza to pełną dostępność w te 4 czy 5 dni. Dotyczy to także osób zaproszonych w charakterze ekspertów.

Przypomnijmy sobie co na temat discovery mówi Marty Cagan:

Wg mnie, Sprint jest idealnym narzędziem, które może w procesie product discovery wykorzystać:

• Realni klienci i ich feedback o potencjalnym produkcie lub usłudze na podstawie makiety? Checked ☑️.

• Zaadresowanie ryzyk pilności, wykonalności, użyteczności poprzez multidyscyplinarny zespół, poprzez rozmowy z ekspertami? Checked ☑️.

Więcej o swoich doświadczeniach z łączeniem Design Sprintów z Discovery i pracą Scrumową pisał Tomek: