Az a jelenség, amikor egy cég, vagy csapat értékmérője a leszállított funkciók mennyisége ahelyett, hogy az elért üzleti eredményekben, vagy a felhasználóknál elért hatásban mérnék a sikert, igen gyakori tévút. Melissa Perri Escaping the Build Trap c. könyve alapján elmagyarázom, mit is jelent ez.

Mi az érték?

Üzleti szempontból nem nagy kihívás megállapítani, hogy mi az érték. Leginkább a céged üzemanyaga, ez lehet például pénz (profit növelése, költségek csökkentése), adat vagy szellemi tőke. Minden egyes erőfeszítés, amit a cégben teszünk, azért tesszük, hogy ezekből a javakból még többhöz hozzájussunk. Az egyszerűség kedvéért a pénzes példát fogom használni. Minden fejlesztő azért dolgozik, azért fejlesztik a funkciókat, hogy végeredményben az ügyfelek fizessenek, és a szervezet hozzájusson még több pénzhez.

A felhasználó, vagy ügyfél szempontjából az érték valamilyen fájdalmukra, igényükre, vágyukra adott kielégülés. A felhasználó akkor realizálja ezt az értéket, amikor a vágy vagy fájdalom csillapítva lett. És csakis ezután fog ellenértéket, azaz pl. pénzt szolgáltatni az üzletért. Oké, persze, előfordul, hogy a vágycsillapítás reményében előre fizet, és nem elégítődik ki, viszont ebben az esetben az üzlet nehezen reménykedhet hosszútávon fenntartható vállalkozásban. Illetve jellemzően a felhasználó azután fizet, hogy felmérte a kockázatokat, és ígéretesnek tartja a megoldást. Azért nem magától értetődő értéket előállítani a felhasználó számára, mivel ő gyakran el sem tudja képzelni, hogy elő lehet állni megoldással a fájdalmára. Henry Ford ezt így fogalmazta meg:

"Ha megkérdeztem volna az embereket, hogy mit szeretnének, azt mondták volna, gyorsabb lovakat".

Valójában Henry Ford sosem mondott ilyet, de ez talán nem is olyan fontos most.

Tehát üzleti szempontból pénzhez jutni közvetett módon a felhasználó problémájának megoldásán keresztül lehet, azaz valamilyen termék vagy szolgáltatás által. Ez a rendszere az értékcserének a tech termékfejlesztés területén. 

 Értékcsere a felhasználó és az üzlet között

Mivel az értékteremtés többnyire nem magától értetődő (többnyire nagyobb fejtörést okoz, mint egy keresztrejtvény), ezért ahhoz, hogy ez az értékcsere jól működjön esszenciális, hogy az üzleti oldal képben legyen a felhasználó problémájáról, és a kontextusról, amiben az jelentkezik. Máskülönben nem lehet meghatározni, hogy mi az érték számára. Ha a problémát nem ismerjük elég jól, és az értéket nem határoztuk meg pontosan, akkor beleesünk abba a hibába, hogy a sikerességet például a leszállított funkciók mennyiségében, sztoripontok összegében (velocity-ben), leütött kódsorban, megírt userstory-k darabszámában, a dokumentáció oldalszámában, azaz kibocsátásban (outputban) mérjük. Ezeket a számokat könnyű előállítani, számunkra jól ismertek, és egyszerű őket összehasonlítani, tehát ez kézenfekvő megoldásnak tűnhet. Viszont ha rendszerben gondolkodunk, akkor minket ezek a számok kevésbé érdekelnek. Sokkal inkább releváns nekünk az, hogy mit eredményeztek (outcome) ezek a felhasználó problémájára adott megoldások, azaz hogy mit értünk el a kibocsátással. Először definiálnunk kell az elvárt hatást (desired outcome), ami a felhasználó problémájának megoldása esetén következik be, utána pedig meg kell vizsgálnunk a lehetőségeket (opportunities), amikkel azt a hatást, vagy eredményt el tudjuk érni. A lehetőségeket elemezzük, adatokat, információkat gyűjtünk, majd döntünk az alternatívák közül, és csak a végén jön a fejlesztés, azaz maga a kibocsátás. Majd mérünk, adatokat gyűjtünk, és megnézzük, elértük-e az elvárt hatást a felhasználóknál.

Tudnunk kell, amit nem tudunk

Tehát a megoldani kívánt problémák komplex problémák. Komplex problémák megoldásánál nem tudjuk előre, hogy milyen módon jutunk el a célig. Felmértük a kezdőállapotot, ahol most vagyunk, van egy elképzelt célunk, és ahhoz, hogy a cél felé haladjunk, folyamatos tanulásra, a gondolkodásunk kitágítására, új perspektívák keresésére van szükség. A felhasználó problémájámra adott különböző megoldási lehetőségek vizsgálatánál érdemes csoportosítanunk az ismeret, illetve az ismeretlen területeket annak függvényében, hogy tudatában vagyunk-e, felismertük-e tudásunknak/nem tudásunknak, avagy fogalmunk sincs arról.

Tudatában vagyunk, hogy van tudásunk. Ide tartoznak a bizonyított tények, amik adatokkal, mérésekkel alá vannak támasztva. 

Tudatában vagyunk, hogy nincs tudásunk. Ezen a területen megvannak a konkrét kérdéseink, amiket fel szeretnénk tenni a felhasználónak. Ide tartoznak a hipotéziseink, amiket felállítunk, majd validálunk. 

Nem vagyunk tudatában, hogy van tudásunk. Ez az intuícióink földje, ahol a vénrókák uralkodnak. Rendelkezünk mély tudással a piacról, a tendenciákról, a felhasználókról, tapasztalatunk van a termékfejlesztés terén, ezért rengeteg dolggal képben vagyunk. Viszont óvatosnak kell lennünk, amikor a megérzéseinkre hagyatkozunk, mivel jellemző ránk, hogy kész tényeknek gondoljuk ötleteinket, pedig ezek valójában csak nem bizonyított feltételezések. A veszélyt itt az jelenti, hogy azt gondoljuk a Tények területén vagyunk, pedig meg kellene kérdőjeleznünk saját nem bizonyított feltételezéseinket, hogy aztán tényekkel megerősítést szerezzünk, azaz igazából a Kérdések területe felé kellene elmozdulnunk. 

Nem vagyunk tudatában, hogy nincs tudásunk. Ez az a terület, ahol annyi ismeretünk sincs, hogy kérdéseket tudjunk megfogalmazni. Ezekre a részekre azután derül fény, miután sokat foglalkoztunk a felhasználóinkkal, kutattunk a problémájukról, megfigyeltük őket működés közben, majd elemeztük az adatokat.

Az a folyamat, ami a kérdéseinkre való válaszkeresést, az intuícióink bizonyítását, illetve a teljes homály felfedését eredményezi, a termékfelderítés (product discovery).

Tehát ahhoz, hogy rájöjjünk, mi a felhasználó problémája, milyen megoldás tudja kielégíteni azt a szükségletet, azaz mi jelent neki értéket, amiért pénzt hajlandó fizetni, különböző eszközökkel (pl. a felhasználói interjúkkal, prototípus készítéssel, A/B teszteléssel stb.) kutatnunk kell.

Ha tetszett, iratkozz fel a blogomra, vagy kapcsolódjunk linkedinen.