Aplikacje i produkty cyfrowe
MVP aplikacji: jak wyznaczyć zakres pierwszej wersji
Część poradnika: Jak stworzyć aplikację mobilną: proces krok po kroku dla zamawiającego
MVP aplikacji to najmniejsza działająca wersja produktu, która pozwala jednemu użytkownikowi przejść całą główną ścieżkę od początku do końca i uzyskać efekt, po który przyszedł. To nie jest „aplikacja z mniejszą liczbą przycisków”, tylko jedna ścieżka domknięta zamiast pięciu urwanych w połowie. Poniżej pokazuję operacyjnie, jak tnie się zakres pierwszej wersji — na jednym przykładzie prowadzonym do końca. Przykład jest fikcyjny, ale złożony z sytuacji, które w takich projektach wracają najczęściej.
MVP, prototyp klikalny czy concierge MVP — co wystarczy na start
Te trzy warianty odpowiadają na trzy różne pytania i kosztują różne pieniądze. Wybierz ten, który odpowiada na pytanie, którego naprawdę nie znasz.
- Prototyp klikalny to połączone ekrany bez kodu i bez bazy danych. Buduje się go w Figmie, Sketchu albo Adobe XD; Figma pozwala spiąć ekrany w interaktywne przepływy jeszcze przed napisaniem pierwszej linijki kodu. Odpowiada na pytanie „czy użytkownik wie, gdzie kliknąć”.
- Concierge MVP to proces obsługiwany ręcznie zamiast kodem: formularz, arkusz i człowiek, który wykonuje pracę, którą docelowo ma wykonywać system. Odpowiada na pytanie „czy ktoś będzie z tego korzystał regularnie”.
- MVP to działający produkt z wąskim, ale pełnym zakresem. Odpowiada na pytanie „czy to utrzyma się w codziennej pracy”.
Czasem najtańszą odpowiedzią jest brak aplikacji. Jeśli proces obsługuje kilkanaście zdarzeń tygodniowo, concierge MVP przez dwa miesiące da Ci twardsze dane niż jakikolwiek kod — a przy okazji pokaże, ile ten proces realnie zajmuje czasu. Gdy MVP ma już powstać jako produkt, drugą decyzją jest to, czy pierwsze wydanie to aplikacja webowa czy mobilna, bo od niej zależy połowa zakresu.
Przykład: kilkanaście funkcji, które przychodzą do głowy na starcie
Przykładowa firma zarządza czterdziestoma wspólnotami mieszkaniowymi i chce aplikacji do zgłaszania usterek. Na pierwszym spotkaniu lista życzeń wygląda tak: zgłoszenie usterki ze zdjęciem, wybór budynku i lokalu, status zgłoszenia, czat z zarządcą, powiadomienia push, powiadomienia e-mail, panel administracyjny, przydzielanie zgłoszeń do ekip serwisowych, kalendarz wizyt technika, oceny po naprawie, eksport zgłoszeń do CSV, raporty miesięczne, logowanie SMS-em, onboarding z samouczkiem, tablica ogłoszeń wspólnoty i integracja z systemem księgowym.
Szesnaście pozycji. Większość z nich kiedyś powstanie — problem w tym, że to lista życzeń, a nie ścieżka.
Druga wersja jest zakresem, bo widać, gdzie się kończy. Pierwsza jest spisem, który każda osoba w zespole przeczyta inaczej.
Trzy pytania, które wyrzucają funkcję do drugiej wersji
Funkcja wypada z MVP, jeśli odpowiesz „tak” na choćby jedno z trzech pytań. Zadaj je po kolei każdej pozycji z listy.
- Czy da się to obsłużyć ręcznie przez pierwsze tygodnie? Przy czterdziestu wspólnotach przydzielanie zgłoszeń do ekip robi jedna osoba w panelu. Ręczna obsługa kosztuje kilkanaście minut dziennie, a zaoszczędzony kod kosztuje tygodnie pracy.
- Czy dotyczy marginesu przypadków? Awaria wymagająca kalendarza wizyt technika zdarza się rzadziej niż zwykłe zgłoszenie hydrauliczne. Marginesu nie automatyzuje się przed rdzeniem.
- Czy główna ścieżka domknie się bez tego? Mieszkaniec zgłosi usterkę i zobaczy status także wtedy, gdy nie ma czatu. Czat nie blokuje ścieżki, więc czeka.
Jeśli na wszystkie trzy pytania pada „nie”, funkcja zostaje w pierwszej wersji. To jedyne kryterium, jakie potrzebujesz.
MoSCoW w praktyce: funkcja, kategoria, decyzja, uzasadnienie
MoSCoW dzieli zakres na cztery kategorie — Must have, Should have, Could have i Won’t have — a do MVP trafia wyłącznie Must have. Kluczowa jest ostatnia kolumna: kategoria bez uzasadnienia jest tylko opinią i wraca na kolejnym spotkaniu.
| Funkcja | MoSCoW | Decyzja | Uzasadnienie |
|---|---|---|---|
| Zgłoszenie usterki ze zdjęciem | Must have | MVP | To cała wartość dla mieszkańca — bez tego aplikacja nie ma powodu istnieć. |
| Wybór budynku i lokalu | Must have | MVP | Bez adresu zgłoszenie jest dla serwisu bezużyteczne. |
| Status zgłoszenia w trzech stanach | Must have | MVP | Brak statusu generuje telefony do biura, czyli to, co aplikacja miała usunąć. |
| Logowanie | Must have | MVP | Zgłoszenia zawierają dane osobowe i adresy, nie mogą być publiczne. |
| Powiadomienie e-mail o zmianie statusu | Must have | MVP | Domyka pętlę informacyjną najtańszym możliwym kanałem. |
| Panel zarządcy: lista i zmiana statusu | Must have | MVP | Ktoś musi zgłoszenie przyjąć, inaczej proces urywa się po stronie mieszkańca. |
| Powiadomienia push | Should have | v2 | E-mail już domyka pętlę; push wymaga wydania mobilnego i zgód użytkownika. |
| Przydzielanie zgłoszeń do ekip | Should have | v2 | Przy tej skali rozdziela je jedna osoba ręcznie w panelu. |
| Eksport zgłoszeń do CSV | Should have | v2 | Do pierwszego audytu wystarczy zestawienie przygotowane raz w miesiącu. |
| Czat z zarządcą | Could have | v2 | Dubluje komentarze w zgłoszeniu i tworzy oczekiwanie odpowiedzi w minutach. |
| Kalendarz wizyt technika | Could have | v3 | Osobny proces z własnymi regułami, rozsadza pierwszą wersję. |
| Onboarding z samouczkiem | Could have | v2 | Jeśli trzy ekrany wymagają samouczka, problemem jest interfejs, nie brak instrukcji. |
| Logowanie SMS-em | Could have | v2 | Dokłada koszt bramki i zależność zewnętrzną; e-mail wystarczy na start. |
| Raporty i wykresy miesięczne | Won’t have | poza zakresem | Nie ma jeszcze danych, z których miałyby powstać. |
| Oceny po naprawie | Won’t have | poza zakresem | Mierzą jakość ekipy serwisowej, a nie działanie aplikacji. |
| Tablica ogłoszeń wspólnoty | Won’t have | poza zakresem | Druga aplikacja w jednej: inna ścieżka, inny cel, inny użytkownik. |
| Integracja z systemem księgowym | Won’t have | poza zakresem | Zgłoszenia usterek nie zasilają księgowości. |
Z szesnastu pozycji w pierwszej wersji zostało sześć. Wybór technologii, testy i wdrożenie to kolejne etapy, które opisuję w przewodniku o tym, jak stworzyć aplikację mobilną, a wpływ zakresu na budżet rozkładam na części w tekście o tym, ile kosztuje aplikacja mobilna.
Panel, onboarding, powiadomienia i eksport — jak rozstrzygnąć cztery najczęstsze spory
To są funkcje, o które klienci walczą najmocniej, więc każdą rozstrzyga się osobną zasadą, a nie ogólnym „minimum”.
Panel administracyjny wchodzi do MVP w minimalnej wersji zawsze wtedy, gdy ktoś po drugiej stronie musi zareagować. Minimum to lista, podgląd i zmiana statusu. Zarządzanie kontami, rolami i konfiguracją zostawiasz zespołowi technicznemu do obsługi ręcznej.
Onboarding odkładasz prawie zawsze. Samouczek jest protezą interfejsu, którego użytkownik nie rozumie; w pierwszej wersji lepiej naprawić ekran niż dopisać do niego instrukcję.
Powiadomienia zostawiasz w jednym kanale, najtańszym w utrzymaniu — zwykle e-mail. Push wymaga wydania mobilnego, obsługi zgód i osobnej infrastruktury, więc jest naturalnym kandydatem do drugiego wydania; to, ile trwa stworzenie aplikacji mobilnej, zależy głównie od tego, ile zmieścisz w pierwszym zakresie. Zanim zaplanujesz push na obie platformy, sprawdź, co PWA na iOS i Androidzie obsługuje bez publikacji w sklepie, a czego tam nie zrobisz.
Eksport danych przekłada się na drugą wersję, dopóki potrafisz przygotować zestawienie na żądanie. Warunek jest jeden: dane muszą być kompletne od pierwszego dnia. Braku danych nie da się nadrobić wstecz, brakującego przycisku „pobierz” — owszem.
Czego z MVP aplikacji wycinać nie wolno
Pięć rzeczy zostaje w zakresie niezależnie od tego, jak agresywnie tniesz resztę, bo ich brak nie jest oszczędnością, tylko długiem. To uwierzytelnianie, kopie zapasowe i możliwość odtworzenia danych, zgodność z RODO, podstawowa dostępność i obsługa błędów.
Uwierzytelnianie i kopie zapasowe są warunkiem tego, żeby wersja w ogóle nadawała się do pokazania użytkownikom. Zgodność z RODO oznacza tu podstawę przetwarzania, informację dla użytkownika i możliwość usunięcia konta — dokładany później dotyka modelu danych, czyli najdroższej części systemu. Ten tekst ma charakter informacyjny i nie jest poradą prawną. Podstawowa dostępność to kontrast, obsługa klawiaturą i sensowne etykiety pól; obsługa błędów to komunikat, kiedy zdjęcie się nie wyśle, zamiast pustego ekranu.
Jedyne, co wolno tu zawęzić, to zakres, a nie jakość: jedna metoda logowania zamiast trzech, jeden format eksportu kopii zamiast pełnej konsoli.
Jak zapisać zakres, żeby dało się go odhaczyć
Zakres jest gotowy wtedy, gdy każda pozycja ma kryteria akceptacji zapisane jako pytania z odpowiedzią TAK albo NIE. Pytanie, na które da się odpowiedzieć „częściowo”, nie jest kryterium akceptacji.
Zacznij od historyjki użytkownika w szablonie „Jako [rola] chcę [funkcja], aby [korzyść]“, a potem dopisz do niej pytania. Dobra historyjka jest testowalna — jeśli nie umiesz sformułować pytania rozstrzygającego, opis jest za ogólny.
„Jako mieszkaniec chcę zgłosić usterkę ze zdjęciem, aby nie dzwonić do biura w godzinach pracy. Gotowe, gdy: czy zgłoszenie zapisuje się z lokalem i zdjęciem? czy mieszkaniec widzi status po zalogowaniu? czy zarządca dostaje wiadomość o nowym zgłoszeniu?"
Historyjki ułóż w kolejności, w jakiej użytkownik ich dotyka — to user story mapping — i przetnij mapę poziomą linią. Wszystko powyżej linii jest pierwszym wydaniem, wszystko poniżej czeka. Praca w sprintach dwutygodniowych domyka ten zakres przyrostowo, a mapa pokazuje po każdym sprincie, czy linia się nie przesunęła.
Ten sam zestaw historyjek jest gotowym materiałem na brief dla software house — wystarczy dopisać kontekst biznesowy. Jeśli chcesz uporządkować zakres, zanim zaczniesz rozmowy, przejdź przez sześć kroków w kreatorze briefu i wróć z gotową listą do pocięcia.
Checklista
Wypisz wszystkie funkcje, jakie przychodzą do głowy, zanim zaczniesz cokolwiek oceniać.
Zaznacz jedną główną ścieżkę użytkownika i sprawdź, czy da się ją przejść od początku do końca.
Przypisz każdej funkcji kategorię MoSCoW i dopisz jedno zdanie uzasadnienia decyzji.
Odłóż do drugiej wersji wszystko, co na starcie obsłuży ręcznie jedna osoba.
Zostaw w zakresie logowanie, kopie zapasowe, zgodność z RODO, podstawową dostępność i obsługę błędów.
Zapisz kryteria akceptacji jako pytania z odpowiedzią TAK albo NIE.
Ustal, po jakich danych z pierwszych tygodni zdecydujesz o zakresie kolejnego wydania.
Najczęstsze pytania
- Co to jest MVP i czym różni się od prototypu?
- MVP to działający produkt, z którego użytkownik korzysta naprawdę: dane się zapisują, proces domyka się od początku do końca. Prototyp klikalny to połączone ekrany bez kodu i bez bazy danych, budowane najczęściej w Figmie, i służy do sprawdzenia, czy interfejs jest zrozumiały. Prototyp odpowiada na pytanie o użyteczność, MVP na pytanie, czy produkt utrzyma się w codziennej pracy.
- Ile funkcji powinno mieć MVP aplikacji?
- Liczba funkcji jest złym miernikiem — liczy się liczba ścieżek. Dobre MVP obsługuje jedną główną ścieżkę użytkownika doprowadzoną do końca, a nie kilka rozpoczętych i urwanych w połowie. W praktyce wychodzi z tego od kilku do kilkunastu ekranów, ale punktem odniesienia zawsze jest ścieżka, nie lista funkcji.
- Czy panel administracyjny musi być w pierwszej wersji?
- Panel jest potrzebny wtedy, gdy ktoś po drugiej stronie musi zareagować na to, co robi użytkownik — na przykład przyjąć i zamknąć zgłoszenie. Wtedy do MVP wchodzi jego minimum: lista, podgląd i zmiana statusu. Zarządzanie użytkownikami, uprawnieniami i konfiguracją da się na starcie robić ręcznie po stronie zespołu technicznego i można to odłożyć.
- Czy MVP można pokazać klientom, czy to wersja tylko do testów?
- MVP jest przeznaczone dla prawdziwych użytkowników — bez nich nie dostaniesz danych, po które je budujesz. Warunek jest taki, że wersja ma działać poprawnie w wąskim zakresie: logowanie, zapis danych, kopie zapasowe i obsługa błędów muszą być gotowe. Wersja niedokończona technicznie nie jest MVP, tylko niedziałającym produktem.
- Co jeśli konkurencja ma więcej funkcji niż moje MVP?
- Konkurent zwykle dołożył te funkcje przez lata, reagując na zgłoszenia użytkowników, których Ty jeszcze nie masz. Kopiowanie całej listy na starcie oznacza budowanie funkcji bez wiedzy, które z nich są używane. Skuteczniej jest wybrać jedną ścieżkę i zrobić ją wyraźnie lepiej, a kolejne wydania planować na podstawie danych z własnej aplikacji.
Źródła i metodologia
Linki prowadzą do źródeł pierwotnych oraz zasad, według których przygotowujemy i aktualizujemy materiały.