Czym jest MVP, a czym nie jest
MVP to skrót od angielskiego minimum viable product — najmniejsza wersja produktu, która pozwala sprawdzić najważniejsze założenie na prawdziwych użytkownikach. W systemie dla firmy to zwykle jeden proces obsłużony od początku do końca: przyjęcie zamówienia, rezerwacja terminu albo zgłoszenie usterki.
MVP nie jest tanią wersją wszystkiego. To nie dziesięć modułów zrobionych byle jak, tylko jeden lub dwa zrobione porządnie, ale bez dodatków. Nie jest też makietą w programie graficznym — makieta pokazuje, jak coś będzie wyglądać, a MVP działa na prawdziwych danych i pozwala ludziom wykonać prawdziwą pracę.
Pomaga rozróżnienie trzech etapów:
- Prototyp — klikalny projekt ekranów. Sprawdza, czy ludzie rozumieją, jak korzystać z narzędzia.
- MVP — działająca pierwsza wersja dla ograniczonej grupy. Sprawdza, czy narzędzie rozwiązuje problem i czy ludzie chcą z niego korzystać.
- Wersja rozwojowa — kolejne funkcje dobierane na podstawie tego, co pokazało MVP.
Zanim powstanie pierwsza linijka kodu
Najtańszy błąd to ten, który wychwycisz przed programowaniem. Zanim zlecisz budowę, odpowiedz na kilka pytań — najlepiej na piśmie:
- Jaki problem rozwiązujemy i dla kogo? Jedno zdanie bez ogólników, na przykład: „biuro kilka razy dziennie dzwoni do kierowców, żeby sprawdzić, które dostawy są już zrobione”.
- Jak ludzie radzą sobie z tym dziś? Obecne obejście — arkusz, telefon, kartka — to Twój punkt odniesienia. Nowe narzędzie musi być od niego wyraźnie lepsze.
- Które założenie jest najbardziej ryzykowne? Czy ludzie w ogóle będą wpisywać dane? Czy klient zapłaci? Czy integracja z obecnym programem jest możliwa?
- Po czym poznamy, że działa? Potrzebny jest mierzalny sygnał: mniej telefonów, krótszy czas obsługi zamówienia, określona liczba osób korzystających co tydzień.
Warto porozmawiać z kilkoma osobami, które będą z narzędzia korzystać. Nie pytaj „czy chciałbyś aplikację?”, bo prawie każdy odpowie „tak”. Pytaj o ostatnią sytuację, w której problem wystąpił: co się stało, ile to trwało i jak sobie poradzili.
Czy da się to sprawdzić bez programowania?
Czasem tak. Formularz, wspólny arkusz i ręczna obsługa po Twojej stronie potrafią przez kilka tygodni udawać system. Jeśli nikt nie chce korzystać nawet z prostej wersji, budowa pełnego narzędzia niczego nie zmieni. Jeśli ludzie korzystają, a ręczna obsługa zaczyna Cię przytłaczać, to dobry sygnał, że pora na kod.
Jak wybrać zakres pierwszej wersji
Najtrudniejsza część MVP to nie budowa, tylko decyzja, czego nie budować. Pomaga prosta metoda: wypisz wszystkie pomysły na funkcje i przypisz każdy z nich do jednej z trzech grup.
- Musi być — bez tego nie da się przejść procesu od początku do końca.
- Później — przydatne, ale pierwsza grupa użytkowników poradzi sobie bez tego, nawet jeśli trochę mniej wygodnie.
- Może nigdy — pomysły, które brzmią dobrze, ale nie wiadomo, czy ktoś ich potrzebuje.
Poniżej przykład dla wyobrażonego systemu zamówień dla klientów hurtowych. To ilustracja metody, a nie opis konkretnego projektu.
| Funkcja | Grupa | Dlaczego |
|---|---|---|
| Logowanie klienta i lista produktów z jego cenami | Musi być | Bez tego klient nie złoży zamówienia |
| Złożenie zamówienia i potwierdzenie mailem | Musi być | To sedno procesu |
| Lista zamówień dla biura z możliwością zmiany statusu | Musi być | Biuro musi zamówienia obsłużyć |
| Ponowienie poprzedniego zamówienia jednym kliknięciem | Później | Wygodne, ale klient może dodać produkty ręcznie |
| Automatyczne połączenie z programem do faktur | Później | Na start biuro może wystawiać faktury tak jak dotąd |
| Aplikacja mobilna w sklepach | Może nigdy | Wersja w przeglądarce działa też na telefonie |
| Rozbudowane raporty i wykresy | Może nigdy | Najpierw trzeba zebrać dane, które warto analizować |
Dobra pierwsza wersja zwykle obsługuje jedną grupę użytkowników i jeden proces. Zamiast budować system dla wszystkich działów naraz, wybierz miejsce, w którym problem jest najbardziej dotkliwy i występuje najczęściej. Co składa się na koszt takiej wersji i jak porównywać oferty, opisuję w artykule ile kosztuje aplikacja dla firmy.
Na czym nie oszczędzać nawet w MVP
Słowo „minimalny” dotyczy liczby funkcji, a nie jakości podstaw. Kilka rzeczy musi działać porządnie od pierwszego dnia:
- Bezpieczeństwo i dane — logowanie, uprawnienia, szyfrowane połączenie, kopie zapasowe. Wyciek danych w trakcie pilotażu potrafi zakończyć projekt.
- RODO — jeśli system przetwarza dane osobowe, od początku wiesz, jakie, po co i kto ma do nich dostęp.
- Podstawowa wygoda — narzędzie nie musi być piękne, ale nie może być męczące. Jeśli ludzie rezygnują po dwóch dniach, nie dowiesz się, czy sam pomysł był dobry.
- Pomiar — dane, które pozwolą odpowiedzieć na pytanie „czy to działa”. Ustal je przed startem, a nie po nim.
- Fundamenty techniczne — porządna baza danych i interfejs API, na których można budować dalej. MVP, które trzeba wyrzucić i napisać od nowa, oznacza podwójny koszt.
Ostatni punkt wymaga wyważenia. Nie chodzi o infrastrukturę na milion użytkowników, tylko o to, żeby kolejne funkcje dało się dołożyć bez przepisywania wszystkiego. W podejściu modułowym, z którego korzystam razem ze StackERP, pierwsza wersja to po prostu pierwszy moduł, a kolejne korzystają z tych samych danych.
Jak sprawdzić, czy pierwsza wersja działa
MVP ma przynieść odpowiedź, a nie tylko działający kod. Dlatego jeszcze przed startem ustal z zespołem lub wspólnikiem:
- kto testuje — konkretna, niewielka grupa, z którą masz bezpośredni kontakt,
- jak długo — tyle, żeby narzędzie weszło w codzienną rutynę, a nie zostało tylko raz obejrzane,
- co mierzysz — dwa lub trzy wskaźniki związane z problemem, np. czas obsługi, liczbę telefonów, udział zamówień złożonych przez system,
- jak zbierasz opinie — krótkie rozmowy po tygodniu i po kilku tygodniach, a nie tylko ankieta.
Na końcu potrzebna jest decyzja. Każdy etap kończę wyborem jednej z trzech dróg: rozwijamy pomysł, zmieniamy kierunek albo go odkładamy. Każda z nich jest dobrym wynikiem, jeśli zapada na podstawie danych, a nie przywiązania do projektu, w który włożono już pieniądze.
Siedem sposobów na przepalenie budżetu
- Budowa wszystkiego naraz. Lista funkcji z warsztatu z całym zespołem to nie jest zakres MVP.
- Narzędzie dla wszystkich. Próba zadowolenia każdej grupy użytkowników kończy się narzędziem, które nikomu nie pasuje.
- Dopieszczanie wyglądu przed sprawdzeniem sensu. Czytelność i wygoda — tak. Kolejne poprawki animacji — później.
- Brak kontaktu z użytkownikami w trakcie budowy. Kilka tygodni bez pokazania postępów to kilka tygodni ryzyka.
- Zmiany zakresu bez decyzji o budżecie. Każdy pomysł „na szybko” to czas. Dopisuj go do listy „później”, a nie do bieżącego etapu.
- Brak jasności co do własności. Kod, konta, domeny i dane powinny mieć właściciela zapisanego w umowie. Przeniesienie autorskich praw majątkowych do kodu wymaga umowy w formie przewidzianej przepisami i wskazania pól eksploatacji — sama zapłata faktury nie wystarczy.
- Uparte trzymanie się planu. Jeśli dane mówią co innego niż założenia, zmiana kierunku jest tańsza niż budowa kolejnych funkcji, z których nikt nie skorzysta.
Masz pomysł na system dla swojej branży?
Najlepsze pomysły na systemy często mają ludzie, którzy od lat pracują w danej branży i codziennie widzą, co można zrobić prościej. Nie muszą umieć programować — wnoszą wiedzę o problemie i kontakt z osobami, które mierzą się z tą samą trudnością.
Dla takich osób przygotowałem osobny model współpracy. Ty wnosisz wiedzę i udział w sprawdzaniu potrzeby, a ja projekt produktu, technologię, wdrożenie, zabezpieczenia i plan utrzymania. Zaczynamy od rozmów z odbiorcami i najmniejszej użytecznej wersji, a punktem wyjścia do rozmowy o podziale może być równy podział kosztów i zysków. Ostateczne proporcje, prawa do produktu i zasady wyjścia zapisujemy w osobnej umowie. Szczegóły opisuję na stronie o wspólnym budowaniu systemów.
Jeśli potrzebujesz pierwszej wersji systemu dla własnej firmy, a nie produktu dla całej branży, zaczynamy tak samo: od rozmowy o procesie. Zakres i wycenę ustalam z partnerem technicznym, StackERP, a całość dzielimy na etapy.