Egy halott startup margójára: mit tanultunk egy év alatt és mit rontottunk el?

helicopter crash texas

Ezt szépen bebuktuk. Nem sikerült az édes álmokat közelebb hozni a szigorú valósághoz, ezért egy hete úgy döntöttünk, hogy a Pilo projektet befejezzük.

Hogy megérte-e? 1000%, hogy igen. Többet tanultunk belőle, mint alkalmazottként 2-3 év alatt lehet. Életre szóló barátságokat kötöttünk. Néhány tanulságot összegyűjtöttem ebbe a posztba. Nekem is jól jöttek volna ezek egy évvel ezelőtt.

Figyelem! A bejegyzés nyomokban a magyar rögvalóságot tartalmazza. (És nincs benne Paul Graham idézet.)

Mit tanultam egy startup csapat elindításáról?

Toborozni könnyű, de időigényes. Viszont 1-2 hónapon belül megtérül.

Kis túlzással a végzett egyetemisták sorban állnak, hogy startupnál dolgozhassanak. Budapest tele van lehetőséget kereső fiatalokkal, akik szeretnének egy nagy dolog részesei lenni. Ha ismered a megfelelő levlistákat és csoportokat könnyen találsz érdeklődőket. A kiválasztás sem olyan bonyolult, hogy ne tudná bárki megcsinálni. Csak le kell ülni 6-8 emberrel egy-egy órára beszélgetni. Amikor ezt megtettem mindig motivált, szakmailag felkészült emberekkel bővültünk. Amikor csak lecsaptam az első kínálkozó jelöltre, abból már rövid távon, 1-2 hónapon belül problémák jelentkeztek.

A biznisz feladatokat jól lehet tördelni. Mérnöki munkánál a dedikált napok működnek jobban.

Az elején minden ilyen projektet részmunkaidőben tolnak az emberek. Az üzleti jellegű feladatokat lehet apró részekre szedni. Megoldható, hogy valaki munka után minden délután dolgozzon rajta néhány órát. A mérnöki munka viszont más, mert ennyi idő alatt épp, hogy csak felveszi az ember a fonalat, nem tud érdemit előre lépni. Ezért a ménököknek biztosítani kell, hogy már az elején legyenek dedikált napok, amikor csak a projekten dolgoznak. Ezeken a napokon mi néha többet haladtunk, mint máskor több hét alatt.

Az új cég kísérletezés. Attól leszel jó kísérletező, ha több mindent tudsz kipróbálni ugyanannyi idő alatt.

Az elején nem tudsz semmit. (Vagy tévesen azt hiszed, hogy tudsz valamit, ami még rosszabb.) Ki kell kísérletezned, hogy milyen termékre van igény, kinek lehet ezt eladni, őket milyen csatornákon lehet elérni, és milyen üzenet hat rájuk. És mellette ugyanezt a befektetőkkel. Ilyen sokismeretlenes egyenlet megoldására nincs képlet, kísérletezned kell. A kísérletezés próbálgatás: van egy ötleted és kipróbálod. Nem fog működni, de tanulsz valamit belőle, ami egy jobb ötletet szül. Az tud eredményesen kísérletezni, aki több dolgot tud kipróbálni ugyanannyi idő alatt. Párhuzamosítani sajnos nem tudod a próbálkozást, mert teljesen össze fogsz zavarodni. Mindig a következő kísérletre kell koncentrálni, és azt minél hamarabb lebonyolítani, hogy használható visszajelzést kapj belőle.

A jó prototípus olyan egyszerű, hogy szégyelled mások előtt. De max 2 hét alatt kész van.

A termékfejlesztés is kísérletezés. Nincs olyan sikeres termék, ami ne ment volna keresztül min. 5-6 prototípuson, mire piacra került. A prototípusok egymásra épülnek: az első nagyon gagyi, és egyre jobbak lesznek. Mi ott rontottuk el, hogy egyből kész terméket akartunk fejleszteni egy egyszerű prototípus helyett. Ezt nem lehet. Az a jó prototípus, ami maximum két hét alatt elkészül. Az a jó prototípus, amit szégyellsz, mert annyira keveset tud.

