Amennyiben most készülünk webes- vagy mobilalkalmazás fejlesztésére, akkor előzetesen legyen kristálytiszta elképzelésünk a bevételszerzés módjáról. Azaz validáljuk az ötletet, a fejlesztés során pedig alkalmazzuk a lean szemléletet. Első körben a minimum viable product megteremtése legyen a cél, majd a piaci igényekhez alkalmazkodva haladjunk előre a folyamatban.
Többek között erről beszélgetett Varga Csaba, az Inflex Stúdió vezetője Gangel Péterrel, a webes- és mobilapplikáció fejlesztéssel kapcsolatban:
Hogy vagy, miként telnek a napjaid mostanság?
A hétfők nálunk mindig izgalmasan telnek, mivel a heti feladatok összegyűjtése mellett lezárjuk a múlt heti teendőket is. Mivel most a teljes csapat home office-ban van, ezért még több koncentrációra van szükség jelenleg. A folyamatos kommunikációt még szokni kell egyébként, akár szóban, akár írásban. Természetesen hoztunk erre megoldásokat, ugyanakkor fokozottabb figyelmet igényel mindez a részünkről is.
Az írásbeli kommunikáció kapcsán kialakítottunk egy megoldást, erről egyébként született is egy cikkem. A virtuális irodánk lényegében a Discord platformjára épített irodakomplexumnak felel meg, ahol úgynevezett szobákat hoztunk létre. Ha valaki beszél, akkor a másik egyből tud rá reagálni. Abszolút jól funkcionál, és kölcsönöz egyfajta közösségi erőt a működésünknek.
Tisztába tudjuk egy kicsit tenni az alkalmazásfejlesztéssel kapcsolatos fogalmakat? Neked például mi jut eszedbe az applikáció szóról?
Azt vettem észre én is, hogy a szó a legtöbb embernél mobilapplikációt jelent. Ugyanakkor a ma alkalmazott technológiáknak köszönhetően egy applikáció igaz lehet akár egy webes, vagy adminisztrációs felületre is.
Most sokan gondolkodnak az alkalmazásfejlesztésben. Mi az első és leglényegesebb pont, amit cégvezetőként mindenképpen tisztázni kell előzetesen?
Személy szerint én is sok pénzt vesztettem már azért, mert bizonyos lépéseket kihagytam, és mindenféle piackutatás és előkészület nélkül elkezdtem fejleszteni. Az utóbbi néhány évben már körültekintőbben járunk el.
Más-más hozzáállást kívánt egy profitszerzéssel, illetve egy problémamegoldással és társadalmi felelősségvállalással kapcsolatos ötlet kivitelezése. Egy ötlet kapcsán mindig az első és legfontosabb kérdés, hogy honnan lesz pénzünk belőle? A legtöbb elképzelés egyébként már ennél a pontnál elvérzik.
Ha megvan a pénztermelés várható módja, akkor validálásra lesz szükség. Ennek a legegyszerűbb módja egy Google kérdőív kiküldése a potenciális célcsoportnak. Az okosan felépített kérdőívvel nemcsak az ötletet tudjuk validálni, hanem egyből értékes felhasználói visszajelzésekre lehet szert tenni.
Fontos azzal is tisztában lenni, hogy miként fogjuk megvalósítani az alkalmazás fejlesztését rövid- és hosszútávon. Amennyiben elegendő tőke áll rendelkezésre, úgy könnyebb lehet a helyzet. Hogyha kockázati tőkét szeretnénk bevonni, akkor pedig még fontosabb lesz kristálytisztán validálni az ötletet.
Miként lehet a legnagyobb körültekintéssel végezni a validálást abban az esetben, ha egy cég a termékének/szolgáltatásának a megmentését várja az applikációtól?
Mindig azt javaslom, hogy a lehető legrosszabbra kell számolni, emellett pedig minimum termékkel kell elindulni. Nulláról indulva tehát a legkevésbé pozitív eshetőségre kell készülni, egyúttal minimális összeget kell az appra fordítani.
Kulcsfogalom lehet a „minimum viable product” /MVP/. Ez egy olyan termék, amivel megvizsgálható, hogy a fő funkció mennyire működik a felhasználók esetében. Érdemes egyébként óvatosnak lenni, mert könnyű „túltolni”, vagyis ilyen-olyan funkciókkal kiegészíteni az MVP-t is. Le kell írni a projekt során teljesítendő legfontosabb célt, és az egész csapatnak ezt az irányt kell követnie.
Még egy kulcsfogalom a prototípus, amibe kevesebb munkaórát kell beletenni, és a majdani termék grafikus megjelenítésének felel meg. Ennek segítségével is validálni lehet, hogy a felhasználók értik és használják-e a kitalált terméket.
Itt jön képbe egy újabb kérdés, mégpedig az, hogy az ötletünk problémát old meg, vagy egy generált problémára ad megoldást. Iszonyatosan kell figyelnünk arra, hogy jól mérjük fel a piaci igényeket, és tényleg valós problémára kínáljunk megoldást.
Mi történik akkor, amikor világossá válik, hogy a fejlesztés több hónapon át tartó, hosszadalmas projekt lesz?
Amikor validáltuk az ötletet és bizonyítást nyert, hogy sikeres tud lenni, akkor még rengeteg irányba el lehet indulni. Amennyiben elegendő tőke áll rendelkezésre, akkor természetesen lehet szépen haladni előre.
Tőke hiányában, ugyanakkor a bizonyítottan működő MVP birtokában egy bizonyos szint után külső segítségre lesz szükség. Amikor egy ötlet kezd beindulni, akkor azt meg kell nyomni, mert ilyenkor könnyen meg tudnak minket előzni.
Ha kicsit robbanunk, akkor azt csak kis körben lehet érzékelni, nagy robbanásnál ugyanakkor nem lehet ellopni magát az ötletet. Tőke hiányában tehát érdemes lehet kockázati tőkét bevonni.
A fejlesztési időintervallumok kapcsán szerinted milyen etapokban gondolkodhatunk cégvezetőként?
Szerintem egy egész éves fejlesztést nem lehet megtervezni. Már csak a lean szemlélet miatt sem tudhatjuk ugyanis egy évre előre, hogy hol szeretnénk majd akkor tartani. A lean szemlélet egyébként lényegesen hasznosabb, és rengeteget lehet rajta keresztül spórolni.
Kisebb etapokban érdemes tehát gondolkodni, majd utána ismét validálni az irányokat, szükség esetén pedig módosítani a megvalósítani kívánt elképzeléseket.
A minimum viable product alkalmazása nem rejti magában azt a kockázatot, hogy egy hibás termék kerül ki a piacra?
Fontos tisztázni, az MVP nem azt jelenti, hogy a termék hibás. Az MVP egy jól kitesztelt alkalmazás, amely csak néhány funkciót tartalmaz. Ezek ugyanakkor 100%-ig működnek, és ki vannak tesztelve. Hibás terméket már csak tiszteletből sem teszünk ki a felhasználóknak.
Fontos tudni rólatok, hogy többek között a Decathlon applikációját is ti csináljátok. Mesélsz erről a projektről egy kicsit?
A Decathlon esetében mi csináltuk az IOS és Android alkalmazást, illetve a teljes felhasználói élmény tervezését is az appnak. Ez egy 3,5 hónapos projekt volt, és kicsit több mint egy éve adtuk át éles használatra.
A rövid határidő miatt pörgetni kellett, ugyanakkor jól látszik, hogy nem feltétlenül van szükség egy teljes évre a fejlesztéshez. Szerettük ebben a projektben, hogy volt beleszólásunk a felhasználói élmény kialakításába. Kifejezetten izgalmas projekt volt.
Mi egyébként web- és mobilalkalmazásokkal foglalkozunk, jellemzően startupoknak segítünk megvalósítani az ötletüket. Emellett pedig van egy B2B vonalunk is, amely az ügyfeleink számára a cégen belüli hatékonyság növelését segíti.
Segítesz kicsit rendet tenni a javasolt és nem javasolt technológiák témakörében?
Webes területen viszonylag jó megoldások állnak rendelkezésre. Mobil oldalon sokkal inkább tapasztalható úgymond egy kis izgalom a native és a cross platformos fejlesztés között. A native fejlesztés ugyebár azt takarja, amikor Androidra és IOS-re is külön lefejlesztjük ugyanazt az alkalmazást két különböző programnyelvben. Ez dupla idővel és dupla annyi munkával jár együtt.
A cross platformos megoldás keretei között egy helyen csináljuk meg az appot, amely aztán mind a két helyen lefordul. Szóval egy forráskód van, az alkalmazás pedig IOS-re és Androidra is létrejön. Egyszerűbb, a telefon szenzorait nem igénylő ötlet validálásához és az MVP létrehozásához az utóbbi megoldás számít olcsóbb választásnak.
Egy ötlet értékelésekor meg szoktuk vizsgálni, hogy milyen elemeket tartalmaz, és ennek alapján döntünk az alkalmazott technológiáról.
Van-e bármilyen záró gondolatod azoknak, akik most készülnek nekiállni bármilyen webes vagy mobilapplikáció fejlesztésének?
A fejlesztő cég választásakor győződjünk meg a tárgyaló partner referenciáiról, akikhez egyébként érdemes kapcsolatokat is kérni. Ezáltal el lehet kerülni a horror sztorikat, egyúttal elkerülhetjük a komolyabb veszteségeket is.
