Wersja minimum to najmniejsza działająca postać Twojej aplikacji, która pozwala klientowi rozwiązać konkretny problem i Tobie sprawdzić sens dalszej pracy.
Jeden problem na początek
Wyobraź sobie otwarcie małej kawiarni: możesz zacząć od dobrej kawy i kilku stolików, bez własnej palarni, sklepu internetowego i sali konferencyjnej. Podobnie działa pierwsza wersja aplikacji. Ma zapewnić pełną usługę w wąskim zakresie, a nie pokazywać wszystkie pomysły, które mogą kiedyś do niej trafić.
W rozmowach o produktach spotkasz skrót MVP, od angielskiego minimum viable product, czyli najmniejszy produkt nadający się do rzeczywistego użycia i nauki na podstawie zachowania odbiorców. Słowo „najmniejszy” nie oznacza tutaj przypadkowego zestawu ekranów. Osoba korzystająca z aplikacji ma samodzielnie dojść do obiecanego rezultatu albo otrzymać jasno opisaną pomoc.
Dla kalkulatora gastronomicznego takim rezultatem może być obliczenie kosztu jednej porcji na podstawie cen składników. Nie musisz od razu prowadzić magazynu restauracji, zamawiać dostaw ani planować zmian pracowników. Te funkcje dotyczą tego samego świata, lecz rozwiązują inne problemy i wymagają osobnych decyzji.
Zapisz swoje założenie jednym zdaniem: „Pomagam właścicielowi małego lokalu policzyć koszt porcji przed zmianą menu”. Jeśli zdanie zawiera kilka różnych odbiorców i długi ciąg słów „oraz”, zakres prawdopodobnie nadal jest zbyt szeroki. Wybierz sytuację, w której wynik jest potrzebny, i osobę, która za ten wynik odpowiada.
Dopisz też, czego na tym etapie nie obsługujesz. Kalkulator może przyjmować ceny wpisywane ręcznie i nie łączyć się z programem magazynowym. Taka granica chroni Cię przed dokładaniem funkcji pod wpływem każdej nowej rozmowy, a klientowi pozwala ocenić, czy proponowane rozwiązanie pasuje do jego pracy.
Cała droga do wyniku
Rozpisz pierwsze użycie aplikacji tak, jak instrukcję dla osoby, która widzi ją pierwszy raz. Zacznij od tego, co użytkownik ma przygotować, a skończ na tym, z czym wychodzi. Pomiń nazwy przycisków i kolory, ponieważ teraz interesuje Cię przebieg zadania.
Dla kalkulatora kosztu porcji może to wyglądać następująco:
- Właściciel lokalu wpisuje nazwę dania i liczbę przygotowywanych porcji.
- Dodaje składniki, wielkości opakowań oraz ceny zakupu.
- Podaje ilość każdego składnika wykorzystaną w przepisie.
- Otrzymuje koszt całego przepisu i jednej porcji.
- Zmienia cenę składnika i sprawdza nowy wynik.
To jest zamknięta droga do korzyści. Jeśli aplikacja pozwala dodać składniki, ale wynik trzeba samodzielnie liczyć na kartce, brakuje najważniejszej części. Jeśli działa wyłącznie na wcześniej przygotowanym przykładzie, masz pokaz możliwości, a nie wersję do codziennej pracy.
Przy każdym kroku zapisz warunek poprawnego działania. Cena nie może być ujemna, liczba porcji nie może wynosić zero, a ilości muszą korzystać ze zgodnych jednostek. Nie potrzebujesz technicznego języka, żeby opisać te zasady osobie pomagającej w budowie albo narzędziu opartemu na sztucznej inteligencji.
Uwzględnij również zakończenie zadania bez sukcesu. Użytkownik powinien rozumieć, dlaczego nie dostał wyniku i co ma poprawić. Spokojny komunikat „Podaj liczbę porcji większą od zera” jest częścią użytecznego minimum, podobnie jak zachowanie wcześniej wpisanych składników po takim błędzie.
Dopiero teraz policz potrzebne widoki. Często formularz i wynik mogą zmieścić się na jednym ekranie. Osobne strony nie tworzą wartości same w sobie, a każda z nich zwiększa liczbę miejsc wymagających sprawdzenia.
Funkcje pod lupą
Lista pomysłów zwykle rośnie szybciej niż gotowy produkt. Zamiast usuwać z niej wszystko poza pierwszym zadaniem, podziel ją według znaczenia dla wybranego rezultatu. Odrzucony na dziś pomysł może wrócić później, ale nie powinien automatycznie trafiać do bieżącej wersji.
| Element kalkulatora | Decyzja na początek | Uzasadnienie |
|---|---|---|
| Wpisanie cen i ilości | Zostaje | Bez danych nie powstanie wynik |
| Przeliczanie gramów i kilogramów | Zostaje | Jednostki wpływają na poprawność obliczeń |
| Wyjaśnienie wyniku | Zostaje | Właściciel musi rozumieć otrzymaną kwotę |
| Kilka motywów kolorystycznych | Czeka | Nie zmieniają obliczonego kosztu |
| Połączenie z hurtownią | Czeka | Na początek ceny można wpisać ręcznie |
| Rozliczanie czasu kucharzy | Poza zakresem | To dodatkowy problem biznesowy |
Przy wątpliwości zadaj sobie pytanie: „Czy bez tego klient nadal wykona zadanie, za które miałby zapłacić?”. Jeśli tak, sprawdź, czy brak funkcji tylko zmniejsza wygodę, czy jednak uniemożliwia używanie aplikacji w rzeczywistych warunkach. Eksport wyniku do pliku może być dodatkiem dla jednej osoby i warunkiem pracy dla innej.
Oceń też częstotliwość potrzeby. Prośba pojedynczego restauratora o obsługę nietypowego opakowania nie musi zmieniać planu całego produktu. Możesz obsłużyć taki przypadek ręcznie i zapisać, czy pojawia się ponownie u innych odbiorców.
Nie traktuj wszystkich dodatków jako równie tanich. Zmiana napisu ma inne konsekwencje niż wspólna praca kilku osób nad jednym przepisem. Ta druga funkcja wymaga ustalenia, kto może oglądać dane, kto może je zmieniać i co dzieje się podczas jednoczesnej edycji.
Zapisuj przy odłożonych pomysłach powód powrotu. „Dodamy historię cen, gdy użytkownicy zaczną regularnie porównywać wyceny” daje lepszą wskazówkę niż „wersja druga”. Rozwój wynika wtedy z zaobserwowanego zachowania, a nie z samego istnienia długiej listy.
Ręczna obsługa pomaga
Pierwsza wersja nie musi wykonywać automatycznie każdej czynności po Twojej stronie. W portalu dla hodowców możesz ręcznie zatwierdzać zgłoszenia do katalogu, jeśli odbiorcy wiedzą, że publikacja wymaga sprawdzenia. Nie musisz od razu budować rozbudowanego systemu samoobsługi dla administratora, czyli osoby zarządzającej aplikacją.
Oddziel jednak ręczną pracę właściciela od niedokończonego zadania klienta. Jeśli obiecujesz natychmiastowy wynik obliczenia, nie zastępuj go wiadomością wysyłaną następnego dnia. Jeśli oferujesz indywidualnie przygotowane zestawienie, ręczne opracowanie może być zgodne z usługą, pod warunkiem jasnego opisu.
Spisz czynności wykonywane poza aplikacją i osobę odpowiedzialną za każdą z nich. Dopisz, skąd będzie wiedziała o nowym zadaniu i jak oznaczy jego zakończenie. Nawet prosty zeszyt spraw do obsłużenia jest lepszy niż poleganie na pamięci i przypadkowym zauważeniu wiadomości.
Mierz własny czas, ponieważ ręczna pomoc może ukryć niewygodę produktu. Jeśli każdemu klientowi musisz tłumaczyć to samo pole formularza, popraw opis pola zamiast uznawać rozmowę za stały element wdrożenia. Jeśli zgłoszenia wymagają oceny merytorycznej, ta praca może pozostać częścią usługi.
Ustal również granicę ręcznej obsługi. Może nią być sytuacja, w której nie jesteś w stanie dotrzymać obiecanego terminu albo przez obsługę nie masz czasu poprawiać produktu. Wtedy automatyzujesz konkretną czynność, której koszt już rozumiesz, zamiast zgadywać przyszłe potrzeby.
Nie zbieraj danych tylko dlatego, że formularz może mieć kolejne pole. Do kalkulacji porcji zwykle nie potrzebujesz adresu restauracji ani daty urodzenia właściciela. Mniej danych to prostszy formularz, łatwiejsza obsługa i mniejszy zakres odpowiedzialności.
Minimum zachowuje jakość
Możesz zmniejszyć liczbę funkcji, ale nie powinieneś świadomie pozostawiać błędnych wyników. Kalkulator z jednym rodzajem obliczenia może być dobrym początkiem. Kalkulator z wieloma opcjami, który czasem myli jednostki, nie daje klientowi podstaw do zaufania.
Podobnie działa rezerwacja boiska. Pierwsza wersja może obejmować jeden obiekt i ręczne ustalanie godzin otwarcia. Powinna jednak chronić przed przyjęciem dwóch potwierdzonych rezerwacji tego samego terminu, ponieważ dostępność miejsca stanowi istotę obietnicy.
Rozróżnij ograniczenie i usterkę. Brak listy oczekujących jest ograniczeniem, które możesz opisać. Znikająca rezerwacja jest usterką, którą trzeba naprawić przed przyjmowaniem rzeczywistych zgłoszeń.
Przygotuj krótką listę przypadków do sprawdzenia przed przekazaniem aplikacji:
- Wykonaj całe zadanie z poprawnymi danymi.
- Zostaw wymagane pole puste i sprawdź komunikat.
- Wpisz dane nietypowe, ale możliwe w rzeczywistej pracy.
- Przerwij zadanie, wróć do niego i oceń zachowanie aplikacji.
- Powtórz próbę na telefonie, jeśli odbiorcy będą z niego korzystać.
Jeżeli aplikacja rozdziela dane klientów, sprawdź także, czy jedna osoba nie widzi informacji drugiej. To warunek poprawnego działania, a nie funkcja do dodania po rozwoju sprzedaży. Do prób używaj wymyślonych danych roboczych, które nie należą do rzeczywistych klientów.
Zadbaj o prosty język komunikatów. Właściciel restauracji powinien zobaczyć, co ma poprawić, a nie techniczny opis problemu. Usuwanie zbędnych opcji i dopracowanie takiej informacji zwykle bardziej pomaga pierwszemu użytkownikowi niż kolejny ozdobny ekran.
Zapisz granice wersji
Przygotuj jedną kartkę opisującą wersję, którą teraz budujesz. Taki dokument jest punktem odniesienia zarówno dla Ciebie, jak i dla osoby pomagającej w realizacji. Gdy pojawi się nowy pomysł, porównasz go z ustaleniami zamiast od razu zmieniać aplikację.
Na kartce umieść odbiorcę, problem, oczekiwany wynik i drogę do jego uzyskania. Dopisz funkcje obowiązkowe, rzeczy celowo pominięte, ręczne obowiązki oraz warunki uznania wersji za gotową. Nie potrzebujesz rozbudowanej prezentacji ani specjalnego programu do planowania.
Warunek gotowości powinien opisywać obserwowalne zachowanie. „Kalkulator jest wygodny” pozostawia dużo miejsca na spór. „Użytkownik wprowadza własny przepis, otrzymuje poprawny koszt porcji i potrafi wyjaśnić, skąd wzięła się kwota” pozwala przeprowadzić konkretną próbę.
Zapisz również pytanie, na które ma odpowiedzieć pierwsze użycie. W kalkulatorze może to być sprawdzenie, czy właściciel lokalu wraca do niego po zmianie cen zakupu. Samo obejrzenie aplikacji i pochwała wyglądu nie odpowiadają na to pytanie.
Każda zmiana zakresu powinna mieć widoczny koszt. Jeśli dodajesz przechowywanie przepisów, dopisz potrzebę ich odnajdywania, poprawiania i usuwania. Funkcja przedstawiona jednym zdaniem może tworzyć kilka nowych czynności, które również trzeba zaprojektować i sprawdzić.
Przy przekazywaniu zakresu drugiej osobie przeczytajcie go na przykładzie jednego rzeczywistego zadania. Jeśli każde z Was inaczej rozumie wynik albo granicę funkcji, doprecyzuj zapis przed rozpoczęciem pracy. Krótki dokument pomaga tylko wtedy, gdy opisuje wspólne ustalenia, a nie same hasła.
Częsty błąd
Nie myl łatwości wygenerowania ekranu z łatwością utrzymania funkcji. Narzędzie AI, czyli program wykorzystujący sztuczną inteligencję do tworzenia odpowiedzi i zmian w projekcie, może szybko dorysować przycisk „Udostępnij”. Nadal trzeba ustalić, kto zobaczy udostępnione informacje i jak właściciel cofnie dostęp.
Podczas pierwszych prób zapisuj zachowanie użytkownika zamiast tłumaczyć mu każdy ruch. Gdy zatrzyma się przy formularzu, zanotuj miejsce i jego własne słowa. Pomoc może być potrzebna, ale wtedy zaznacz, że zadanie nie zostało wykonane samodzielnie.
Rozdziel uwagi na przeszkody, usprawnienia i nowe zastosowania. Przeszkoda uniemożliwia osiągnięcie obiecanego rezultatu, usprawnienie skraca drogę, a nowe zastosowanie rozszerza produkt. W pierwszej kolejności naprawiasz przeszkody, ponieważ bez tego nie sprawdzisz sensu istniejącej wersji.
Nie dodawaj funkcji wyłącznie dlatego, że ktoś powiedział „przydałoby się”. Poproś o opis ostatniej sytuacji, w której jej zabrakło, oraz sposobu poradzenia sobie z problemem. Taka odpowiedź pokazuje rzeczywistą potrzebę i pozwala porównać ją z innymi pracami.
Gdy aplikacja spełnia zapisane warunki, zakończ etap budowania tej wersji. Kolejne poprawki planuj na podstawie użycia, a nie obawy, że produkt wygląda zbyt skromnie. Mały zakres ułatwia zauważenie, czy rozwiązanie rzeczywiście pomaga, ponieważ wynik nie ginie wśród wielu pobocznych funkcji.
Odłożone pomysły pozostaw w osobnym miejscu. Dzięki temu podczas naprawiania błędu nie zaczniesz przypadkiem rozbudowywać produktu, a przegląd kolejnych potrzeb zrobisz po zakończeniu prób obecnego zakresu.
Podsumowanie w pięciu punktach
- Wybierz jednego odbiorcę, jeden problem i konkretny rezultat pierwszej wersji.
- Zachowaj pełną drogę do wyniku, nawet jeśli mieści się na jednym ekranie.
- Odkładaj dodatki, zapisując warunek, pod którym wrócą do planu.
- Zmniejszaj zakres funkcji, zachowując poprawność wyników i rozdzielenie danych klientów.
- Zakończ budowę wersji po spełnieniu ustalonych warunków i obserwuj rzeczywiste użycie.
Co dalej
Przeczytaj „Narzędzia, które tworzą aplikacje z opisu”, żeby wybrać sposób zbudowania ustalonego zakresu. Temat „Opinie i testowanie” pomoże Ci zaplanować zbieranie uwag od pierwszych użytkowników.