Amiről kevesen beszélnek: tudd, hogy hol tartasz a folyamatban. (WTF!? milyen folyamatban?)

Ha azt szeretnéd, hogy a gyerekedből tudós legyen, akkor nem az a jó megoldás, hogy 6 évesen beülsz vele egy egyetemi előadásra. Vidd el inkább a csodák palotájába bugyuta kísérleteket nézni. Abban a pillanatban ez viszi őt közelebb a célhoz.

Cégvezetőként mérhetetlen mennyiségű tanács fog rád zúdulni: olvasod az amcsi blogokat és jönnek az önjelölt szakértők megmondani a tutit. Tele lesz a fejed ötletekkel, hogy mit kéne csinálni. Mi is rengeteg olyan dolgot csináltunk, aminek ott és akkor semmi értelme nem volt. Pedig a nagyok is azt csinálták ám. Csak ők már nagyok, Te meg még kicsi vagy. Sokan beszélnek arról, hogyan lehet működtetni egy 100 fős céget, de kevesen tudják mit kell tenni egy 3 főssel, hogy elinduljon a 10 főssé válás útján. Hogy aztán majd 4-5 év múlva meglegyen a 100 is.

A cég beindítása egy fejlődési folyamat. Tudnod kell, hogy hosszabb távon hova akarsz eljutni, de azt kell csinálnod, ami az aktuális állapotodban a következő lépés ebbe az irányba. Ezt a lépést nem tudod úgy kitalálni, hogy csak a nagy cél lebeg a szemed előtt. Ezért legyen egy nagy és egy kicsi célod. A nagy célod az, ahova 5 év múlva el akarsz érni. A kicsi célod az a következő lépés, amit ma meg kell tenned, hogy elindulj a folyamatban a következő lépcsőfok felé. Nem a végcél felé, csak a következő lépcsőfok felé. Ezen a lépcsőn senki sem tud kettesével ugrálni. Inkább lépkedj egyesével, de fürgén.

Mit tanultam a magyar startup közösségről?

Az események, versenyek csak névjegykártya cserére jók.

Amikor először bekerülsz ebbe a közegbe, akkor meglepődsz, hogy mennyi startup esemény van és igyekszel ott lenni mindenhol. Ez oké, de nem érdemes túl nagy energiát ebbe fektetni, mert ezek a rendezvények csak arra jók, hogy összegyűjtsd mindenkinek a névjegyét. A lényeg a színfalak mögött zajlik. A versenyeket néha úgy állítják be, mint komoly lehetőséget a befektető szerzéshez. Ez nem igaz. Befektetőket hónapokon keresztül végzett tudatos munkával lehet szerezni, és nem versenyeken, nem demo dayeken.

Mindenkit el kell osztani kettővel. Vagy inkább tízzel.

Mint mindenhol, itt is mindenki többnek mutatja magát, mint ami valójában. Ez igaz a komoly befektetőtársaságokra, híres szakértőkre, és magukra a startupokra is. Rengeteg storynk van arról, hogy világszerte ismert accelerator programok a valóságban milyen gyengék. Például a Startup Sauna vezetője személyesen, színpadi közönség előtt vett minket short-listre a programjukhoz, majd, amikor néhány nap múlva írtunk nekik és hívtuk, hogy akkor hogyan tovább, akkor egyszerűen nem reagáltak, nem tudtuk elérni őket. És ez az egyik legjobb program Európában. Tudok olyan magyar accelerator programról, ahol már több százmilliót eltapsoltak működési költségekre úgy, hogy közben a támogatott startupokhoz ebből érdemben csak a töredéke jut el. Tehát óvatosan a nagy nevekkel, nem minden az, aminek látszik.

