A próba és hiba világában az nyer, aki a leggyorsabban megtalálja a hibákat. Egyesek ezt a megközelítést “fail fast”-nak nevezik. Eric Ries Lean-nek, Kent Beck és más szoftverfejlesztők pedig Agile-nak nevezik.
Bárhogy is nevezzük, a lényeg az, hogy a valós felhasználók visszajelzései révén a lehető leggyorsabban kiderítsük, hogy a termékkel kapcsolatos feltételezéseink közül melyek tévesek.
Az agilis módszertan feltételezi a termékfejlesztés sprintekre való felosztását, ami lehetővé teszi a kockázatok csökkentését és a szükséges változásokra való gyors reagálást.
Mivel az agilis módszertan a vevői visszajelzéseken alapuló iteratív folyamat gondolata köré épül, az MVP központi szerepet játszik az agilis fejlesztésben.
A minimálisan életképes termék (Minimum Viable Product, MVP) megalkotása segít abban, hogy az új termék elegendő funkcióval rendelkezzen a korai elfogadók kielégítéséhez, ami lehetővé teszi az értékes visszajelzések megszerzését, és a funkciók teljes készletének későbbi kiépítését.
A szoftveriparban leginkább a termék életképességének ellenőrzésére gyakorolják az MVP koncepciót. Ha olyan céget keres, amelyik elkészíti Önnek az MVP-t, nézze meg ezt a szoftverfejlesztő céget.
A szoftverek többségét manapság agilis módszertannal fejlesztik. Az agilis környezetben gyakran hallani a minimálisan életképes termék (MVP) kifejezést.
Ez a kifejezés egyszerűen annyit jelent: a legminimálisabb funkcióval rendelkező dolog, amit meg tudsz építeni, ami elég jól kezeli a lehetőséget a legtöbb célvásárló számára, és validálja a piacot és a terméket.
Más szóval, ha végiggondolnád az alapvető funkciót, amit az ügyfeleidnek el akarsz érni, mi az a legegyszerűbb termék, amit meg tudsz építeni, amivel elérhetik ezt a célt?
Tegyük fel például, hogy visszamész az időben, és egy újság számára készült alkalmazás első változatán dolgozol. Az alkalmazás alapvető funkciója az olvasók tájékoztatása lenne. Ezért a legegyszerűbb termék, amit létrehozhatnál, a hírek címlapjainak listája és egy gomb a frissítéshez.
A sikeres MVP kulcsa ismét az, hogy az alkalmazás által nyújtott alapvető értékre, azaz a friss hírekre összpontosítsunk, ahelyett, hogy az alkalmazás további funkcióinak kiépítésével töltenénk az időnket.
Megjegyezzük, hogy az MVP nem jelenti azt, hogy a terméknek rossznak kell lennie. Az igazság az, hogy nagyon jónak kell lennie abban, amit csinál, de csak néhány alapvető funkció elvégzésére kell összpontosítania.
Dióhéjban összefoglalva, az MVP fő jellemzői a következők:
- Elégséges értékkel rendelkezik ahhoz, hogy az emberek kezdetben hajlandóak legyenek használni vagy megvásárolni
- Elégséges jövőbeli előnyöket mutat fel ahhoz, hogy megtartsa a korai alkalmazókat
- Egy visszacsatolási hurkot biztosít a jövőbeli fejlesztés irányításához
Miért érdemes agilis módszertant használni az MVP fejlesztéséhez?
Az agilis és más módszertanok közötti legfontosabb különbség az, hogy az agilis kihasználja az MVP-ket. Az agilis megközelítéssel a lehető legegyszerűbb dolgot építi meg, adatokat gyűjt arról, hogyan használják az ügyfelek, majd szükség esetén finomítja a terméket.
Ez lehetővé teszi, hogy meglehetősen hatékonyan dolgozzon, és csak azokat a funkciókat építse, amelyeket az ügyfelek akarnak és használni fognak, ahelyett, hogy időt pazarolna olyan dolgok építésére, amelyek az ügyfeleket nem érdeklik.
Hasonlítsa ezt össze a termékfejlesztés nem MVP-alapú megközelítésével. Más megközelítésekkel a végén sok időt tölthetsz azzal, hogy megpróbálod megépíteni a “tökéletes” terméket minden elképzelhető funkcióval, de ha már kint van a való világban, rájössz, hogy az ügyfelek a felét sem használják azoknak a funkcióknak, amikről azt hitted, hogy használni fogják.
Itt van az agilis minimálisan életképes termék (MVP) példája:
Forrás: Dropbox
Drew Houston – a Dropbox vezérigazgatója úgy döntött, hogy videó formájában hozza létre a felhő-tároló startup MVP-jét.
Elkészítettek egy magyarázó videót, és megosztották a hálózatukkal, hogy felmérjék az emberek reakcióit. A 3 perces videó elmagyarázta, mi is az a Dropbox, és bemutatta, hogyan segít az embereknek.
A videó közzététele után a vállalat egyik napról a másikra 5000-ről 75 000-re növelte a “korai hozzáférés” regisztrációját – mindezt anélkül, hogy tényleges termékük lett volna.
Az MVP (agilis) építésének fő előnyei tehát a következők:
- Eredeti fogyasztói kutatás
Mennél gyorsabban jut el a termék a célfelhasználóhoz, annál hamarabb kap visszajelzést és elemzi a vásárló kihívásait vagy preferenciáit. Ha a felhasználók nem találják értékesnek az MVP-jét, akkor van tere a pivotra és a többi értékjavaslat tesztelésére.
Vagy ha az ellenkezője igaz, akkor biztos lehet benne, hogy a kifejlesztett funkciók hasznosak a célügyfelek számára, így továbbléphet. A legrosszabb esetben befagyaszthatja a projektet, hogy csökkentse a veszteségeit.
- Tesztelési szakasz
Az MVP kifejlesztésének legnagyobb előnye, hogy lehetővé teszi a különböző üzleti modellek és koncepciók tesztelését.
Azáltal, hogy a funkciókkal terhelt termék helyett az alapvető funkciókat kínálja, ellenőrizheti, hogy a termékkoncepciójuk rezonál-e az Ön üzleti modelljével, és lehetőséget biztosít arra, hogy az eredmények alapján változtasson a termék irányán.
A funkciónehéz termékekkel ellentétben az MVP bevezetésekor lehetőséged lesz azonosítani, hogy milyen típusú társadalmi csoportok a legaktívabb felhasználók, hogyan lépnek kapcsolatba a termékkel, és hogyan tudod pénzzé tenni azt.
- Költséghatékonyság
A minőségi termékek többéves fejlesztés eredményei, megfelelő árcédulával. De mivel ezek a termékek hosszabb időn keresztül iteratív módon jöttek létre, a költségek időben eloszlanak.
Az MVP-megközelítés azáltal is segít a megtakarításban, hogy megakadályozza a termék túlbonyolítását. Ahogy a termék egyre nagyobb teret nyer, és egyre több információt gyűjt a termék irányával kapcsolatban, növelheti vagy csökkentheti a befektetéseket.
Ha többet szeretne megtudni az agilis és SCRUM-módszerekről, akkor ajánljuk figyelmébe a SCRUM Institute cikkét arról, hogyan válhat SCRUM-mesterré egy részletes, lépésről lépésre bemutatott folyamatban. Ők kínálják a legnépszerűbb, és a leggazdaságosabb Scrum tanúsítási programokat is világszerte.
Az MVP építésének folyamata (Agile)
Most, ha már tudod, mi az MVP, miért használják az Agile-ban, és milyen előnyei vannak, nézzük meg az MVP építéséhez szükséges 6 lépést.
1. lépés: Határozd meg, milyen problémát oldasz meg és kinek
Az új termékek verziójának kifejlesztésekor a legtöbb ember nem elég szigorúan határozza meg a problémákat, amelyeket meg akar oldani, és nem fogalmazza meg, miért fontosak ezek a problémák. E nélkül a folyamat nélkül a termék elszalaszthatja a lehetőségeket és pazarolhatja az erőforrásokat. Éppen ezért jobbá kell válnia a helyes kérdések feltevésében, hogy a helyes problémákat kezeljék.
Nézze meg a termékötletét, és tegye fel magának a kérdést:
- Ki a célközönsége?
Ha ebben a szakaszban elakad, próbálja meg azonosítani a személyes kihívásait. Van valami, amit jobban tudnál csinálni, ha lenne megfelelő eszközöd?
- Miért van szüksége a célközönségének erre a termékre?
Ez segít azonosítani a termék fő célját és a megoldást a potenciális vásárlók igényeire.
- Milyen helyzetben használnák?
Forrás: Metabeta
Megjegyzés: A fenti kérdésekre adott válaszok meghatározása során fontos, hogy minden reális maradjon, és emellett idő- és költségbecslést is végezzünk.
2. lépés: Elemezd a versenytársaidat
Amint kitaláltad, hogy milyen problémát oldasz meg, ideje megnézni, hogy más cégek hogyan oldják meg ezt a problémát – vagy legalábbis próbálják megoldani. Ezen a ponton nyilvánvaló, hogy versenytárselemzést kell végeznie, ha vannak hasonló termékek a piacon.
Azt is szem előtt kell tartania, hogy még ha úgy gondolja is, hogy nincsenek közvetlen versenytársai, a terméke egyediségébe vetett hite megalapozza, hogy magabiztosan hozza piacra a termékét.
3. lépés: A felhasználói folyamat meghatározása, drótváz & tervezés
A leendő terméked felhasználói folyamatának meghatározása magában foglalja, hogy közvetlenül az elsődleges célodra összpontosítasz. Ahhoz, hogy meghatározzuk a fő felhasználói áramlást, először meg kell határoznunk a folyamat szakaszait, ami tulajdonképpen egyszerű, mert csak a terméked elsődleges céljának eléréséhez szükséges lépéseket kell elmagyaráznod.
Ezen a ponton nem szabad a funkciókban gondolkodnia – hanem az alapvető feladatokra kell összpontosítania, például azokra a céltípusokra, amelyeket a végfelhasználók elérnek, amikor a termékét használják, az elvárásaikra stb.
Amint végzett a felhasználói folyamatok meghatározásával, áttérhet a drótvázlatkészítésre, amely egyszerűen egy weboldal vagy alkalmazás illusztrációja. A drótváz egy olyan elrendezés, amely megfogalmazza, hogy a fontos oldalakon milyen kezelőfelületi elemek találnak majd helyet.
Példa a drótváz kialakítására:
A felhasználói felület (UI) tervezése az interakciótervezés, a vizuális tervezés és az információs architektúra fogalmait egyesíti. Itt kell hasznosítania az előző fázisokban tanultakat annak érdekében, hogy olyan élményt hozzon létre, amely meglepi és gyönyörködteti a végfelhasználót.
Itt a Cleevio-nál, amikor elkészül az első prototípus (általában kattintható mock-up), felhasználói tesztelést végzünk. A felhasználói tesztelés elengedhetetlen az új alkalmazás sikeréhez. Amikor készen vannak a felhasználói tesztelés eredményei, iteráljuk a drótvázakat, és újra teszteljük őket a felhasználókon.
A drótvázak tesztelése után tovább kell lépni a tervezési fázisba, amelynek minden platformon (iOS, Android, Web,…) másnak kell lennie.
4. lépés: elemezzük a funkciókat
Tudta, hogy a beépített szoftvertermékek funkcióinak több mint 45%-át ritkán vagy soha nem használják?
Most, hogy megalkottad a felhasználói folyamodat, elkezdheted a funkciók részletesebb listájának összeállítását az egyes szakaszokhoz, de a statisztikákat szem előtt tartva.
Mihelyt lefektette az egyes szakaszokra vonatkozó funkciókat, fontossági sorrendet kell felállítania. Mi az a legfontosabb művelet, amelyet a felhasználóidnak el kell végezniük? Ez lesz a fő funkciód.
A funkciók priorizálásának egyik módszere a MoSCoW, amely annak eldöntésére szolgál, hogy mely funkciókat kell először befejezni, melyeknek kell később jönniük, és melyeket kell kizárni. Egy másik technika, amelyet a funkciók szükségességének mérésére használnak, az üzleti értéken alapul (fejlesztési idő vs. nice to have vs. költségek)
Source: ProductPlan
5. lépés: Fejlesztés & Tesztelés
Most, hogy ismered a minimálisan életképes terméked (MVP) jellemzőit, itt az ideje, hogy a gyakorlatban is megvalósítsd őket. A fejlesztési szakaszba lépve tesztelnie kell a termékét, és dolgoznia kell a minőségének javításán.
A drótvázak jóváhagyása után el kell kezdenie dolgozni a beállítási architektúrán, az adatbázison, és el kell kezdenie az API, az adminisztráció és az összes back-end fejlesztését.
Az alfa- és béta-tesztelés segíthet ebben, mivel ez az egyik legnépszerűbb módja a termék teljesítményének tesztelésének különböző forgatókönyvekben. Ügyeljen arra, hogy a tesztelést összehangolja, és csak azokat a változtatásokat hajtsa végre, amelyek a teljes felhasználói élményt befolyásolják.
Az alkalmazás elindítása előtt alapesetben a következő teszteket kell végrehajtania ellenőrzött környezetben:
- Funkcionalitás tesztelése
- Használhatósági tesztelés
- Kompatibilitási tesztelés
- Tömegtesztelés
- Interfész tesztelése
- Teljesítménytesztelés
- Biztonsági tesztelés
A fejlesztési folyamat során folyamatosan tesztelnie kell az összes megvalósított funkciót.
Itt a Cleevio-nál például mobilalkalmazásokat készítünk, és a béta buildek kiadásait feltöltjük a Google alfa/béta tesztelésére és az Apple TestFlightjára. A belső tesztépítések az Appcenterben vannak (a Microsoft hivatalos eszköze).
Amikor a “release candidate” (a piacra kész termék) készen áll, nyílt vagy zárt béta tesztelést végzünk, ahol minél több releváns felhasználót meghívunk a béta tesztprogramba, és visszajelzéseket gyűjtünk a funkcionalitásról és a hibákról.
6. lépés: Iteratív úton eljutni a termék-piaci illeszkedésig vagy kudarcig
Ha validálta az MVP-t, elkezdheti vizsgálni a termék terjedelmét és bővíteni. Ezen a ponton vagy induló tőkét veszel fel, hogy gyorsabban piacra tudj lépni, vagy elbuksz.
Mobilalkalmazások esetében általában “puha bevezetést” végzünk, amikor az MVP-t az AppStore-ba és a Google Play-be tesszük, de ekkor még nem ösztönözzük az alkalmazás marketingjét.
Amint az alkalmazás egyre több felhasználót kap, néhány hiba felbukkanhat, és biztosak vagyunk benne, hogy mindent minél előbb kijavítunk. Általában kétnaponta adunk ki új buildeket. Amint az alkalmazás stabil, és az összeomlásmentes felhasználói arányunk meghaladja a 99,9%-ot, javasoljuk, hogy kezdjük el a marketinget és szerezzünk több felhasználót.
Az adatok nagyon fontosak, ezért javasoljuk a felhasználók viselkedésének nyomon követését Mixpanel vagy Google Firebase analitikával, hogy megértsük, hogyan használják valójában a felhasználók az alkalmazást.
A termék fejlesztése soha nem fejeződik be. Nagyon fontos, hogy kikérjük a felhasználók visszajelzéseit és iteráljuk a terméket. Amikor több felhasználóval rendelkezünk, A/B tesztelést végzünk, hogy különböző megoldásokat tesztelhessünk és növelhessük a felhasználók elkötelezettségét.
Forrás: A Cleevio-nál az elmúlt 10 évben több mint 120 MVP-t fejlesztettünk ki, így elég tapasztalat van a tarsolyunkban ahhoz, hogy tudjuk, mely MVP-k skálázódnak, és melyek égnek és halnak meg.
Tudjuk, hogy egy kicsit megterhelő elkészíteni egy útitervet, dokumentációt vagy drótvázakat az MVP ötletéhez, ezért nyugodtan forduljon hozzánk, és mi szívesen adunk néhány ingyenes tanácsot.
Az MVP-jével kapcsolatos tanácsadásért írjon nekünk e-mailt a [email protected] e-mail címre.