Czigola Gábor ∗
4. A legszűkebb értelemben vett termék (LÉT / MVP)
Amikor ötletünk megvalósításába kezdünk, ill. az ahhoz kapcsolódó tervezési fázis során, törekedjünk a legszűkebb értelemben vett termék (MVP - minimum viable product) előállítására. Ez azt jelenti, hogy azt, és csak azt fejlesszük le, csak arra fordítsunk erőforrást, ami az ötletünk apavető magját képezi (core principles).
Például a vanmit.hu esetében ezek a kereskedelem, a lokalitás és a bizalom volt. Ez azt implikálta, hogy szükségünk van 1) új eladás indítására 2) vásárlás lehetőségére 3) térképen listázni, szűrni az eladásokat 4) felhasználói profilra (ez utóbbi már vitatható, mert az oldal a közvetlen, nem postai értékesítésre szolgál, a bizalom az üzenetküldés és személyes találkozás során is megteremthető) .
Minden egyes funkciót és fejlesztést meg kell kérdőjelezni ebben a fázisban, hogy tényleg szükség van-e rá? Nem az a kérdés, hogy jó ötlet-e, hogy hasznos lenne-e, hogy szeretnék-e, hogy van-e létjogosultsága, hogy zseniális-e, hanem hogy tényleg használhatatlan lenne-e a termék ha kihagyjuk, tényleg helyettesíthetetlen-e, tényleg nélkülözhetetlen-e?
Minden egyes másodperc, amit egy kihagyható, helyettesíthető, nél-külözhető képesség fejlesztésére telik elvesztegetett erőforrás. Hiába hasznos, hiába jó ötlet, hiába szeretnénk. Más, valóban feltétlenül
szük-séges képesség fejlesztésétől veszi el az erőforrást. Ha működni tud a termék nélküle, nincs rá szükség a termék életképességének bizonyítá-sához. Ha már egyszer a termék beindult, úgyis lesz kapacitásunk új képességeket fejleszteni, és akkor sokkal több információnk lesz, hogy a prioritásokat jól határozzuk meg.
5. Megvalósítás
Az eddigiek során meghatároztunk egy megvalósítandó ötletet, ami egy meghatározott célközönség meghatározott problémájára fog megoldást adni. Először üzleti terv készült (szembeállítva a kiadásokat és bevételeket, szükséges befektetést, várható nyereséget), majd ha a megvalósítás mellett döntünk, megvalósítási tervet (product plan) készítünk. Ez már technikai jellegű, tartalmazza:
• domén modell (domain design)
Definiálja az entitásokat, adattípusokat, a szolgáltatások interfé-szét valamint az elemi műveleteket. Miközben ezek meghatározásra kerülnek, a fejlesztők és üzleti résztvevők között sok kommuni-káció szükséges, ennek pozitív hozadéka egy egységes nyelvezet kialakulása.
• megvalósítási architektúrát (implementation architecture) A domén modellre épülve meghatározandó, hogy milyen fejlesztői eszközöket, platformot, keretrendszereket, programkönyvtárakat és tervezési mintákat használjunk. Mik az integrációs pontok és hogyan garantáljuk a nem-funkcionális követelményeket.
• grafikai terv
Hogyan néz ki a termék? Milyenek az átmenetek? Hogyan mutatja a hibákat? Milyen a szín és formavilága? Milyen ikonokat és képi elemeket használ?4
• fejlesztési és szállítási terv és infrastruktúra (development and release plan and infrastucture)
4Személyes tapasztalatom az, hogy kerülendő a .psd/.pdf formátumban szállítani ezt, mert helyet ad az interpretációnak és a részletek leplezésének. Ajánlott a termék végső formátumában kérni ezeket, weboldal esetén például egy html/css template-ben.
Megválaszoljuk, hogyan fog(nak) a fejlesztői csapat(ok) dolgozni, hogyan lesznek képesek folyamatosan szállítani (continuous de-livery), hogyan fogunk tesztelni, hogyan fogunk élesbe menni.
Egyrészt folyamatokat és infrastuktúrális követelményeket kell megadni, másrészt az integrációs pontok fejlesztői és tesztelői változatát.
• minimum képességek (minimum features)
A legszűkebb értelemben vett termék a legszűkebb értelemben vett képességekkel, és csak azokkal kell rendelkezzen. Ezek lényegében funkcionális követelmények csoportosítása. Amennyiben agilis módszerrel fejlesztünk (pl. scrum, kanban) akkor ezek lényegében sztorik vagy taszkok, amivel a fejlesztést majd elindítjuk.
Ezen a ponton fontos fejben tartani, hogy a legtöbb startup csak nagyon kis mértékben innovál, valójában már meglévő lehetőségeket csomagol be, tesz egyszerűbbé, könnyen elérhetővé. Ezt tükrözze a megvalósítási tervünk is, tehát használjunk nyílt forráskódú és szabad szoftvereket, nyílt, felhő alapú szolgáltatásokat. Licenszekre és infrastruktúrára költeni ebben a fázisban jelzésértékű, rossz értelemben.
Hasonlóan fontos szem előtt tartani, hogy a valódi termék nem a terv, nem a dokumentáció, nem az infrastruktúra és nem a szoftver.
A valódi termék a felhasználói élmény! Számtalan projekt hasalt el a döntésképtelenség és a végtelen refaktorálások feneketlen vermében, nevük is van e jelenségeknek, íme néhány:
• bearanyozás (gold plating)
A fejlesztés során újabb és újabb javaslatokkal állnak elő, hogyan lehetne még jobban csinálni, alapvető tervezési döntéseket felülírva, és egyébként üzleti szempontól jelentéktelen vagy amúgy is jól működő részek refaktorálását megkövetelve. Ha van kézenfekvő megoldás, ne keressünk tovább még tökéletesebbet. Ha van egy működő megoldás, ne akarjuk a
”újabbra” és
”modernebbre”
cserélni. Ha üzleti szempontból nem bír jelentőséggel, nem szabad időt pazarolni rá. Természetesen törekedni kell a legjobb döntésekre, de egy döntés megváltoztatása mindig költséges, megalapozott nyereség nélkül ne vágjunk bele. (cost/benefit analysis)
• analízis-paralízis (analysis paralysis)
Gyakori, hogy a döntéshozók nem akarnak, nem tudnak vagy nem képesek döntéseket hozni. Ki kell tudni kényszeríteni ezeket. Ha van több megoldás, mindig éljünk a legkézenfekvőbb választásával.
Nem ördögtől való akár egy dobókockát segítségül hívni. Egy termék nem attól lesz sikeres mert ilyen vagy olyan adatbázis rendszerrel, ilyen vagy olyan perzisztencia réteggel, ilyen vagy olyan MVC keretrendszerrel működik. Az sem ritka, hogy valaki puszta fontoskodásból akadékoskodik, szervez véget nem érő megbeszéléseket, követel senkinek sem kellő dokumentációkat, miközben a döntés valójában üzleti szempontól nem releváns. Ha mi se tudjuk jobban, bízzuk inkább a fejlesztőkre, mintsem hogy akadályozzuk a haladást.
• túltervezés (overengineering)
Egyrészt akkor jelentkezik ha valaki mindent a kezében szeretne tartani, mindenben kritikus problémákat vél felfedezni, másrészt ha mindenre saját megoldást, saját tervet követel. Ezeket mégse képes időben leszállítani, vagy ha le is szállítja mégse kapunk teljes megoldást, vagy igazából nem is látjuk mi a valójában a probléma.
Ez gyakran néhány személy hozzá nem értésének az eredménye akiktől meg kell vonni a döntési jogkört.
• túlabsztrahálás (overabstraction) Jellemzően folyamatos spekuláció (
”mi lesz ha”) és megalapozatlan nagyvállalati tervminták hozadéka. Ha egy interfésznek csak egy implementációja van tervben, ne készítsünk interfészt, csak implementációt. Ha egy alkalmazásrétegnek nincs üzleti célja, ne hozzuk létre. Ha egy funkció nem megalapozott tervbe vett felhasználói esettel, ne implementáljuk. Legyünk rendkívül kritikusak és törekedjünk a szigorú minimumra, a spekuláció csak kifogáskeresés.
Ezeket követve sikeresen szállítjuk le termékünket a nagyközönség elé. Fontos pillanat ez, hisz minden a puding próbája az evés (dogs gonna eat dog food). Ezek során a fejlesztésről átkerül a hangsúly a marketingre, ami nem tárgya e írásnak. Annyit megemlítenék, hogy ez nem triviális és nem technikai terep, szakértelmet és odafigyelést igényel. Végtelen pénzt lehet marketingre elkölteni, eredmények nélkül, és kicsi pénzből
is lehet jó marketinget csinálni. Ajánlásom, hogy lényegesen több pénzt költsünk marketingre mint fejlesztésre, ne kövessük el azt a hibát, hogy a sivatag közepére építünk áruházat5. Ha nem marad pénzünk és nincs valódi (nem spekuláción, közhelyeken alapuló) marketing tervünk a termékünk felhasználókhoz való eljuttatására, nem sok esély van a sikerre6. Tapasztalatom szerint a
”jó bor eladja magát” inkább városi legenda mintsem marketing valóság. (Persze szűk, alaposan ismert célközönség esetén igaznak tűnhet, hisz pl. egy kis faluban mindenki mindenről tud, a termék szájról-szájra terjed.)
6. Konklúzió
Sikeres szállítás után a terméket birtokba veszik a felhasználóink.
Ismét idézzük fel, a valódi termék maga a felhasználói élmény. Mérések és metrikák segítenek ebben a fázisban, hogy megértsük valójában milyen élményt is nyújt a termék. Ezek segítségével elkerülhetjük, hogy saját prekoncepcióink áldozatává váljunk. Gyakori, hogy a felhasználók egy része (vagy egésze) máshogy fogja fel, máshogy értelmezi a funkciókat, mint ahogy mi hisszük, elképzeltük, megterveztük, megvalósítottuk.
Nehezíti a felismerést, hogy mi hónapokon keresztül dolgoztunk és mélyen belénk ivódott egy konkrét nézet, ismeret és felhasználás, míg a valódi felhasználók tabula rasa, először találkozva a termékkel, teljesen eltérő képet kaphatnak. Léteznek eszközök, hogy időben felismerjük és reagáljunk az ilyen helyzetekre:
• vakteszt (hallway usability testing)
Mutassuk meg a kész vagy félkész terméket véletlen kollégáknak, ismerősöknek teljesen váratlanul és minden magyarázat nélkül.
Értik? Felismerik? Tudják használni? Ezt megtehetjük már a tervezési folyamat során egy prototípuson vagy félkész fejlesztői változaton is, így időben értesülünk problémákról, félreértések-ről; szükséges módosításokat időben eszközölhetünk. (Általános igazság szoftverfejlesztés során, hogy egy hibás döntés és a hiba
5Avanmit.huesetében ez történt, nagyon kevesen tudnak a létezéséről, nincs meg a működéshez szükséges kritikus tömeg.
6Avanmit.huesetén elmondható, kis túlzással, hogy nem volt marketing tervünk.
A közösségi oldalakon bohóckodás, és néhány fizetett hirdetés messze nem váltotta be a reményeket. Próbálkoztunk fizetett marketingesekkel is, akik maguk sem rendelkeztek jobb tervvel.
korrekciója között lévő időbeli távolsággal exponenciálisan nő a javítás költsége.)
• látogatottság (visitor analytics) Hány oldalletöltésünk van na-ponta? Hány egyedi látogatónk van? Mennyi az átlagos új egyedi látogató? Melyek a leglátogatottabb oldalak? Milyen régiókból jönnek? Milyen eszközöket (user agent) használnak? Milyen csa-tornákból érkeznek (hirdetések, közösségi oldal, blogok, keresők, közvetlen látogatók)? Meddig maradnak az oldalon? Milyen arány-ban hagyják el az oldalt (bounce rate)? Milyen utat járnak be tipikusan az oldalon?
• kulcsszó analitika (keyword analytics)
Milyen kulcsszavakkal lehet rátalálni a termékünkre? Milyen oldalak linkelnek ránk? Keresőkben az oldalunk megfelelően és releváns információkkal jelenik-e meg? Kihasználunk-e minden SEO technikát nemcsak a főoldalunkon de az aloldalakon is?
• konverzió (conversion)
Ez a metrika különösen értékes mert a bevételek becslését is lehetővé teszi. Ezzel azt mérjük, hogy egy adott üzletileg (és potenciálisan bevételileg) releváns lépéssorozatot hányan követnek végig ill. hányan hagyják el. Például az oldalra látogatók közül hányan regisztrálnak? A regisztrálók közül hányanvásárolnak (ide helyettesítsünk be bármilyen a termék által nyújtott üzletileg releváns funkciót, pl. üzenetküldés, keresés)? Milyen korreláció van csatornák és funkciók között? (Lehetséges pl. hogy egy reklámkampányból sok látogató érkezik, de alig regisztrálnak!)
• A/B teszt (A/B testing) Ez a metrika a saját prekoncepcióinkat validálja. Úgy működik, hogy a felhasználóknak véletlenszerűen máshogy teszi elérhetővé ugyanazt a funkciót. Például más bejelentkezési, regisztrációs felületet ad. Lehet ez apró különbség (szín, megjelenés) de jelentősebb is (egy vagy több lépéses, egyszerűsített formok, extra validációk, mint captcha kihagyása, más aggregált nézetek mutatása). Ezek az un. A/B variánsok, melyeknek a konverzióit külön-külön mérve megismerhetjük felhasználóink értelmezését, szokásait, preferenciáit. Vegyünk itt figyelembe korrelációt más dimenziókkal. Például ugyanarra az
A/B tesztre más régió (US/EU), más eszközök (mobile/desktop) felhasználói más eredményt produkálhatnak.
• Kapcsolat, PR Hasznos visszajelzéseket kaphatunk közvetlenül felhasználóinktól. Érdemes egyszerűen, regisztráció és e-mail cím megadása nélkül elérhetővé tenni kapcsolat és hibajelentés funkciókat. A termék által küldött e-maileket ne egy noreply, hanem egy kapcsolat e-mail címről küldjük.
Az Internet egy gyorsan mozgó célpont, így gyorsan kiderül, hogy megfelelő célközönséggel sikeresek lehetünk-e vagy sem.7
7. Utószó
Siker esetén nincs más dolgunk mint hátradőlni. Ez se tarthat sokáig, fontos kérdések várnak minket a jövőben. Hogyan skálázzuk az termékünket, kiadásainkat, bevételeket? Hogyan bővítsük piacunkat?
Milyen befektetések, fejlesztések hoznák a legnagyobb növekedést?
Különösen nagy siker esetén fenyeget a veszély, hogy áldozatává válunk ennek. Ekkor fontos, hogy megbízható és kompetens emberekkel vegyük magunkat körül, ne pedig keselyűkkel, és magunk se üljünk elefántcsonttoronyba. Tapasztalt technikus a sikertől nem válik jó üzletemberré.
Sikertelenség esetén se csüggedjünk. Egyrészt ne adjuk fel mielőtt nem veszítenénk (dont’t give up before you fail), másrészt ne is erőltessük azt, ami nem működik (Einstein szerint a hülyeség definíciója az, amikor ugyanazt cselekedjük újra-meg-újra mégis más eredményt remélve.) Ne felejtsük el levonni a következtetéseket sem, egy jó tudós mintájára, akinek a negatív eredmény is eredmény. Ha veszítünk, sose veszítsük el a tanulságot. (If you lose, don’t loose the lesson.) (Többet tanulhatunk
7Avanmit.huesetében a siker egyelőre elmaradt. Nem tartottuk be az MVP szabályait, jelentős erőforrásokat pazaroltunk lényegtelen dolgokra (pl. cégalapítás, képszerkesztés funkció, aukció és extra opciók). Túl sokáig fejlesztettünk, től későn kaptunk visszajelzést. A fejlesztés túl sok iteráción ment át, rögtön reszponzív, mobil kompatiblis designnal kellett volna kezdenünk. Az erőforrások jelentős részét a fejlesztés felemésztette, nem maradt lényegében marketingre, az oldal ismeretlen. Nem határoztunk és céloztunk meg egy kellően szűk célközönséget. Jelenlegi üresjáratot arra használjuk, hogy egy új, leegyszerűsített MVP koncepcióval álljunk elő az év végére.
egy sikertelen vállalkozásból, mint egy drága de tisztán elméleti MBA képzésből.) Bátorítson minket az a tény, hogy tízből kilenc startup kudarcba fullad. Szilícium-völgyi mondás: ha kétszer nem buktál eddig legalább, akkor nem is lehetsz sikeres. (Bukott startupokat ne féljünk feltüntetni CV-n se.) A bukás lehetőséget tartsuk szem előtt kezdetektől:
ha nem tartjuk lehetségesnek a bukást, ha nem buknánk büszkén és szívesen a csapatunkkal, ha nem számolunk eleve a teljes tőke potenciális elveszítésével, azt ajánlom, inkább bele se vágjunk.
Mindezek fényében szeretnék mindenkit arra bátorítani, hogy merje megvalósítani ötleteit, álmait. Mire való az élet, ha nem erre? Több beszélgetésben is volt részem, ahol egy tervet bemutatva valaki azt mondta, igen, erre én is gondoltam évekkel ezelőtt, de semmit sem tettem érte. Olyan időket élünk ahol startapok milliárdokat érnek, például az Instagram egy milliárd dolláros felvásárlásakor összesen 13 munkatárs és 9 befektető osztozott a pénzen. Nagy cégek jellemzően a meglévő pozícióikból élnek (oligopólium), nem jellemző, hogy képesek innovációra.
Az Interneten piacra lépni nagyon alacsony költséggel, befektetéssel jár, csak saját magunk vagyunk a lehetőségeink korlátja, ugyanakkor a startupok szabályai a hagyományos vállalkozásokra, befektetésekre is igazak. Ne hagyjuk, hogy életünk meg nem valósított álmaink könyvévé váljon.
Hivatkozások
[1] Széchenyi I.,Hitel,http://mek.oszk.hu/06100/06132/
[2] B. Aulet, Disciplined Entrepreneurship: 24 Steps to a Successful Startup, 2013.,http://www.amazon.com/gp/product/1118692284 [3] S. Sinek,Start With Why,
https://www.youtube.com/watch?v=sioZd3AxmnE&sns=em [4] Amir,The Stanford Startup and the MIT startup, Reconfigurable
Computing blog, November 5, 2013.
http://fpgacomputing.blogspot.sg/2013/11/the-stanford-startup-and-mit-startup.html
[5] B. Aulet, Our Dangerous Obsession with the MVP, Techcrunch, March 1, 2014.
http://techcrunch.com/2014/03/01/our-dangerous-obsession-with-the-mvp/
[6] Wikibooks,Introduction to Software Engineering.
http://en.wikibooks.org/wiki/Introduction_to_Software_
Engineering