MVP aplikacji mobilnej - jak zaplanować pierwszą wersję bez przepalania budżetu

Na tablicy jest już kilkadziesiąt karteczek. Logowanie przez Google, czat, płatności, program poleceń, tryb ciemny i panel administratora mają sens rozpatrywane osobno, lecz razem tworzą projekt, którego przez wiele miesięcy nie zobaczy żaden użytkownik.

Tak najłatwiej przepalić budżet na aplikację, bo pierwsza wersja puchnie podczas rozmów, dopisywanie pomysłów nic nie kosztuje, a rachunek pojawia się później, kiedy każdy dodatkowy ekran trzeba zaprojektować, zaprogramować, połączyć z danymi i przetestować na dwóch systemach.

MVP porządkuje tę rozmowę, dostarczając działający fragment produktu i odpowiedź na konkretne pytanie biznesowe, na przykład czy właściciele apartamentów będą regularnie potwierdzać sprzątanie w telefonie zamiast na grupie w komunikatorze.

Zacznij od sytuacji z życia użytkownika

Zdanie "chcemy aplikację dla naszych klientów" nie wystarcza do rozpoczęcia projektu, bo brakuje w nim chwili, w której ktoś sięga po telefon, celu tej osoby i wyniku, jaki ma zobaczyć po minucie.

Pomaga krótki zapis: "Gdy wydarza się X, użytkownik chce zrobić Y, żeby osiągnąć Z". Dla gabinetu może to być pacjent, który po pracy chce przełożyć wizytę bez dzwonienia, a w firmie terenowej technik potwierdzający wykonanie zlecenia od razu po wyjściu od klienta.

Porozmawiaj z kilkoma osobami, które naprawdę wykonują tę czynność, pokaż im obecny proces i zapytaj, gdzie czekają, co przepisują ręcznie oraz czego szukają drugi raz. Jedna rozmowa potrafi skreślić funkcję, którą zespół uważał za oczywistą.

Ułóż najkrótszą pełną drogę użytkownika

MVP powinno mieć początek i koniec, więc użytkownik zakłada konto, wykonuje zadanie, dostaje potwierdzenie i może wrócić do wyniku. Ekran główny bez działającego zapisu do bazy jest makietą, a formularz bez informacji o błędzie zostawia człowieka w połowie drogi.

Zanim powstanie kod, narysuj ten przebieg na kartce lub w prostym prototypie, przejdź go z osobą spoza projektu i patrz, gdzie zatrzymuje palec podczas wykonywania zadania. Bez podpowiedzi. Takie piętnaście minut zwykle daje zespołowi lepszy materiał niż godzina dyskusji o kolorach.

Jeśli ten przebieg obejmuje role pracowników, panel operacyjny albo integracje z systemami firmy, aplikacja mobilna staje się częścią większego narzędzia i warto od razu zaplanować także system webowy dla zespołu, zamiast po premierze dopinać przypadkowy panel.

Oddziel konieczne od wygodnego

Słowo "konieczne" szybko traci znaczenie podczas planowania, dlatego każdej funkcji przyda się jeden z trzech koszyków oraz zapisany powód, który mówi znacznie więcej niż sama nazwa.

Przykład? Aplikacja do rezerwacji zajęć potrzebuje listy terminów, zapisu, anulowania i potwierdzenia. Oceny trenerów mogą poczekać. Czat także, jeśli kontakt po rezerwacji da się na początku obsłużyć telefonem lub wiadomością e-mail.

Nie warto jednak wycinać rzeczy niewidocznych na ekranie. Kopie danych, uprawnienia, obsługa błędów czy możliwość usunięcia konta nie wyglądają efektownie na prezentacji, ale chronią produkt przed trudnym startem. Mniejszy zakres biznesowy daje prawdziwą oszczędność. Dług ukryty w środku aplikacji wróci po premierze jako pilna naprawa.

Zaplanuj dane i zaplecze przed interfejsem

Telefon jest tylko jedną częścią rozwiązania, więc trzeba ustalić, skąd aplikacja pobiera dane, kto może je zmieniać i co dzieje się bez połączenia, a w projekcie z płatnościami lub danymi osobowymi dochodzą zasady dostępu, rejestrowanie operacji i usuwanie informacji na żądanie.

