Czy jest sens budować MVP iteracyjnie?

Czy idee MVP (Minimal Viable Product – minimalnego przydatnego produktu) i iteracyjnego developmentu są powiązane? Czy próbują rozwiązać ten sam problem w inny sposób, czy są komplementarne i mogą być używane razem?

MVP w pigułce

MVP to podejście spopularyzowane przez ruch Lean Startup. Stojącą za nim ideą jest jak najszybsza i najtańsza weryfikacja potencjału rynkowego wizji produktu, poprzez udostępnienie najprostszej możliwej wersji produktu prawdziwym klientom.

Idea ta opiera się na trzech spostrzeżeniach:

• Żadna ilość teoretyzowania ani badań rynkowych nie jest w stanie zweryfikować wizji produktu. Jedynie chęć prawdziwych klientów do zapłacenia za ten produkt może ją zweryfikować.
• Nie chcemy ponosić kosztów kompletnego, zawierającego pełny zestaw funkcjonalności i dopieszczonego produktu by zweryfikować jego wizję. Chcemy zweryfikować ją przy pomocy taniego, minimalnego “proof of concept”.
• Klienci nie zapłacą za ułomny, nieużyteczny ani słabej jakości produkt, niezależnie czy jego wizja jest dla nich atrakcyjna czy nie. W związku z tym, nasz pierwszy “proof of concept”, mimo że minimalny, musi być też przydatny.

Iteracyjny development w pigułce

Iteracyjny development to podejście będące osią większości metodyk Agile. Jego ideą jest budowanie produktu ciągiem krótkich, sztywno ograniczonych czasowo, stałej długości “sprintów”, w taki sposób, by na koniec każdego sprintu otrzymać mały przyrost końcowego produktu. Możemy wydać go na produkcję natychmiast lub zaczekać aż dostateczna ilość takich niewielkich przyrostów się zakumuluje.

By takie podejście mogło działać musi zostać spełnionych kilka warunków:

• Produkt musi być budowany jako ciąg “pionowych wycinków”. Przyrosty mogą być bardzo małe, ale każdy przyrost musi być w pełni funkcjonalny, użyteczny dla użytkownika końcowego.
• Każdy przyrost musi się potencjalnie nadawać do wydania na produkcję. Nie musimy wydawać go natychmiast, ale musi on być dostatecznej jakości i być dostatecznie dopracowany technicznie, by nadawać się do natychmiastowego wydania jeżeli zdecydujemy się to zrobić.
• Każdy przyrost musi wnosić jakąś wartość dodaną dla klienta. Prace powinny być zorganizowane w taki sposób, by przyrosty wnoszące największą wartość były budowane najpierw.

Czy idee MVP i iteracyjnego developmentu kolidują ze sobą?

Może się wydawać, że idee MVP i iteracyjnego developmentu się nakładają. MVP to niewielki, w pełni funkcjonalny wycinek produktu, wartościowy dla klienta – identycznie jak przyrost na koniec sprintu. Jest tylko jedna, fundamentalna różnica:

• MVP nie jest sztywno ograniczone czasowo tak jak sprinty. Uznajemy je za gotowe w momencie gdy osiąga przydatność, a nie gdy upłynie z góry zdefiniowany przedział czasu. Nie ma też powodu by odwlekać wydanie MVP na produkcję gdy jest gotowe.
• Przyrost zbudowany podczas sprintu musi się potencjalnie nadawać do wydania na produkcję, ale w przeciwieństwie do MVP może nie być jeszcze przydatny dla klienta. Być może będziemy musieli zaczekać aż inkrementy z kilku kolejnych sprintów się zakumulują zanim będziemy mogli udostępnić produkt klientom.

Czy w takim razie jest sens pracować iteracyjnie? MVP to z definicji najmniejszy możliwy przyrost produktu, który jest przydatny dla klientów. Czy istnieje jakakolwiek korzyść z dzielenia tego przyrostu na jeszcze mniejsze, nieprzydatne przyrosty?

Owszem, istnieje.

Iteracyjny development pomaga nam się upewnić, że MVP jest rzeczywiście przydatne

O wiele łatwiej odgadnąć jaki zestaw funkcjonalności jest konieczny, by minimalny produkt był przydatny, niż odgadnąć jak powinien wyglądać końcowy produkt, by stał się sukcesem rynkowym, niemniej jednak to nadal tylko zgadywanie. Możemy wyobrazić sobie co będzie przydatne, ale nie możemy tego zweryfikować dopóki nie mamy w swoich rękach działającego produktu.

