Jak określić zakres MVP: ogranicz pierwszą wersję do tego, co naprawdę się liczy

Niemal każdy, kto przychodzi do nas z pomysłem na aplikację, zbudował już jej pełną wersję w głowie. Potrafi opisać pulpit, stronę ustawień, program poleceń, tryb ciemny. Czego zwykle nie potrafi powiedzieć, to która pojedyncza część tego obrazu, gdyby działała, sprawiłaby, że całość byłaby warta zachodu. Określenie zakresu MVP to niewdzięczna, lekko bolesna praca polegająca na znalezieniu tej jednej części — i odwadze, by resztę zostawić na później.

Widziałem powstawanie wielu pierwszych produktów i te, które mają kłopoty, prawie nigdy nie zawodzą dlatego, że zespół był leniwy. Zawodzą, bo od pierwszego tygodnia zakres był zły. Do wersji pierwszej upchnięto zbyt wiele, budżet skończył się, zanim ktokolwiek czegokolwiek się nauczył, a do premiery zespół wydał wszystko, by ledwie dotrzeć na linię startu — bez pieniędzy, by zareagować na to, co naprawdę robili prawdziwi użytkownicy.

To więc przewodnik, który daję ludziom, zanim powstanie choćby jedna linijka kodu. Nie chodzi o rytuały Agile ani modne frameworki. Chodzi o jedno uczciwe pytanie — jaka jest najmniejsza rzecz, którą możemy zbudować, by dowiedzieć się, czy ten pomysł jest prawdziwy? — i dyscyplinę, by wciąż na nie odpowiadać, gdy pokusa dodania „jeszcze tylko jednej funkcji” znów się skrada. Bo zawsze się skrada.

Czym MVP naprawdę jest (i czym nie jest)

To pojęcie wytarło się od nadużywania, więc bądźmy precyzyjni. Minimum viable product to najmniejsza wersja Pana pomysłu, która dostarcza realną wartość realnemu użytkownikowi i uczy czegoś, czego nie da się wyczytać z prezentacji. Słowo, o którym ludzie zapominają, to viable — żywotne. Musi naprawdę działać dla kogoś, od początku do końca, nawet jeśli robi tylko jedną rzecz.

A oto czym MVP nie jest. To nie wpół ukończona wersja pełnego produktu z popsutymi rogami wszędzie. To nie prototyp do wyrzucenia. I z pewnością nie „tania wersja” — taniość to efekt uboczny dobrego określenia zakresu, a nie cel. Celem jest nauka. Wydaje Pan jak najmniej pieniędzy, by odpowiedzieć na najdroższe pytanie, jakie ma: czy ktokolwiek tego użyje i czy użyje tego tak, jak myślę?

To rozróżnienie liczy się bardziej, niż brzmi. Mentalność „pierwsze 20%” prowadzi do czegoś popsutego w każdym kierunku i nieprzydatnego nigdzie. „Jedna rzecz, porządnie” prowadzi do czegoś, co człowiek może wziąć do ręki, naprawdę użyć i wyrobić sobie opinię. Opinie to cały sens. Nie da się iterować na podstawie ciszy.

Pułapka budowania zbyt wiele i dlaczego tak łatwo w nią wpaść

Nikt nie zamierza świadomie przesadzić z zakresem. To dzieje się jedną rozsądną decyzją naraz. Dodaje Pan logowanie, bo przecież potrzeba kont. Konta oznaczają przepływ resetu hasła, weryfikację e-mail i stronę ustawień. Ustawienia oznaczają profil, co oznacza przesyłanie zdjęć, co oznacza miejsce do ich przechowywania. Każdy krok z osobna jest sensowny. Razem złożone — wydał Pan dwa miesiące i sporą część budżetu, zanim część, która czyni Pana pomysł wyjątkowym, w ogóle ruszyła.

