MVP za 30 dana ima smisla samo kada obim, početni uslovi i način odlučivanja staju u taj period. To nije obećanje da svaka ideja može da stigne u produkciju za mesec dana. Definišite najmanje izdanje koje odgovara na stvarno poslovno pitanje za određenu grupu korisnika. Zatim dogovorite šta znači da radi, ko ga prihvata i koji rizici mogu da zaustave raspored.
Počnite od jednog ishoda i jednog korisničkog toka
Uzmimo hipotetički interni portal za zahteve. Pitanje je da li zaposleni mogu da podnesu zahtev i vide odluku bez praćenja prepiske. Tok je podnošenje, pregled, odobravanje ili odbijanje i uvid u status. To daje korisnu granicu za početnu analizu. Tržište sa više ponuđača, naplata, mobilna aplikacija i široka analitika predstavljaju druge ishode, čak i kada ih neko naziva neophodnim budućim funkcijama.
Zapišite ishod u rečenici koju kupac i inženjer razumeju isto. Navedite prve korisnike, očekivani obim i podatke koje obrađuju. Izaberite jedno merilo uspeha, poput završetka postupka bez podrške, i prikupite početno stanje gde je moguće. Usvajanje proizvoda i tržišna potražnja ostaju hipoteze za proveru; isporučen interfejs ih ne dokazuje.
Dogovorite obim kroz ponašanje koje se može proveriti
| Uključeno ponašanje | Primer dokaza za prihvatanje |
|---|---|
| Podnošenje ispravnog zahteva | Obavezna polja se proveravaju; uspešno podnošenje dobija vidljivu oznaku |
| Pregled unutar odgovarajuće organizacije | Ovlašćene osobe vide dozvoljene zahteve; pristup drugoj organizaciji se odbija |
| Odobravanje ili odbijanje | Samo dozvoljene uloge odlučuju; sačuvani status odgovara prikazanom |
| Oporavak od neuspelog podnošenja | Korisnik vidi korisnu grešku i nastavlja bez gubitka unosa |
| Rad i predaja | Odgovorna osoba može da objavi izdanje, pregleda greške i prati uputstva za oporavak |
Uz tok rada dogovorite realna očekivanja za pristupačnost, bezbednost i performanse. Ona su deo upotrebljivog rešenja. Kada je rok tesan, smanjite broj funkcija. Nemojte izbaciti autentifikaciju, proveru dozvola ili neophodnu obradu grešaka da biste sačuvali datum. Navedite koje provere su automatske, a za koje je potreban poslovni predstavnik.
Jasno navedite šta nije uključeno
- Bez izvorne mobilne aplikacije, osim ako je ona izabrana kao prva platforma; dogovorite podržane pregledače i uređaje.
- Bez migracije istorijskih podataka izvan dogovorenog uzorka ili formata za uvoz.
- Bez naplate, naprednog izveštavanja, uređivača uloga i dodatnih organizacionih tokova, osim ako su ključni za ovaj postupak.
- Bez pretpostavke da će nepotvrđena integracija, produkcioni pristup ili spoljno odobrenje stići na vreme.
Isključenja sprečavaju da dve strane istim rečima kupuju različite proizvode. Zapišite ih uz uključeni obim, ne u zaboravljenoj belešci sa sastanka. Kada stigne novi zahtev, uporedite ga sa ciljem izdanja. Zamenite ga poslom sličnog napora, odložite ga ili jasno dogovorite promenu vremena i budžeta.
Proverite spremnost pre početka roka
Pre datuma početka potvrdite osobu koja odlučuje, reprezentativne podatke, pravac dizajna, potreban pristup sistemima i osobu koja prihvata rezultat. U ponudi definišite da li 30 dana znači kalendarske ili radne dane. Dogovorite rok za povratne informacije i postupak kada zavisnost zastane. Nezavršeno odobrenje provajdera plaćanja ili nedostupan ERP administrator predstavljaju rizik rasporeda, a ne slobodan inženjerski kapacitet.
| Kontrolna tačka | Odluka ili dokaz |
|---|---|
| Početna nedelja | Potvrda toka, prototipa, pristupa i primera za prihvatanje |
| Druga nedelja | Demonstracija celog minimalnog toka sa reprezentativnim podacima |
| Treća nedelja | Provera dozvola, neuspešnih putanja i poslovnih kriterijuma |
| Završni period | Rešavanje prepreka, dokumentovanje rada i odluka o uvođenju |
Ovaj raspored je ilustrativan, nije garancija isporuke. Aktivnosti se preklapaju, a kalendar zavisi od dogovorenog obima i spremnosti. Nedeljna demonstracija treba rano da otkrije potrebne odluke. Ako je ceo tok blokiran na polovini perioda, promenite granicu izdanja umesto da doteran ekran koristite kao dokaz da je proces skoro završen.
Definišite šta kupac dobija
Prihvatanje uključuje pristup izvornom kodu, konfiguraciju objavljivanja, dokaze testiranja, poznata ograničenja i uputstvo za rad. Odredite ko posle isporuke upravlja hostingom, pristupnim podacima i podrškom. Razlikujte nedostatke u dogovorenom ponašanju od zahteva za nove funkcije. Period podrške i očekivano vreme odgovora dogovorite u ponudi umesto da podrazumevate neograničeno održavanje.
Za razvoj proizvoda pripremite korisnički tok i odluku koju prvo izdanje treba da omogući. Ako nerešena arhitektura ili integracije dominiraju obimom, počnite od softverske arhitekture. Poređenje modela saradnje objašnjava kada odgovara ograničen projekat, a kada stalni tim.