Ha ebből már fejlesztési feladatot készítenél, az MVP fejlesztésének menete bemutatja, hogyan kapcsolódik a szűkítéshez a megvalósítás és az indulás. Itt az első funkciólista összeállításához kapsz munkamintát.
01 / MVP-fejlesztés
Indulj egy teljes felhasználói történetből
Ne modulokat sorolj elsőként, hanem egy végigvihető helyzetet. Például: egy szolgáltatót kereső érdeklődő kiválaszt egy lehetőséget, elküldi az igényét, a szolgáltató pedig látja és feldolgozza azt. Ez tisztázza, hol kezdődik és hol ér véget a termék feladata.
A bejelentkezés nem automatikusan kötelező első funkció. Ha a feladat egyszeri kapcsolatfelvétel, lehetséges egyszerűbb út. Ha viszont érzékeny vagy ügyfelenként elkülönülő adatokat kell visszanézni, a hozzáférés megtervezése a működés lényegéhez tartozhat. A döntést a konkrét adatok és kockázatok alapján hozd meg.
02 / MVP-fejlesztés
Három kérdéssel szűrd a funkciókat
Minden ötletnél kérdezd meg: szükséges-e az alapfeladat befejezéséhez; változtat-e azon, hogy mit tanulunk a próbából; illetve elhagyható-e elfogadható működési kockázattal. Ez megakadályozza, hogy egy látványos extra kiszorítsa a kevésbé látványos mentést vagy hibakezelést.
A többféle felhasználói szerep, a teljes automatizálás és a részletes riport külön-külön is nagy terjedelem lehet. Ha egy elem későbbre kerül, írd le a következményét és az átmeneti megoldást. A halasztás így tudatos döntés lesz, nem elfelejtett feladat.
03 / MVP-fejlesztés
Elfogadási próbák nélkül a funkciónév túl tág
Az „értesítés” megnevezés nem határozza meg, ki, mikor és milyen adattal kap üzenetet. Egy ellenőrizhető feltétel pontosabb: érvényes beküldés után az igény mentve van, az érintett szereplő értesítést kap, a felhasználó pedig egyértelmű visszajelzést lát. Az értesítési hiba külön legyen kezelhető.
A példát egészítsd ki hibás és ismételt művelettel is. Mi történik hiányzó adattal, lassú kapcsolattal vagy kétszeri kattintással? Ezek nem feltétlenül jelentenek bonyolult rendszert; arra szolgálnak, hogy az alapfeladat a szokásos eltéréseknél is követhető maradjon.
04 / MVP-fejlesztés
Különítsd el a termék használatát az üzleti bizonyítéktól
A sikeres átadás azt igazolja, hogy az egyeztetett folyamat működik. A validálás azt vizsgálja, hogy a célcsoport használja-e és értéket kap-e belőle. A kettőhöz eltérő próba kell: fejlesztési ellenőrzés és célzott felhasználói megfigyelés.
A következő körhöz írj rövid döntési naplót: mit feltételeztünk, mit figyeltünk meg, mit változtatunk. A látogatószám önmagában kevés, ha nem tudod, eljutottak-e az emberek a fontos műveletig. A mérés kialakításakor csak a döntéshez szükséges adatot gyűjtsd, az alkalmazott eszközök adatkezelési feltételeit külön tisztázva.
Másold át ezt a briefmintát a saját projektedhez
| Mező | Szemléltető kitöltés |
|---|---|
| Célcsoport és helyzet | Kis szolgáltató új érdeklődést kap a weben |
| Első teljes feladat | Az igény beérkezik, mentve van és feldolgozható |
| Vizsgált feltételezés | Az érdeklődő önállóan megérti és befejezi a beküldést |
| Első körből kihagyva | Többszereplős jóváhagyás és összetett riport |
| Elfogadási próba | Érvényes, hibás és ismételt beküldés követhető |
| Következő döntés | A megfigyelt elakadások alapján választunk új feladatot |
VIGYÉL MAGADDAL EGY KONKRÉT LISTÁT
Mit írj össze az egyeztetés előtt?
- Egy célcsoport, egy helyzet és egy lezárható feladat.
- A tesztelendő üzleti feltételezés.
- Kötelező funkciók és külön a halasztott elemek.
- Minden fő funkcióhoz kipróbálható elfogadási feltétel.
- A próba résztvevői, megfigyelése és kiértékelésének időpontja.
- Az indulás és a későbbi fenntartás felelősei.
Kapcsolódó útmutató
Prototípus vagy MVP: mire van szükséged az ötleted teszteléséhez?