Tak samo jest z zagadnieniami jakości i użyteczności (usability). Nie tylko brak funkcjonalności może uczynić produkt nieprzydatnym, niska użyteczność także może zniechęcić klientów. I tak jak poprzednio, teoretyzowanie na temat użyteczności nigdy nie da nam tak dobrych odpowiedzi jak przeprowadzenie testów użyteczności na działającym produkcie.

Budowanie produktu małymi, ale działającymi przyrostami, i ciągła ewaluacja tych przyrostów pozwala nam podejmować lepsze decyzje na temat tego, co jest potrzebne by produkt stał się przydanty oraz osiągnąć tą przydatność taniej, dzięki temu, że mniej po drode błądzimy.

Iteracyjny development pomaga nam zapewnić, że MVP jest rzeczywiście minimalne

Ponieważ nie wiemy dokładnie jaki zestaw funkcjonalnosci uczyni produkt przydatnym, nie możemy również zbudować prawdziwie minimalnego produktu. Kroczymy po cienkiej linii pomiędzy minimalnym a nieużytecznym produktem, więc gdy jesteśmy zmuszeni polegać na zgadywaniu, mamy tendencję do “dopychania” do produktu dodatkowych funkcjonalności, by czuć się bezpiecznie.

Z drugiej strony, przy podejściu iteracyjnym, połączonym z budowaniem najbardziej wartościowych funkcjonalności najpierw, zaczynamy od przyrostu produktu, który jest zdecydowanie mniejszy niż MVP. Następnie stopniowo go rozbudowujemy, intensywnie testując i ewaluując produkt po każdym sprincie. To pozwala nam własnoręcznie ocenić, na działającym produkcie, czy stał się on już przydatny, nie musimy więc zgadywać i nie musimy “dopychać” funkcjonalności by czuć się bezpiecznie. W efekcie, możemy wydać na produkcję prawdziwie minimalny produkt, natychmiast gdy osiągnie on przydatność.

Iteracyjny development pomaga nam zachować elastyczność podczas budowania MVP

Cały feedback od klienów i wszystkie okazje do pivot-u trafiają się, oczywiście, już po tym gdy MVP zostanie wypuszczone na produkcję. Jednakże, proces przekuwania pomysłu w namacalny produkt zapewnia wiele okazji do nauki i drobnych korekt kursu, nawet jeśli dzieje się to jedynie wewnętrznie.

Iteracyjne budowanie przyrostów produktu potencjalnie nadających się do wydania na produkcję umożliwia nam pozostawanie otwartym na tego typu okazje. Jest wprawdzie niezbyt prawdopodobne, by elastyczność, jaką to zapewnia, zaowocowała dużym pivot-em w trakcie developmentu MVP, jest za to bardzo prawdopodobne, że zaowocuje ona licznymi drobnymi poprawkami, które sprawią, że MVP będzie lepsze a nasza początkowa wizja produktu bardziej doszlifowana.

Podsumowując: traktuj potencjalnie nadający się do wydania na produkcję przyrost produktu na koniec każdego sprintu jako wewnętrzne MVP

Zadaliśmy sobie w tym poście pytanie, czy ma sens rozbijanie MVP na ciąg mniejszych iteracji, skoro MVP i tak jest już minimalne. Mój punkt widzenia na tą kwestię jest taki, że MVP jest minimalnym produktem, który może zapewnić nam feedback od klientów. Jednakże, możemy rozbić MVP na jeszcze mniejsze części by pozyskać feedback niższego poziomu podczas developmentu. Myśl o tym jako o wewnętrznym MVP, minimalnym produkcie, jaki może zapewnić nam feedback od interesariuszy i z testów użyteczności. Oczywiście, takie wewnętrzne MVP nie pozwoli nam zweryfikować wizji produktu w taki sam sposób jak “prawdziwe” MVP, jednak wciąż zapewnia ono wiele korzyści, nie powinniśmy więc w naszym procesie odrzucać takiej okazji.

Jakie są Twoje doświadczenia? Czy używasz iteracyjnego developmentu do budowania MVP? Jakie korzyści albo wady takiego podejścia zauważyłeś? Podziel się swoją opinią w komentarzach poniżej!