Van néhány zseniális arc.

Egy év alatt sok emberrel találkoztam, és volt köztük néhány igazán zseniális arc. Ők főleg más csapatok alapítói voltak. Nagyon inspiráló olyan közegben mozogni, ahol mindenkinek nagy álmai vannak és azok megvalósításán dolgozik. A legtöbbet pedig szerintem a saját csapatomtól kaptam. Már miattuk megérte.

Ezek után happy end?

Nyár elején elindítottam egy másik vállalkozást az UX studiot, ahol felhasználói felületeket tervezünk. Visszatértem tehát a kaptafához, és ez bevált. A kezdetektől pozitív cash-flow mellett, néhány hónap után máris három fős kis csapattal dolgozom együtt. Vállalkozó maradtam, de most egy ideig a part menti, biztonságos vizeken hajózom.

Ha esetleg zavar, hogy nehezen használható az alkalmazásod felülete, a felhasználóid nem értik meg, hogy igazából mire jó, akkor írj nekem és beszéljünk róla egyszer egy kávé/sör mellett: pasztor.david{kukac}uxstudio.hu

 

Ledobhatjuk végre a régi béklyókat

Felszabadító érzés lenne, ha a digitális életünkben nem kéne többet ezzel a három dologgal foglalkozni:

  1. Mentés: A Google Docs óta tudjuk, hogy milyen az élet mentés nélkül. Először mindenkinek kicsit furcsa, de gyorsan megszokja az ember, és utána már mindenhol erre vágyik. Nem is értem, hogy az asztali alkalmazások mért nem működnek régóta így. Automatikus mentés, és visszaállítási lehetőség a korábbi változatokra. Ez kell nekünk.
  2. Alkalmazás megnyitás/bezárás: Engem, mint felhasználót egyáltalán nem érdekel, hogy melyik alkalmazás fut éppen, melyik alszik, melyik ébredezik, vagy melyik kávézik a szomszéddal. Csak az érdekel, hogy amit meg akarok nyitni, az induljon el gyorsan, amit épp használok az fusson gyorsan, a többi pedig ne zabálja az erőforrásokat feleslegesen. Ennyi. Elvégre az alkalmazások futásának menedzselése az operációs rendszer feladata, nem az enyém. Ezen az úton már elindult az Apple, és a mobil oprendszerek is.
  3. Bootolás: Ma már a legtöbb ember csak aludni küldi el a gépét. Van olyan ismerősöm, aki hónapok óta nem indította újra.  Mobilon alapból nem szokás a ki-be kapcsolgatás. Régen ez még egy különleges pont volt a számítógépek életében, de ennek vége. Nem akarunk többé kikapcsolni.

Itt az ideje felkavarni kicsit az operációs rendszerek állóvizét is. Sok olyan dologhoz lehetne hozzányúlni, amit ma természetesnek veszünk, de valójában csak feleslegesen rabolják az időnket.

A Prezi paradoxon

Elvileg a prezi.com nem csak a látványos animációkról szól. Azzal, hogy lehetőségünk van egy felületen zoomolni, átláthatóbbá tudjuk tenni a dolgokat, be lehet mutatni a kontextust, az összetartozó gondolatokat, és különböző mélységekben lehet megismerni az anyagot. Néhány éve hasonló okból volt nagy divat a mindmap. Ezek a megoldások mind arra a megfigyelésre alapoznak, hogy az ember elméje gráfba szervezi az információkat.

Valamiért mégis fura prezit nézni.