Druga połowa pułapki jest emocjonalna. Wycinanie funkcji wydaje się przyznaniem, że pomysł jest mały. Nie jest — to przyznanie, że nie wie Pan jeszcze, które funkcje się liczą, co jest po prostu prawdą. Każda funkcja zbudowana, zanim ma Pan użytkowników, to zakład postawiony w ciemno. Część tych zakładów będzie błędna, a te wycięte z MVP to najtańsze możliwe zakłady do pomyłki, bo nigdy ich Pan nie postawił.

Znajdź jedno zadanie, które Twoje MVP musi wykonać

Każdy produkt, niezależnie od tego, jak duży w końcu się staje, ma pętlę rdzeniową — pojedynczą sekwencję, którą użytkownik powtarza i która tworzy wartość. Dla aplikacji rezerwacyjnej to znajdź termin, zarezerwuj go, dostań przypomnienie. Dla marketplace to wystaw rzecz, ktoś ją znajduje, pieniądze zmieniają właściciela. Dla narzędzia wewnętrznego to zarejestruj dane raz, używaj ich wszędzie. Wszystko inne w produkcie istnieje, by tę pętlę wspierać, zdobić lub rozszerzać. Pana MVP to pętla. Tylko pętla.

By znaleźć swoją, niech Pan dokończy to zdanie na głos: „Użytkownik przychodzi do mojego produktu, by ______, i jest zadowolony, jeśli ______.” Pierwsza luka to zadanie. Druga to sposób, w jaki Pan pozna, że zadziałało. Jeśli nie potrafi Pan wypełnić obu luk jednym tchem, nie znalazł Pan jeszcze rdzenia — i nie jest gotów, by określić zakres, a tym bardziej budować.

Niech Pan będzie bezwzględny co do różnicy między pętlą rdzeniową a rzeczami, które wydają się niezbędne, lecz nie są. Logowanie wydaje się niezbędne. Zwykle nie jest, w wersji pierwszej — mnóstwo MVP startuje z jednym współdzielonym linkiem, ręcznym zaproszeniem lub bez kont w ogóle i uczy się wszystkiego, czego trzeba, zanim zbuduje maszynerię uwierzytelniania. Pulpity analityczne wydają się niezbędne. Nie są; może Pan czytać bazę danych ręcznie, gdy ma jedenastu użytkowników. Niech Pan obnaży produkt do pętli, a zdziwi się, ile odpada.

Posortuj każdą funkcję na: musi, powinno i nie teraz

Gdy już nazwał Pan pętlę rdzeniową, niech Pan weźmie dużą listę funkcji i posortuje każdą do trzech koszyków. Koszyki są celowo tępe, bo tępość zatrzymuje niekończące się rozmowy „ale może”.

• Musi: pętla rdzeniowa dosłownie bez tego nie działa. Jeśli to usunąć, nie ma produktu. Niech ta lista będzie wstrząsająco krótka — zwykle od trzech do sześciu pozycji.
• Powinno: czyni produkt lepszym, ale pętla działa też bez tego. Wszystko tutaj czeka na wersję drugą. Żadnych wyjątków w pierwszej wersji.
• Nie teraz: funkcje, których świadomie nie buduje Pan teraz. Spisanie ich ma znaczenie — tak zapewnia Pan siebie i swój zespół, że pomysł nie jest porzucany, tylko ułożony w kolejności.

Sztuczka, która sprawia, że to działa, to trzeci koszyk. Większość ludzi spiera się tylko o „musi” kontra „powinno”, co jest wyczerpujące i nigdy się nie kończy. Lista „nie teraz” to miejsce, gdzie mieszka ulga — to obietnica złożona przyszłemu sobie, że fajny pomysł jest bezpieczny i zaplanowany, tylko nie teraz. Gdy ludzie zaufają, że nic nie jest wyrzucane, przestają walczyć o utrzymanie wszystkiego w wersji pierwszej.

Określaj zakres czasem i pieniędzmi, a nie listą funkcji

Oto cicha zmiana, która zmienia wszystko: niech Pan przestanie określać zakres przez „czego chcemy” i zacznie przez „co mieści się w budżecie i terminie”. Niech Pan najpierw zdecyduje, ile pieniędzy i ile tygodni jest gotów wydać, by odpowiedzieć na pytanie rdzeniowe. Potem niech dopasuje listę funkcji do tego pudełka. Brzmi to na opak, ale to najużyteczniejsze ograniczenie, jakie może Pan sobie dać, bo wymusza priorytetyzację, której inaczej by Pan unikał.

