Jak spisać zakres pierwszej wersji aplikacji (MVP), żeby wycena i termin miały sens?

Co musi być w zakresie pierwszej wersji?

Pięć elementów. Zakresu, w którym brakuje któregoś, nie da się wycenić ryczałtem ani rozliczyć przy odbiorze, bo nie ma listy, do której można przyłożyć gotową aplikację.

1. Problem i odbiorcy — czyją pracę aplikacja skraca i kto siada przed ekranem: role z nazwy, nie „użytkownicy”.
2. Jedna funkcja główna i najwyżej dwie wspierające — opisane czasownikiem i przypisane do widoku, na którym się dzieją.
3. Lista ekranów i ról — policzalna i ponumerowana, razem ze stanem pustym i stanem błędu.
4. Granica: czego w tej wersji nie ma — jawna lista, nie milczenie.
5. Kryteria odbioru i wkład zamawiającego — co znaczy „gotowe” dla każdej funkcji, w scenariuszach do przeklikania, oraz materiały, decyzje i dostępy z datami po stronie zamawiającego.

W pierwszej wersji aplikacji dla firmy powtarza się u nas ten sam skład: logowanie i konta, panel klienta, panel administratora, funkcja główna z jedną lub dwiema wspierającymi, płatności i subskrypcje, strona sprzedaży pod markę, automatyzacje i statystyki, dokumenty (regulamin, polityka prywatności, RODO) oraz uruchomienie na żywo.

Te dziewięć pozycji to nie jest dziewięć funkcji. Osiem z nich to szkielet, który ma każda aplikacja przyjmująca płatności i konta. Funkcja główna jest jedna i tylko ona decyduje, czy komuś się przyda.

Czego nie wpisywać do pierwszej wersji i dlaczego?

Cztery grupy funkcji wracają u nas w prawie każdej rozmowie o zakresie i prawie zawsze wypadają z pierwszej wersji. Nie dlatego, że są złe, tylko dlatego, że kosztują czas, zanim jest komu je pokazać. Wracają do rozmowy po starcie, kiedy widać, z czego użytkownicy naprawdę korzystają.

Funkcje z efektem sieciowym — czat, oceny, polecenia, ranking. Mają sens przy setkach aktywnych kont; przy dwudziestu wyglądają jak pusty ekran i psują wrażenie z aplikacji, która poza tym działa.

Integracje „na później” — wymiana danych z programem księgowym, hurtownią albo systemem sieci franczyzowej. To najdroższa część zakresu, bo zależy od cudzej dokumentacji, cudzych limitów i tempa odpowiedzi drugiej strony. Wchodzi wtedy, gdy jest kto z niej korzysta.

Panel raportów — raporty liczą się z danych, których w dniu startu jeszcze nie ma. Przez pierwsze miesiące wystarczy eksport do pliku i dwa liczniki w panelu administratora, a kształt raportów podpowiedzą prawdziwe dane.

Role „na wyrost” — pięć rodzajów użytkownika zamiast dwóch mnoży ścieżki do zbudowania i do przetestowania, a w małej firmie i tak wszystko robią dwie osoby. Rolę dokłada się wtedy, gdy pojawia się drugi typ pracownika.

Osobno stoi obecność w sklepach z aplikacjami. To decyzja o dystrybucji, nie o funkcji, i wraca przy wyborze między aplikacją w przeglądarce a natywną — nie przy spisywaniu zakresu.

Jak zakres steruje wyceną i terminem?

Zależność działa w obie strony: zamknięta wycena powstaje z zamkniętej listy, a termin biegnie od kompletu decyzji i materiałów. Kwot tutaj nie podajemy — pełny rachunek posiadania aplikacji przez trzy lata policzył serwis Policz pomysł.

Pozycja opisana ogólnie nie znika z wyceny. Zostaje wyceniona najostrożniejszym wariantem, jaki da się z niej odczytać, bo ryzyko ma swoją cenę i swój termin. Niedopowiedzenie w zakresie działa więc przeciwko zamawiającemu, nie na jego korzyść.

Termin ma drugi warunek, o którym łatwo zapomnieć: materiały, decyzje i dostępy po stronie zamawiającego. Ich brak zatrzymuje bieg terminów — nie jako kara, tylko dlatego, że pracy nie da się wykonać. Dlatego wkład zamawiającego stoi w zakresie razem z datami.

Zakres steruje też odbiorem. Do gotowej aplikacji przykłada się listę z zakresu, a nie wrażenie z pokazu — kryteria odbioru mają sens tylko wtedy, gdy wynikają wprost z listy ekranów. Sam odbiór, z oknem na uwagi i tym, co dzieje się przy ich braku, opisujemy w tekście o budowie krok po kroku.

Jak wygląda zmiana zakresu w trakcie?

Zmiana zakresu to osobna wycena, nie „dorzucimy”. Brzmi twardo, a chroni zamawiającego: pozwala policzyć, ile kosztuje pomysł, który przyszedł do głowy w piątym tygodniu budowy, i zdecydować, czy jest wart przesunięcia startu.

Zmiany dzielą się na trzy rodzaje i tylko dwa z nich są zmianą zakresu.

• Doprecyzowanie — ekran był na liście, ustalamy szczegół działania. To nie jest zmiana zakresu i nie rusza terminu.
• Nowa funkcja albo nowy ekran — wchodzi opis, wycena i wpływ na termin; praca zaczyna się po akceptacji, a nie w trakcie rozmowy.
• Przebudowa czegoś, co już powstało — najdroższy wariant, bo ta sama praca jest wykonywana drugi raz, razem z testami. Dlatego makiety akceptuje się przed kodem.

Każda zmiana ma zapis: co się zmienia, na których ekranach, co z terminem, kto i kiedy to zaakceptował. Zmiana ustalona ustnie wraca po dwóch miesiącach jako spór, którego nikt nie umie rozstrzygnąć.

Po czym poznać, że zakres jest gotowy do wyceny?

Po sześciu pytaniach. Jeśli na każde pada odpowiedź bez „to jeszcze ustalimy”, dokument jest gotowy — niezależnie od tego, kto go pisał.

• Da się policzyć ekrany i role bez dopytywania kogokolwiek?
• Każda funkcja opisana jest czasownikiem („klient rezerwuje termin”), a nie rzeczownikiem („zarządzanie rezerwacjami”)?
• Jest lista „czego nie ma”, zaakceptowana przez obie strony?
• Kryteria odbioru da się przeklikać krok po kroku i zapisać wynik?
• Jest napisane, co dostarcza zamawiający i do kiedy?
• Jest zdanie: co jest poza listą ekranów, jest poza zakresem?

To ostatnie zdanie robi więcej, niż wygląda. Zdejmuje z rozmowy o zmianach ton oskarżenia i zamienia ją w rachunek: tyle pracy, taki termin, decyduje zamawiający. Resztę kolejności prac — od zakresu do rozruchu — opisujemy w dziale Jak przebiega budowa.