Zanim zlecisz budowę MVP, uzgodnij jeden efekt pierwszej wersji, listę rzeczy, których w niej nie będzie, i sposób sprawdzenia wyniku. Potem odbieraj konkretną wersję według zapisanych kryteriów. Dostęp do kodu, danych i kont ustal jeszcze przed rozpoczęciem prac.
Lista funkcji w ofercie niewiele mówi o tym, czy dostaniesz produkt, który możesz przyjąć i dalej rozwijać. Ten poradnik prowadzi przez cztery dokumenty, które to rozstrzygają: krótki brief, kryteria odbioru, zasady oceniania zgłoszeń i listę dostępów. Wszystko pokazujemy na jednym przykładzie: rezerwacji sal w coworkingu.
Co wysłać, zanim poprosisz o wycenę
Wystarczy brief aplikacji na jedną stronę. Każdy wykonawca, który go dostanie, wyceni ten sam produkt, więc porównasz oferty, a nie domysły.
- Kto będzie korzystać. Jedna grupa użytkowników na start, np. „członkowie coworkingu”, a nie „wszyscy, którzy rezerwują sale”.
- Problem. Co dziś zajmuje im czas albo kończy się błędem.
- Jeden efekt pierwszej wersji. Co użytkownik ma zrobić od początku do końca, bez pomocy zespołu.
- Czego w tej wersji nie będzie. Ta lista chroni budżet bardziej niż lista funkcji.
- Ograniczenia. Termin, budżet lub jego górna granica, wymagane integracje, dane, które już masz.
- Kto decyduje po Twojej stronie. Jedna osoba, która odbiera wersje i rozstrzyga spory o zakres.
Jeśli punkt 3 wymaga kilku zdań połączonych słowem „oraz”, to zwykle są dwa produkty. Wybierz ten, który pierwszy ma trafić do ludzi.
Przykład: rezerwacja sal w coworkingu
Poniższy przykład przygotowaliśmy na potrzeby tego poradnika. Nie jest to projekt klienta ani zapis prawdziwego odbioru.
Pierwsza wersja: członek coworkingu wybiera wolny termin, rezerwuje salę i może anulować własną rezerwację. Koordynator widzi rezerwacje swojej lokalizacji. W przykładzie każda organizacja ma jedną lokalizację.
Zakres w pięciu punktach:
- W1. Zalogowany członek widzi wolne terminy i rezerwuje salę swojej organizacji. Po odświeżeniu strony rezerwacja nadal jest widoczna.
- W2. Na tę samą salę i ten sam termin może istnieć tylko jedna rezerwacja, nawet gdy dwie osoby klikną jednocześnie.
- W3. Członek anuluje tylko własną rezerwację, a anulowanie zwalnia termin.
- W4. Koordynator widzi rezerwacje swojej organizacji. Osoba z innej organizacji nie zobaczy ich ani nie zmieni, także przez bezpośredni adres.
- W5. Przed uruchomieniem wskazana osoba po Twojej stronie potwierdza dostęp do kodu, hostingu, danych i rozliczeń oraz uzgodniony sposób odzyskania danych.
Poza zakresem: płatności i abonamenty, aplikacje na telefon, rezerwacje cykliczne, powiadomienia e-mail i SMS, synchronizacja z kalendarzem, lista oczekujących oraz samodzielne zakładanie organizacji i sal. Konta i sale do pierwszego uruchomienia przygotowuje zespół wykonawcy.
Zwróć uwagę na W2 i W4. Oba wydają się oczywiste, ale nie zobaczysz ich na makietach ekranów. Jeśli ich nie zapiszesz, nikt ich nie sprawdzi.
Od listy funkcji do kryteriów odbioru
Kryterium odbioru opisuje sytuację, działanie i wynik, który każdy może zobaczyć. „Rezerwacja działa” nim nie jest. „Dwie osoby rezerwują tę samą salę w tej samej chwili i tylko jedna dostaje potwierdzenie” już tak. Dobre kryterium opisuje zasadę działania, a nie kolejne kliknięcia, więc nie trzeba go przepisywać, gdy zmienią się ekrany (Cucumber, „Writing better Gherkin”).
Dla pięciu punktów zakresu wystarczy osiem sprawdzeń:
- S1 (W1). Członek rezerwuje salę, odświeża stronę, wylogowuje się i loguje ponownie. Widzi jedną swoją rezerwację, a termin nie jest już wolny.
- S2 (W2). Dwie osoby wysyłają rezerwację tej samej sali na ten sam termin jednocześnie. Jedna dostaje potwierdzenie, druga informację, że termin jest zajęty. W systemie jest jedna rezerwacja. Sam zrzut ekranu tego nie dowodzi; potrzebny jest zapis obu prób i stan danych.
- S3 (W3). Członek anuluje rezerwację, a druga osoba rezerwuje zwolniony termin. Zostaje jedna rezerwacja, tej drugiej osoby.
- S4 (W3). Członek próbuje anulować cudzą rezerwację z pominięciem przycisków w aplikacji, np. zmieniając numer rezerwacji w adresie. Dostaje odmowę, a rezerwacja się nie zmienia.
- S5 (W4). Osoba z innej organizacji próbuje otworzyć listę rezerwacji i konkretną rezerwację, a potem ją anulować. Nie dostaje żadnych danych, zmiana jest odrzucona.
- S6 (W4). Koordynator otwiera listę. Widzi rezerwacje swojej organizacji i nie widzi cudzych.
- S7 (W1, W4). Bez logowania nie da się odczytać ani utworzyć rezerwacji.
- S8 (W5). Osoba wskazana w W5 loguje się własnym kontem do repozytorium i hostingu, sprawdza eksport danych i dostęp do rozliczeń, a potem patrzy, jak dane są odtwarzane w oddzielnym środowisku. Hasła, klucze i kody odzyskiwania nie trafiają do żadnego raportu.
Przy każdym sprawdzeniu zapisz, czego oczekujesz i jaki dowód chcesz zobaczyć. Wykonawca, który przy wycenie nie potrafi powiedzieć, jak pokaże S2 albo S5, prawdopodobnie ich nie planuje.
Wersje co tydzień: uwagi do konkretnej wersji
Umów się, że co tydzień dostajesz działającą wersję razem z listą sprawdzeń, które powinna już przechodzić. W przykładzie mogą to być najpierw S1 i S7, a przed odbiorem wszystkie osiem.
Żeby te przeglądy coś dawały, każda uwaga powinna wskazywać numer lub datę wersji i kryterium, którego dotyczy. „W wersji z 14 listopada S3 nie przechodzi: po anulowaniu termin nadal jest zajęty” da się naprawić i sprawdzić ponownie. „Rezerwacje jakoś nie działają” prowadzi do rozmowy, która niczego nie zamyka.
Wygodnie jest prowadzić jedną tabelę odbioru: wymaganie, sprawdzenie, wersja, kto sprawdzał i kiedy, czego oczekiwano, co się stało, dowód, decyzja, ponowne sprawdzenie.
Błąd czy nowe zamówienie? Cztery zgłoszenia
Najwięcej sporów przy MVP zaczyna się od zdania „przecież to oczywiste”. Zapisany zakres pozwala rozstrzygnąć je spokojnie:
- Na tę samą salę i ten sam termin powstały dwie rezerwacje. To błąd: W2 i S2 wprost tego zabraniają. Wykonawca poprawia, a S2 powtarza się przed odbiorem tego wymagania. Kto płaci za poprawkę, rozstrzyga umowa.
- Chcesz listy oczekujących, gdy termin jest zajęty. To zmiana zakresu: lista oczekujących jest wprost wyłączona. Najpierw nazwij nowy efekt i oceń jego wpływ na zakres, budżet i termin. Potem zdecyduj: wymieniasz na nią coś z obecnego zakresu, przenosisz ją do kolejnego etapu albo odkładasz.
- Chcesz rezerwacji co tydzień o tej samej porze. Też zmiana zakresu. Ta wersja zostaje bez zmian, dopóki nie uzgodnicie osobno nowego zakresu.
- Ekran rezerwacji długo się wczytuje, ale nikt nie zapisał, jak szybko ma działać. Ani błąd, ani zmiana zakresu, tylko luka w ustaleniach. Trzeba zobaczyć, co się dzieje, i uzgodnić mierzalny próg, np. czas odpowiedzi przy określonej liczbie użytkowników. Nie zakładaj z góry, że przyspieszenie to płatna zmiana ani że wolne działanie musisz przyjąć bez dyskusji.
Czwarty przypadek warto przewidzieć jeszcze przed startem: jeśli coś jest dla Ciebie ważne, a nie da się tego sprawdzić, dopisz kryterium.
Na czyich kontach powstaje produkt?
Przekazanie produktu nie zaczyna się w ostatnim tygodniu. Zanim prace ruszą, ustal, na czyich kontach powstaje:
- kod: repozytorium w Twojej organizacji, w którym Ty albo wskazana przez Ciebie osoba ma rolę właściciela, a nie zaproszonego współpracownika. W GitHubie właściciel organizacji ma pełny dostęp administracyjny, a członek tylko taki, jaki mu nadano (GitHub, role w organizacji);
- hosting i baza danych: konto w chmurze, za które płacisz Ty lub które da się przenieść na Ciebie;
- domena, wysyłka e-maili, analityka i zewnętrzne integracje: każda z przypisanym właścicielem;
- rozliczenia: kto płaci za usługi i komu przychodzą faktury;
- odzyskanie danych: gdzie są kopie i kto potrafi je odtworzyć.
Każdy dostaje własne konto z odpowiednią rolą. Nie udostępniajcie sobie haseł. Pamiętaj też, że przeniesienie samego repozytorium ma swoje warunki i nie przenosi hostingu, danych ani płatności (GitHub, przenoszenie repozytorium). Dlatego w S8 loguje się osoba wskazana przez Ciebie, własnym kontem, a nie wykonawca.
Odbiór wersji i decyzja o kolejnym etapie
Odbierasz konkretną wersję według uzgodnionych wymagań: każde kryterium ma wynik i dowód. Jeśli któreś sprawdzenie nie przeszło, a mimo to chcesz uruchomić produkt, zapisz to jako swoją decyzję, z datą i numerem wersji.
Po odbiorze wróć do listy rzeczy wyłączonych z zakresu. Część z nich użytkownicy pierwszej wersji zgłoszą sami, część okaże się zbędna. Dopiero wtedy wiesz, co powinno trafić do następnego etapu.
Jak to wygląda u nas
W Awakast pierwsza wersja to etap „Od pomysłu do pierwszej wersji”: razem ustalamy problem i zakres, projektujemy kluczowe ekrany z partnerskim studiem UX/UI, budujemy produkt i uruchamiamy go z pierwszymi użytkownikami. Zwykle trwa to sześć do ośmiu tygodni. Zakres i wynagrodzenie, stałe lub z górnym limitem, ustalamy przed rozpoczęciem prac. Kod, dane i konta należą do Ciebie od pierwszego dnia.
Jest jakiś powód, żeby nie ustalić, co powinna robić Twoja pierwsza wersja? Opowiedz nam o swoim pomyśle.