Stałe pudełko robi też coś psychologicznego. Gdy budżet jest otwarty, każda funkcja jest do dyskusji, a lista tylko rośnie. Gdy pudełko jest stałe — powiedzmy osiem tygodni i ustalona kwota — rozmowa się odwraca. Przestaje być „czy mamy to dodać?”, a staje się „co wypada, jeśli to wchodzi?” To drugie pytanie buduje dobre MVP. Kompromisy są widoczne zamiast ukryte, a zespół podejmuje je z rozmysłem.

Prawdziwy przykład: ograniczanie zakresu pomysłu na zarządzanie zleceniami

Zilustrujmy to konkretem z przypadku, nad którym pracowaliśmy — zanonimizowanym, ale wiernym temu, jak to wygląda. Mała firma od ogrzewania i hydrauliki przyszła do nas, chcąc aplikacji dla swojej ekipy terenowej. Brief na papierze był ogromny: planowanie zleceń na żywo, śledzenie GPS aut, portal klienta, automatyczne fakturowanie, ewidencja części w każdym pojeździe, kreator wycen, dokumentacja zdjęciowa i pakiet raportów dla właściciela. Naprawdę użyteczny produkt — ostatecznie. Jako pierwsza wersja: gwarantowany sposób, by wydać roczny budżet, zanim się czegokolwiek nauczy.

Zrobiliśmy więc ćwiczenie. Zadaliśmy właścicielowi zdanie: „Użytkownik przychodzi do tego, by ______, i jest zadowolony, jeśli ______.” Po pewnej wymianie zdań wypłynęła prawdziwa odpowiedź. Największym codziennym bólem techników nie było planowanie ani fakturowanie — był nim obieg papierów tam i z powrotem. Kończyli zlecenie, bazgrali godziny i części na kartce, jechali z powrotem, a ktoś w biurze przepisywał to wszystko do systemu księgowego, często dni później, często z błędami. Pętla rdzeniowa była po prostu taka: zarejestruj to, co się wydarzyło na zleceniu, raz, na miejscu, by nikt nie przepisywał.

Co weszło do wersji — a co nie

Wszystko zostało posortowane. Koszyk musi sprowadził się do czterech rzeczy: lista dzisiejszych zleceń dla każdego technika, prosty formularz do rejestrowania godzin i użytych części na zlecenie, załącznik ze zdjęciem oraz sposób, by biuro widziało te dane w momencie ich przesłania. To było całe MVP. Bez GPS, bez portalu klienta, bez kreatora wycen, bez wymyślnych raportów — wszystko zaparkowane, jawnie, na liście „nie teraz” z notatką, że nadejdzie.

Zbudowaliśmy ten rdzeń w kilka tygodni zamiast większej części roku. I oto część, która usprawiedliwia całe podejście: gdy tylko ruszyło, prawdziwe priorytety zespołu okazały się różnić od briefu. Właściciel zakładał, że śledzenie GPS będzie następne; technicy ledwie o nim wspomnieli. Czego chcieli, głośno, to wysyłać klientowi SMS-em okno przyjazdu z poziomu aplikacji — funkcja, której nawet nie było na pierwotnej liście. Ponieważ MVP było małe i tanie, został budżet, by zbudować to, czego naprawdę chcieli, zamiast tego, co zgadli miesiące wcześniej.

Błędy, które po cichu rujnują zakres MVP

Nawet zespoły, które przyjmują „trzymaj małe”, zwykle potykają się o te same kilka rzeczy. Żadna nie jest dramatyczna. To powolne przecieki, które na nowo nadymają zakres, gdy Pan nie patrzy, aż pewnego dnia „minimalny” produkt znów ma trzydzieści ekranów i sześciomiesięczny harmonogram.

