MVP, MMF, PSI, WTF? Első rész: Az MVP megértése

Amikor új terméktulajdonosokkal dolgozom, gyakran tapasztalom, hogy a TLA-k (hárombetűs rövidítések) tengerébe keveredünk, amikor eljön az idő, hogy ténylegesen elkezdjük az ötletek Backlogját kiadható értéknövekedéssé alakítani.

A munka lebontásának gondolata – a nagy, tervezett termékkiadások kisebb értéknövekedéssé történő lebontása – az, ahol sok új terméktulajdonos küszködik. Hogyan fogjuk ezt a termék ütemtervet, és hogyan alakítsuk át olyanná, amit a Scrum csapataim valóban rövid, rendszeres ütemben tudnak teljesíteni? Hogyan alakíthatom át a Nagyon fontos funkciók (Very Important Features, VIF) hatalmas listáját a tanulási lehetőségek iteratív halmazává, hogy értéket szolgáltassak, és valóban adjak valamit az ügyfeleink kezébe? Más szavakkal….

“Mi a mi MVP-nk?”

“Ez a mi MMF-ünk?”

“Kiadhatjuk ezt a PSI-t MVP-ként, vagy több történetre van szükségünk, mielőtt MMF-et kapunk?”

Szintén….mi??

Mit jelentenek ezek a TLA-k? Miben különböznek egymástól? Hogyan kapcsolódnak egymáshoz? Miért érdekel ez engem?

Az MVP-vel (Minimum Viable Product) kezdve ez a háromrészes sorozat segít a kezdő agilistáknak megérteni, mit jelentenek ezek a TLA-k. Miben különböznek egymástól? Hogyan kapcsolódnak egymáshoz? Miért kellene foglalkoznom velük? Azoknak is segít emlékeztetni azokat, akik már egy ideje agilisan dolgoznak, hogy miért ezek a fogalmak az agilitás alappillérei.

Akik most kezdik megismerni a Scrumot, a Scrum kézikönyvhöz fordulhatnak… és gyorsan megtanulják, hogy a Scrum kézikönyv hallgat arról, hogyan kell egy terméket apró, kiadható értéknövekedések gyűjteményévé alakítani.

Az ezzel a fontos témával kapcsolatos információhiány igazán frusztráló lehet az új terméktulajdonosok számára. Remélhetőleg a cikk további része tisztázza az MVP-ket, és mindig vannak Certified Scrum Product Owner tanfolyamok, amelyeket további információkért megnézhet. Egyelőre merüljünk el a minimálisan életképes termékben.

Az MVP

Elvégezted a kutatást, végigjártad az ügyfél-fókuszcsoportokat a Buy a Feature néhány fordulóján, és hoztál néhány döntést azzal kapcsolatban, hogyan nézhet ki a következő kiadásod. Sőt, már a marketingcsapatodat is bevontad, és iterálod az ötleteket, hogyan lehetne nagyot dobni – hirdetések a szaklapokban, reklámozott tweetek, Facebook-posztok…

De még mindig van néhány kínzó kérdésed néhány funkcióval kapcsolatban, amelyeken dolgozol. Gondolkodtál rajtuk, elemezted őket, de van egy hang a fejedben, ami folyton azt kérdezi: “De honnan tudod?”

Ez az a pont, ahol az MVP a képbe kerül – nem Steph Curry, hanem a (talán rosszul elnevezett) Minimum Viable Product.

A Lean Startup Conundrum

A “The Lean Startup” című könyvében Eric Reis zavarba ejtően újraértelmezi a “Minimum Viable Product” kifejezést, amit egy 2015-ös interjúban meg is magyaráz. Röviden:

“Néhány figyelmeztetés rögtön az elején. Az MVP a neve ellenére nem arról szól, hogy minimális termékeket hozzunk létre. Másodszor, az, hogy a definíció a maximum és a minimum szavakat használja, azt jelenti, hogy határozottan nem formulaszerű.”

Ha tehát a terméktulajdonlás világa és az agilis közösség úgy definiálta újra a Minimum Viable Productet, hogy az nem a minimum vagy termékek létrehozásáról szól, akkor mi az?

All About the Learning

Az a zsémbes hang a fejed hátsó részében, ami azon gondolkodik, hogy van-e kiút az elemzési paralízis csapdájából, amibe kerültél, és próbálod kitalálni, hogyan tudhatnád meg ténylegesen a válaszokat néhány kérdésedre, ahelyett, hogy a hamis biztonság mélyebb érzetébe elemzed magad? Itt jön a képbe a minimálisan életképes termék.

Ahol a PSI (Potentially Shippable Increment, potenciálisan szállítható növekmény) a lehetőség megteremtéséről szól, hogy potenciálisan szállítson valamilyen értéket, és az MMF (Minimum Marketable Feature, minimálisan piacképes funkció) arról szól, hogy ezeket az értékdarabokat olyan funkciók gyűjteményévé kombinálja, amelyek megoldják az ügyfelek problémáit, ott az MVP arról szól, hogy a csapat a lehető legkevesebb munkát végezze el annak érdekében, hogy lezárjon egy validált tanulási kört.

A termékfelfedezés Lean Startup módszertanában az egyik legfontosabb szokás, amelyre rá kell szokni, a hipotézisek validálása és a kísérletek létrehozása. A hagyományosan kockázatkerülő szervezetekben az a meggyőződés, hogy a bevezetés előtt ki kell elemezni a kockázatot a termékből, hosszú átfutási időkhöz és – frusztráló módon – adatokon alapuló feltételezésekhez vezet az ügyfelek vágyairól és igényeiről. Ha igazán jók vagyunk a statisztikai elemzésben, és ha igazán jó adataink vannak az ügyfeleink statisztikailag jelentős részéről, akkor elég jól meg tudjuk fogalmazni, hogy mit akarnak az ügyfeleink.

De a nap végén ez még mindig csak egy találgatás.

Az MVP-k készítésekor szándékosan csak annyi funkciót építünk, hogy fel tudjuk tenni a megfelelő kérdéseket az ügyfeleinknek – megvenné ezt a terméket? Van értelme ezeknek az ikonoknak? Frusztrálja Önt ez a munkafolyamat, vagy segít megtalálni a következő kedvenc éttermét?

Ebben a pillanatban papír prototípusokat, weboldal drótvázakat, UI mock-upokat nézegetünk; átsétálunk az utca túloldalára a bevásárlóközpontba, hogy a lehető legközelebbi embereknek megmutassuk a terveinket, csak hogy gyorsan validáljuk, hogy jó úton járunk.

A jó MVP létrehozásának varázsa azonban nem az eszközökben vagy technikákban rejlik; hanem abban a fegyelemben, hogy amikor egy weboldal hőtérképének adatait akarod elemezni, hogy kitaláld, melyik színséma működik a legjobban, akkor inkább fogj néhány filcet és papírt, vázolj fel néhány alacsony hűségű megoldást, és kérdezz meg valakit: “Ezek közül melyik tetszik jobban?”

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.