Pierwsza wersja aplikacji nie musi umieć wiele. Musi jednak doprowadzać wybraną sprawę do końca. Formularz zgłoszenia, z którego dane trafiają do skrzynki bez właściciela, jest początkiem procesu, a nie jego rozwiązaniem. MVP, czyli minimalny użyteczny zakres produktu, powinno pozwolić sprawdzić konkretny sposób pracy. Sam fakt, że udało się coś opublikować, nie odpowiada jeszcze na pytanie, czy warto to rozwijać.
Wyobraźmy sobie niewielką firmę serwisową. Jej pierwsza aplikacja ma przyjmować zgłoszenia i przydzielać je wykonawcom. Panel klienta, rozbudowany magazyn części oraz prognozowanie obłożenia mogą poczekać. Nie powinno natomiast zabraknąć informacji, kto prowadzi sprawę, co dzieje się po odmowie terminu i jak odnotować wykonanie usługi. Bez tego zespół wróci do telefonów, a aplikacja stanie się eleganckim miejscem rozpoczęcia starego bałaganu.
Wybierz jeden obieg, a nie po jednym ekranie z każdego działu
Zakres pierwszej wersji najlepiej wyznacza pełna ścieżka: od zdarzenia wejściowego do wyniku, który ktoś odbiera. Może to być przyjęcie zapytania, przygotowanie oferty i jej zatwierdzenie. Może to być zapis uczestnika oraz nadanie dostępu do materiałów. Tak zamknięty fragment pracy pozwala ustalić odpowiedzialność, dane i warunki testu. Zestaw przypadkowych ekranów z kilku procesów tego nie zapewnia, nawet jeśli każdy ekran osobno wygląda na gotowy.
Przy wyborze ścieżki przydaje się opis przygotowany przed zamówieniem aplikacji dla firmy. Zapisz, jak często zadanie występuje i gdzie najczęściej się zatrzymuje. Jeśli rzadki wyjątek zajmuje zespołowi kilka dni, może być ważniejszy niż popularna, ale już prosta czynność. Nie wybieraj pierwszego modułu wyłącznie dlatego, że łatwo go pokazać na prezentacji. Użytkownik będzie go obsługiwał po prezentacji, kiedy prowadzący już wyjdzie.
Ogranicz funkcje, zachowaj podstawowe obowiązki
Mniejszy zakres nie oznacza dowolnego obchodzenia się z dostępami i danymi. Nawet niewielka aplikacja potrzebuje uzgodnionych ról, sposobu odzyskania danych i czytelnego zachowania przy błędzie. Można zacząć od jednego oddziału oraz dwóch ról użytkownika. Trzeba jednak wiedzieć, kto widzi dokumenty i kto może zatwierdzić zmianę. Odkładanie tych ustaleń zazwyczaj zwiększa liczbę miejsc, które później trzeba przebudować.
Podobnie jest z integracjami. Nie każde połączenie musi być automatyczne od pierwszego dnia. Czasem uzgodniony import pliku pozwala rzetelnie sprawdzić sam proces, zanim firma zainwestuje w stałą wymianę danych. Powinno być jasno określone, kto wykonuje import, jak sprawdza wynik i jak poprawia pomyłkę. Taką decyzję można świadomie podjąć przy projektowaniu aplikacji webowej lub mobilnej; nie należy jej ukrywać pod hasłem „integracja w kolejnym etapie”.
Zaprojektuj próbę, która może obalić założenie
Jeśli chcecie sprawdzić, czy pracownicy samodzielnie zamkną zlecenie w terenie, nie oceniajcie tylko liczby utworzonych kont. Ustalcie zadania, urządzenia i sytuacje, w których aplikacja ma zadziałać. Wybierzcie zwykły dzień pracy, a nie wyłącznie spokojny pokaz dla kierownika. Obserwujcie, w którym momencie ktoś wraca do poprzedniej metody. Często właśnie ten moment mówi najwięcej o brakującej informacji lub niejasnej regule.
Przed startem zapiszcie również wynik, który będzie podstawą decyzji. Może nim być kompletność protokołu bez telefonu do biura albo liczba spraw wymagających ponownego wprowadzenia danych. Warunki te powinny później trafić do kryteriów odbioru aplikacji. W przeciwnym razie po pilotażu każda osoba może pamiętać inny cel. Pamięć projektu jest kosztownym miejscem na oszczędzanie dokumentacji.
Zostaw drogę do następnego kroku
Podział na etapy powinien znaleźć odzwierciedlenie w wycenie zakresu aplikacji i zasadach późniejszego utrzymania. Po pilotażu nie powinno być wątpliwości, kto posiada kod, gdzie działają konta i jak można zamówić zmianę. Pierwsza wersja ma ograniczać ryzyko inwestycji, dlatego musi pozostawiać firmie możliwość podjęcia kolejnej decyzji, także z innym wykonawcą, jeśli tak ustalono warunki współpracy.
Już przy pierwszej wersji warto ustalić, które identyfikatory, role i informacje będą potrzebne później. Nie chodzi o budowanie całej przyszłej platformy z wyprzedzeniem. Chodzi o unikanie oczywistych ślepych uliczek, takich jak rozpoznawanie klienta wyłącznie po nazwie wpisanej ręcznie. Rozsądny fundament pozwala rozwijać aplikację bez przebudowy każdej wcześniejszej decyzji. Szczególnie dobrze widać to w aplikacji dla małej firmy, która z czasem obsługuje coraz więcej zleceń.
Po zakończeniu próby możecie rozszerzyć zakres, poprawić wybrany fragment albo zatrzymać projekt. Każda z tych decyzji może być sensowna, jeśli wynika z obserwacji. Z Archifutura ustalamy na początku, co pierwsza wersja ma udowodnić, a następnie budujemy zakres pozwalający to sprawdzić. W oprogramowaniu na zamówienie użyteczność pierwszego modułu jest lepszym punktem startu niż ambitny plan, którego nikt jeszcze nie miał okazji użyć.
