Esettanulmány egy startupról

Termékfejlesztés

Történt, hogy egy ifjú szakértő mérnök, a történetünkben legyen Marci, a munkája során talált egy olyan lehetőséget, amiről, joggal, azt gondolta, hogy érdemes lenne megcsinálni rá egy jó kis szoftvert és kipróbálni az üzleti életben.

Le is ült, végig is gondolta, hogy egyébként mit szeretne csinálni az eddigi gyakorlatai és tapasztalatai alapján. Összerakott egy igénylistát, és képernyőterveket, majd bekopogott a Hiventures-höz. Nagy örömmel adtak az üzleti elképzelésére egy első körös befektetést.

Eddig egész biztatóan alakultak a dolgok.

Következő lépésben barátunk megpróbált fejlesztőket verbuválni akikkel meg is lehet valósítani a projektet. Végül szerződtetett egy csapatra való embert, akikkel elkezdték a fejlesztést.

Hogy nagyjából irányban legyenek tartva a dolgok, Marci leírta gyönyörűen egy nagyjából 160 oldalas doksiban, hogy miről is szól ez a szoftver, mit és hogyan is kellene csinálnia. Egy valami azonban erősen hiányzott

Tanulság 1:  már a projekt legelején gondolkodni kell arról, hogy milyen modellben és mennyiért próbáljuk majd értékesíteni a terméket / szolgáltatást

Neki is álltak a fejlesztők, és elköltöttek a négy zsák pénzből két zsák pénzt. Ezért a 2 zsák pénzért egy kattintható prototípuson kívül azonban nem sok mindent tudott letenni a csapat.

Ez érthetően rettenetes rossz érzéssel töltötte el  Marcit, és feltámadtak kétségei, hogy ebben a formában, ezzel a tempóval  nemhogy a maradék két zsák, de még húsz sem lenne elég hogy termék legyen.

Tanulság 2: A domain ismeret szükséges feltétel ugyan, de nem elégséges. Meg kell támogatni, többek között a digitális termékfejlesztés tudással. Ő megint egy külön szakma, amit érdemes előre megtanulni, vagy hozzáértő embert alkalmazni.

Valahogy úgy hozta a sors, hogy összekeveredtünk, és vázoltam neki, hogy az Agile módszertani világban egy ilyen termékfejlesztés hogy zajlik. Mit kéne csinálni ahhoz, hogy ha más nem is, de a maradék pénzből egy olyan termék vagy szolgáltatás jöjjön létre, ami az ő víziójának megfelel, és a piacon eladható.

Meg is állapodtunk, és elkezdtük a munkát. Áttekintettük az Agile termékfejlesztés fázisait és artifaktjait… és bele is futottunk az első problémába: Mi is a termékvízió?

Miután összeraktuk az Agile Product Visiont, tehát azt a fajta termékvíziót, amit az Agile módszertan előír, rájöttünk, hogy túl széles az a vízió, amit meg szeretne megcsinálni, minimumnak tart.

Tanulság 3: attól, hogy pár mondatban össze tudod foglalni a lényeget, még nem biztos, hogy rövid is az, amiről a lényeg szól.

Az első lépést azonnali megtorpanás követte.

Márton vállalta, hogy az elképzeléseit szétbontja és Agile Product Vision-ök formájába önti. Elképesztő munkát tett bele. Néhány nap múlva előállt nagyjából 120 visionnel. Teljesen egyértelmű volt, hogy lehetetlenség ilyen komplexitású terméket a lehetőségeinken belül lefejleszteni.

Három napnyi közös tekergetés és próbálkozás után, sikerült Mártonnal meghatározni 3 olyan Product Visiont amiről azt gondoltuk, hogy érdemes elindulni. Lehet belőle üzlet az első  nekifutásból.

Tanulság 3: such Fokus Karate Kid! Mindig lehet egyszerűsíteni és csökkenteni a scopeot. Mindig.

Tanulság  4: mindig vedd számba a hipotéziseket és validáld őket! Különösen igaz ez azokra a gondolatokra, amik a “unique selling point” fejezetbe kerülnek

Megvizsgáltuk ennek a 3 Product Visionnek az értékesíthetőségét, valamint, hogy a már kész szoftverelemekből mennyi szolgálja ki ezeket.

Külön dolgoztunk azon, hogy melyik milyen formában, csatornán, kommunikációval lesz eladható.

Ebből a háromból legalább olyan nehéz volt kiválasztani azt az egyet, amit elsőként ki akartunk tenni a piacra, mint a 120-ból azt a hármat. De végül sikerült.

Hamar kiderült, hogy a terméket hitelesen csak Márton tudja képviselni. Ekkor történt, hogy Márton értékesítői coachingot vett magának.

Tanulság 5: eladni IS(!) egy külön szakma, vagy megtanulod, vagy veszel hozzáértő embert

