Modelul forward deployed engineer pune un inginer care construiește în firma clientului lângă un al doilea om, care răspunde de scope, de măsura succesului și de adopție. Începe cu un scoping scurt la sediu, stabilește succesul în scris, livrează un singur use case și planifică predarea. Palantir l-a inventat. O firmă mijlocie poate împrumuta aproape tot.
Ce urmează e construit doar din ce au publicat companiile: articole pe blog, anunțuri de angajare, interviuri și, pentru Palantir, prospectul de listare la bursă. Rezultatele raportate sunt afirmațiile lor, așa că le las deoparte. Structura e partea care merită copiată.
Cum lucrează Palantir cu forward deployed engineers?
Palantir pune împreună un om care construiește și unul care răspunde de rezultat, Delta și Echo din ce este un forward deployed engineer, și îi așază într-un model comercial pe care prospectul din 2020 îl numește Acquire, Expand, Scale. Compania face piloți „generally at our own expense”, în general pe banii ei, și își descrie inginerii din teren ca pe un braț al cercetării și dezvoltării (Palantir S-1). Ce învață inginerii la un client se întoarce în produs pentru următorul.
O parte nu se mută: pilotul gratuit. Palantir și-l permite pentru că un client câștigat devine ani de licențe software. O firmă care cumpără servicii de inginerie n-are în spatele pilotului nicio afacere cu licențe care să-l plătească.
Cum lucrează OpenAI cu forward deployed engineers?
Versiunea OpenAI e cea mai bine documentată, printr-un interviu pe care Colin Jarvis, șeful echipei de forward deployed engineering, l-a dat pentru The Pragmatic Engineer. Are trei faze. Scoping-ul: câteva zile la client („A couple of days onsite”). Validarea, în care se stabilesc criteriile de succes și evaluările și care se încheie cu un raport final despre cum au ieșit evaluările față de obiective. Apoi livrarea, la sediul clientului, „typically for a few days per week”, de obicei câteva zile pe săptămână (The Pragmatic Engineer).
Alte două obiceiuri sunt relatate indirect. Potrivit relatării TNW despre prezentarea lui de la HumanX, Jarvis a povestit că le cere liderilor să lase AI-ul deoparte și să numească întâi cele mai mari pârghii din business-ul lor și a spus că FDE-ii OpenAI nu au niciun stimulent financiar legat de cât e folosit produsul. Amândouă arată în aceeași direcție: inginerul e acolo ca să miște o cifră de business, nu ca să vândă mai mult produs.
Cum lucrează Wonderful cu forward deployed engineers?
Wonderful, care construiește agenți AI pentru companii mari, publică cea mai clară versiune a perechii. Echipa are un forward deployed engineer care „Makes it work”, face lucrurile să meargă, și un Deployment Strategist care „Makes it matter”, face să conteze: use case-uri, metrici, business case și adopție. Strategistul e măsurat după rezultatele financiare ale clientului, „measured on customer P&L outcomes” (Wonderful, cariere).
Fazele lor sunt cele mai explicite despre plecare. Stau sub titlul „From Wonderful-led to full client ownership, by design”, adică de la o implementare condusă de Wonderful la un client care deține totul: întâi un use case în producție, apoi pregătirea echipei clientului să construiască, apoi preluarea producției de către client. Faza din mijloc încape într-o propoziție: construiesc împreună cu echipele clientului și le pregătesc pe parcurs, ca acestea să poată construi și după plecarea lor (Wonderful).
Ce adaugă Anthropic, Salesforce și Sierra?
Anthropic îi dă celui care răspunde de rezultat o fișă a postului mai precisă. Technical Deployment Lead-ul „won't write production code”, nu scrie cod de producție, și duce colaborarea de la un SOW semnat la un roadmap ordonat, cu milestone-uri clare, dependențe, criterii de succes și ipoteze de valoare (Anthropic). Salesforce dimensionează echipa pentru implementările Agentforce la „a nimble team of two FDEs and one Deployment Strategist”, doi FDE și un Deployment Strategist (Salesforce).
Sierra începe fiecare implementare cu un workshop de design de 90 de minute și, după lansare, scrie că se întâlnește săptămânal cu oamenii clientului (Sierra). Decagon adaugă economia repetiției: fiecare implementare face următorul agent mai ușor de construit (Decagon).
Ce tipare au în comun echipele de forward deployed engineering?
Pune companiile una lângă alta și se repetă șapte tipare.
| Tipar | Ce înseamnă | Cine îl folosește |
|---|---|---|
| Un om care construiește și unul care răspunde | Unul scrie codul; celălalt răspunde de scope, de măsura succesului și de adopție | Palantir, Wonderful, Salesforce, Anthropic |
| Scoping scurt înainte de orice construcție | Zile sau ore cu clientul, nu luni de discovery | OpenAI, Sierra, Wonderful |
| Succesul în scris, înainte | Criterii și evaluări stabilite înainte de construcție | OpenAI, Anthropic |
| Un use case, apoi extindere | Întâi producția, al doilea use case după | Wonderful, Palantir |
| Judecat după rezultatul de business | Nu după utilizare, ore sau licențe vândute | Palantir, OpenAI, Wonderful |
| O plecare planificată | Pregătirea echipei clientului și predarea, ca faze cu nume | Wonderful |
| Ceva refolosibil din fiecare implementare | Ce te învață un client intră în următorul proiect | Palantir, Decagon |
Ce poate împrumuta o firmă mijlocie din modelul forward deployed?
Aproape tot, la o scară mult mai mică. Așa aș traduce fiecare tipar pentru o firmă de 50 până la 1.000 de oameni:
- Un singur use case. Nu un program. Un proces, ales pentru că te costă ceva măsurabil în fiecare săptămână.
- Un om care construiește și unul care răspunde. Un inginer senior construiește; al doilea om răspunde de scope, de măsura succesului și de adopție. Fără el, inginerul ajunge, încet, să preia tichete.
- Scoping la sediu. O dimineață în firmă, cu oamenii care rulează procesul, pentru că felul în care e descris un proces într-o ședință rar seamănă cu ce arată datele lui.
- Criterii de succes în scris. Un baseline măsurat înainte de construcție, un milestone de producție și o cifră de adopție, semnate de un sponsor numit.
- O parte din săptămână. Cam trei zile pe săptămână pentru un use case, aproape de „few days per week” de la OpenAI.
- Un plan de plecare. Un inginer de-al vostru lucrează alături din prima săptămână, iar la predare rămâneți cu codul, documentația și setul de evaluare.
- O piesă refolosibilă. Fiecare colaborare lasă un template, o rețetă de integrare sau un set de evaluare de la care poate porni al doilea use case.
Două lucruri e mai bine să rămână la vendorii mari: pilotul gratuit, care are nevoie de o afacere cu licențe în spate, și echipa de trei. O firmă mijlocie are nevoie de un inginer și de un om care răspunde de rezultat. De ce are nevoie de ei mai mult decât de încă o licență am scris în de ce nu ajunge software-ul AI.
La Sapio lucrăm exact în forma asta. Totul începe cu formularul de contact de pe sapio.ro și o discuție scurtă. Apoi îți trimit o ofertă făcută pe măsură, după complexitatea și nevoile proiectului: consultanță AI sau Tech Audit-ul, o dimineață la voi la sediu și un raport în trei zile lucrătoare. După aceea vin un roadmap de transformare, cu criteriile de succes scrise, și un inginer senior în echipă, cam trei zile pe săptămână, care răspunde de un singur use case până când rulează în producție, iar eu sunt omul care răspunde de rezultat din partea noastră.
Scurtătura Palantir pentru Delta era „one customer, many capabilities”, un client și multe capabilități. Pentru o firmă mijlocie aș întoarce-o: un client, o capabilitate și o dată la care inginerul pleacă. Plecarea e partea care dovedește că restul a funcționat.
Dacă te întrebi cu ce use case să începi: vladtudor.com/consultant-ai.