Miért a felfedezés az igazi első lépés
A Forward Deployed Engineer szerep magja, hogy egy mérnök beépül az ügyfél környezetébe, és ott old meg valós problémát. A gyakorlatban azonban a legnagyobb kockázat nem az, hogy a megoldás rosszul épül fel, hanem az, hogy jól felépített megoldás születik a rossz problémára. Az FDE ezért nem az első naptól kódot ír, hanem előbb megérti, mi is a feladat. A szerep egyik jól dokumentált vonása, hogy a mérnök rengeteg bizonytalanságban dolgozik, és amit az ügyfél leír, az gyakran nem egyezik az adat és a rendszer valóságával. A felfedezés célja pontosan ennek a szakadéknak a felmérése, még mielőtt bármi épülne.
A felfedezés nem előkészítő formalitás, hanem az FDE első érdemi mérnöki munkája. Itt dől el, hogy melyik feladat éri meg az erőforrást, hol van egyáltalán használható adat, és milyen rendszerhatárok szabják meg a mozgásteret. Aki ezt a szakaszt átugorja, az az építés közepén szembesül azzal, hogy a kért funkcióhoz nincs adat, vagy hogy a valós szűk keresztmetszet egészen máshol van. A jó felfedezés így nem lassítja a projektet, hanem megvédi a felesleges építéstől.
Az elhangzott kérés és a valós probléma
A megbízások jó része egy megoldás nyelvén érkezik, nem egy probléma nyelvén. Az ügyfél nem azt mondja, hogy sok időt veszítünk a beérkező dokumentumok kézi feldolgozásán, hanem azt, hogy építsünk egy chatbotot. A kettő nem ugyanaz. Az elhangzott kérés egy feltételezett megoldás, amelyet valaki már megfogalmazott a fejében. A valós probléma az az üzleti fájdalom, amely mögötte áll. Az FDE dolga, hogy a kérés mögött megtalálja a fájdalmat, mert csak arra lehet értékes megoldást építeni.
Ez a különbségtétel a szerep lényegéből fakad. Mivel a mérnök egy ügyfélre koncentrál sok képességgel, nem egy általános funkciót szállít, hanem egy konkrét munkafolyamat konkrét szűk keresztmetszetét oldja meg. Ehhez a felszíni kérést vissza kell bontani. A jó kérdés nem az, hogy milyen legyen a chatbot, hanem hogy melyik lépésen múlik a legtöbb idő, kockázat vagy hiba abban a folyamatban, amelyben az ügyfél dolgozik.
Folyamattérképezés a valós adaton
A keretezés akkor válik pontossá, amikor a mérnök végigköveti a tényleges munkafolyamatot, nem annak leírását. A folyamattérképezés (process mapping) azt jelenti, hogy lépésről lépésre rögzítjük, ki mit csinál, milyen rendszerben, milyen bemenetből milyen kimenetet állít elő, és hol keletkezik várakozás, hiba vagy döntés. Ez az FDE szerep egyik megkülönböztető vonása. A mérnök nem anonimizált, laborban tisztított adaton dolgozik, hanem az ügyfél valós rendszerein és valós adatán, ezért azonnal látja azt, ami egy tiszta bemutatóban rejtve marad.
A terepen szinte mindig kiderül, hogy a folyamat máshogy működik, mint ahogy a dokumentáció vagy a vezetői összefoglaló állítja. A mezők hiányosak, a rekordok ellentmondanak egymásnak, a felhasználók pedig kézi kerülőutakat építettek a rendszer korlátai köré. Ez nem baj, hanem információ. Épp ezek a pontok mutatják meg, hol van valós fájdalom, és hol tud egy AI megoldás mérhető értéket adni. A folyamattérkép így egyszerre lesz a problémakeretezés és a későbbi architektúra alapja.
- Kövesd a folyamatotVégig a valós lépéseken, nem a leíráson. Ki, mit, milyen rendszerben, milyen adatból.
- Keresd a szűk keresztmetszetetHol keletkezik a legtöbb idő, hiba, várakozás vagy kockázat a folyamatban.
- Nézd meg az adatotLétezik-e, elérhető-e, elég tiszta-e ahhoz, hogy egy megoldás rá tudjon épülni.
- Keretezd a problémátEgy mondatban, mérhetően. Melyik lépést, mennyivel, kinek javítjuk.
- Rögzítsd a sikerkritériumotMihez képest lesz jobb, és hogyan fogjuk ezt megmérni még az építés előtt.
A use case kiválasztása: érték és megvalósíthatóság
A felfedezés ritkán egyetlen problémát talál, hanem többet. A mérnöki döntés az, hogy melyikkel érdemes kezdeni. Két tengely mentén érdemes mérlegelni. Az egyik az üzleti érték, vagyis mennyit számít az ügyfélnek, ha ezt a lépést megoldjuk. A másik a megvalósíthatóság, amelybe beletartozik az adat elérhetősége és minősége, a rendszerhatárok, a jogosultsági korlátok és a technikai kockázat. A jó első use case az, amelyik mindkét tengelyen elég magasan van, magas értékű, de reálisan megépíthető a rendelkezésre álló adatból és környezetben.
A gyakori hiba a látványos, de nem megvalósítható eset választása, ahol az érték nagy, de az adat nincs meg, vagy a jogosultsági korlát élesben nem enged hozzáférést. Szintén hiba a könnyű, de érdektelen eset, amely megépül, de senkinek nem hiányzott. Az FDE célja egy olyan első szelet, amely elég értékes ahhoz, hogy az ügyfél komolyan vegye, és elég biztos ahhoz, hogy tényleg élesbe menjen. A jól választott első eset bizalmat és lendületet ad a következő szeletekhez.
A sikerkritérium meghatározása előre
A felfedezés kimenete nem lehet pusztán egy jó ötlet. Kell hozzá egy mérhető sikerkritérium, amelyet még az építés előtt rögzítünk. Ez azért fontos, mert az AI megoldások minősége nem magától értetődő. Egy demó lenyűgöző lehet, miközben élesben megbízhatatlan. A sikerkritérium az a mérce, amelyhez képest eldönthető, hogy a megoldás valóban jobb-e a mai állapotnál. A jó kritérium konkrét és megfigyelhető, például egy lépés átfutási idejének csökkenése, a kézi javítások arányának mérséklődése, vagy egy döntés pontosságának javulása egy elfogadott alapállapothoz képest.
A sikerkritérium egyben a későbbi evalok magja is. Ha előre tudjuk, mit jelent a jó válasz ebben a konkrét munkafolyamatban, akkor abból mérhető ellenőrzés építhető, amely a fejlesztés alatt és élesben is figyeli a minőséget. A felfedezés végén ezért mindig ott áll három elem együtt. Egy mondatban a keretezett probléma, mellette a rögzített sikerkritérium, és az a megállapítás, hogy az ehhez szükséges adat elérhető és használható. Ez a három adja a következő lépés, a gyors prototípus szilárd alapját.
Három dolog a felfedezés végén. Egy mondatban keretezett, valós probléma. Egy mérhető sikerkritérium, amelyet előre rögzítünk. És a megerősítés, hogy a szükséges adat létezik és elérhető. Ez a három együtt véd meg attól, hogy jó megoldás szülessen a rossz problémára.
A felfedezés mint bizalomépítés
A felfedezésnek van egy második, kevésbé látható haszna. Amikor a mérnök végigjárja a folyamatot, kérdez, és a valós adatra alapoz, azzal bizalmat épít az ügyfél csapatánál. A felhasználók látják, hogy valaki tényleg megérti a munkájukat, nem egy általános terméket akar rájuk erőltetni. Ez a bizalom később, a bevezetésnél és a stakeholder kommunikációnál térül meg, mert a megoldás nem kívülről érkezik, hanem a közösen feltárt problémára válaszol.
A jól elvégzett felfedezés így nemcsak a helyes problémát adja meg, hanem a kapcsolatot is, amelyen a projekt élni fog. A következő lecke onnan folytatja, ahol a felfedezés véget ér. Miután a probléma keretezett és a siker mérhető, jön a gyors prototípus, amely a legrövidebb úton, egy vékony vertikális szeleten mutatja meg, hogy a megoldás valóban működhet.
Workshop
AI Transformation Day
Egésznapos, vezetőknek szóló program. Feltérképezzük, hol tart a szervezet, mi az első reális lépés, és milyen belső feltételek szükségesek a sikerhez. A nap végén konkrét, prioritizált cselekvési lista.
Érdekel a program →