Egy funkció teljes költsége
Felhívás! Szeptembertől elérhető vagyok tanácsadásra, részletek a cikk alján.
Amikor a feature factory-ról írtam, eltúloztam azt a gondolkodásmódot, amit ezek a cégek képviselnek. A problémájukat annak tudtam be, hogy az új funkciókat értékként, nem pedig költségként, illetve kockázatként kezelik. Ez nem teljesen így van. A legtöbb cég megbecsüli az új fejlesztésekre fordított időt, valamint nagyjából azt is, hogy milyen várható előnyöket hozhat az ügyfelek és a szervezet számára. A bökkenő csupán az, hogy a költséget alulbecsülik, a várható értéket pedig felül.
Egy funkció költségébe általában a tervezési, fejlesztési és tesztelési időt szokták beleszámolni. Pedig ha bárki megkérdez egy tapasztalt mérnököt, azt fogja hallani, hogy pár éves időtávon egy funkció karbantartása nagyságrendekkel több időt igényel, mint a fejlesztése. Ez azt jelenti, hogy minden egyes új funkció csökkenti a jövőbeli fejlesztésekre fordítható időkeretet, hiszen több karbantartásra lesz szükség. A karbantartási idő több összetevőből áll: a használt technológiát, fejlesztői könyvtárat frissen kell tartani, a jelentkező hibákat javítani, a többletfunkció okozta teljesítménycsökkenést pedig orvosolni kell.
Persze ezt is lehet jobban és rosszabbul csinálni. A rosszul megtervezett és tesztelt fejlesztések több karbantartást igényelnek, mint jól kivitelezett társaik. Emellett érdemes limitálni a felhasznált technológiákat, valamint egységes design könyvtárat kidolgozni, amit újra fel tud használni minden csapat. Minden új eszköz bevezetését nagyon szkeptikusan kell fogadni és csak tényleg indokolt esetben szabad rábólintani. Nem egyszer láttam láttam már olyan technológiát, amit egyetlen funkció használt, mert valaki a fejlesztés előtt olvasott róla és úgy gondolta, miért ne próbálja ki. Előfordult olyan is, hogy egy ügyfél habzó szájjal hívott, mert a fejlesztett rendszer miatt folyton összeomlott a böngészője. A rendszer egy saját gyártmányú fejlesztői könyvtárra épült, ez okozta a hibát. Sajnálatos módon az egyetlen mérnök, aki tüzetesebben ismerte a könyvtárat, éppen apaszabin volt…
Természetesen lehet azzal érvelni, hogy minél többet tud egy rendszer, annál több és jobban fizető ügyfele van, így az ezáltali növekedés (új emberek felvétele) kiegyenlíti a mérleget. Egy nagyobb szervezet ugyanakkor több kommunikációt, bonyolultabb belső felépítést is jelent, tehát végeredményben mégiscsak kevesebb idő jut új funkciók fejlesztésére.
Van egy további rossz hírem: a funkciók számával nem csak a fejlesztésre szánható idő csökken, hanem a sebessége is lassul. Ugyanis minél komplexebb egy környezet, annál több lehetséges interakcióval kell foglalkozni. Tervezéskor, fejlesztéskor, teszteléskor, illetve dokumentáció/tananyag gyártásnál is fel kell tenni a kérdést, hogy miként fog működni az új fejlesztés a már meglévő funkciók függvényében. Például vegyünk egy webshopot, aminek a DHL és a GLS csomagküldő szolgálattal is van integrációja. Ha egy fejlesztéssel ki lehet majd választani, milyen napszakban kéri a vevő a csomagot, azt mind a DHL, mind a GLS rendszerébe be kell vinni. Ezzel nem azt akarom mondani, hogy a több integráció rossz, de muszáj látni a jövőbeli fejlesztési sebességre gyakorolt hatását is.
Mi történik egy feature factory-ban, ha lelassul a fejlesztés? A csapatokra nagyobb nyomás kerül, hiszen a lényeg azon van, mennyi újdonságot tudnak szállítani. Ehhez jön a “két éve ezt egy hét volt megcsinálni, nem értem, mi tart most egy hónapig” effektus is. Ez arra ösztönzi a csapatokat, hogy gyorsabban dolgozzanak, ami rosszabb minőségű funkciókat eredményez. Ennek az eredménye az lesz, hogy még több időt kell karbantartásra fordítani, ami még jobban lassítja a fejlesztést. Ez egy ördögi kör, amiből nagyon nehéz kiszállni. A legtöbb cég, amit láttam, nem is tudott: sokszor inkább elkezdték nulláról felépíteni az “új platformot”.
Mi a helyzet az új funkciók értékével? Lenny Rachitsky (a legnépszerűbb termékmenedzsment hírlevél írója) nemrég interjút készített Roni Kohavi-val. Itt szóba került, hogy mennyi kísérlet (új funkciók, új design) végződött sikerrel. Roni szerint minél jobb a terméked, annál kevesebb ötlet fogja beváltani a hozzá fűzött reményt. Felhozott három példát is:
A Microsoft egészében nagyjából minden harmadik kísérlet járt sikerrel.
A Bing-ben (a Microsoft keresőmotorjában, ha valaki esetleg nem arra használta volna, hogy megkeressen és letöltsön egy másik böngészőt) ez az arány 15% volt.
Az AirBnB-ben pedig csupán 8%.
Ha csak a legjobb arányt nézzük, akkor is háromból kettő fejlesztés nem ad hozzá semmit a termék értékéhez, csupán lassítja a további munkát.
A megoldás kézenfekvőnek tűnik: ha a sok funkció lelassítja a fejlesztést, ráadásul értéket sem teremt, akkor meg kell szabadulni tőlük. Ez hívják unshipping-nek. A funkciók törlésének módja, illetve lehetősége cégenként változik, ezért ebbe nem is mennék bele részletesen. A kérdés az, hogyan lehet megtalálni azokat a régebbi fejlesztéseket, amiket érdemes visszavonni? A könnyű válasz az, hogy termékanalitika segítségével meghatározhatók a termék azon részei, amelyek kevésbé vannak kihasználva. Igen ám, de kevés olyan feature factoryt láttam, ahol van részletes termékanalitika. Itt jön képbe a termékmenedzser, akinek meg kell ítélnie a meglévő funkciókat. Melyiket mennyire használják, mennyi értéket jelentenek az ügyfél számára? Több csatornán is érkezik be információ, ami támpontot adhat:
Ügyfélinterjúk. Hogy néz ki a napi szintű munkavégzés? A termék mely részeit érintik a felhasználók?
Hibajegyek. Melyik fejlesztésekre érkeznek bejelentések? Azok a funkciók, amikről nem jön hibajelzés, tökéletesen működnek vagy nincsenek használva?
Értékesítési demo. Milyen funkciók szolgálnák ki legjobban az érdeklődő igényeit? Mi az, aminek a léte vagy nemléte nem számít egy vevő szemszögéből?
Ezeken kívül én az értelmetlenségi ökölszabályt szoktam használni: ha egy funkciót régebben csináltak és ránézésre nincs értelme, akkor valószínűleg tényleg nincs értelme, tehát ki lehet törölni. Ez mókásan hangzik, de az utóbbi két évben csupán egyszer találtam végül olyan indokot, amiért a fenti teszten megbukott funkció mégsem került az unshipping listára.
Összefoglalva: egy fejlesztés valószínűleg drágább, mint azt a legtöbben gondolnák, és kevesebb értéket hoz. Ezért fontos, hogy a rendszeres unshipping a termékfejlesztés része legyen.
Végezetül pedig a tanácsadásról: szeptembertől az időm nagyobb részét szeretném arra fordítani, hogy ne csak a blogomon keresztül segítsek cégeknek jobb terméket fejleszteni, hanem személyre szabottan is. Az első, ingyenes egy órás konzultációhoz elegendő egy rövid kérdőív kitöltése. Ezután felvesszük egymással a kapcsolatot, leülünk, és átbeszéljük, hogy miben és hogyan tudok segíteni.