• Pozłacanie brzegów: spędzanie dni na dopieszczaniu panelu admina, który zobaczy tylko Pan, podczas gdy pętla rdzeniowa wciąż jest surowa. Niech Pan poleruje to, czego dotykają użytkownicy; zaplecze niech zostanie brzydkie i funkcjonalne.
• Budowanie pod skalę, której Pan nie ma: projektowanie pod milion użytkowników, gdy trzeba udowodnić, że pierwszych dziesięciu wróci. Problem skali niech Pan rozwiąże, gdy będzie mieć szczęśliwy problem skali.
• Mylenie „niezbędne” ze „standardem branżowym”: to, że każdy konkurent ma funkcję X, nie znaczy, że Pana MVP jej potrzebuje, by przetestować rdzeniowy pomysł. Nie wystawia Pan gotowego produktu, prowadzi Pan eksperyment.
• Projektowanie z góry każdego przypadku brzegowego: obsługa rzadkich, dziwnych danych wejściowych, zanim wie Pan, czy ktokolwiek używa zwykłej, normalnej ścieżki. Niech prawdziwe użycie powie, które przypadki brzegowe są w ogóle realne.
• Brak definicji ukończenia: bez spisanego zdania opisującego, jak wygląda „skończone”, budowa nigdy się nie kończy. Rozpełzanie zakresu uwielbia projekt bez linii mety.

Jeśli ma Pan strzec się tylko jednego z tych, niech to będzie ostatni. Jasna, spisana definicja ukończenia — „technik może zarejestrować godziny i części zlecenia w telefonie, a biuro widzi to natychmiast” — to najpotężniejsze pojedyncze narzędzie, by utrzymać zakres w uczciwości. Każdy proponowany dodatek zostaje przyłożony do tego zdania. Jeśli nie służy zdaniu, to pomysł na wersję drugą, choćby był nie wiem jak dobry.

Prosty proces określania zakresu MVP

Zbierając to w całość, oto sekwencja, którą przeszedłbym z każdym przed rozpoczęciem pierwszej wersji. Jest celowo niskotechnologiczna — większość da się zrobić z dokumentem i uczciwą rozmową, na długo zanim potrzebny będzie programista w pokoju.

1. 1
   Nazwij pętlę rdzeniową

   Dokończ zdanie: „Użytkownik przychodzi, by zrobić ___, i jest zadowolony, jeśli ___.” Jeśli nie potrafisz, nie jesteś gotów określać zakresu — rozmawiaj dalej, aż wypłynie prawdziwe zadanie.
2. 2
   Wyrzuć każdą funkcję, potem posortuj

   Wydostań całą listę życzeń z głowy na papier. Posortuj każdą pozycję na musi, powinno albo nie teraz. Listę „musi” trzymaj bezlitośnie krótką.
3. 3
   Ustal pudełko

   Zdecyduj o budżecie i terminie, zanim sfinalizujesz listę funkcji. Niech lista zmieści się w pudełku, a nie odwrotnie.
4. 4
   Napisz definicję ukończenia

   Jedno konkretne zdanie opisujące działającą pętlę rdzeniową. To Twoja tarcza przeciw rozpełzaniu zakresu do końca projektu.
5. 5
   Zbuduj, wystartuj, obserwuj, potem decyduj

   Dostarcz rdzeń prawdziwym użytkownikom. Obserwuj, co naprawdę robią. Niech ich zachowanie — a nie wcześniejsze zgadywanie — wybierze, co zejdzie z listy „powinno” jako następne.

Niech Pan zauważy, że ostatni krok zawraca Pana na początek. Dobre MVP to nie jednorazowe wydarzenie, to pierwszy obrót koła. Określa Pan mały zakres, dostarcza, uczy się, a to, czego się Pan nauczy, na nowo określa zakres kolejnej wersji. Zespoły, które wygrywają, to nie te, które zaplanowały idealny produkt z góry — nikt tego nie robi. To te, które dość szybko postawiły coś prawdziwego przed użytkownikami, by rzeczywistość mogła je jeszcze pokierować.

Częste pytania