FDE Műhely

Fogalomtár

Mi az a Forward Deployed Engineer?

Egy mérnök, akit nem a saját irodájában találsz meg, hanem az ügyfélnél. Feltérképezi, hogyan megy ott a munka valójában, eldönti, hova való egyáltalán az AI, és meg is építi. A szerepet a Palantir tette ismertté, és ma ez a technológia egyik legkeresettebb pozíciója.

A rövid válasz

A forward deployed engineer — magyarul leginkább előretolt mérnök — az a szerep, amelyik összeköti azt, amit a technológia tud, azzal, ahogy egy adott cég valójában működik. Nem tanácsadó, mert kódot ír. Nem klasszikus fejlesztő, mert a munkája fele az ügyfél irodájában, emberekkel beszélgetve telik.

A kifejezés katonai eredetű: az előretolt egység nem a bázison várja, hogy megérkezzen hozzá a feladat, hanem kimegy a terepre. Ugyanez a logika: nem az ügyfél jön el a termékhez, hanem a mérnök megy el az ügyfélhez.

Miért pont most lett ebből a legkeresettebb szerep

Néhány évvel ezelőtt még kérdés volt, kinek lesz hozzáférése a jó modellekhez. Ma minden cég meg tudja venni ugyanazt. Ha ötven vállalatnál megnézed a stacket, nagyjából ugyanazt találod.

Ha viszont mindenkinél ugyanaz az alapképesség, akkor az intelligencia már nem versenyelőny. Az előny oda kerül, hogy ki hova és hogyan építi be. Ez pedig nem modellkérdés, hanem folyamatkérdés — és emberkérdés.

Az FDE munkájának három szakasza

1. Megérteni, hogyan megy a munka valójában

Ez a legtöbb időt elvivő rész, és ezt szokták a legjobban alábecsülni. Minden cég másképp csinálja ugyanazt. Két hasonló méretű vállalatnál a szállítói számlák feldolgozása az egyiknél tíz lépés, a másiknál harminc; az egyik Salesforce-t és Gongot használ, a másik HubSpotot és Clayt. Ráadásul a kivételek — az, hogy mi történik, ha valami elromlik — szinte soha nincsenek dokumentálva.

Erről külön is írtunk: a dokumentált folyamat és a valódi folyamat.

2. Eldönteni, hova való az intelligencia — és hova nem

Ez az FDE ítélete, és ez a szerep legértékesebb része. Egy tízlépéses munkafolyamatban jellemzően kettő-három lépés az, ahol tényleg ítéletre van szükség. A többi determinisztikus szoftverrel gyorsabban, olcsóbban és megbízhatóbban megoldható.

Az is legitim válasz, hogy egy folyamathoz nem kell hozzányúlni: mert túl kockázatos, mert túl kicsi a megtérülés, vagy mert már eleve automatizált.

3. Megépíteni és élesbe vinni

Cégenként nagyon eltérő, mennyi tényleges kódolást jelent. Van, ahol egy meglévő platformon konfigurálsz, és a kód SQL-ben merül ki. Van, ahol produkciós rendszert írsz. A közös pont az, hogy amikor élesben elromlik valami, a te neved van rajta — tudnod kell, mit kell csinálni.

A szerep nehézsége: két külön szakma egy emberben

Az FDE nem a két készséghalmaz átlaga, és főleg nem a rosszabbik feléből összerakva. A jó FDE mindkét oldalon erős — ezért ritka, és ezért drága.

Amit egy jó tanácsadó tud

Az üzleti oldal

  • Munkafolyamatok felvétele megfigyeléssel
  • Költség, kockázat és ösztönzők értése
  • Bevezetés és elfogadtatás a szervezetben
  • Belső politika és szponzorkezelés
  • Üzleti érték számokban kimondva

Amit egy jó szoftvermérnök tud

A mérnöki oldal

  • Rendszertervezés, API-k, adatmodellek
  • Ágensek, eszközhasználat, kontextuskezelés
  • Evalok, guardrailek, hibamódok
  • Megbízhatóság, naplózás, monitorozás
  • Produkciós kód és üzemeltetés

A piac tele van olyan „FDE"-vel, aki egyik oldalon sem elég erős. Ez a szerep akkor termel értéket, ha az üzleti megértést végig ugyanaz az ember viszi el a működő szoftverig.

Mikor érdemes FDE-t szerződtetni?

  • Ha van egy folyamatotok, ami sok kézi munkaórát visz el, és senki nem tudja pontosan megmondani, hány lépésből áll.
  • Ha már volt egy AI-pilot, ami demóban működött, élesben nem.
  • Ha a belső fejlesztőcsapatnak nincs kapacitása heteket tölteni egy másik osztály folyamatának a felvételével.
  • Ha meg kell tudnotok mondani a vezetőségnek számokban, hogy egy AI-beruházás mit hozott.

Ha ezek közül bármelyik ismerős, nézzétek meg, hogyan dolgozunk, vagy írjatok.

Gyakori kérdések

Az FDE ugyanaz, mint egy solution architect?

Nem. A solution architect jellemzően tervez, és a megvalósítást átadja. Az FDE ugyanaz az ember, aki felvette a folyamatot, meg is építi, és élesben is felel érte. A tervezés és a megvalósítás közötti információveszteség az, amit ez a szerep megszüntet.

Miért kell helyszíni jelenlét, ha távolról is lehet dolgozni?

Egy egyórás online meetingen azt kapod meg, amit a kolléga a munkájának gondol. Egy teljes munkanapon mellette ülve azt kapod meg, ami a munkája — beleértve azt is, amikor valami elromlik, és ő ösztönösen megoldja anélkül, hogy ez bárhol dokumentálva lenne. Vegyes modellben dolgozunk: a felmérés helyszíni, az építés jellemzően távoli.

Mennyibe kerül egy FDE Magyarországon?

A nemzetközi piacon ez a szerep az egyik legdrágább technológiai pozíció. Magyarországon a napidíjas és a beépülő konstrukció is elérhető; a nagyságrendekről az Árak oldalon írunk.

Nekünk van saját fejlesztőcsapatunk. Akkor is kell FDE?

Gyakran pont akkor a leghasznosabb. A belső csapat ismeri a rendszereket, de ritkán van kapacitása heteket tölteni egy másik osztály folyamatának a felvételével — és ritkán van rutinja abban, hogy egy nem determinisztikus rendszert hogyan kell kiértékelni. Sok esetben az FDE a belső csapattal együtt dolgozik, nem helyettük.