Tematyka „minimalnego produktu powodującego uśmiech na twarzy klienta” (Minimum Viable Product) jest wiecznie żywa. Najczęściej zadawanym pytaniem jest właśnie „Jak wyznaczyć MVP?” Łatwo powiedzieć, że chcemy zrobić absolutne minimum. Ale co to znaczy?
MVP, czyli prostota
Zarówno Product Ownerzy jak i Zespoły Dewloperskie dają się przekonać bez problemu, że warto jest unikać wodotrysków i robienia rzeczy zbędnych. Jeżeli coś wcale nie pomaga nam w osiągnięciu naszego zwinnego celu, czyli zadowolenia klienta, to prostu tego nie róbmy.
Po co robić funkcje logowania za pomocą Facebooka, Google’a, itd. jeżeli sukces naszego produktu w ogóle od tego nie zależy? Zwykle bardziej opłaca się wypuścić go wcześniej, niż zajmować się takimi detalami.
W odpowiedzi na pytanie „Czy warto?” pomóc nam może określenie wartości PBI (Elementów Backlog Produktu). Warto przy tej okazji zastanowić się, czy kolejność wymagań to na pewno priorytet czy wartość biznesowa. Ale nawet nie odwołując się do żadnych konkretnych technik, wystarczy wziąć pod lupę elementy Backlogu Produktu i jak na dłoni wyjdzie nam, że nie wszystko „trzeba” zrobić. Ok, „powinno się”, ale nie jest to absolutnie niezbędne. Idee prostoty i MVP idą ze sobą w parze.
Sam temat prostoty poruszaliśmy w „bolesnym” filmiku na YouTube pod tytułem „Prostota, a 12 Zasad Zwinnego Tworzenia Oprogramowania” oraz w tekście o bardzo tajemniczym tytule „Cząstkowy Efekt Synergii„. W obu przypadkach chodziło nam o podobne podejście do rozwijanego produktu. Mówiąc wprost – zróbmy tak mało, jak tylko się da, żeby nasz klient i tak był zadowolony. Bądźmy pozytywnie leniwi.
To wymaga dobrej znajomości potrzeb biznesowych i/lub doświadczenia z produktem, segmentem rynku lub organizacją. To Product Owner powinien być w stanie dowiedzieć się lub przewidzieć, które rzeczy są naprawdę niezbędne, które są zbędne, a których braku nikt nawet nie zauważy.
Techniki wspierające MVP
MVP można identyfikować z wykorzystaniem wielu dobrze znanych i lubianych technik. Wszystkie z nich wymagają dużego wkładu i zaangażowania interesariuszy, użytkowników, Product Ownera i samych Zespołów Deweloperskich. I nie ma tu znaczenia czy zdecydujemy się na metodę MoSCoW, czy pójdziemy w stronę określania Cost of Delay, czy też MVP wyjdzie nam przy okazji sesji Story Mapping. Powinniśmy być w stanie skrajnie łatwo osiągnąć przynajmniej dwa efekty.
Po pierwsze, zidentyfikujemy i odłożymy na później wszystkie te wymagania, które są bardziej życzeniowe i nie wynikają wprost z potrzeb biznesowych. Po drugie, wśród tego wszystkie co zostanie znajdziemy rzeczy, bez których absolutnie nie ma sensu wypuszczać naszego produktu na rynek. I tutaj zaczynają się schody, bo to wcale nie koniec okrajania naszego rozwiązania do postaci MVP.
To tutaj zaczyna się ciężka praca Product Ownera i interesariuszy, którzy muszą zdecydować się na strategię budowy. I to oni powinni odkryć, że zdefiniowane przed chwilą MVP wcale nie jest „minimalne”. Bo patrząc z punktu widzenia biznesu za rok, czy za dwa – pewnie potrzebujemy wszystkiego (minus wodotryski i życzenia). Tylko już dobrze wiemy, że planowanie pierwszego wdrożenia na za rok (czy za dwa) nie jest rozsądne w dzisiejszych czasach. Ba, nigdy nie było.
Plagą stosowania podejścia zwinnego w Polsce (i nie tylko) jest używanie go do budowania „dobrze określonych produktów”. Przy czym wiemy, że ta fraza w cudzysłowie jest bzdurą, bo dopiero w trakcie budowy odkrywamy, o co tak naprawdę może nam chodzić. I to wtedy podejmujemy kluczowe decyzje co jest „good enough” i nadaje się do wdrożenia. Co nie znaczy, że nie powinniśmy się nad tym zastanowić wcześniej.
Systemowe, a biznesowe MVP
Jeżeli używamy podejścia zwinnego jako maszynki do realizacji stałej i niezmiennej listy wymagań, to równie dobrze możemy pójść w stronę jakiegoś dobrego waterfalla. Najczęstszy problem, z jakim się spotykamy na naszych szkoleniach dla Product Ownerów, to chęć zaliczenia do MVP stu procent „must have’ów”. Jest to patrzenie na koncepcję MVP systemowo (bądź procesowo) – wiemy co chcemy osiągnąć, więc zrealizujemy to „zwinnie”. A może by tak wypuścić coś mniejszego?
„Ale jak to! Nasi klienci potrzebują wszystkich funkcjonalności!”
Po pierwsze, zwykle nie mamy nawet takich badań. Po drugie, to są tylko założenia. A po trzecie i najważniejsze – czy na pewno nie jesteśmy w stanie zidentyfikować podgrupy, która może się cieszyć z podzbioru całości? Friends & family, nasi pracownicy i współpracownicy czy nawet jakiś określony rejon geograficzny – tam możemy znaleźć o wiele mniejsze MVP. Możemy nawet nazwać je pilotażem.
Inna popularna strategia, to odraczanie w czasie rzeczy cyklicznych lub terminowych. Mamy przecież blisko 30 dni np. na zrobienie miesięcznych płatności automatycznych, a aż do końca roku na rzeczy związane z zamknięciem tegoż. Nawet w kwestiach regulacyjnych bardzo często zbieranie danych czy wniosków i ich przetwarzanie oraz raportowanie to odrębne tematy.
Te pomysły na MVP to przede wszystkim spojrzenie pod kątem biznesowym. Zamiast zastanawiać się „bez czego aplikacja nie ruszy” przechodzimy do tematu „jak najszybciej znaleźć korzyść biznesową, nawet dla mniejszej grupy odbiorców”. I w taki sposób powinniśmy działać zwinnie.
Przykłady na wyznaczanie MVP
Żeby nie pozostawać gołosłownym, czas na parę przykładów.
Wdzieliśmy „zwinne projekty” mające na celu zastępowanie jednego systemu drugim. W klasycznym podejściu czekalibyśmy na 100% funkcjonalności, w zwinnym – poszczególne obszary uruchamiane mogą być etapami. Owszem, znaczy to, że przez jakiś czas ludzie będą pracowali na dwóch systemach. Ale ponieważ nowy będzie już działał produkcyjnie, uzyskamy nieocenioną informację zwrotną oraz będziemy mogli szybciej reagować na potrzeby rynku (przenoszenie starych funkcjonalności może przegrać z budową nowych).
Ba, widzieliśmy nawet rozwiązania, gdzie nowa aplikacja był udostępniana ściśle określonej grupie odbiorców, którzy wcześniej mieli trudności z korzystaniem z wersji podstawowej. Żeby nie zdradzać za dużo, wyobraźcie sobie budowę wersji 2.0 z obsługą wielu języków, gdzie jako MVP powstaje aplikacja dedykowana na nowy rynek. Rodacy korzystają z 1.0 do czasu osiągnięcia „100% must have’ów” przez nową wersję. Ale osoby z innych krajów już mogą działać z 2.0 (a tak naprawdę nie mają innego wyjścia).
Jeszcze inny przykład to aplikacja mająca miliony użytkowników, gdzie nowe funkcjonalności były wdrażane regularnie dla kilku procent odpowiednio dobieranych klientów. Znacząco ograniczało to ryzyko „pudła” oraz pozwalało w kontrolowany sposób sprawdzać wykorzystanie nowych pomysłów. Wiemy przecież, że lepiej jest zmienić jedną rzecz, niż pięćdziesiąt.
Pamiętajcie, że nawet Instagram na początku nie zawierał Stories, tagowania miejsc, Story Highlights i wielu innych funkcji. Co więcej, niektóre rzeczy, które mogłyby być elementem MVP bądź samego Instagrama zostały zbudowane jako osobne aplikacje (patrz np. Boomerang). Tak, to znów ta prostota.
W kontekście MVP warto wziąć pod lupę Instagram i inne skrajnie proste aplikacje ery smartfonów. Widząc je dziś, pewnie wydaje Wam się, że wszystkie funkcje są absolutnie niezbędne. Tymczasem patrząc na ich historię, widzimy, że jednak dało się zrobić mniej niż 100%. I jestem absolutnie przekonany, że w Waszych produktach też MVP jest większe, niż być powinno.
Tomek, bardzo merytoryczny i ciekawy artykuł! Sam jestem zwolennikiem budowy produktów MVP z głową i przede wszystkim edukowania naszych potencjalnych partnerów na ten temat. Nie jest to proste, bo jak sam piszesz – wszystko jest zawsze „must have”.
Trafiłem ostatnio na ciekawego partnera z Niemiec, który na starcie zakomunikował, że chce MVP i wie z czym to się je. Na warsztatach produktowych i tak trochę popłynęliśmy, co później jeszcze zawężaliśmy i ostatecznie powstałą koncepcja, która jest do wykonania w 2-3 miesiące.