Nem csak a megszokás miatt. A valóság az, hogy ezek a gráfos gondolattérképek csak a gondolataink lejegyzését könnyítik meg, az információ befogadását nem. Az adatokat az ember is csak lineárisan, szép sorban képes befogadni. A térképen mindig csak egy utat tudunk bejárni egyszerre. Az elénk táruló sokféle lehetőség elbizonytalanít minket. Egy térkép az információ struktúráját magyarázza el, de az ember alapvetően nem szeret struktúrákat befogadni. Az ember logikusan egymásra felépített, lineáris gondolatfolyamokat tud gyorsan befogadni, amit aztán később beépít a saját gráfjába. Ezért szeretjük annyira a történeteket, a meséket, és utáljuk annyira a matekot.

Amikor szöveget írunk, akkor azt határozzuk meg, hogy a saját térképünkön milyen útvonalon menjen végig az olvasó. Ez nehezebb, mintha csak simán lerajzolnánk az egész térképet. Cserébe az olvasónknak megkönnyítjük vele a dolgát, és nagyobb eséllyel jut el hozzá az üzenetünk.

Egy jó szónok olyan, mint egy drámaíró. Végig tudatosan vezeti a közönségét, pontosan tudja, mikor fognak nevetni, mikor lesznek kíváncsiak, hol vannak a csúcspontok és hol lazíthatnak egy kicsit a hallgatók. A jó előadók egy gondosan megtervezett úton vezetik végig a közönséget. Ők történetet mesélnek, poénokkal és csattanókkal együtt. A jó előadók pont abban különböznek másoktól, hogy sok energiát fektetnek az út megtervezésébe és nem elégszenek meg a térképpel. Nekik a prezi továbbra sem jelent többet a látványos animációknál. Az más kérdés, hogy ez bőven elég ahhoz, hogy a Prezit használják.

Te is bünteted a törlést?

Van egy elég rossz berögződés, ami szinte minden szoftverben benne van. Majdnem mindenhol büntetik a törlést. A legtöbb esetben a törléshez egy vészjósló piros vagy fekete gombot kell megnyomni, és egyből kapsz egy figyelmeztetést is: megkérdezik, hogy biztos vagy-e a dolgodban?

Ez a hozzáállás azért alakult ki, mert az informatikusok (kezdetben joggal) féltek az adatvesztéstől. Ez végül azt eredményezte, hogy számítógépes környezetben az emberek egyenesen félnek a törléstől. Amúgy sem szeretünk kidobni dolgokat (neked hány felesleges tárgy van a szobádban?), de a felhasználói élmény még jobban eltántorít minket ettől. A MiniCRMből sokan még a supportos kollégák unszolására sem merik kitörölni a regisztrációkor kapott példa adatokat. Pedig ők is pontosan tudják, hogy ezek feleslegesek.

Ez nagy kár, mert a törlés jó dolog. A felesleges dolgok törlése csökkenti a zajt, átláthatóbbá teszi a felületet, segít a célunkra koncentrálni. Épp ezért inkább jutalmazni kéne a törlést.

A törlés akkor van megfelelően kialakítva, ha:

  • minden törlés később visszavonható, a törölt dolgok egy lomtárból visszaállíthatók (ezzel csökkentjük a törlés kockázatát)
  • a törlés nem egy riasztó gomb mögé van rejtve (szín, forma, ikon képe)
  • nincs elbizonytalanító kérdés (biztos?), helyette inkább bátorítani kéne a felhasználókat (jól tetted, szabadulj meg mindentől, ami nem kell!)

Design = felfedezés

A design felfedezés. Sokféle ötlet van, mindegyiknek vannak előnyei és hátrányai. Amíg nem próbáljuk ki őket, addig mindegyik csak egy ködös elmélet. Ezért fontos a prototípusok, vázlatok készítése. Sokkal könnyebb eldönteni, hogy melyik a jó változat, ha látjuk magunk előtt őket. Ami szóban jónak hangzott az prototípusként sokszor már kevésbé fényes. És ez fordítva is igaz: ami szóban kicsit furcsának hat, magunk előtt látva már természetes.

