Jak zaplanować pierwszą wersję (MVP) aplikacji dla firmy

Czym jest MVP w aplikacji dla firmy

MVP (minimum viable product) to najmniejsza wersja aplikacji, którą da się faktycznie używać w pracy i na której da się sprawdzić, czy kierunek jest dobry. W aplikacji dla firmy oznacza to zwykle wąski fragment procesu, obsłużony od początku do końca, a nie szerokie, ale płytkie wszystko.

Różnica jest praktyczna. Aplikacja, która ma ekran zamówień, ekran klientów, raporty i ustawienia, ale w żadnym z nich nie da się wykonać całej czynności, jest makietą. Aplikacja, która pozwala jednej grupie osób przyjąć zamówienie i przekazać je do realizacji, jest MVP, nawet jeśli nie ma raportów.

MVP nie jest też wersją „na szybko” w rozumieniu niedbałej. Dane, które wprowadzają użytkownicy, bezpieczeństwo i kopie zapasowe muszą być w porządku od pierwszego dnia. Ograniczać zakres można, jakość nie.

Co przygotować

• Opis procesu, który ma przejąć aplikacja: kto, co i kiedy robi dzisiaj.
• Listę osób, które będą aplikacji używać, wraz z ich zadaniami.
• Przykładowe dane (arkusze, zrzuty, dokumenty), na których pracuje się dziś.
• Wskazanie osoby po stronie firmy, która podejmuje decyzje o zakresie.
• Listę systemów, z którymi aplikacja będzie się łączyć (ERP, poczta, sklep, marketplace).
• Ustalone kryteria, po których poznasz, że pierwsza wersja się sprawdza.

Krok 1: jeden proces, jeden zespół użytkowników

Wybierz proces, który spełnia trzy warunki: jest powtarzalny, dziś kosztuje czas lub powoduje błędy i ma właściciela w firmie, czyli osobę, której zależy na zmianie. Wybierz też jedną grupę użytkowników, najlepiej kilka osób, które są gotowe testować i dawać uwagi.

Opisz proces jednym zdaniem w formie: „Aplikacja pozwala [kto] zrobić [co], żeby [po co]”. Na przykład: „Aplikacja pozwala handlowcowi zapisać zapytanie klienta i przekazać je do wyceny, żeby zapytania nie ginęły w poczcie”. Przykład jest hipotetyczny. Jeśli nie umiesz zmieścić celu w jednym zdaniu, zakres jest za szeroki.

Zapisz też, czego pierwsza wersja nie obejmuje. Lista „poza zakresem pierwszego etapu” jest równie ważna jak lista funkcji, bo chroni przed dopisywaniem „jeszcze tylko tego”.

Krok 2: lista funkcji i podział na teraz i później

Wypisz wszystkie funkcje, które przychodzą do głowy, także te zbędne. Potem dla każdej odpowiedz na dwa pytania:

1. Czy bez tej funkcji da się przeprowadzić wybrany proces od początku do końca?
2. Czy da się ją na początku zastąpić prostszym rozwiązaniem, na przykład ręczną czynnością lub eksportem do arkusza?

Jeśli na pierwsze pytanie odpowiedź brzmi „nie”, funkcja jest „teraz”. Jeśli „tak”, jest „później”, chyba że pozostałe okoliczności wymuszają inaczej. Zaawansowane raporty, powiadomienia, wiele ról użytkowników, wersje językowe, eksporty i panele administracyjne zwykle trafiają do kolumny „później”.

Użyteczny jest podział na trzy kolumny: konieczne, przydatne i na razie nie. Gdy w kolumnie „konieczne” jest więcej niż kilkanaście pozycji, wróć do kroku 1 i zawęź proces.

Krok 3: dane i integracje niezbędne od początku

Dane i integracje są najczęstszym powodem rozrostu zakresu. Ustal:

• Skąd pochodzą dane startowe? Jeśli aplikacja ma pracować na istniejących kontrahentach czy produktach, trzeba je zaimportować. Dane z arkuszy zwykle wymagają porządkowania: duplikaty, brakujące pola, różne formaty.
• Z którymi systemami aplikacja musi się połączyć już w pierwszej wersji? Zadaj pytanie: czy wersja bez integracji nadal ma sens? Często odpowiedź brzmi „tak”: integrację da się zastąpić ręcznym wprowadzaniem lub importem pliku na czas testów. Jeśli „nie”, integracja należy do pierwszego etapu.
• Jakie dane osobowe aplikacja przetwarza i po co? UODO przypomina, że zasady przetwarzania z art. 5 RODO obejmują minimalizację i ograniczenie przechowywania, czyli zbieranie danych tylko w zakresie potrzebnym do celu i przechowywanie tylko tak długo, jak to niezbędne. Pierwsza wersja to dobry moment na ich zastosowanie: nie zbieraj „na zapas”.
• Kto będzie administratorem, a kto podmiotem przetwarzającym? Jeśli aplikację tworzy i utrzymuje zewnętrzny wykonawca, który ma dostęp do danych osobowych, potrzebna jest umowa powierzenia przetwarzania, w formie pisemnej. UODO zwraca uwagę, że administrator powinien wcześniej sprawdzić, czy wykonawca zapewnia wystarczające gwarancje.

