Minimum Viable Product (MVP) – Hogyan ne legyen Más Valaki Problémája?

Írta Fodor Andrea 

Bevezetés

A szakmában hallottam egy olyan gyakorlatról, miszerint az agilis csapatok dolgoznak a terméken egy jó ideje, de az nem áll össze. A vezetőség kezdi elveszteni a türelmét a sorozatos ígérgetések és újratervezések miatt, és bekeményít. Az a döntés születik, hogy ahol éppen tartanak, használatba adják, és elnevezik MVP-nek, becenevén Más Valaki Problémájának.

Az informatikában tomboló bábeli zűrzavar keretében gyakran dobálózunk szavakkal, kifejezésekkel, aminek nem biztos, hogy pontosan értjük az értelmét és jelentőségét. Ilyen például az MVP, azaz a Minimum Viable Product, illetve az MMP, azaz a Minimum Marketable Product. A jelentését érteni véljük, de vajon jól tudjuk-e alkalmazni a gyakorlatban? A válasz nem is olyan egyszerű.

MVP másvalaki problémája

A Minimum Viable Product (MVP) jelentése, definíciója:

A minimum viable product (MVP) egy termék vagy szolgáltatás legkisebb, még működőképes verziója, amely tartalmazza az alapfunkciókat ahhoz, hogy a felhasználók kipróbálhassák, visszajelzést adhassanak, és a fejlesztők validálhassák az ötlet piaci életképességét, mielőtt további időt és pénzt fektetnének a teljes fejlesztésbe. 

A Minimum Marketable Product (MMP) jelentése, definíciója:

A Minimum Marketable Product (MMP) a termék legkisebb, már értékesíthető verziója, amely elég funkciót és minőséget kínál ahhoz, hogy a piacon fizetőképes vevőket vonzzon, és üzleti értéket termeljen, miközben a későbbi verziókban további fejlesztések érkezhetnek. 

Hogyan értelmezhetők ezek a definíciók a gyakorlatban?

Mindkét definíció új termék kialakításánál, piacra dobásánál értelmezhető, mégpedig addig, amíg a termék piacra nem kerül.  

Ez pedig tiszta formájában csak B2B és/vagy B2C terméket fejlesztő, jellemzően startup cégek esetén fordul elő, integráció nélkül. Ilyen vállalati körülmények között nagyon ritkán van, vállalatoknál leginkább integrációt igénylő, nagyobb projektekről beszélünk, ahol ezek a kifejezések – bár használatuk életbevágó – teljesen más értelmet kell, kapjanak. De nézzük sorban! 

B2C termékfejlesztés

Miről is van szó? Jellemzően startup vállalkozásoknál jöhet szóba. Van egy jó ötlet, egy csapat, egy jónak tűnő üzleti modell elképzelés. Lehet egy új randiapp, vagy sharing economy szolgáltatás, webshop, vagy akár egy fintech ötlet, gyakorlatilag nulláról felépítve. 

B2C termékfejlesztés  esetén a termék gyakorlatilag csak a felhasználóknak készül, nincs belső megrendelő. Nagyvállalatoknál tiszta formájában, integráció nélkül, vagy minimális integrációval csak akkor fordul elő, ha a vállalat valami teljesen új, alaptevékenységétől eltérő alkalmazással áll elő, pl. egy bank létrehoz egy webáruházat.   

Ilyenkor a fenti definíciók tökéletesen alkalmazhatók. A cél az, hogy az ötlet piacképességéről mielőbb meggyőződjünk. A startup vállalkozók jellemzően két nagy hibát szokott elkövetni. Az egyik, amikor csak egy ötlettel lépnek a finanszírozók elé,  amit még senki nem használ, nincs róla valós visszajelzés. A másik, ha túl sokáig tökéletesítgetik a terméküket, saját elképzeléseik szerint, nagyon sok pénzt és energiát ölnek bele, anélkül, hogy meggyőződnének arról, hogy fogadja a piac az ötletüket. Az MVP és az MMP  ezeket a hibákat hivatott kiküszöbölni.  

Az MVP a termék olyan változata, amiben a képernyők, a legfontosabb funkciók már működnek olyan szinten, hogy a tesztelni megcélzott célcsoport már látja, hogyan működik, és mit fog tudni az alkalmazás, és ami által visszajelzéseket kapunk arról, hogy jó irányba megyünk-e. 

A MMP pedig már piaci használatra kész, azaz tartalmazza az alapműködéshez szükséges , valamint a felhasználó számára értékes és a termékünket megkülönböztető funkciókat is.  

Az MMP élesítésétől kezdve pedig prioritási sorrendben adjuk hozzá a termékhez az egyes funkciókat.  

B2B termékfejlesztés

