Kim jest forward deployed engineer?

„Forward deployed engineer” to nazwa stanowiska, która zaczęła się pojawiać wszędzie tam, gdzie firmy kupują oprogramowanie. Brzmi jak żargon i w połowie nim jest: „forward deployed” pochodzi z wojska, gdzie oznacza rozmieszczenie blisko miejsca działań, a nie w kwaterze głównej. Jeśli odłożyć tę pożyczoną połowę, zostaje coś prostego. Forward deployed engineer to doświadczony inżynier, który pracuje wewnątrz Twojej firmy, przy Twoim problemie, zamiast patrzeć na niego z dystansu.

Ta różnica znaczy więcej, niż się wydaje. Prace techniczne, które kupujesz, mają zwykle jeden z dwóch kształtów. Albo kupujesz dokument, w którym ktoś bada Twoją firmę i oddaje rekomendację, albo kupujesz projekt, w którym ktoś zabiera spisaną specyfikację i wraca z gotowym oprogramowaniem. Oba kształty zakładają, że trudną częścią jest wykonanie pracy, a pytanie było jasne, zanim ktokolwiek zaczął. W wielu projektach z AI to założenie jest po prostu błędne. Trudną częścią jest ustalenie, co system naprawdę musi obsłużyć, a dowiadujesz się tego, uruchamiając coś na prawdziwych sprawach z zeszłego miesiąca, a nie pisząc dłuższą specyfikację.

Model forward deployed jest odpowiedzią na ten problem. Zamiast dostać specyfikację, inżynier siada tam, gdzie wykonywana jest praca, obserwuje jeden pełny cykl, ustala jeden wynik z osobą, która może powiedzieć „tak”, i buduje w jego stronę, zmieniając kurs, gdy prawdziwe przypadki pokazują, czego nie przewidział. Odpowiada za rezultat, a nie za listę zadań. Kiedy to działa, klient zauważa różnicę nie w technologii. Zauważa, że nikt nie czeka, aż ktoś inny coś spisze.

Skąd wzięła się ta nazwa

Nazwę spopularyzował Palantir, amerykańska firma software'owa, która od lat publicznie używa jej na własnych stronach z ofertami pracy: opisuje tak inżynierów wysyłanych do pracy u klienta, zamiast budowania produktu na dystans. Wzorzec się rozszedł. Laboratoria AI i dostawcy oprogramowania dla firm publicznie rekrutują dziś na stanowiska o tej lub bardzo zbliżonej nazwie, bo to, co sprzedają, trzeba dopasować do danych i procesów każdego klienta, zanim zacznie być cokolwiek warte.

Jest szczery powód, dla którego ten model istnieje. Systemy ogólnego przeznaczenia rozwiązują ogólną część problemu, a potem się zatrzymują. Wartość, która zostaje, jest zamknięta w bałaganie konkretnej firmy: w wyjątkach, w lokalnych zasadach, w arkuszu, który ktoś prowadzi ręcznie, w trzech systemach opisujących tego samego klienta inaczej. Żadna ilość pracy nad produktem z dystansu tego nie odblokuje. Jedyne wejście prowadzi przez wysłanie kogoś w ten bałagan.

Czym taka osoba naprawdę się zajmuje

Pierwsze dwa miesiące wyglądają podobnie wszędzie tam, gdzie ten model działa. Pierwszy tydzień to obserwowanie pracy i uzyskanie dostępu do systemów, których ona dotyka, a kończy się jedną stroną opisu: jaki jest wynik i jak będzie mierzony. Dobry forward deployed engineer spędza w tym tygodniu więcej czasu na pytaniach niż na pisaniu kodu i to nie jest opóźnienie: to od tego zależy, czy reszta pracy jest w cokolwiek wycelowana.

• Tydzień pierwszy: obserwacja jednego pełnego cyklu pracy, dostępy i jedna strona z opisem wyniku oraz miary.
• Tydzień drugi: coś wąskiego działa na prawdziwych danych, na oczach ludzi, których pracy to dotyczy.
• Potem: błędy, które popełnia, są specyfikacją dla reszty pracy.
• Około drugiego miesiąca: produkcja, nadzór człowieka i dokumentacja, dzięki której zespół prowadzi to sam.

