Lista potrzeb rośnie, a budżet pozostaje ten sam. Najłatwiej wykreślać pojedyncze funkcje, aż suma się zgodzi. Problem pojawia się po starcie: użytkownik może rozpocząć sprawę, ale nie może jej zakończyć, albo pracownik musi ręcznie naprawiać każdy przypadek.
Pierwsza wersja powinna obsługiwać mniejszy zakres pracy, ale w sposób kompletny. To daje lepszą podstawę do wyboru niż podział na „ważne” i „mniej ważne” pomysły.
Przejdź jedną sprawę od początku do końca
Weź przykładowy system zapisów na wydarzenia. Uczestnik wybiera termin, podaje dane, dostaje potwierdzenie i może anulować zapis. Pracownik widzi listę i wie, co zrobić, gdy zabraknie miejsc.
Zaawansowane rekomendacje wydarzeń mogą poczekać. Informacja o nieudanym zapisie raczej nie: bez niej człowiek nie wie, czy ma miejsce. O potrzebie funkcji decyduje jej rola w całej ścieżce.
Podziel zakres na trzy grupy
- Potrzebne, żeby zakończyć podstawową sprawę.
- Potrzebne do obsługi i bezpiecznej eksploatacji rozwiązania.
- Usprawnienia, które można dodać po poznaniu realnego użycia.
Do każdej odłożonej funkcji dopisz sposób pracy bez niej. Jeżeli odpowiedź brzmi „pracownik zrobi to ręcznie”, oszacuj czas i przypisz odpowiedzialność. Praca nie znika tylko dlatego, że nie ma jej w systemie.
Sprawdź koszt późniejszej rozbudowy
Zapytaj wykonawcę, które decyzje pierwszego etapu utrudnią kolejne. Nie musisz od razu budować wszystkiego, ale warto ustalić podstawowy model danych i sposób łączenia z innymi systemami.
Zamknij zakres krótkim opisem: kto, jaką sprawę i w jakich warunkach załatwi w pierwszej wersji. Dołącz listę wyjątków oraz odłożonych elementów. Taki opis jest punktem wyjścia do wyceny i odbioru; samo hasło „MVP” pozostawia zbyt dużo miejsca na różne interpretacje.
Wszystkie liczby z artykułu i tysiące innych umów znajdziesz w bazie.
Otwórz bazę umów