Wybierz etap według największej niewiadomej
Jeżeli nie wiadomo, czy rozwiązanie osiągnie potrzebną jakość albo zintegruje się z kluczowym systemem, warto sprawdzić to w ograniczonym PoC. Jeżeli wykonalność jest wystarczająco poznana, ale trzeba zbadać użyteczność i sposób korzystania z produktu, można rozważyć MVP.
W tym poradniku używamy tych definicji roboczo. Organizacje i dostawcy mogą stosować nazwy inaczej, dlatego opis zakresu ma pierwszeństwo przed etykietą. Prototyp interfejsu, techniczny eksperyment i działająca usługa mogą wyglądać podobnie podczas prezentacji, a wymagać zupełnie innego nakładu pracy oraz odpowiedzialności za działanie.
Porównaj rezultaty i kryteria odbioru
Poniższe porównanie jest propozycją Celor do uzgodnienia briefu z wykonawcą. Nie oznacza, że każdy projekt musi przejść oba etapy.
| Obszar | PoC | MVP |
|---|---|---|
| Główne pytanie | Czy wybrane założenie da się potwierdzić? | Czy ograniczony produkt jest użyteczny w pracy użytkownika? |
| Rezultat | Wyniki eksperymentu i ograniczenia | Działająca wersja o uzgodnionym zakresie |
| Użytkownicy | Zwykle zespół testujący | Wskazana grupa rzeczywistych użytkowników |
| Odbiór | Dowody względem hipotezy | Funkcje, jakość i sposób pomiaru wykorzystania |
| Dalsza decyzja | Kontynuować, zmienić podejście lub zakończyć | Rozwijać, poprawić lub wycofać produkt |
W obu przypadkach określ, kto potwierdza wynik i jakie materiały zostaną przekazane po zakończeniu prac.
Ogranicz funkcje, zachowując potrzebną jakość
MVP może obsługiwać jedną grupę użytkowników i wąski proces. Nie wynika z tego zgoda na brak ochrony danych, niekontrolowane błędy czy niejasną odpowiedzialność za awarie. Wymagania zależą od rzeczywistego sposobu użycia i konsekwencji problemów.
Pomocną analogię daje GOV.UK: alpha służy testowaniu pomysłów i ryzykownych założeń, a beta obejmuje pracę z rzeczywistymi użytkownikami, pomiar i zdolność wspierania usługi. Nie są to definicje PoC i MVP, lecz przykład rozdzielenia eksperymentu od operacyjnego użycia.
W briefie MVP uwzględnij uprawnienia, podstawowe wsparcie, kopie danych tam, gdzie są potrzebne, oraz plan wycofania wadliwej wersji.
Przykład: odczyt dokumentu a obsługa zlecenia
Hipotetyczny PoC sprawdza odczyt kilku pól z określonej grupy dokumentów. Pliki są wgrywane ręcznie, wynik trafia do arkusza, a ekspert ocenia poprawność. Taki eksperyment może odpowiedzieć na pytanie o jakość odczytu.
MVP dla pracowników może wymagać logowania, kolejki spraw, korekty pól, historii zmian i przekazania danych do istniejącego systemu. Różnica kosztu wynika wtedy z rozszerzenia zadania i warunków pracy.
Nie zakładaj, że kod PoC stanie się podstawą produktu. Poproś wykonawcę o wskazanie elementów możliwych do ponownego użycia, elementów do przebudowy oraz niezweryfikowanych zależności.
Doprecyzuj zamówienie przed akceptacją wyceny
Przed rozpoczęciem prac odpowiedz na pięć pytań:
- Jaka decyzja lub potrzeba użytkownika uzasadnia ten etap?
- Co dokładnie działa na koniec i na jakich danych?
- Kto używa rozwiązania oraz w jakim środowisku?
- Jak sprawdzamy jakość, koszt i wartość wyniku?
- Jakie prace pozostaną przed kolejnym etapem?
Przy AI wykorzystaj plan PoC. Przy gotowej propozycji wykonawcy przejdź do oceny oferty software house’u. Second Opinion pomaga zweryfikować zakres, estymację i ryzyka przed zobowiązaniem do projektu; wariant Express kosztuje 2 900 PLN netto.
Częste pytania
Czy zawsze trzeba zbudować PoC przed MVP?
Nie. Jeżeli rozwiązanie jest znane, a ryzyko techniczne niewielkie, dodatkowy PoC może niewiele wnieść. Etap powinien odpowiadać na istotną niewiadomą, która wpływa na decyzję inwestycyjną.
Czy MVP to produkt niskiej jakości?
Nie. Ograniczenie dotyczy zakresu. Wymagany poziom bezpieczeństwa, niezawodności i wsparcia trzeba dopasować do realnego użycia oraz uzgodnić z wykonawcą.
Źródła i dalsza lektura
Źródła wspierają wskazane w tekście zasady. Listy kontrolne i przykłady to propozycje Celor do dopasowania do konkretnego projektu.