Hagyj fel előítéleteiddel, és tudd meg, hogy a sikeres vállalatok miért fogadják el az MVP-t, mint az ügyfeleik boldoggá tételének kulcsát.
By Arbi Vartan and Jeff Brinkerhoff
Slalom loves Agile. Izgatottak vagyunk azok miatt a valós, mérhető előnyök miatt, amelyeket a vállalkozások ebből nyertek, és a legnagyobb előnyeiről egy sor blogbejegyzésben és egy ingyenes agilis webináriumban beszélünk – nézze meg lekérésre.
Az MVP, vagyis a minimálisan életképes termék az agilis gyakorlat alapvető eleme. És egyben olyasmi is, ami ellenállást vált ki. Hallottuk már ügyfeleinktől olyanokat, mint például: “A vezetőink nem a minimumot akarják – a lehető legjobb minőséget akarják”. Valóban, miért ne akarnánk a legjobbat nyújtani? Ez egy nagyszerű kérdés, de az MVP félreértésén alapul.
A 2001-ben Frank Robinson által megalkotott és Eric Ries által a Lean Startup című könyvében népszerűsített MVP a világ minden táján a jól teljesítő termékcsapatok egyik alappillérévé vált. Miért volt a Google ilyen sokáig ilyen domináns? Miért az Apple gyártja a világ legnépszerűbb termékeit? Miért sikerült a Netflixnek nemcsak túlélnie, hanem az eredeti üzleti modelljén túl is virágoznia? Sok tényező hozzájárult ehhez, de egy közös pont van: mindannyian az MVP-t használják.
Szóval, mi az MVP? Íme Eric Ries definíciója:
Amint ez a definíció világossá teszi, az MVP nem egy olyan termék, amely a lehető legkevesebb, a nyilvános bevezetéshez szükséges funkcionalitással rendelkezik. Egyáltalán semmi köze a termék nyilvános kiadásához. Az MVP inkább a tudományos módszer használatának kulcsa a terméképítésben. Ez pusztán a validált tanulás mechanizmusa, amelyet a hipotézisek tesztelésére és annak felfedezésére használnak, hogy mi felel meg az ügyfelek igényeinek.
Hagyja a kifejezést, ha kell, de tartsa meg a koncepciót
A Slalomnál az MVP koncepcióját integráltuk mind abba, ahogyan termékeket építünk a vállalatok számára, mind abba, ahogyan együttműködünk velük, hogy kihasználják az agilis elvek és gyakorlatok üzleti modelljükbe való beépítésének előnyeit. Azonban – több mint húsz vállalati agilis átalakítás és több száz iparági partnerség után – azt tapasztaltuk, hogy néha egyszerűbb, ha nem erőltetjük az olyan kifejezések használatát, mint az MVP. Néhányan áttértek a “Minimum szerethető termék” kifejezésre, Henrik Kniberg (aki leginkább a Spotify mérnöki kultúrájával kapcsolatos munkájáról ismert) pedig az Earliest Testable, Earliest Usable és Earliest Lovable Products kifejezések használatát javasolja.
Ezek közül bármelyik kifejezés megfelel. Az agilis a boldogabb, produktívabb csapatokról szól – nem a terminológiáról. A mi megközelítésünk ezzel vagy bármely más félreértelmezett, nem egyértelmű Agile-fogalommal kapcsolatban az, hogy kihagyjuk a szót, és feltesszük a következő három kérdést:
- Miért csináljuk? Az MVP esetében a gyors tanulásról van szó, valamint az alapelvekről: az ügyfélelégedettségről, a folyamatos fejlesztésről és az egyszerűségről.
- Mi kellene ahhoz, hogy az én cégemnél ez megvalósuljon? Ó, a keretezés ereje! Ahelyett, hogy azt kérdeznénk, hogy meg tudja-e csinálni, inkább a blokkoló tényezőkre – szervezeti vagy egyéb – koncentrálunk. Az erre a kérdésre adott válasz gyakran a mozdíthatatlannak hitt egyének beleegyezésének formáját ölti.
- Mi lenne, ha nem tennénk meg? Egy másik keretezési stratégia: összpontosítson a status quo fenntartásának költségeire. Ez sürgető érzést kelthet, és összhangot teremthet egy új munkamódszerrel.
Itt egy történet a status quo veszélyeiről: Egy vállalat projektje, amellyel nemrégiben együtt dolgoztunk, hat hónapot töltött egy nagyobb szoftverkiadással, amely több mint 200 belső felhasználót érintett. Bezárkóztak egy szobába, és befejezték az építést és az összes tesztelést. És csak ezen a ponton kértek visszajelzést egy maroknyi üzleti elemző helyettesétől – nem pedig a tényleges felhasználóktól. Ez a fajta checkbox tevékenység, túl későn ahhoz, hogy valódi hatást gyakoroljon, és anélkül, hogy valóban a validált tanulásra összpontosítana, aligha minősül visszajelzéskérésnek. Ez valójában egy kísérlet az elkerülhetetlen érvényesítésére.
Az eredmény előre látható volt. Mivel már annyi időt és pénzt költöttek, kénytelenek voltak továbblépni, és mind a 200 felhasználó elutasította az új szoftvert a lassú teljesítmény és a használhatóság hiánya miatt. Hat hónapot és több mint 12 millió dollárt költöttek el, és csak ujjal mutogattak egymásra az üzleti és a technológiai csapatok között.
Most képzeljük el ugyanezt a forgatókönyvet egy MVP-vel, amelyet a projekt korai szakaszában a végfelhasználók egy csoportja számára telepítettek. A fejlesztők azonnal megtanulhatnák, hogy mit rontottak el, majd további MVP-ket telepíthetnének, mindegyiknél iteratív módon javítva, egészen a valódi felhasználókkal közösen fejlesztett és általuk jóváhagyott végleges termék bevezetéséig. További előny: a tesztcsoportban lévő felhasználók alaposan belevetették magukat a projektbe, és evangelizálnák azt társaik körében.
Mi pontosan ezt a forgatókönyvet láttuk megvalósulni, és ezért hiszünk szilárdan az MVP-ben – bárhogy is nevezzük azt.