Mit jelent az embedded delivery
Az embedded delivery azt jelenti, hogy a mérnök nem távolról, a saját cége irodájából dolgozik egy feladaton, hanem beépülve, az ügyfél környezetén belül. A kód, amit ír, az ügyfél valós adatán fut, az ügyfél éles vagy éleshez közeli rendszerein, az ügyfél infrastruktúráján. Ez éles ellentéte annak a klasszikus felállásnak, amelyben egy szakértő egy anonimizált adatmásolaton, offline proof of concepten mutatja meg, hogy egy megoldás elvben működne. Az embedded delivery esetében nincs elvben. A megoldásnak ott és akkor kell működnie, ahol a valós munka történik, és pontosan azokkal a korlátokkal, amelyekkel a szervezet minden nap együtt él.
Ez a különbség nem a helyszínről szól, hanem a hozzáférésről. Az embedded mérnök a valós adathoz, a valós rendszerekhez és a valós szereplőkhöz fér hozzá, nem azok leegyszerűsített modelljéhez. Ezért nem tudja megkerülni azt, ami egy tiszta demóban rejtve marad. A hiányos mezők, az inkonzisztens rekordok, a jogosultsági korlátok és a rendszerhatárok mind a felszínre kerülnek, még mielőtt a megoldás élesbe menne.
A legközelebb a problémához elv
Az embedded delivery mögött egyetlen egyszerű elv áll. A mérnök a lehető legközelebb helyezkedik el a valós problémához. Minden réteg, amely a mérnök és a probléma közé ékelődik, információt veszít. Egy közvetítő, aki továbbadja a kérést, elhagyja a részleteket. Egy anonimizált másolat lecsiszolja azt, ami épp a lényeg. Egy írott specifikáció rögzíti a pillanatnyi értelmezést, de nem tud reagálni arra, amit a mérnök menet közben lát. A távolság tehát nem semleges, hanem költséges, mert éppen a legfontosabb részleteket tünteti el.
A Forward Deployed Engineer ezt a távolságot szünteti meg. Ott dolgozik, ahol a valós adat, a valós rendszerek és a valós döntéshozók vannak. A modell konfigurációját nem elméleti elvárásokhoz, hanem a terepen mért teljesítményigényekhez igazítja. Ha egy éles hiba jelentkezik, azt maga debugolja, nem egy jegyen keresztül üzen róla. A közelség a szerep legfontosabb erőforrása, mert a valós adaton szerzett tapasztalat olyasmit tanít, amit semmilyen leírás nem ad át.
Az eredményért felel, nem a leszállítandóért
A klasszikus szállítói logikában van egy leszállítandó, egy dokumentum, egy prototípus vagy egy demó, amit a mérnök átad, és ezzel a feladat lezárul. Az embedded delivery ennél tovább megy. Itt a mérce nem az átadott anyag, hanem az éles adoptáció és a mérhető munkafolyamat hatás. A kérdés nem az, hogy elkészült-e a megoldás, hanem az, hogy használják-e a valóságban, és mozdít-e egy valós üzleti mutatót. Amíg ez nem teljesül, a munka nincs kész, akármilyen kész a kód.
Ez a felelősség másképp alakítja a döntéseket is. Egy mérnök, aki csak a leszállítandóért felel, megállhat a látványos demónál. Egy mérnök, aki az eredményért felel, tovább dolgozik azon, ami a demó és a megbízható éles rendszer között van, a hibakezelésen, a jogosultságokon, a monitorozáson és a karbantarthatóságon. A siker mércéje az OpenAI megfogalmazásában az éles adoptáció, a mérhető hatás és az eval vezérelt visszajelzés, amely a termék és a modell irányát is alakítja. Ez a szemlélet a szerep magja.
Különálló tanácsadás
- Kívülről, a cég irodájából dolgozik
- Anonimizált vagy szintetikus adatmásolaton
- Egy dokumentumot vagy demót ad át
- A megvalósítás és az eredmény már nem az ő felelőssége
Embedded delivery
- Beépülve, az ügyfél környezetén belül dolgozik
- Az ügyfél valós adatán és éles rendszerein
- Működő megoldást visz éles adoptációig
- A valós használatért és a mérhető hatásért felel
Munka a bizonytalanságban
Az embedded delivery egyik legnehezebb jellemzője, hogy a specifikáció ritkán teljes. A feladat gyakran nem kész leírással érkezik, hanem egy homályos igénnyel, amely mögött a valóság csak menet közben derül ki. Az OpenAI tapasztalata szerint a korai scopingban leírt sokszor nem egyezik azzal, amit a terepen látott adat és rendszer valósága mutat. Ez nem hiba a folyamatban, hanem a folyamat természete. A mérnök feladata épp az, hogy a bizonytalanságban is haladjon, és a hiányzó információt ne kifogásnak, hanem megoldandó feladatnak tekintse.
Ehhez önálló működés kell. Az Anthropic Applied AI leírásában elvárás, hogy a mérnök a bizonytalanságban is helytálljon, autonóm módon működjön, és a céget a legmagasabb szinten képviselje az ügyfélkörnyezetben. A gyakorlatban ez azt jelenti, hogy a mérnök dönt akkor is, amikor nincs teljes kép, majd a döntését a valós adaton igazolja vagy korrigálja. A bizonytalanság tűrése ezért nem passzív türelem, hanem aktív képesség, a haladás fenntartása hiányos információ mellett.
A ritmust az ügyfél diktálja
A megszokott terméktempó egyenletes, kéthetes sprintekben halad. Az embedded delivery ritmusát ezzel szemben az ügyfél operatív határidői adják. Ha egy döntés vagy egy folyamat egy adott naphoz kötött, a megoldásnak addigra kell működnie, függetlenül attól, hogy hol tart a szokásos kadencia. Ezért az embedded munka gyakran intenzív delivery szakaszokban zajlik, amikor a mérnök heti több napot tölt az ügyfélnél, közvetlenül a probléma közelében.
Ez a több hetes, beépült jelenlét a szerep bevett formája. Az Anthropic leírása több hetes sprintekről beszél, amelyeket a mérnök az ügyfélnél tölt, promptok és evalok tervezésével, ügynökök éles bevezetésével és felfedező interjúk futtatásával. Az OpenAI delivery fázisában heti több nap az ügyfélnél töltött idő, az adott probléma megértése, az ügyféladat megszerzése és a megoldás megépítése. A ritmust tehát nem a naptár adja, hanem az, hogy mikor kell a valós munkafolyamatban működnie a megoldásnak.
Egy mérce. Az embedded delivery sikerét nem a leszállított dokumentum méri, hanem az, hogy a megoldás éles használatba kerül és mozdít egy valós üzleti mutatót. Amíg nincs adoptáció, a munka nincs kész.
Bizalom és a technikai kapcsolattartó szerep
A beépült jelenlét bizalmi helyzet. A mérnök hozzáfér az ügyfél valós adatához és rendszereihez, és gyakran vezetői döntésekhez közeli információt lát. Ezért a szerep nem csak technikai, hanem kapcsolati is. A Forward Deployed Engineer az account elsődleges technikai kapcsolattartója. Ő kezeli az architektúra kérdéseket, ő debugolja az éles hibákat, és ő igazítja a modell konfigurációt a valós teljesítményigényekhez. A szervezetben a technikai csapatoktól a vezetőkig sokféle szereplővel áll közvetlen kapcsolatban.
Ez a kapcsolattartói szerep nem másodlagos a mérnöki munka mellett, hanem annak a feltétele. Bizalom nélkül a mérnök nem kapja meg a valós adatot, a rendszerekhez való hozzáférést és a szereplők őszinte visszajelzését, márpedig ezek nélkül az embedded delivery nem működik. A mérnök hitelessége abból fakad, hogy a saját kezével visz megoldást éles működésig, nem csak beszél róla.
A gondolkodásmód, hajlam az építésre
Az embedded delivery központi beállítottsága a hajlam az építésre (bias to build). Hosszú tervezés és teljes specifikáció bevárása helyett a mérnök egy vékony, működő szeletet épít, és abból tanul. A vékony szelet a lehető legkisebb egység, amely mégis teljes, végponttól végpontig működik. Ez azért fontos, mert a valóság gyorsabban kiderül egy futó megoldásból, mint bármilyen leírásból. Az iteráció pedig az ügyféllel a hurokban zajlik. A mérnök megmutatja, amit épített, a szereplők visszajeleznek, és a következő kör ehhez igazodik.
Ez a hurok az, ami az embedded delivery-t egyszerre gyorssá és megbízhatóvá teszi. A gyors építés korán felszínre hozza a valós korlátokat, az ügyféllel közös iteráció pedig biztosítja, hogy a megoldás nem elképzelt, hanem tényleges igényre válaszol. A következő leckében ez a szemlélet folytatódik, ott az ügyfélfelfedezés és a problémakeretezés kerül a középpontba, vagyis az, hogyan találjuk meg a valós problémát, mielőtt bármit építenénk.
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 →