Dane, które trzeba zapewnić na pierwszy dzień, zapisz w osobnej liście. Opóźnienia w MVP bardzo często wynikają z danych, a nie z programowania.

Krok 4: wersja do sprawdzenia w firmie

Pierwsza wersja ma trafić do użytkowników szybko, zanim będzie „skończona”. Zaplanuj:

• Krótki okres testowy z małą grupą osób, które używają aplikacji do prawdziwej pracy, a nie tylko do oglądania.
• Sposób zbierania uwag: jedno miejsce, w którym użytkownicy zgłaszają problemy i pomysły (formularz, arkusz, wspólny wątek), a nie kilka kanałów jednocześnie.
• Dane testowe i prawdziwe: najpierw dane przykładowe, potem prawdziwe, ale w ograniczonym zakresie.
• Osoba, która odpowiada na zgłoszenia po stronie firmy i po stronie wykonawcy.
• Kryteria sukcesu, ustalone przed testem. Na przykład: „zapytania nie giną”, „zamówienie można przyjąć bez przepisywania”, „użytkownik nie musi pytać, jak coś zrobić”. Nie przyjmuj z góry liczb, jeśli nie masz ich z pomiaru dotychczasowego procesu.

Taki sposób pracy odpowiada etapowej budowie z wersją do sprawdzenia, opisanej w sekcji Współpraca na stronie M8T: mail, rozmowa i wycena, budowa etapami z wersją do sprawdzenia, wdrożenie i poprawki.

Krok 5: decyzja o kolejnym etapie

Po okresie testowym podejmij decyzję na podstawie tego, co zebrałeś, a nie wrażeń. Przejrzyj:

• czy kryteria sukcesu zostały spełnione,
• jakie uwagi pojawiały się najczęściej,
• które z funkcji „później” okazały się potrzebne, a które nie,
• czego użytkownicy próbowali używać w sposób, którego nie przewidziano (to wskazówka, co jest ważne),
• co sprawiało im trudność.

Z tego powstaje lista priorytetów na drugi etap. Możliwe decyzje: rozszerzyć aplikację na kolejną grupę, dodać brakujące funkcje, zmienić kierunek albo zakończyć projekt. Zakończenie po pierwszym etapie jest uczciwym wynikiem, jeśli wersja pokazała, że problem inaczej się rozwiązuje, i kosztowało znacznie mniej, niż gdyby zbudowano całość.

Do kolejnego etapu rozważ osobną wycenę. Pierwszy etap pokazał, jak wygląda praca z danymi i użytkownikami, więc oszacowanie następnego będzie dokładniejsze.

Typowe pułapki

• Zakres rośnie w trakcie. Każde „a może jeszcze...” dopisuje pracę. Ratunek: lista „poza zakresem pierwszego etapu” i jedna osoba decydująca o zmianach.
• Za dużo użytkowników na początku. Im więcej osób, tym więcej sprzecznych próśb. Zacznij od kilku.
• Brak właściciela po stronie firmy. Aplikacja bez osoby, której zależy na wdrożeniu, trafia do szuflady.
• Dane nie są gotowe. Import okazuje się dłuższy niż budowa. Zacznij porządkowanie danych równolegle z projektem.
• Zbyt późna wersja do sprawdzenia. Pierwsze użycie po kilku miesiącach przynosi niespodzianki, na które nie ma już budżetu.
• MVP bez jakości. Wersja pierwsza może być wąska, ale nie powinna gubić danych ani być podatna na oczywiste błędy bezpieczeństwa.
• Kryteria sukcesu ustalane po fakcie. Wtedy każdy wynik da się uznać za dobry.

Szablon do wypełnienia

• Proces: ...
• Użytkownicy w pierwszym etapie: ...
• Zdanie celu: Aplikacja pozwala ... zrobić ..., żeby ...
• Funkcje konieczne: ...
• Funkcje przydatne, odłożone: ...
• Poza zakresem pierwszego etapu: ...
• Dane startowe i ich źródło: ...
• Integracje w pierwszym etapie: ...
• Dane osobowe: jakie, po co, jak długo: ...
• Osoba decydująca po stronie firmy: ...
• Okres testowy i grupa testowa: ...
• Kryteria sukcesu: ...
• Data przeglądu i decyzji o drugim etapie: ...

Podsumowanie

Plan pierwszej wersji sprowadza się do pytania: jaki najmniejszy fragment procesu da się obsłużyć w aplikacji w całości i jak sprawdzić, że to ma sens. Wąski zakres, uporządkowane dane, krótka pętla uwag od użytkowników i decyzja po teście zmniejszają ryzyko budowania aplikacji, której nikt nie potrzebuje.

Jeśli masz proces, który chcesz przenieść do aplikacji, możesz opisać go M8T. Zakres usług M8T obejmuje aplikacje webowe, platformy B2B, systemy CRM i WMS oraz integracje.