A szoftverfejlesztés

Mártonnak erőteljesen javasoltuk, hogy mindaddig amíg nem rakjuk össze a részletes, legfontosabb és legelsőnek priorizált igényeket, és még nem építettük fel a backlogot, addig ne folytassa a fejlesztést.

Márton inkább azon az állásponton volt, hogy ha már a fejlesztők ott vannak, és fixen fizeti őket, akkor  ne álljanak, hanem fejlesszenek.

Tanulság 6: csak annyi fejlesztőt tarts, amennyi soha nem zavar, ha épp értékesebb, ha áll, és nem fejleszt

Mindeközben összeraktuk Mártonnal az Agile módszertan szerinti üzleti logikai folyamatábrákat, valamint az Epic szintű backlogot.  

Az Epic szintű backlogok segítségével meg tudtuk írni az elsődlegesen legfontosabb user sztorikat. Ezeket Story Mapbe szerveztük.

Az Epic szintű backlog és az üzleti logikai folyamatábrák folyamatos összevetése abban támogatott minket, hogy a lehető legkevesebb user sztorit írjuk meg, a lehető legkevesebb elfogadási kritériummal. Ezt már érdemes volt a fejlesztőknek odaadni.

Tanulság 7: Agile termékfejlesztési artifactok helyes használata fényévekkel közelebb hozza a működő szoftvert

Mindeközben felkértük Mártont, hogy alkalmazzon egy külső szoftver architectet, aki megnézi és validálja, hogy a csapat eddig elkövetett kódja milyen minőségű, mennyire fenntartható, mennyire fejleszthető. Erről Márton sajnos nem volt meggyőzhető. Ő elhitte a fejlesztőknek hogy jól dolgoznak, és majd egy Scrum Master segíti a csapatot. Majd a Scrum Master kifigyeli, ha nem stimmelnek a dolgok. Ezzel még nem is lett volna akkora baj, csakhogy a csapat nem egy helyen volt, hanem szétszórva az országban.

Nos… a kód minden alkalommal letérdelt, amikor az addigi “éles” elemekhez hozzányúltak.

Tanulság 8: bízz, bízz, de sűrűn ellenőrizz! Ráadásul független szakértők bevonásával. Sokkal olcsóbb, mint egy spagetti kódot fenntartani, nem is beszélve a további fejlesztések hozzáillesztéséről.

Tanulság 9: a Scrum Master sok mindenre jó ugyan, de megvannak a korlátai. Tanuljuk meg, mire való és hogyan tudjuk a legjobban használni ezt a szereplőt.

A csapat időnként találkozott Budapesten, ami általában parttalan vitákba meg meta beszélgetésekbe torkollott. Muszáj volt ezt a csoport fejlesztőt csapattá kovácsolni. Épp ezért a lehető legsűrűbben tartottunk budapesti összejöveteleket (heti átlag kettőt), miközben napi szinten igyekeztünk koordinálni a fejlesztőket a megbeszéltek szerint.

Első nagy áttörés az volt, amikor először kezdték el prioritási sorrendben követni a megírt user sztorikat.

Második sikerélmény az volt, amikor a sztorikat már lebontották fejlesztői taskokra és ezeket becsülték meg, Márton pedig ezen becslések alapján próbált meg az egyes featurek-re költségvetést összeállítani.

Tanulság 10: közös, szemtől szemben folytatott munkánál nincs inspirálóbb és hatékonyabb

Transzparencia és a vég kezdete

És akkor elkezdett a termék látványosan fejlődni.

Az egyre transzparensebb, mostmár Scrum Masterrel is megtámogatott működés miatt a szekrénybe gyömöszölt csontvázak egyre-másra kerültek elő. Ezek mellett már nem lehetett elmenni, hiszen kattintható prototípusok helyett már folyamatosan fejlődő, bemutatható, potenciálisan élesíthető késztermék szeleteket vártak az első vevőjelöltek!

Ennek következtében Márton többször is összezörrent a fejlesztői csapattal. Néha már gyógypedagógia módszerekkel, de végül a konfliktusokat sikerült uralni, és a maradék két zsák pénzből másfél zsákért elkészült az MVP, a Minimum Viable Product. Fél zsák pénz az MVP backlogja volt.

Tanulság 11: ha nem vagy felkészülve a konfliktusok kezelésére, a transzparencia, ami a te érdekeidet szolgálja, neked is fájni fog. Konfliktuskezelésre fel lehet készülni, az tanulható.

A transzparencia miatt elég sokszor kilógott a lóláb. Kiderült hogy mely fejlesztők akarnak igazából dolgozni, és kik azok akikkel tudásuk alapján is érdemes. Azonnal látszott, hogy a csapat egy része valójában csak látszatmunkát végzett. Nekik saját rejtett agendájuk volt. Ezen a ponton viszont pillanatok alatt a felszínre került az elképzelésük. Azt gondolták ugyanis, hogy a fizetésért cserébe összehányt kódot, majd óradíjban, mint újonnan alakuló fejlesztő cég fogják beszállítóként javítani és karbantartani. Ez már egyértelműen jogi kategória.