Amikor B2B termékfejlesztésről beszélünk, akkor egy csapat, vagy cég ötlete nem az egyén, hanem egy másik cég számára jelent értéket. Itt már a végfelhasználó és a megrendelő elválik egymástól, tehát több szempontot kell figyelembe venni. Az érték itt nem a felhasználó, hanem a megrendelő számára képződik, úgy, hogy közben a felhasználók sem kerülhetnek hátrányos helyzetbe.  

(Nagyvállalatoknál ezt a felállást – integráció nélküli termékfejlesztés – kizárólag abban az esetben láttuk,  amikor egy anyavállalat belső terméket fejleszt a leányvállalatai számára, amit saját maga nem használ, így az integrációt a leányvállalatokra bízza, de ez – bár nem példa nélküli – elég ritkán fordul elő) 

B2B termékfejlesztés esetén a Minimum Viable Product célja az érdeklődés felkeltése, a vevő „szándéknyilatkozatának” megszerzése. Ehhez olyan szintig kell eljuttatni a terméket, ami már „mutogatható” az ügyfélnek. Amiből már el fogja tudni képzelni, és visszajelzést tud adni, hogy  ez milyen értéket jelent számára. Ezek gyakorlatilag prototípusok, amik lehetnek papír alapúak vagy digitálisak is (low or high fidelity prototypes).  

Az MMP B2B termékfejlesztés esetén pedig az a termék, ami már értékesíthető, azaz elég értéket tartalmaz ahhoz, hogy az ügyfél fizessen érte, és megkezdje a termék bevezetési projektjét, azaz a saját folyamataiba való integrálását.

MVP a B2B termékfejlesztés esetén

MVP és MMP a nagyvállalati környezetben:

A fentiekből is látszik, hogy bármennyire is erőltetjük, az MVP és az MMP fenti definíciói nem alkalmazhatók nagyvállalati környezetben, kivéve azt a fent említett  ritka esetet, amikor a nagyvállalat szoftverfejlesztő céget játszik. Ennek ellenére nagy szükség van a MVP és az MMP helyes értelmezésére, de lehet, célszerűbb lenne ezekre más kifejezéseket alkalmazni.  

Egy nagyvállalatnál a nagyobb informatikai projektek másképp zajlanak. Szerencsés megkülönböztetni a nagyobb, több üzleti területet és informatikai rendszert érintő projekteket az egyes rendszereken végzendő kisebb fejlesztési igényektől. Milyen típusú – informatikát érintő – projektjei lehetnek egy nagyvállalatnak?  

Új rendszer bevezetése – egy eddig nem létező üzleti képesség megvalósítása, vagy manuális folyamatok automatizálása. Ez lehet:  

  • új, zöld mezős fejlesztés (belső, vagy szállító által) 
  • vásárolt szoftver (B2B szoftverfejlesztőtől)  testreszabása és integrációja 

Meglévő rendszer cseréje – egy működő rendszer elavulás vagy bármilyen más okból való kiváltása. Optimális esetben együtt jár az üzleti folyamatok megváltoztatásával.  

  • új, zöld mezős fejlesztés (belső, vagy szállító által) 
  • vásárolt szoftver (B2B szoftverfejlesztőtől) testreszabása és integrációja 

Üzleti folyamatok megváltozása – jogszabályi változás, átszervezés, összeolvadás, vagy egyéb ok miatt – az informatikai rendszerek működését rá kell szabni a megváltozott folyamatokra. Ez lehet:  

  • sok kicsi, kapcsolódó fejlesztési igény 
  • nagyon ritkán új rendszerbevezetés vagy rendszercsere is kapcsolódhat hozzá 

Ezek a projektek nem csak „termékfejlesztések”, hanem egy új, vagy vásárolt termék üzleti folyamatokba illesztése. Akkor vannak kész, ha az adott rendszert az üzlet használatba vette, és a teljes érintett üzleti folyamat működik (alap funkcionalitás, könyvelés, elszámolások, kontrolling kimutatások és vezetői jelentések, követelésbehajtás, stb.) 

És itt kezdődnek a gondok, a valóságot nagyon nehéz összeegyeztetni a fenti definíciókkal. Ha megértjük az egyes lépéseket, akkor tudunk nevet is adni neki. A fontos az, hogy bárminek hívjuk, mindenki ugyanazt értse alatta.  

minimum viable product nagyvállalatnál

Miről is van szó?  

Egy projektet nem húzhatunk a végtelenségig, valamikor le kell zárni. Ehhez kell megtalálni azt a scope-ot, amit mindenképpen egyben kell leszállítani, és ami után már a felmerült problémák, új igények már a kis fejlesztések keretében tudnak megvalósulni. Ez leggyakrabban az alábbi elemeket tartalmazza:  

  • rendszeralapok (törzsadatok, szerkezet, adatbázisok, stb.) 
  • jogszabályi követelményeknek való megfelelés 
  • alapvető funkciók, ami nélkül nem értelmezhető a termék 
  • legfontosabb üzleti értéket jelentő funkciók 
  • integrációs elemek 