Prosta mapa danych wystarczy na początek. Wypisz obiekty, na przykład użytkownik, rezerwacja i płatność, a przy każdym zaznacz właściciela danych oraz osoby uprawnione do odczytu i edycji. Brzmi technicznie, lecz ta jedna kartka ujawnia wiele kosztownych luk jeszcze przed makietami.

Zespół powinien też ustalić ręczną ścieżkę awaryjną: co zrobi obsługa, gdy płatność przejdzie, a potwierdzenie nie dotrze, i kto poprawi błędny termin? Dobrze zaplanowane aplikacje mobilne uwzględniają pracę firmy po drugiej stronie ekranu.

Premiera zaczyna się przed wysłaniem aplikacji do sklepu

Sklep z aplikacjami nie jest miejscem na pierwszy test. Wytyczne Apple App Review mówią wprost o kompletnym i działającym wydaniu. Backend ma być dostępny podczas weryfikacji, a funkcje wymagające logowania potrzebują konta demonstracyjnego lub pełnego trybu demo. Aplikacja powinna też oferować użyteczność wykraczającą poza opakowanie zwykłej strony.

Google opisuje jakość z perspektywy głównej potrzeby użytkownika. Dokładanie funkcji nie może prowadzić do bałaganu i błędów. Osobne wskazówki obejmują doświadczenie użytkownika, jakość techniczną i prywatność, więc kryteria premiery powinny obejmować każdy z tych obszarów.

• Działające środowisko produkcyjne i konto demonstracyjne dla osoby sprawdzającej aplikację
• Pełna droga użytkownika przetestowana na prawdziwych urządzeniach, także przy słabym połączeniu
• Czytelne komunikaty błędów, pustych stanów i braku uprawnień
• Polityka prywatności, wymagane zgody oraz sposób usunięcia konta i danych
• Dane kontaktowe do pomocy i osoba odpowiedzialna za reakcję po premierze
• Analityka głównego zdarzenia oraz raportowanie awarii skonfigurowane przed publikacją

Na Androidzie wskaźniki vitals obejmują między innymi awarie i błędy ANR, czyli sytuacje, w których aplikacja przestaje odpowiadać. Firebase Crashlytics zbiera raporty o awariach, błędach niekrytycznych i ANR, dzięki czemu po premierze zespół zobaczy problem wraz z wersją aplikacji i urządzeniem. To znacznie lepszy trop niż wiadomość "u mnie nie działa".

Mierz decyzję, a nie ruch w aplikacji

Liczba pobrań wygląda dobrze na slajdzie, lecz niewiele mówi o wartości produktu, więc dla aplikacji rezerwacyjnej warto sprawdzać zakończenie pierwszej rezerwacji, a w narzędziu dla techników poprawnie zamknięte zlecenie. Wskaźnik powinien pasować do pytania, od którego zaczął się projekt.

Ustal przed premierą, jaki wynik skłoni zespół do rozwijania funkcji, zmiany przebiegu lub zatrzymania pomysłu, a zamiast rynkowego benchmarku zapisz obecny koszt procesu, zachowanie pierwszych użytkowników i wnioski z rozmów z ludźmi, którzy przerwali zadanie.

Po wypuszczeniu MVP przyjrzyj się czterem rzeczom: ukończeniu głównej czynności, miejscom rezygnacji, powrotom po pierwszym użyciu oraz stabilności. Później otwórz listę funkcji odłożonych. Dane mogą wskazać zupełnie inną kolejność niż ta, którą zespół przewidywał na początku.

Dokument, z którym można zacząć pracę

Dobry brief MVP mieści się na kilku stronach i zawiera sytuację użytkownika, pełną drogę głównego zadania, zamknięty zakres, mapę danych, kryteria premiery oraz plan pomiaru. Do tego dochodzą szkice ekranów i lista decyzji, które jeszcze nie zapadły.

Wyślij taki materiał osobie odpowiedzialnej za produkt i zespołowi technicznemu. Jeśli każdy potrafi wskazać funkcję odłożoną do następnego wydania oraz zdarzenie, które mierzy powodzenie MVP, można rozpocząć wycenę i planowanie pierwszego sprintu. Na następnym spotkaniu zespół będzie już pracował nad konkretnym produktem, a tablica z karteczkami zostanie wreszcie zamknięta.