Márton vajszívű volt és ez rendszeresen bajba sodorta. Végül elengedte ezeket az embereket, de nagyon sokba került még így is, hogy az MVP legalább a jelen állapotában működjön, tudván, hogy az első bevételeket egyből egy alapos újraírásba kell majd fektetni.

Tanulság 12: a transzparencia nem hazudik. Aki hazudik, kókány munkát végez és/vagy meglop, azzal nem szabad kesztyűs kézzel bánni.

Tanulság 13: Döntéseket így is, úgy is meg kell hozni. Annak következményeivel együtt kell élni. A halogatás csak az okozott kárt növeli.

Lényeg a lényeg, az MVP elkészültével Márton a fejlesztő csapatot végül szélnek eresztette. Addigra azonban már késő volt. A kicsalt és kizsarolt összegek a zsákok jelentős részét felemésztették.

Tanulság 14: saját fejlesztői kapacitás fenntartása helyett, aminek a menedzselési költségével és időigényével általában a tulajdonosok/alapítók nem számolnak, koncentrálj egy jó minőségű backlog előállítására, amit aztán bérbevett Agile Delivery Teammel gyártatsz le.

Tanulság 15: egy Agile Delivery Teamet csak akkor kell kifizetni, ha a szállított termék valóban működik, és kiállja a minőségbiztosítás próbáját, akár harmadik fél vizsgálata alatt is.

Tanulság 16: egy Agile Delivery Team nem olcsó, de nagyságrendekkel olcsóbb, mint a saját csapat és az azzal járó teljesítési kockázat, valamint a szállítói anyagi felelősségvállalás hiányából fakadó extra kockázat.

Majdnem siker

Mindezek ellenére, valahogy még az utolsó utáni pillanatban sikerült áttolni a szoftvert a célvonalon, és létrejött belőle egy elég stabilan működő Live Beta szintű szoftverszolgáltatás. Őt már le lehetett telepíteni valódi gyárak, valódi gyártósorai mellé.

Márton üzleti tanácsadója kötötte az ebet a karóhoz, hogy először az itthoni piacon kell tudni érvényesülni. Mondván: ha már az itthoni piacon van kellő tapasztalat és fejlesztés, azután érdemes elkezdeni próbálkozni a külföldi cégekkel. Azonban az értékesítési próbálkozások azt mutatták, hogy a magyarországi piac igen korlátozottan nyitott a termékre. Fenntartható mennyiségű és intenzitású értékesítést itthon nem lehet, vagy legalábbis nem tudtuk hogyan lehetne, csinálni.

Márton nem hallgatott üzleti tanácsadójára és egy érdekes és szerencsés próbálkozás folytán kiderült, hogy az erdélyi piac, ahol az ipari kamarában is van kellően beágyazott személyes kapcsolat, feltehetően nyitott lesz a termékre.

Márton a nyakába vette Erdélyt az ottani ismerőse társaságában, és két-hetes körút során megkötöttek négy szerződést, valamint több szándéknyilatkozatot.

Miközben voltak korábbról elképzeléseink, hogy mit mennyiért szeretnénk majd értékesíteni, a személyes kapcsolatok, interjúk, egyeztetések és terepszemlék erőset kanyarítottak a modelleken.

Tanulság 17: a helyi, beágyazott erők kapcsolati tőkéje szinte mindig értékesebb, mint az elméleti tanács.

Tanulság 18: Neked! személyesen kell ott lenni (legalábbis az elején) minden értékesítési eseménynél.

Tanulság 19: a terepen, és csakis a terepen dől el, hogy milyen bevételgeneráló modellt lesz érdemes alkalmazni.

Márton eddigre már elfáradt. Az értékesítési körút, meg egy mindentől független balszerencse gyakorlatilag elégette az összes maradék pénzt és hitelt, amit a termékbe bele lehetett tenni. Ez teljes mértékben felemésztette Márton lelkesedését és akaraterejét is.

A feloldozás

Annak ellenére, hogy végül létrejött a szoftver, ami termelőképes, és azoknak az ügyfeleknek akiknek le lett telepítve örömet és hasznot okoz, fizetnek is érte, Márton végül elengedte a projektet.

Márton ma egy nagyvállalatnál dolgozik. Emberek tucatjainak a közvetlen vezetője. Személyes piaci értéke sokszorosára nőtt ezalatt a rövid, de elképesztően intenzív idő alatt.

És a termék?

Egyelőre úgy tűnik a feledés homályába merül… egyelőre 🙂

Tornai Balázs