Gyakori az a tévhit, hogy van egy Product Owner, odaáll a fejlesztő csapat elé, és le-standupolja az ehhez szükséges product backlogot, de a valóságban ez több iterációban, fentről lefelé tervezve, rengeteg információgyűjtési és elemzési munka következtében alakul ki.  

A projekt akkor van kész, ha a felhasználók használatba vették, az új folyamatok működnek, és a projekt elfogadható módon elérte azt a célt, amiért elindították.  

Nyilván ez után is maradnak hibák, hiányosságok, a backlogban is maradt egy csomó olyan funkció, amit hátrasoroltunk, illetve a használatból fakadóan jönnek új igények is. Erre, ha nagyon indokolt, lehet  új projektet indítani, de ha kevés az összefüggés, érdemes ezeket backlogszerűen, a kis fejlesztések keretében prioritási sorrendben – az egyéb üzleti prioritásokat is figyelembe véve kezelni.  

Ezt a scope-ot hívhatjuk MMP-nek, de akár találhatunk rá más nevet is. Projektműködésben ezt általában egyszerűen scope-nak hívtuk.  

Vannak esetek, hogy a teljes project scope/MMP/hívd bárminek túl nagy és komplex ahhoz, hogy egyben valósítsuk meg. Tudvalevő, hogy ha egyben nyeljük le az elefántot, megakad a torkunkon. Tehát akkor járunk jól, ha értelmes egységekre daraboljuk fel a teljes scope-ot. Fontos hangsúlyozni, hogy ez csak az implementáció fázisolását jelenti, önállóan ezek a fázisok nem jelentenek értéket (ha jelentenek, akkor külön feladatként/projektként kellene indítani). 

A jó darabolás E-2-E üzleti folyamat mentén történik, és az eredménye – bár a projekt elvárt eredményéhez nem, vagy csak részben járul hozzá – használatba vehető a felhasználók által, illetve integrált, tehát illeszkedik az egyéb rendszerekhez, folyamatokhoz (esetleg vállalható kompromisszumokkal), a használatba vett fázisokra vonatkozóan a stakeholderek/felhasználók oktatása és szabályzatok aktualizálása megtörtént. 

Például: egy banki követelésbehajtó rendszer lecserélésekor az alábbi fázisokat lehet kialakítani:  

  • hitelkártyák behajtási folyamatának kialakítása 
  • személyi kölcsönök behajtása 
  • jelzáloghitelek behajtása 
  • vállalati hitelek behajtása 
  • egyéb hitelek behajtása 

A projekt végét az jelenti, hogy a régi rendszerből kihúztuk a dugót. Amíg ez meg nem valósul, az egyes fázisokat egymás után kell indítani .  

(Gyakran látok példát rossz darabolásra, amikor is technikai layerek mentén darabolják fel a projektet. Pl. 

  • képernyők 
  • backend folyamatok 
  • adatkapcsolatok, interfészek 
  • riportok 

Ebben az esetben az elkészült darabok nem csak nem jelentenek üzleti értéket, de nem is vehetők használatba, ezáltal nem nyerünk semmit. ) 

Tehát bárhogy is hívjuk, a projekt méretű feladatok leszállítandó terjedelménél a fentiek szerint kell eljárni. 

Mit érthetünk MVP-n? Nagyvállalatnál jellemzően nem akarjuk az ötlet piaci értékét validálni, mert ez a döntés korábban már megszületett. A Minimum Viable Pproduct alatt itt a kialakított képernyőket (prototípusokat) kezdeti verzióit tudjuk megmutatni, és ezzel kapcsolatosan visszajelzéseket tudunk gyűjteni a felhasználói stakeholder csoporttól. Azonban ebből csak UX-re illetve a felületre vonatkozó visszajelzéseket remélhetünk, az üzleti érték teljesülése kapcsán nem remélhetünk érdemi információt. 

MVP nagyvállalatnál

Összefoglalás:

A Minimum Viable Product és a Minimum Marketable Product fogalma tehát csak a B2B vagy B2C, jellemzően startup szoftvercégeknél alkalmazható. 

Nagyvállalatnál nagyon fontos, hogy mindenki pontosan értse, hogy az adott cégnél mit értünk ezen kifejezések alatt, mert biztos, hogy nem azt, amit a szakirodalomban vagy a képzéseken megtanítanak a kollégáknak. 

MVP és kapcsolódó képzések:
Product Owner képzés

Ez a gyakorlati Product Owner képzés az elméleti alapok lefektetése mellett segít eligazodni, hogy Product Owner szerepben az adott cégnél mit várnak tőled.

Product Owner képzés a gyakorlatban – variációk, ötletek, megoldások

product owner

agilitásbusiness analyst