Utólag nagyon egyszerű meglátni, hogy miért jó egy megoldás. De ezt a jó megoldást megtalálni, csak a feladat ismeretében, nem olyan egyszerű. Több ötletet, ezeknek is számos változatát ki kell próbálni, mire meg lesz az igazi. Az Intercom blog ábrája nagyon jól mutatja mi a különbség egyetlen ötlet csiszolgatása, és sok ötlet kipróbálása, vagyis a lehetőségek felfedezése között.

Átlátni az adatdzsungelen

Ezerszer ismételt frázis, hogy azért jó az elektronikus kereskedelem és az online marketing, mert minden mérhető, mindenről van statisztikánk. De álljunk csak meg egy pillanatra. A rengeteg adat tényleg minden esetben hatékonyabbá teszi a működést?

Ha az ember egy valódi boltban dolgozik, vagy netán telefonos sales tevékenységet végez, akkor egy-két óra alatt annyi vásárlóval beszél, mint a tisztán online bizniszben utazó társai hónapok alatt. A személyes beszélgetéseknek megvan az az előnye, hogy instant visszajelzést nyújtanak a termékről, a marketingről, a vásárlók döntési szempontjairól, mindenről. Persze ezeket a visszajelzéseket is tudni kell értelmezni, mert a vásárlók sokszor maguk sem tudják mit akarnak (vagy nem azt mondják ki). De ettől még a személyes beszélgetés során sokkal gyorsabban jönnek a visszajelzések.

Az online világban ezzel szemben minden mérve van. De ahhoz, hogy ugyanazokat a problémákat, ugyanazokat az okokat kihámozd az rengeteg adatból, sokkal több munkára van szükség. Amíg egy boltban elég megkérdezni három embert, hogy mi nem tetszik neki egy termékben, addig egy webáruházban ugyanezt az információt hosszas adat bogarászással, valamint a képek és szövegek rendszeres tesztelésével lehet elérni.

Ráadásként nem mindenki tud ugyanolyan könnyen kiigazodni az adatokon. Aki reál területről jön, azt korábban megtanították analitikusan gondolkodni, ő könnyedén mozog ebben a világban. De akinek ez kimaradt az életéből, az csak egy rakat számot lát maga előtt, jobb esetben grafikonokat, és nincs meg a módszere arra, hogy ezekből következtetéseket olvasson ki.

Ezért fontos a webes üzletben is a rendszeres élő felhasználókkal való tesztelés, az ügyfelekkel való személyes kapcsolattartás. Ezek az alkalmak legalább részben visszaadják azt, ami egy hagyományos IRL boltban alapból megvan.

A RITE módszer és az Age of Empires II. tesztelése

Nemrég olvastam az egyik kedvenc régi stratégiai játékom, az Age of Empires II. usability teszteléséről. A módszer, amit itt alkalmaztak a RITE (Rapid Iterative Testing and Evaluation) nevet viseli. Általában úgy szoktak tesztelni, hogy amikor elkészül egy funkció, vagy használható prototípus, akkor behívnak néhány tesztalanyt (általában öt elég), aztán a teszt során megtalált hibákat javítják, majd jön az ellenőrző teszt, amikor megnézik, hogy tényleg megoldódott-e a probléma.

A játékfejlesztők arra jöttek rá, hogy ez az eljárás üzleti körülmények között nem elég hatékony. Tesztalanyokat toborozni nem lehet egyik napról a másikra. Agilis környezetben egy-egy funkciót 2-3 hét alatt fejlesztenek le. Nem fér bele, hogy a teszt szervezése önmagában elvegyen 2 hetet. A hagyományos módszereknél az elkészült megoldások tesztelésével várni kell. Ez nem jó, mert ha megoldok egy problémát azonnal látni akarom hogyan boldogulnak vele a userek. Addig akarom kipróbálni, amíg még meleg. Ráadásul a gyakorlat azt mutatja, hogy nem mindig van szükség öt tesztalanyra. A legfontosabb hibák már az első, vagy második tesztalany után kiderülnek.

