MVP, MMF, PSI, WTF? Część pierwsza: Zrozumienie MVP
Kiedy pracuję z nowymi Właścicielami Produktu, często zauważam, że wpadamy w morze TLA (trzyliterowych akronimów), kiedy przychodzi czas, aby faktycznie zacząć przekształcać ich Backlog pomysłów w możliwe do wydania przyrosty wartości.
Pomysł rozbicia pracy – rozbicia naszych dużych, zaplanowanych wydań produktu na mniejsze przyrosty wartości – jest tym, z czym zmaga się wielu nowych Właścicieli Produktu. Jak przekształcić tę Mapę Drogową Produktu w coś, co moje zespoły Scrumowe mogą faktycznie dostarczać w krótkich, regularnych odstępach czasu? Jak przekształcić tę ogromną listę Bardzo Ważnych Cech (Very Important Features – VIF) w iteracyjny zestaw okazji do uczenia się, dostarczania wartości i faktycznego oddawania czegoś w ręce klientów? Innymi słowy….
„Co to jest nasze MVP?”
„Czy to jest nasze MMF?”
„Czy możemy wypuścić ten PSI jako MVP, czy potrzebujemy więcej historyjek, zanim będziemy mieć MMF?”
A także…. co??
Co oznaczają te TLA? Jak się różnią od siebie? Jak są powiązane? Dlaczego powinno mnie to obchodzić?
Zaczynając od MVP (Minimum Viable Product), ta trzyczęściowa seria pomoże początkującym agilistom zrozumieć, co oznaczają te TLA. Czym się różnią od siebie? Jak są powiązane? Dlaczego powinno mnie to obchodzić? Pomoże również przypomnieć tym, którzy pracują w Agile od jakiegoś czasu, dlaczego te koncepcje są podstawą zwinności.
Dla ludzi, którzy dopiero zaczynają uczyć się o Scrumie, mogą sięgnąć do Przewodnika po Scrumie… i szybko dowiedzą się, że Przewodnik po Scrumie milczy na temat tego, jak przekształcić produkt w zbiór małych, możliwych do uwolnienia przyrostów wartości.
Brak informacji na ten ważny temat może być naprawdę frustrujący dla nowych Właścicieli Produktu. Mam nadzieję, że dalsza część tego artykułu wyjaśni kwestię MVP, a po więcej informacji zawsze można zajrzeć na zajęcia Certified Scrum Product Owner. Na razie zanurzmy się w Minimum Viable Product.
The MVP
Przeprowadziłeś swoje badania, przeprowadziłeś grupy fokusowe klientów przez kilka rund Buy a Feature i podjąłeś pewne decyzje dotyczące tego, jak może wyglądać twoje następne wydanie. W rzeczywistości, zaangażowałeś swój zespół marketingowy i iterujesz przez pomysły, jak zrobić duży rozgłos – reklamy w czasopismach branżowych, promowane tweety, posty na Facebooku…
Ale nadal istnieją pewne dręczące pytania, które masz wokół niektórych funkcji, nad którymi pracujesz. Myślałeś o nich, analizowałeś je, ale jest ten głos w twojej głowie, który wciąż pyta: „Ale skąd wiesz?”
Tam właśnie MVP wchodzi do gry – nie Steph Curry, ale (być może błędnie nazwany) Minimum Viable Product.
The Lean Startup Conundrum
W swojej książce „The Lean Startup”, Eric Reis myląco redefiniuje termin „Minimum Viable Product”, co wyjaśnia w wywiadzie z 2015 roku. W skrócie:
„Some caveats right off the bat. MVP, pomimo nazwy, nie polega na tworzeniu minimalnych produktów. Po drugie, użycie w definicji słów maksimum i minimum oznacza, że zdecydowanie nie jest to formuła.”
Więc, jeśli świat Product Ownership i społeczność Agile przedefiniowała Minimum Viable Product, aby nie było ani o tworzeniu minimum, ani produktów, to czym jest?
All About the Learning
Ten dokuczliwy głos z tyłu głowy, zastanawiający się, czy istnieje sposób na wyjście z pułapki paraliżu analitycznego, w której się znajdujesz, próbując wymyślić sposób na rzeczywiste poznanie odpowiedzi na niektóre z twoich pytań, zamiast analizowania siebie w głębsze poczucie fałszywego bezpieczeństwa? To właśnie tam pojawia się Minimum Viable Product.
Gdzie PSI (Potentially Shippable Increment) dotyczy stworzenia możliwości potencjalnego dostarczenia czegoś wartościowego, a MMF (Minimum Marketable Feature) dotyczy połączenia tych kawałków wartości w zbiór funkcji, które rozwiązują problemy klienta, MVP dotyczy wykonania minimalnej ilości pracy, jaką zespół może wykonać w celu zamknięcia zatwierdzonej pętli uczenia się.
W metodologii Lean Startup odkrywania produktu, jednym z najważniejszych nawyków, jakie należy wyrobić, jest nawyk walidacji hipotez i tworzenia eksperymentów. W organizacjach bardziej tradycyjnie unikających ryzyka, przekonanie, że ryzyko musi zostać przeanalizowane przed wprowadzeniem produktu na rynek, prowadzi do długich czasów realizacji i, co frustrujące, do opartych na danych założeń dotyczących pragnień i potrzeb klientów. Jeśli jesteśmy naprawdę dobrzy w analizie statystycznej, i jeśli mamy naprawdę dobre dane o statystycznie znaczącej części naszych klientów, możemy wykonać całkiem niezłą robotę, formułując wykształcone przypuszczenie na temat tego, czego chcą nasi klienci.
Ale na koniec dnia to wciąż jest przypuszczenie.
Gdy tworzymy MVP, celowo budujemy tylko tyle funkcjonalności, aby zadać naszym klientom właściwe pytania – czy kupiłbyś ten produkt? Czy te ikony mają sens? Czy ten przepływ pracy cię frustruje, czy pomaga ci znaleźć następną ulubioną restaurację?
W tym momencie patrzymy na papierowe prototypy, makiety stron internetowych, makiety UI; idziemy na drugą stronę ulicy do centrum handlowego, aby pokazać nasze projekty najbliższym ludziom, tylko po to, aby szybko zweryfikować, że jesteśmy na dobrej drodze.
Magia w tworzeniu dobrego MVP nie tkwi w narzędziach czy technikach; tkwi w dyscyplinie, kiedy chcesz przeanalizować dane z mapy cieplnej strony internetowej, aby dowiedzieć się, który schemat kolorystyczny działa najlepiej, zamiast tego chwyć za markery i papier, naszkicuj kilka rozwiązań o niskiej wierności i zapytaj kogoś: „Które z nich podoba ci się bardziej?”
.