MVP czy nie MVP? Oto jest pytanie.
W obszarze rozwoju produktów on-line skrót MVP jest prawdopodobnie jednym z mocniej zakorzenionych akronimów. Jego rozwinięcie o „Minimal Viable Product” – minimalny opłacalny produkt. W pewnej popularnej wyszukiwarce internetowej znajduje się podobno trochę ponad 125 000 000 (tak – STO DWADZIEŚCIA PIĘĆ MILIONÓW!) wyników które jak mniemam traktują o tym czym jest MVP, jakie może być jego zastosowanie i rozwijają się wokół tej koncepcji. Dlatego też nie będę w tym artykule dotykał kwestii czym jest MVP. Zamiast tego chciałbym podzielić się z Tobą Drogi Czytelniku pewnym sprzeciwem, czy też przemyśleniem które wykiełkowało w mojej głowie na przestrzeni ostatnich lat kiedy miałem niejednokrotnie do czynienia z tym konceptem.
Jak tylko daleko jestem w stanie sięgnąć pamięcią wstecz, pojęcie MVP zawsze kojarzyło mi się z pewnym mitycznym „pierwszym etapem” realizacji projektu czy działań produktowych. Z minimalną ilością pracy konieczną do wyprodukowania czegoś, co podpowie czy w ogóle dany pomysł ma rację bytu i odpowiada na zadaną potrzebę. W tamtym czasie nie widziałem nic złego w takim podejściu. Ba, nadal poruszanie się możliwie małymi i szybkimi „krokami” jest czymś co staram się realizować i propagować w swojej codziennej pracy. Dlaczego więc w pewnym momencie zwątpiłem w termin MVP? Powodów jest kilka.
Po pierwsze dlatego, że chyba najczęstszy przypadek kiedy termin MVP pojawiał się w moim otoczeniu i w rozmowach to sytuacja kiedy zaczynała się dyskusja co jeszcze spełnia kryteria MVP, a co już wykracza poza jego granice. Z perspektywy czasu dochodzę do wniosku że w pewnym sensie MVP stało się symbolem samym w sobie i zatracił się jego pierwotny sens. Rozmowy nie dotykały najważniejszego pytania, czyli „co jest potrzebne żebyśmy mogli poznać odpowiedź na nasze pytania?” tylko przeszły w stronę precyzowania definicji. Przez to gubiliśmy w ogóle z oczu istotę naszych poszukiwań. Z kolei sytuacja kiedy zaczynają się spory o definicje prawie nigdy nie prowadzi do rozwiązania problemu, tylko do nerwów. W związku z tym zrodziła się w mojej głowie myśl żeby w ogóle porzucić to pojęcie a skupić się na pierwotnym znaczeniu. Takie odejście od „litery” prawa a skupienie na jego „duchu”.
Drugi zgrzyt jaki się we mnie pojawił to nie do końca słuszne przekonanie że MVP jest czymś co się robi tylko raz, na początku projektu żeby potwierdzić kilka głównych pomysłów, a potem już można postępować dowolnie. Oczywiście – nikt nikomu nie zabroni po fazie „MVP” przejść do układania rocznych planów, ale z drugiej strony czy stoi coś na przeszkodzie żeby kolejne kroki realizować z zachowaniem założeń MVP? Gdy zrealizujemy już pierwszy mały krok, zamiast rzucać się do razu sprintu – sądzę że warto jednak powtórzyć proces i zaplanować następny mały krok. W ten sposób stajemy się mniej podatni na bezwład wynikający ze zbyt dalekich planów, bo częściej pozyskujemy wiedzę i możemy jej użyć aby dostosować swoje dalsze kroki, ale także w pewien sposób minimalizujemy ryzyko że czegoś nie przewidzieliśmy, albo że pomyliliśmy się. Chciałbym tutaj też podkreślić że rozmiar tego „małego kroku” i czas na jego realizację powinien być w pełni dostosowany do rozmiaru i możliwości organizacji. Koniec końców idea MVP powinna służyć i pomagać, a nie blokować czy narzucać. Tym nie mniej jednak jestem przekonany że rzadko pojawiają się powody ku temu, aby po MVP zmieniać drastycznie tok postępowania.
Trzecia i ostatnia z moich bolączek to że MVP stało się w ogóle odrębnym podejściem, bytem, nazwą etapu w projekcie (zamiast np. „kickoff” czy „alfa”) – a nie elementem “normalnego” działania. Wartości i podejście proponowane przez MVP powinno moim zdaniem być elementem zdroworozsądkowego podejścia przy codziennej pracy z produktem, realizacją założeń manifestu Zwinnego Wytwarzania Oprogramowania. Podobnie jak w życiu – zdrowy tryb życia nie polega na tym, że zjemy tylko zdrowie śniadanie w poniedziałek, a przez resztę tygodnia zjadamy co popadnie. Ośmieliłbym się nawet zaryzykować stwierdzenie że na produkty dojrzałe i rozwinięte również przecież czekają zagrożenia takie jak na produkty w bardzo wczesnym stadium rozwoju. Skoro więc zagrożenia i szanse towarzyszą rozwojowi produktów przez cały czas, to dlaczego rozsądek mamy zachowywać tylko na początku drogi?
Zmierzając do konkluzji – uważam że warto rozważyć pomysł przyjęcia postulatów MVP nie tylko pod kątem realizacji pierwszego etapu projektu czy produktu, ale włączyć je na stałe do swojego przybornika. Pierwszym krokiem ku takiej przemianie moim zdaniem byłoby „zakopanie” pojęcia MVP jako czegoś odrębnego i jednorazowego, a drugim byłoby odświeżenie znajomości wyżej wspomnianych zasad Manifestu Zwinnego Wytwarzania Oprogramowania. Myślę że w ten sposób umożliwimy sami sobie w większym stopniu wykorzystanie dobrodziejstw tego podejścia.
Tradycyjnie jeszcze dodam tylko, że powyższe przemyślenia są jedynie wynikiem moich obserwacji i doświadczeń, więc jeśli w Twoim odczuciu MVP jako osobny etap czy odmienne podejście ma swój sens to bardzo serdecznie zapraszam do rozmowy w komentarzach.
Piona!
