Sprint review, trzeci miesiąc projektu. Zespół z dumą pokazuje moduł raportów z siedmioma typami wykresów. Ładny. Tylko że rezerwacji, czyli tej jednej rzeczy, dla której system w ogóle powstał, wciąż nie da się zrobić od początku do końca. Widziałem ten obrazek w kilku projektach i za każdym razem przyczyna była ta sama: na etapie zakresu nikt nie potrafił powiedzieć "nie w tej wersji".
To jest robota analityka. Nie spisywanie życzeń, tylko doprowadzenie do decyzji: co wchodzi do pierwszej wersji, a co czeka. Pokażę Ci, jak to robić w praktyce: story mapping, techniki cięcia, gotowe skrypty rozmów z biznesem i przykład rozpisany decyzja po decyzji.
MVP to nie wersja byle jaka - czym jest, a czym nie jest
MVP (Minimum Viable Product) to najmniejsza wersja produktu, która dostarcza użytkownikowi realną wartość i pozwala sprawdzić, czy założenia biznesowe w ogóle się bronią. Trzy słowa i każde robi robotę:
- Minimum - nic ponad to, co konieczne, żeby ścieżka użytkownika działała od wejścia do efektu.
- Viable - zdatne do użycia naprawdę, przez prawdziwych ludzi, w prawdziwym procesie. Nie prototyp, nie makieta na pokaz.
- Product - kompletny w wąskim zakresie, a nie połowiczny w szerokim.
Najlepiej tłumaczy to znana ilustracja Henrika Kniberga: jeśli docelowo budujesz samochód, MVP nie jest jednym kołem (koło nikogo nigdzie nie zawiezie), tylko deskorolką. Potem hulajnogą, potem rowerem. Każdy etap wozi człowieka z punktu A do B. Gorzej niż samochód, ale wozi - i po drodze uczysz się, czego ludzie naprawdę potrzebują.
Czym MVP NIE jest:
- Fazą 1, do której wpadło wszystko "ważne". Jeśli w pierwszym wydaniu ląduje 80% zakresu, to nie jest MVP. To cały projekt z innym szyldem.
- Wersją byle jaką. Tniemy zakres, nie jakość. Formularz rezerwacji w MVP ma działać bezbłędnie - po prostu nie stoi obok niego panel raportów.
- Wymówką, żeby nigdy nie dowieźć reszty. Interesariusze boją się dokładnie tego. I często słusznie - dlatego wrócimy do tego przy skryptach rozmów.
Skąd się bierze przerośnięty zakres
Zanim zaczniesz ciąć, zrozum mechanikę puchnięcia. Zakres rośnie, bo:
- Interesariusz płaci raz. W jego głowie to jedyna szansa: "jak teraz nie wpiszę mojej funkcji, to potem nie będzie budżetu". To racjonalna obawa, nie kaprys.
- Analityk zbiera zamiast modelować. Pytanie "czego potrzebujecie?" zamienia warsztat w spisywanie listy życzeń. Każda odpowiedź trafia do dokumentu z tą samą wagą.
- Nikt nie jest właścicielem "nie". Każdy dział coś dokłada, nikt nie odejmuje. Bez jednej osoby decyzyjnej lista tylko rośnie.
- Wymagania wiszą w próżni. Wymaganie niepodpięte pod cel biznesowy jest nieoceniane - a czego nie da się ocenić, tego nie da się wyciąć.
- Syndrom "przy okazji". "Skoro i tak robimy moduł płatności, dorzućmy faktury cykliczne". Trzy takie zdania i masz kwartał roboty więcej.
Punkt pierwszy jest najważniejszy: strach przed "fazą 2, która nigdy nie nadejdzie" jest zwykle oparty na doświadczeniu. Dlatego cięcie zakresu to przede wszystkim budowanie zaufania: wszystko, co wytniesz, ląduje w widocznym, zarządzanym miejscu.
Story mapping: mapa historyjek jako narzędzie cięcia zakresu
Story mapping (technika spopularyzowana przez Jeffa Pattona) to najskuteczniejsze narzędzie do cięcia zakresu, jakie znam. Powód jest prosty: zamienia listę wymagań w obraz procesu. Na liście każda pozycja wygląda na równie ważną. Na mapie od razu widać, że bez jednej proces stoi, a bez drugiej jest tylko trochę mniej wygodnie.
Jak przeprowadzić warsztat krok po kroku:
Krok 1: szkielet (backbone). Ułóż poziomo, od lewej do prawej, główne kroki użytkownika. Dla systemu rezerwacji: znajdź termin → wybierz salę → podaj dane → zapłać → zarządzaj rezerwacją. To oś czasu procesu, nie lista funkcji.
Krok 2: historyjki pod krokami. Pod każdym krokiem wieszasz wszystkie wymagania i pomysły, które go dotyczą - od najbardziej niezbędnych u góry do "miło by było" na dole. Tu ląduje całe 60 karteczek z warsztatów.
Krok 3: linia wydania. Rysujesz poziomą linię przez całą mapę. Nad linią jest pierwsze wydanie. Pytanie-test do każdej karteczki brzmi: "czy bez tego użytkownik przejdzie ścieżkę i dostanie efekt?". Nie "czy to ważne" - wszystko jest ważne. Tylko: czy bez tego proces się zatrzyma.
Krok 4: test spaceru. Przejdź palcem całą ścieżkę wyłącznie po karteczkach nad linią. Jeśli w którymś kroku jest pusto, masz dziurę - użytkownik utknie. MVP musi być cienkie, ale kompletne w poziomie. Cienki pasek przez cały proces bije na głowę trzy kroki dopieszczone do perfekcji i urwaną resztę.
Logistyka: 2-3 godziny, sponsor lub właściciel produktu, 1-2 osoby znające proces od środka, ktoś z zespołu wytwórczego i Ty jako prowadzący. Ściana i karteczki albo tablica online. Jedna zasada ogłoszona na starcie: karteczki przesuwamy, nigdy nie wyrzucamy.
Techniki wyznaczania MVP: walking skeleton, ścieżka krytyczna, wersje ekspresowe
Story mapping daje obraz. Te trzy techniki pomagają zdecydować, co konkretnie zostaje nad linią.
Walking skeleton - najcieńszy możliwy przekrój przez cały system, który działa end-to-end. Formularz, logika, baza, powiadomienie e-mail: wszystkie warstwy, każda w minimalnym wydaniu. Zysk jest podwójny: użytkownik ma działającą ścieżkę, a zespół sprawdza architekturę i integracje na czymś małym, zanim dobuduje mięso.
Ścieżka krytyczna użytkownika - jedna persona, jeden scenariusz, który realizuje większość wartości produktu. Pytanie brzmi: "kto musi móc zrobić co, żeby produkt miał sens pierwszego dnia?". Jeśli odpowiedź to "klient musi zarezerwować i opłacić salę", to obsługa administratora może być na start brzydka i ręczna.
Wersje ekspresowe funkcji - mój ulubiony manewr, bo pozwala nie mówić "nie". Zamiast wycinać funkcję w całości, budujesz jej najtańszą działającą wersję: płatność online → numer konta i ręczne oznaczenie "opłacone", automatyczne SMS-y → zwykły e-mail, edycja rezerwacji → anulowanie i założenie nowej, panel raportów → eksport CSV. Funkcja "jest", proces działa, a koszt to ułamek pełnej wersji.
Do uporządkowania tego, co zostało nad linią (i kolejności dobudowywania reszty), przydadzą się MoSCoW i WSJF - obie techniki rozpisałem z przykładami w artykule o priorytetyzacji wymagań.
Jak rozmawiać z biznesem o wycinaniu funkcji - gotowe skrypty
Techniki są proste. Rozmowy nie. Kilka skryptów, które u mnie działają:
Gdy wszystko jest "must have":
"Przyjmuję, że wszystkie te funkcje są potrzebne. Pytanie nie brzmi CZY je zrobimy, tylko W JAKIEJ KOLEJNOŚCI. Co musi działać pierwszego dnia, żeby system miał sens, a co może dojechać dwa tygodnie później?"
Zamiana "czy" na "kiedy" rozbraja większość oporu, bo nikt nie traci swojej funkcji - tylko miejsce w kolejce.
Gdy interesariusz walczy o funkcję z dołu mapy:
"Co konkretnie się stanie w pierwszym miesiącu po starcie, jeśli tego nie będzie? Kto ucierpi i jak bardzo?"
Jeśli odpowiedź brzmi "no... będzie mniej wygodnie", funkcja właśnie sama zjechała pod linię. Jeśli odpowiedź to "księgowość nie zamknie miesiąca", funkcja zostaje - i dobrze, że zapytałeś: właśnie odkryłeś twarde wymaganie zgłoszone jednym zdaniem na końcu warsztatu.
Gdy zakres rośnie, a termin stoi:
"Mamy stałą datę i stały zespół. Jedyne, czym możemy sterować, to zakres. Jeśli dokładamy X, to co w zamian przesuwamy za linię?"
Nigdy nie zgadzaj się na "dołóżmy, jakoś się zmieści". "Jakoś" znaczy: kosztem jakości albo terminu - tylko jeszcze nikt o tym nie wie.
Gdy pada argument "faza 2 nigdy nie przychodzi":
"Rozumiem, bo często tak bywa. Dlatego wycięte funkcje nie idą do kosza, tylko na mapę, którą wszyscy widzą. Umówmy się na przegląd miesiąc po starcie - z danymi z produkcji zdecydujemy, co wchodzi dalej."
Ten strach traktuj poważnie. To jedyny zarzut wobec MVP oparty na faktach. Zamiast przekonywać, daj mechanizm: widoczny backlog i termin przeglądu w kalendarzu.
Przykład: system rezerwacji - od 60 wymagań do MVP, decyzja po decyzji
Firma wynajmująca sale szkoleniowe zamawia system rezerwacji. Po warsztatach z czterema działami lista liczy 60 wymagań. Szkielet mapy: znajdź termin → wybierz salę → podaj dane → zapłać → zarządzaj rezerwacją. Decyzje (wybrane z tych 60):
| Wymaganie | Decyzja | Dlaczego |
|---|---|---|
| Kalendarz dostępności sal | zostaje | bez tego nie ma produktu |
| Rezerwacja z formularza | zostaje | rdzeń procesu |
| Konta użytkowników z historią | pod linię | rezerwacja bez konta: e-mail + link do zarządzania |
| Płatność online | wersja ekspresowa | dane do przelewu + ręczne oznaczenie "opłacone" |
| Powiadomienia SMS | pod linię | e-mail z potwierdzeniem wystarczy na start |
| Edycja rezerwacji | wersja ekspresowa | anulowanie + nowa rezerwacja |
| Panel raportów obłożenia | wersja ekspresowa | eksport CSV raz dziennie |
| Integracja z kalendarzem Google | wersja ekspresowa | załącznik .ics w mailu potwierdzającym |
| Cennik dynamiczny (rabaty, sezony) | pod linię | jeden płaski cennik |
| Wielojęzyczność | pod linię | klienci rezerwują po polsku |
Po przejściu całej listy nad linią zostaje 14 wymagań z 60. Test spaceru przechodzi: klient znajduje termin, rezerwuje, dostaje dane do przelewu, admin oznacza wpłatę, potwierdzenie z .ics ląduje w skrzynce.
Zwróć uwagę na wzorzec: prawie nic nie wycięto "w całości". Większość spornych funkcji dostała wersję ekspresową. Biznes nie usłyszał "nie" - usłyszał "tak, w tańszej wersji, a pełną zbudujemy, jeśli dane pokażą potrzebę". Zupełnie inna rozmowa.
I bardzo możliwe, że po trzech miesiącach okaże się, że eksport CSV wystarcza na zawsze i panel raportów nigdy nie powstanie. Zaoszczędziłeś właśnie komuś kwartał pracy.
Checklist: zanim zamkniesz zakres MVP
- Test spaceru przechodzi: główna ścieżka działa od wejścia do efektu.
- Każda wycięta funkcja wisi na mapie widocznej dla interesariuszy, nie w niebycie.
- Sporne funkcje mają wersję ekspresową albo jawną decyzję z uzasadnieniem.
- Jedna konkretna osoba jest właścicielem "nie".
- Termin przeglądu mapy stoi w kalendarzu, nie w obietnicach.
- Masz 2-3 metryki startowe i wiadomo, kto je czyta.
- Zakres jest spisany i rozesłany: co wchodzi, co czeka i dlaczego.
Najczęściej kuleje termin przeglądu - a to on trzyma umowę z biznesem przy życiu.
Co po MVP: iteracje, mierzenie, kiedy dobudować resztę
MVP bez pomiaru to po prostu mały produkt. Sens ma dopiero pętla: wydaj → zmierz → zdecyduj.
- Przed startem ustal 2-3 metryki, które powiedzą Ci, czy MVP robi to, po co powstał. Dla rezerwacji: liczba ukończonych rezerwacji, odsetek porzuceń w kroku płatności, liczba telefonów do biura (świetny wskaźnik tego, czego w systemie brakuje). Jak dobierać metryki i nie wpaść w liczby-ozdobniki, rozpisałem w artykule o KPI i mierzeniu sukcesu.
- Wracaj do story mapy w stałym rytmie, na przykład co miesiąc. Karteczki spod linii awansują, kiedy dane pokazują potrzebę - nie dlatego, że ktoś głośniej prosi.
- Wersje ekspresowe obserwuj osobno. Admin ręcznie oznacza 5 przelewów dziennie? Spoko, niech tak zostanie. Oznacza 80? Właśnie dostałeś twardy argument za płatnościami online, poparty liczbą, a nie opinią.
- Część funkcji nie powstanie nigdy. I dobrze.
Cięcie zakresu odróżnia analityka od osoby spisującej wymagania. Wraca też na rozmowach rekrutacyjnych, zwykle w formie "opowiedz o sytuacji, w której musiałeś odmówić interesariuszowi". Jeśli dopiero budujesz warsztat BA, zajrzyj do ścieżek przebranżowienia na analityka - z konkretnymi kompetencjami do przeniesienia.
A jeśli wolisz przećwiczyć story mapping i rozmowy o zakresie na realistycznych case'ach, zamiast tylko o nich czytać - załóż konto na platformie Analify. Uczysz się przez praktykę: wyzwania, case studies i peer review od innych analityków.