MVP - co to jest?

24 marca 2022
Jakub Rojek Jakub Rojek
Zdjęcie autorstwa Ash z Pexels (https://www.pexels.com/pl-pl/zdjecie/nalesnik-z-pokrojona-truskawka-376464/)
Kategorie: Analiza IT, Zarządzanie, Metodyki

Pomysły, z których potem powstają projekty IT, są bardzo różne. Czasami są to koncepcje zorientowane na konkretne, wyspecjalizowane środowisko (np. adeptów lub ekspertów z konkretnej dziedziny). Niekiedy są dedykowane wręcz jednemu środowisku - firmie, instytucji, a nawet działowi. A bywają też projekty, które nie celują w konkretnego odbiorcę, ale bardziej w ich liczbę. Wiele te aspekty dzieli, ale też łączy, w tym jedna podstawowa rzecz - poza pewnymi przypadkami, nigdy nie wiadomo, czy pomysł rzeczywiście się sprawdzi i pozwoli aplikacji lub systemowi zaistnieć na rynku albo po prostu będzie używany na tyle, aby koszty się zwróciły.

Tutaj już dotykamy sfery biznesu, ale nie ma co się dziwić - oprogramowanie komputerowe ma modelować pewien kawałek rzeczywistości i pozwolić na uzyskanie korzyści czasowych lub rzeczowych, co w konsekwencji przekłada się na zoptymalizowanie kosztów, a co dalej za tym idzie, przewagę biznesową. Nie bez powodu w specyfikacjach oprogramowania definiuje się tzw. środowisko biznesowe, próbując odwzorować tradycyjnie realizowane procesy na modłę komputerową. Zawsze na końcu chodzi o to, aby system IT coś nam dał, a nie po prostu tylko był.

Zatem nic dziwnego, że początkowy etap prac nad projektem jest ekstremalnie ważny na wielu płaszczyznach. Zazwyczaj podczas niego okazuje się, że pracy jest bardzo dużo, czas oczekiwania dłuższy niż klient się spodziewał, a nadal nie wiadomo, czy to wszystko będzie stanowiło atrakcyjną wartość biznesową dla użytkowników. Czy wówczas należy załamać ręce i zaniechać projektu? Nie - warto zaprzyjaźnić się z podejściem MVP.

Czym jest MVP?

Tutaj muszę rozczarować wszystkich kibiców sportowych, bo ten skrót nie oznacza w tym przypadku Most Valuable Player. W informatyce jest to Minimum Viable Product, czyli - tłumaczając niedosłownie - minimalna wersja produktu zdatna do użycia. Omawianie zaczniemy od pewnej metafory.

Wyobraźmy sobie tort urodzinowy, który wygląda pięknie, ale wymaga dużo pracy i nie wiadomo, czy będzie smaczny. Mimo wszystko chcemy jednak spróbować naszych sił, bo możemy tym zabłysnąć w towarzystwie. Wpadamy na pomysł, aby zrobić wycinek tego docelowego tortu - mały kawałek zawierający większość składników. Nie będzie to to samo, co właściwe ciasto, a nawet nie jego miniatura, ale za to będzie zdecydowanie prostsze i szybsze w przygotowaniu, przez co możemy łatwo i prędko przekonać się, czy smakołyk ma szansę być rzeczywistą atrakcją wieczoru. Jeśli tak - decydujemy się na tworzenie większej porcji tortu, bardziej przypominającej końcowy kształt i z większą liczbą składników. A jeśli nie - wiemy, że nic z tego nie będzie i zmarnowaliśmy czas oraz pieniądze, ale nie tak dużo, jak w przypadku próby robienia całego tortu.

To jest właśnie MVP - wybieramy najważniejszą funkcjonalność z docelowego produktu i tworzymy z niej produkt, który wydaje się pełnoprawny, ale tak naprawdę ma stanowić tylko próbkę, pozwalającą ocenić potencjalną wartość końcowego systemu. Nie jest to prototyp - ten z kolei cechuje się brakiem implementacji pewnych widocznych funkcji i wstawianiem zamiast nich "zaślepek". MVP to pełnowartościowy produkt, z dopracowanym interfejsem i czynnikami jakościowymi, ale funkcjonalnie ograniczony do niezbędnego minimum. Czasami, szczególnie w świecie gier wideo, można spotkać się jeszcze z określeniem vertical slice i mogłoby się wydawać, że to synonim, jednak po bliższym przyjrzeniu się, można zauważyć pewne różnice.

Tworzenie MVP idealnie wpasowuje się w ideologię agile - nie planujemy projektu od początku do końca, tylko wybieramy najważniejsze funkcje przynoszące użytkownikowi wartość biznesową i stopniowo je implementując działamy od sprintu do sprintu, jak najszybciej wdrażając powstałe wersje. Gdy wspólnie z klientem uznamy, że to, co stworzyliśmy, stanowi rdzeń tego, co ma być zaoferowane użytkownikowi, zleceniodawca może zacząć działać na większą skalę, walidując produkt na testowej grupie odbiorców i analizując, co sprawia problemy, co warto doprecyzować oraz czy dalsze prace mają w ogóle sens.

Podsumowując ten fragment, MVP pozwala:

  • stosunkowo małym kosztem ocenić, czy końcowy produkt miałby sens,
  • zweryfikować pomysły (teorię) z prawdziwymi sytuacjami, w których system byłby wykorzystywany (praktyką),
  • skupić się na tym, co jest najważniejsze i uniknąć funkcji, które nie mają sensu, mogą zdezorientować użytkowników, a niepotrzebnie zabiorą czas i pieniądze,
  • ograniczyć docelową funkcjonalność (za chwilę rozwiniemy temat),
  • rozpocząć wcześniejszy marketing z "gotowym" produktem do pokazania.

Jak konstruuje się MVP?

Tak naprawdę nie istnieje jedna właściwa metoda - każdy projekt i środowisko biznesowe są inne, a zatem również zakres MVP będzie za każdym razem się różnił. Natomiast możemy wypisać sobie pewne wskazówki, które pomogą nam we właściwym podejściu do tematu.

Przede wszystkim, przygotujmy sobie wymagania funkcjonalne, które zidentyfikowaliśmy dla naszego projektu. Będzie to element rejestru produktu (ang. product backlog), ale to nie wszystko - musimy również przemyśleć i wypisać zadania, które są potrzebne zarówno do realizacji oprogramowania, jak i wprowadzenia go na rynek. Jak najbardziej takim zadaniem jest zarówno przygotowanie ekranu profilu użytkownika czy logowanie, jak i choćby wybór oraz kupienie serwera lub przygotowanie stron pomocy dla użytkowników. To wszystko też zajmuje czas (czy to zespołu IT, czy zleceniodawcy), więc trzeba wszystkie takie zadania uwzględnić w budżecie.

Następnie zadaniom nadać priorytety oraz ważności. Wbrew pozorom, nie do końca jest to to samo - priorytet określa nam perspektywę czasową, z jaką trzeba wykonać dane zadanie, natomiast ważność definiuje to, czy w ogóle to zadanie jest ważne dla projektu. W praktyce jednak często unifikuje się te cechy i tworzy jedną wartość przypisywaną każdemu zadaniu. Zazwyczaj stosuje się skalę trójstopniową (H - High, M - Medium, L - Low), aczkolwiek można zastanowić się nad wprowadzeniem także poziomu pilnego (VH - Very High). O tym, jak radzić sobie z przydzielaniem priorytetów w narzędziu, pisaliśmy w tym artykule.

Kolejnym krokiem jest posortowanie zadań pod kątem priorytetu i sprawdzenie, czy to, co dostało najwyższy priorytet, rzeczywiście układa nam się w spójną wizję produktu. Prawdopodobnie tak nie będzie - okaże się, że nadal zadań jest za dużo i oszczędności wcale nie będą duże. W takiej sytuacji nie pozostaje nic innego, jak przyjrzeć się zadaniom jeszcze raz i przemyśleć (w większym gronie), które naprawdę są istotne, a które z żalem, ale jednak trzeba odpuścić. Być może występują pomiędzy nimi ciągi przyczynowo-skutkowe, co może nam ułatwić identyfikację powiązań zadań i ustalić kolejność, dzieląc tym samym MVP na podetapy. Czasami nie ma siły - MVP będzie większe niż się spodziewamy i wówczas decydująca jest nasza wiara oraz jakość wykonania projektu. Rzadko zdarza się odwrotna sytuacja - zadań priorytetowych jest na tyle mało, że produkt wydaje się wręcz mały. Przestrzegamy jednak wówczas przed dobraniem zadań mniej istotnych, aby wypełnić "przestrzeń" - owszem, czasami może nam się to opłacić, ale właśnie po to wprowadzamy mechanizm priorytetów, aby ograniczać funkcjonalność i budżet. Zbyt mała pula ważnych wymagań może też oznaczać, że projektu widocznie nie opłaca się robić, gdyż jego funkcje spełnia inna aplikacje lub aplikacje. Może to być rozczarowujące, ale w biznesie trzeba też wiedzieć, kiedy należy odpuścić.

Jeszcze dla porządku - skąd zatem wymienione wcześniej ograniczanie docelowej funkcjonalności? W toku prac i przygotowywania MVP może się okazać, że funkcja, która nie jest priorytetowa, ale wydawała nam się dość istotna, jest tak naprawdę niepotrzebna i system radzi sobie bez niej lub w międzyczasie trafiliśmy na lepsze rozwiązanie. To też efekt działania zarówno agile'u, jak i podejścia MVP.

Warto wspomnieć, że istnieje jeszcze jedna forma wprowadzenia MVP, dotycząca systemów mających zamodelować większy proces biznesowy w danym przedsiębiorstwie, a który można podzielić na części. Zazwyczaj jest tak, że o ile przygotowanie specyfikacji takiego oprogramowania jest możliwe, to jego realizacja oraz wdrażanie w całości jest ryzykowne (i to z wielu przyczyn, głównie pozatechnicznych). W takich sytuacjach warto wraz z klientem wybrać jeden fragment procesu i zająć się implementacją tylko jego. Szczególnie, jeśli ten etap jest obecnie szczególnie problematyczny dla firmy klienta i jego informatyzacja (etapu, nie klienta) w widoczny sposób podniesie wydajność pracowników. W przypadku sukcesu będzie to zachęta do zajęcia się innymi fragmentami procesu, także z uwzględnieniem wniosków z początkowego etapu.

Wady MVP

Tak naprawdę w przypadku tego podejścia trudno mówić o poważnych wadach, gdyż jest to raczej metoda radzenia sobie z nadmiarem zadań w projekcie pod kątem biznesowym. Jest to zatem coś, co ma nam pomóc, a nie stanowi drogę, z której nie ma odwrotu (żadnej funkcji nie przekreślamy całkowicie - jedynie ją odraczamy lub wstrzymujemy na czas nieokreślony). Natomiast jest jedna sytuacja, w której MVP może okazać się niebezpieczne - jest to realizacja źle dobranego zakresu produktu, który pokazuje go w wyjątkowo ubogiej wersji. Tak, jak wcześniej wspominaliśmy, MVP to nie prototyp i np. interfejs użytkownika musi być dopieszczony. Jednak jeśli wycinek produktu będzie oferował zbyt mało, a marketing nie uświadomi jasno odbiorców, że to tylko wersja testowa, która będzie rozbudowywana, to możemy zrazić do siebie potencjalnych klientów, w efekcie czego skreślą aplikację lub system już na starcie. To niebezpieczeństwo wynikające bardziej z marketingowym aspektów prowadzenia przedsięwzięcia IT, ale warto o nim wspomnieć, gdyż ma wpływ także na kwestie techniczne. Nie od dzisiaj wiadomo, że pierwsze wrażenie ma bardzo dużą moc.

Podsumowanie

MVP to bardzo użyteczne podejście przy wszelkiego rodzaju startupach i projektach IT, gdzie występuje niepewność związana z finansowym przyjęciem rozwiązania w docelowym środowisku. Jest to też, oczywiście, mechanizm pozwalający ograniczyć budżet, natomiast wymaga dobrego procesu weryfikacji i walidacji przez klienta. Naturalnie łączy się też z podejściem zwinnym, w efekcie czego proces powstania oprogramowania powinien być spójny zarówno technicznie, jak i biznesowo.

Pozdrawiam i dziękuję - Jakub Rojek.

Lubimy pisać, nawet bardzo, ale na co dzień tworzymy aplikacje webowe i mobilne. Sprawdź niektóre z wykonanych przez programów.

O autorze

Jakub Rojek

Główny programista i współwłaściciel Wilda Software, z wieloletnim doświadczeniem w tworzeniu i rozwoju oprogramowania, ale także w pisaniu tekstów na różnorakich blogach. Zaprawiony w boju analityk i architekt systemów IT. Jednocześnie absolwent Politechniki Poznańskiej i okazjonalny prowadzący zajęcia na tej uczelni. W wolnych chwilach oddaje się graniu w gry wideo (głównie w karcianki), czytaniu książek, oglądaniu futbolu amerykańskiego i e-sportu, odkrywaniu cięższej muzyki oraz wytykaniu innym błędów językowych.

Jakub Rojek