Odrzuć swoje uprzedzenia i dowiedz się, dlaczego firmy odnoszące sukcesy stosują MVP jako klucz do uszczęśliwiania swoich klientów.
Przez Arbiego Vartana i Jeffa Brinkerhoffa
Slalom kocha Agile. Jesteśmy podekscytowani rzeczywistymi, wymiernymi korzyściami, jakie firmy odnoszą dzięki niej, i omawiamy niektóre z jej największych zalet w serii wpisów na blogu oraz w bezpłatnym webinarium na temat Agile – do obejrzenia na żądanie.
MVP, czyli Minimum Viable Product, jest podstawą praktyki Agile. Jest to również coś, co wywołuje opór. Słyszeliśmy, jak nasi klienci mówili: „Nasi szefowie nie chcą minimum – chcą najlepszej możliwej jakości”. Rzeczywiście, dlaczego nie chciałbyś zrobić wszystkiego, co najlepsze? To świetne pytanie, ale oparte na niezrozumieniu MVP.
Powołany przez Franka Robinsona w 2001 roku, a spopularyzowany przez Erica Riesa w jego książce Lean Startup, MVP stał się filarem wysokowydajnych zespołów produktowych na całym świecie. Dlaczego Google dominuje od tak dawna? Dlaczego Apple tworzy jedne z najpopularniejszych produktów na świecie? Dlaczego Netflix nie tylko przetrwał, ale i rozwinął się poza swój pierwotny model biznesowy? Przyczyniło się do tego wiele czynników, ale jednym wspólnym wątkiem jest to, że wszystkie one używają MVP.
Czym więc jest MVP? Oto definicja Erica Riesa: Ta wersja nowego produktu, która pozwala zespołowi zebrać maksymalną ilość zweryfikowanej nauki o klientach przy najmniejszym wysiłku.
Jak jasno wynika z tej definicji, MVP nie jest produktem o najmniejszej możliwej funkcjonalności niezbędnej do publicznego uruchomienia. Nie ma nic wspólnego z publicznym wypuszczeniem produktu na rynek. MVP jest raczej kluczem do wykorzystania metody naukowej do budowania produktów. Jest to wyłącznie mechanizm zatwierdzonego uczenia się, wykorzystywany do testowania hipotez i odkrywania, co zaspokoi potrzeby klientów.
Zrzuć termin, jeśli musisz, ale zachowaj koncepcję
W firmie Slalom zintegrowaliśmy koncepcję MVP zarówno z tym, jak tworzymy produkty dla firm, jak i z tym, jak z nimi współpracujemy, aby czerpać korzyści z włączenia zasad i praktyk Agile do ich modelu biznesowego. Jednak – po ponad dwudziestu transformacjach Agile w przedsiębiorstwach i setkach partnerstw w różnych branżach – stwierdziliśmy, że czasami prościej jest nie zmuszać do używania terminów takich jak MVP. Henrik Kniberg (najlepiej znany ze swojej pracy z kulturą inżynieryjną Spotify) proponuje używanie terminów Earliest Testable, Earliest Usable i Earliest Lovable Products.
Każdy z tych terminów jest w porządku. W Agile chodzi o szczęśliwsze, bardziej produktywne zespoły – nie o terminologię. Nasze podejście do tej lub jakiejkolwiek innej błędnie zinterpretowanej, niejasnej koncepcji Agile polega na pominięciu tego słowa i zadaniu następujących trzech pytań:
- Po co to robić? W przypadku MVP chodzi o szybką naukę, a także o podstawowe zasady: zadowolenie klienta, ciągłe doskonalenie i prostotę.
- Co trzeba zrobić, aby zrobić to w mojej firmie? O, potędze kadrowania! Zamiast pytać, czy możesz to zrobić, skupiamy się na blokerach – organizacyjnych lub innych. Odpowiedź na to pytanie często przybiera formę kupna od osób, które uważano za nie do ruszenia.
- A co by było, gdybyśmy tego nie zrobili? Kolejna strategia kadrowania: skup się na kosztach utrzymania status quo. Może to zbudować poczucie pilności i zapewnić spójność wokół nowego sposobu pracy.
Oto historia o niebezpieczeństwach związanych ze status quo: Projekt dla firmy, z którą ostatnio współpracowaliśmy, obejmował spędzenie sześciu miesięcy na wydaniu dużego oprogramowania, które miało wpływ na ponad 200 użytkowników wewnętrznych. Zamknęli się w pokoju i zakończyli budowę i wszystkie testy. Dopiero w tym momencie zwrócono się o opinię do garstki analityków biznesowych – nie do rzeczywistych użytkowników. Tego rodzaju działanie, zbyt późne, aby mogło wywrzeć jakikolwiek realny wpływ, i bez prawdziwego skupienia się na zwalidowanym uczeniu się, trudno nawet zakwalifikować jako zbieranie opinii. Jest to tak naprawdę próba zatwierdzenia tego, co nieuniknione.
Wynik był do przewidzenia. Ponieważ poświęcono już tak wiele czasu i pieniędzy, poczuli się zmuszeni iść naprzód i wszyscy 200 użytkowników odrzucili nowe oprogramowanie z powodu jego powolnego działania i braku użyteczności. Sześć miesięcy i ponad 12 milionów dolarów wydanych, a tylko wskazywanie palcem między zespołami biznesowymi i technologicznymi, aby to pokazać.
Wyobraźmy sobie ten sam scenariusz z MVP wdrożonym do grupy użytkowników końcowych na początku projektu. Programiści mogliby natychmiast dowiedzieć się, co robili źle, a następnie wdrożyć kolejne MVP, ulepszając iteracyjnie każde z nich, aż do wdrożenia ostatecznego produktu – opracowanego z prawdziwymi użytkownikami i przez nich zatwierdzonego. Kolejna korzyść: użytkownicy w grupie testowej byliby w pełni zaangażowani w projekt i ewangelizowaliby go wśród swoich rówieśników.
Widzieliśmy dokładnie taki scenariusz i dlatego jesteśmy tak zdecydowanymi zwolennikami MVP – jakkolwiek byśmy go nie nazwali.
.