Design sprint mieści miesiące wymiany zdań w pięciu dniach. LEGO użyło go 150 razy w jeden rok, żeby naprawić proces kreatywny, który stał w miejscu od dekady. Sama metoda jest na tyle prosta, że da się ją opisać na jednej stronie, choć z dyscypliną potrzebną, żeby naprawdę przeprowadzić sprint, jest trudniej. Jeśli twoja firma chce sprawdzić duży pomysł, zanim wpakuje w jego budowę miesiące pracy, warto to zrozumieć.
Historia za tym wszystkim
Kilka lat temu wewnętrzna agencja kreatywna LEGO działała tak samo od mniej więcej dekady i nie nadążała za zmianami. Zamiast wprowadzać zmianę stopniowo, osoba prowadząca agencję zrobiła coś radykalnego: w 2017 roku produkcja stanęła na dwa miesiące, od kwietnia do czerwca, a duża część wewnętrznej agencji odłożyła codzienną pracę i zamiast tego prowadziła design sprinty, jak później opisała osoba, która prowadziła to wdrożenie.
W pierwszym tygodniu równolegle działało dziesięć sprintów. Do końca dwumiesięcznej przerwy zrobili ich około sześćdziesięciu. W ciągu roku ukończyli ponad 150. LEGO wpisało tę metodę na stałe w sposób pracy swojej wewnętrznej agencji i wykorzystało ją do przebudowy działania całego zespołu. To skrajna wersja tej metody. Większość firm nigdy nie potrzebuje używać jej na takiej skali. Warto jednak zatrzymać się nad tym, dlaczego LEGO poszło tak daleko: porządne przetestowanie pomysłu przed jego budową jest zwykle szybsze i tańsze niż odkrycie po miesiącach developmentu, że to nie działa.
Czym naprawdę jest design sprint
Design sprint to sposób testowania nowego pomysłu w parę dni zamiast w miesiące: mały zespół i uporządkowany proces, w którym definiujecie cel, szkicujecie rozwiązania i testujecie je z prawdziwymi ludźmi, zanim ruszy jakikolwiek prawdziwy development. Metodę stworzył Jake Knapp w czasach pracy w Google, a później opisał ją w książce „Sprint”, napisanej razem z dwoma kolegami z Google Ventures.
Nie chodzi o to, żeby w pięć dni zbudować prawdziwy produkt. Chodzi o to, żeby zbudować tylko tyle (klikalny prototyp, makietę, zgrubną wersję), żeby pokazać to prawdziwym ludziom i zobaczyć, jak reagują. Dowiadujesz się, czy pomysł działa, zanim wydasz czas i pieniądze na budowę prawdziwej rzeczy.
Jak zwykle wygląda pięć dni
Dokładna struktura różni się trochę w zależności od tego, kto prowadzi sprint, ale rdzeń wygląda tak:
Dzień 1, zrozum problem. Zespół ustala, co tak naprawdę próbuje rozwiązać, i wybiera jeden konkretny kawałek, na którym skupi się przez ten tydzień.
Dzień 2, naszkicuj rozwiązania. Na początku każdy pracuje sam i szkicuje własne pomysły, zamiast od razu wskakiwać w grupowy brainstorming, który często faworyzuje tego, kto mówi najgłośniej.
Dzień 3, zdecyduj. Zespół przegląda wszystkie szkice i wybiera najmocniejsze pomysły do dalszej pracy, bez nieskończonych debat.
Dzień 4, zbuduj prototyp. Nie prawdziwe, działające oprogramowanie. Tylko tyle makiety, żeby wyglądała i sprawiała wrażenie prawdziwej, gdy ktoś spróbuje z niej skorzystać. To ta sama zasada szybkiego prototypowania, która stoi za wieloma dobrymi decyzjami produktowymi: zbuduj najmniejszą rzecz, która pozwala przetestować pomysł, a nie całość.
Dzień 5, przetestuj to z prawdziwymi ludźmi. Zespół obserwuje, jak garstka prawdziwych użytkowników próbuje korzystać z prototypu, i reaguje na to, co widzi, a nie na to, na co liczył.
W piątek po południu wiesz, czy pomysł się sprawdza, zanim napiszesz choćby linię kodu produkcyjnego.
Kiedy ma to sens w rosnącej firmie
Design sprint warto zrobić, gdy zbliżasz się do decyzji, która byłaby kosztowna, gdyby wyszła źle. Nowa funkcja, której budowa zajmie miesiące. Nowy kierunek produktu, co do którego nie masz pewności. Redesign, który dotyka czegoś, na czym klienci już polegają. W każdym z tych przypadków pięć dni spędzonych na sprawdzeniu, czy pomysł w ogóle działa, to tania polisa przed miesiącami budowania złej rzeczy. To dokładnie to samo myślenie, co przy unikaniu typowych błędów przy szukaniu product-market fit, zanim zaangażujesz prawdziwy budżet w dany kierunek.
Kiedy to prawdopodobnie przesada
Nie każda decyzja wymaga pięciu dni i pokoju pełnego ludzi. Jeśli poprawka jest mała albo zespół już zna odpowiedź, pełny sprint tylko dokłada ceremonii, nie dodając wiele wiedzy. To też nie jest właściwe narzędzie, jeśli prawdziwy problem polega na tym, że nikt jeszcze nie ustalił, co biznes w ogóle chce osiągnąć. To inna rozmowa, o celach i priorytetach, a nie o testowaniu konkretnego pomysłu.
Design sprint a Discovery Workshop
To nie to samo, choć logika jest podobna. Design sprint odpowiada zwykle na jedno wąskie pytanie: czy ta konkretna funkcja lub ten przepływ zadziała, sprawdzone na prototypie i garstce użytkowników. Discovery Workshop odpowiada na większe: co właściwie powinniśmy budować i w jakiej kolejności, zanim cokolwiek z tego trafi do specyfikacji. Wyobraź sobie design sprint jako testowanie jednego klocka, a Discovery Workshop jako ustalanie, co budujesz ze wszystkich klocków razem.
Jak to się ma do naszego sposobu pracy
Jedno i drugie ma odpowiedzieć na drogie pytanie, zanim zapłacisz za to, że przekonasz się o tym na własnej skórze. Jeśli masz pomysł, co do którego masz wątpliwości, a budowa go od razu wydaje się ryzykiem, którego nie chcesz podejmować na ślepo, Discovery Workshop jest stworzony właśnie do takiej rozmowy.
