MVP aplikacji — co to jest i jak spisać zakres pierwszej wersji, żeby wycena i termin miały sens?

Tekst wygenerowany przez AI · Wydawca: Tomasz Niedźwiecki · zawiera oznaczoną reklamę jego usług

Co to jest MVP aplikacji?

Skrót MVP pochodzi od „minimum viable product”. Eric Ries zdefiniował je w 2009 r. na blogu Startup Lessons Learned jako wersję nowego produktu, która przy najmniejszym wysiłku daje zespołowi najwięcej potwierdzonej wiedzy o klientach („maximum amount of validated learning about customers with the least effort”).

W aplikacji dla firmy z tej definicji zostają dwie rzeczy. Pierwsza wersja ma działać na prawdziwych użytkownikach i prawdziwych danych, bo inaczej niczego nie sprawdza. I ma być najmniejsza, bo każda funkcja ponad minimum opóźnia moment, w którym ktoś z niej skorzysta.

MVP to nie „tańsza wersja wszystkiego”. To jedna rzecz zrobiona do końca: od logowania, przez funkcję główną, po płatność — jeśli aplikacja ją przyjmuje — i start na docelowej domenie.

Przykład: MVP aplikacji dla warsztatu — co wchodzi, a co nie?

Weźmy warsztat samochodowy, który przyjmuje zgłoszenia telefonicznie i gubi terminy. Role: właściciel, dwóch mechaników, klient końcowy. Funkcja główna: klient rezerwuje termin naprawy z wolnych okien i dostaje potwierdzenie SMS.

• Wchodzi: logowanie właściciela i mechaników, kalendarz wolnych okien, formularz rezerwacji dla klienta, zmiana statusu zlecenia, SMS z potwierdzeniem, panel administratora, regulamin i polityka prywatności, start na domenie warsztatu.
• Nie wchodzi: płatności online za naprawę, wymiana danych z hurtownią części, program lojalnościowy, oceny mechaników, raporty miesięczne, wersja w sklepach z aplikacjami.

Druga lista nie jest listą „złych pomysłów”. To kolejka na drugą wersję, ustalona zanim ktokolwiek zaczął pisać kod — dzięki niej nikt nie dopisuje jej punktów po cichu w trakcie budowy.

Co musi być w zakresie pierwszej wersji? Lista do skopiowania

Pięć elementów. Zakresu, w którym brakuje któregoś, nie da się wycenić ryczałtem ani rozliczyć przy odbiorze, bo nie ma listy, do której można przyłożyć gotową aplikację.

1. Problem i odbiorcy — czyją pracę aplikacja skraca i kto siada przed ekranem: role z nazwy, nie „użytkownicy”.
2. Jedna funkcja główna i najwyżej dwie wspierające — opisane czasownikiem i przypisane do widoku, na którym się dzieją.
3. Lista ekranów i ról — policzalna i ponumerowana, razem ze stanem pustym i stanem błędu.
4. Granica: czego w tej wersji nie ma — jawna lista, nie milczenie.
5. Kryteria odbioru i wkład zamawiającego — co znaczy „gotowe” dla każdej funkcji, w scenariuszach do przeklikania, oraz materiały, decyzje i dostępy z datami po stronie zamawiającego.

W pierwszej wersji aplikacji dla firmy powtarza się u nas ten sam skład: logowanie i konta, panel klienta, panel administratora, funkcja główna z jedną lub dwiema wspierającymi, płatności i subskrypcje, strona sprzedaży pod markę, automatyzacje i statystyki, dokumenty (regulamin, polityka prywatności, RODO) oraz uruchomienie na żywo.

Te dziewięć pozycji to nie jest dziewięć funkcji. Osiem z nich to szkielet, który ma każda aplikacja przyjmująca płatności i konta. Funkcja główna jest jedna i tylko ona decyduje, czy komuś się przyda.

Czego nie wpisywać do pierwszej wersji i dlaczego?

Cztery grupy funkcji wracają u nas w prawie każdej rozmowie o zakresie i prawie zawsze wypadają z pierwszej wersji. Nie dlatego, że są złe, tylko dlatego, że kosztują czas, zanim jest komu je pokazać.

Funkcje z efektem sieciowym — czat, oceny, polecenia, ranking. Mają sens przy setkach aktywnych kont; przy dwudziestu wyglądają jak pusty ekran i psują wrażenie z aplikacji, która poza tym działa.