Czym to się różni od tego, co już kupujesz

Firma doradcza zostawia dokument. To dobry zakup, kiedy wąskim gardłem jest decyzja. To zły zakup, kiedy wszyscy już się zgadzają, co powinno się wydarzyć, a nic się nie dzieje. Forward deployed engineer zostawia zamiast tego działający system, co jest mniej warte niż dokument, jeśli trudną częścią była decyzja, i dużo więcej warte, jeśli nie była.

Kontraktorzy i outsourcing zespołów sprzedają moce przerobowe. Ktoś po Twojej stronie pisze zadania i bierze na siebie ryzyko, że poprosi o niewłaściwą rzecz, a dostawcę ocenia się po tym, czy zadania zostały zamknięte. Forward deployed engineer jest oceniany po tym, czy proces stał się szybszy albo tańszy, i współdecyduje o tym, co powstaje.

Projekt o stałym zakresie wymaga, żeby odpowiedź była znana przed startem. Kiedy jest, wybierz stały zakres: jest tańszy, a ryzyko błędnej wyceny bierze na siebie dostawca. Kiedy nie jest, stała cena albo zostanie zawyżona na zapas, co czyni ją drogą, albo będzie egzekwowana co do litery, co daje dokładnie to, co spisano, i nic, czego ktokolwiek potrzebował.

Kiedy to dobry wybór

• Umiesz wskazać proces, który kosztuje Twój zespół najwięcej godzin, ale nie wiesz, jak go naprawić, i nikt u Ciebie tego nie zbuduje.
• Ktoś dostarczył dokument o szansach na AI w Twojej firmie i od tego czasu nic nie ruszyło.
• Rekrutacja zajęłaby miesiące, a nie jest jeszcze pewne, czy ta praca uzasadnia etat.
• Trudną częścią procesu są wyjątki, więc każdy zakres spisany dzisiaj byłby zgadywaniem.

Te cztery przypadki łączy jedno: pytanie wciąż jest otwarte. Kiedy pytanie jest otwarte, kupowanie wyniku wygrywa z kupowaniem planu albo pary rąk.

Kiedy to zły wybór

• Wiesz dokładnie, co ma powstać. Kup wykonanie: jest tańsze, a ryzyko bierze dostawca.
• Nikt po Twojej stronie nie podejmie decyzji w tydzień. Ten model żyje szybkim „tak” albo „nie”, a bez tego inżynier stoi, a Ty płacisz za ten postój.
• Dostęp do danych i systemów zajmie trzy miesiące zgód. Zegar i tak tyka.
• Naprawdę potrzebujesz więcej rąk do istniejącego backlogu. To outsourcing zespołu, inny i tańszy produkt.

Dostawca, który nigdy nie powie Ci, że jeden z tych punktów dotyczy właśnie Ciebie, coś Ci sprzedaje. Nie pytaj, czy robi forward deployed engineering. Pytaj, od czego by Cię odwiódł.

O co zapytać, zanim się zgodzisz

• Kto dokładnie wejdzie do zespołu i czy mogę z tą osobą porozmawiać przed podpisaniem czegokolwiek?
• Co zostanie spisane na koniec pierwszego tygodnia i jak będzie mierzony wynik?
• Co będzie działać na prawdziwych danych produkcyjnych na koniec drugiego tygodnia?
• Gdzie mieszka kod i do kogo należy, jeśli współpraca skończy się wcześniej?
• Jaki jest okres wypowiedzenia i czy jest opłata za wyjście?

W Pluscode pracujemy w ten sposób, bo to jedyny znany nam sposób, żeby wyciągnąć wynik z tych zabałaganionych, konkretnych i w połowie opisanych procesów, na których stoją prawdziwe firmy. Jeśli umiesz nazwać zadanie, które kosztuje Twój zespół najwięcej godzin, poświęcimy mu trzydzieści minut z inżynierem, który wykonałby tę pracę, i powiemy szczerze, czy to właściwa droga, czy wystarczy coś mniejszego i tańszego. Ta rozmowa nic nie kosztuje i do niczego nie zobowiązuje.