A RITE módszer lényege, hogy a teszteket nem tömbösítjük, hanem folyamatosan mennek, egyenletesebben elosztva a fejlesztés ideje alatt. Minden teszt után összeírjuk a felmerült problémákat és egyből nekiállunk a megjavításuknak. Sok olyan hiba van, amit néhány perc alatt ki lehet javítani: a rossz szövegezés például ilyen. Ezt két tesztalany között is meg lehet tenni, nem kell a következő teszt napot megvárni. Azokat a hibákat is egyből el lehet kezdeni javítani, amik több fejlesztést igényelnek. Ezek nem lesznek kész a következő tesztalanyig, de minél hamarabb nekiállunk a javításnak annál jobb.

Ez a módszer tehát még agilisebb munkát tesz lehetővé és arra törekszik, hogy a lehető legrövidebb idő alatt a legtöbb usability hibát kijavítsuk, valamint gyorsan kapjunk visszajelzést a javítások helyességéről. Másik előny, hogy a hamar megjelenő hibáknak (amik általában a legsúlyosabbak), hamar meglesz a megoldása, és ezeket így több tesztalanyon tudjuk validálni.

Az Age of Empires tutorial módját tesztelték ezzel a módszerrel. Az alábbi grafikonon láthatók a teszt alkalmak és a hibák. Két fajta hiba van az ábrán: a failure azokat a fatális usability hibákat jelöli, amelyek megakadályozták a felhasználót abban, hogy folytassa a tutorilat. Az error csak simán összezavarja a felhasználót, megnehezíti a dolgát.

A függőleges vonalak jelölik hol javítottak a teszteléshez használt prototípuson.

Milyen hibákat talál még a usability teszt?

Sok élő felhasználós teszttel a hátam mögött kezd letisztulni, hogy milyen típusú hibákat lehet megtalálni usability teszttel. A teszteknek mindig van egy célja, amit vizsgálni szeretnénk. De az előre meghatározott célunkon kívül a tesztek szinte mindig találnak …

  • nem konzisztens elnevezéseket: főleg alkalmazásokban lehet velük találkozni és a tesztek során meglepő, hogy szinte mindig felmerül egy-két ezzel kapcsolatos probléma
  • olyan apró hibákat, amiket korábban elhessegettél: ezért kegyetlen a tesztelés, mert minden kis semmiség előjön
  • szent teheneket: néha valamilyen okoskodó magyarázat mögé bújva nem tervezünk újra problémás részeket. A rendszeres teszteken ezek a hibák újra és újra és újra elő fognak jönni. Egészen addig, amíg meg nem javítod őket.

Kirakós

Webes és szoftveres felületeket tervezni olyan, mint egy logikai játékkal játszani. Minden elemnek megvannak a maga szabályai: melyiket hova érdemes rakni, melyik hogyan kapcsolódik a többihez. A feladat egy olyan konstrukciót megalkotni, ahol minden elem a helyére kerül, úgy, hogy az elrendezés megfelel az előre végiggondolt feltételeknek.

Ez néha könnyű. Néha meg egyenesen lehetetlen. Akkor kezd a dolog nehézkessé válni, amikor nem találod azt a kombinációt, ami minden feltételt kielégít. Ilyenkor van szükség az un. kreativitásra. Kell egy jó ötlet, egy egyedi, újszerű gondolat. A kreativitás képes arra, hogy a lehetetlennek tűnő, ellentmondásos helyzeteket úgy oldja fel, hogy ne kelljen egy kompromisszumos félmegoldást választani.

De az ötlet nem jön gyorsan. És szinte biztos, hogy nem fog már a probléma felismerésének alkalmával bekopogtatni. Ilyenkor az ember elrakja a fejébe a feladatot és az napokig ott motoszkál benne tudat alatt, míg egyszer csak a villamoson, vagy a wc-n ülve beugrik a megoldás.