Integracje „na później” — wymiana danych z programem księgowym, hurtownią albo systemem sieci franczyzowej. To najdroższa część zakresu, bo zależy od cudzej dokumentacji, cudzych limitów i tempa odpowiedzi drugiej strony.

Panel raportów — raporty liczą się z danych, których w dniu startu jeszcze nie ma. Przez pierwsze miesiące wystarczy eksport do pliku i dwa liczniki w panelu administratora.

Role „na wyrost” — pięć rodzajów użytkownika zamiast dwóch mnoży ścieżki do zbudowania i do przetestowania, a w małej firmie i tak wszystko robią dwie osoby.

Osobno stoi obecność w sklepach z aplikacjami. To decyzja o dystrybucji, nie o funkcji, i wraca przy wyborze, czy aplikacja ma być natywna, hybrydowa czy jako PWA w przeglądarce.

Jak zakres steruje wyceną i terminem?

Zależność działa w obie strony: zamknięta wycena powstaje z zamkniętej listy, a termin biegnie od kompletu decyzji i materiałów. Kwot tutaj nie podajemy — ile kosztuje MVP w polskich cennikach, zestawia przegląd cenników MVP na policzpomysl.pl, a rachunek posiadania aplikacji przez trzy lata — osobny tekst na policzpomysl.pl.

Pozycja opisana ogólnie nie znika z wyceny. Zostaje wyceniona najostrożniejszym wariantem, jaki da się z niej odczytać, bo ryzyko ma swoją cenę i swój termin. Niedopowiedzenie w zakresie działa więc przeciwko zamawiającemu, nie na jego korzyść.

Termin ma drugi warunek: materiały, decyzje i dostępy po stronie zamawiającego. Ich brak zatrzymuje bieg terminów — nie jako kara, tylko dlatego, że pracy nie da się wykonać. Dlatego wkład zamawiającego stoi w zakresie razem z datami. Ile tygodni zajmuje każdy etap budowy, zestawia tekst o tym, ile trwa stworzenie aplikacji, na policzpomysl.pl.

Zakres steruje też odbiorem. Do gotowej aplikacji przykłada się listę z zakresu, a nie wrażenie z pokazu. Sam odbiór, z oknem na uwagi i tym, co dzieje się przy ich braku, opisujemy w tekście o budowie krok po kroku.

Jak wygląda zmiana zakresu w trakcie?

Zmiana zakresu to osobna wycena, nie „dorzucimy”. Brzmi twardo, a chroni zamawiającego: pozwala policzyć, ile kosztuje pomysł, który przyszedł do głowy w piątym tygodniu budowy, i zdecydować, czy jest wart przesunięcia startu.

• Doprecyzowanie — ekran był na liście, ustalamy szczegół działania. To nie jest zmiana zakresu i nie rusza terminu.
• Nowa funkcja albo nowy ekran — wchodzi opis, wycena i wpływ na termin; praca zaczyna się po akceptacji, a nie w trakcie rozmowy.
• Przebudowa czegoś, co już powstało — najdroższy wariant, bo ta sama praca jest wykonywana drugi raz, razem z testami. Dlatego makiety akceptuje się przed kodem.

Każda zmiana ma zapis: co się zmienia, na których ekranach, co z terminem, kto i kiedy to zaakceptował. Zmiana ustalona ustnie wraca po dwóch miesiącach jako spór, którego nikt nie umie rozstrzygnąć.

Po czym poznać, że zakres MVP jest gotowy do wyceny?

Po sześciu pytaniach. Jeśli na każde pada odpowiedź bez „to jeszcze ustalimy”, dokument jest gotowy — niezależnie od tego, kto go pisał.

• Da się policzyć ekrany i role bez dopytywania kogokolwiek?
• Każda funkcja opisana jest czasownikiem („klient rezerwuje termin”), a nie rzeczownikiem („zarządzanie rezerwacjami”)?
• Jest lista „czego nie ma”, zaakceptowana przez obie strony?
• Kryteria odbioru da się przeklikać krok po kroku i zapisać wynik?
• Jest napisane, co dostarcza zamawiający i do kiedy?
• Jest zdanie: co jest poza listą ekranów, jest poza zakresem?

To ostatnie zdanie robi więcej, niż wygląda. Zdejmuje z rozmowy o zmianach ton oskarżenia i zamienia ją w rachunek: tyle pracy, taki termin, decyduje zamawiający.