Czym jest Forward Deployed Engineer i dlaczego brzmi tak znajomo?

Najważniejsze wnioski:

  1. Forward Deployed Engineer to rola, w której jedna osoba rozumie problem biznesowy i buduje rozwiązanie.

  2. Rola eksploduje przez AI. Szybkie budowanie przestało być trudne. Trudne jest zrozumienie, co budować.

  3. Większość projektów software'owych nie upada przez zły kod. Upada, bo ktoś bardzo dobrze zbudował nie to, co trzeba.

  4. Idea FDE nie jest nowa. Dobre zespoły software'owe zawsze tak pracowały. Dolina Krzemowa po prostu zaczęła szukać takich ludzi pod konkretną nazwą stanowiska.

Niedawno trafiłam na nazwę stanowiska, której wcześniej nie widziałam.

Forward Deployed Engineer.

Uznałam, że to jakaś niszowa rola infrastrukturalna, i przewinęłam dalej. Potem zobaczyłam ją znowu. I jeszcze raz.

Okazuje się, że to obecnie jedno z najszybciej rosnących stanowisk w Dolinie Krzemowej. A kiedy sprawdziłam, co to właściwie znaczy, pierwsza myśl była taka: przecież tak wygląda dobre tworzenie oprogramowania od zawsze?

Czym to w ogóle jest?

Definicja

Forward Deployed Engineer (FDE) — inżynier oprogramowania osadzony bezpośrednio w organizacji klienta, który rozumie problem biznesowy i buduje techniczne rozwiązanie. W przeciwieństwie do tradycyjnych programistów pracujących na podstawie specyfikacji, FDE jest blisko klienta przez cały projekt i dostosowuje rozwiązanie do tego, co naprawdę dzieje się w realnym środowisku.

Termin pożyczono z wojska, gdzie żołnierz wysunięty do przodu stacjonuje blisko miejsca, w którym naprawdę coś się dzieje. W tech idea jest ta sama: ktoś blisko problemu, a nie zarządzający nim z oddali.

Taki sposób pracy istniał zawsze w dobrych zespołach software'owych. Nowością jest to, że Dolina Krzemowa szuka teraz takich ludzi pod konkretną nazwą stanowiska.

Forbes ujmuje to prosto: FDE są najbardziej wartościowi w dynamicznych, szybko zmieniających się środowiskach, gdzie utrzymanie spójności z biznesem wymaga stałej obecności, a nie jednorazowego przekazania projektu.

To ważne rozróżnienie. FDE to nie tylko ktoś, kto coś buduje. To ktoś, kto rozumie, co trzeba zbudować i dlaczego, i odpowiada za to, żeby to naprawdę działało w środowisku, dla którego powstało.

Dlaczego wszyscy teraz szukają takich ludzi?

Krótka odpowiedź: AI.

Narzędzia AI sprawiły, że zbudowanie czegoś szybko jest łatwiejsze niż kiedykolwiek. Ale szybko nie znaczy dobrze. Większość korporacyjnych projektów AI nie upada dlatego, że model był kiepski. Upada, bo nikt nie dopilnował, żeby rozwiązanie pasowało do organizacji, której miało służyć.

Model działa. Wdrożenie nie.

Ktoś wciąż musi zrozumieć procesy, przypadki brzegowe i to, kto z jakiego narzędzia korzysta i po co. Ktoś musi usiąść z ludźmi, którzy faktycznie będą z tego korzystać, i ustalić, czego naprawdę potrzebują. AI tego nie zrobi. Zrobi to dobry inżynier, który był w tym pokoju.

The New Stack opisuje to świetnie: gdy AI przyspiesza pisanie kodu, wąskie gardło się przesuwa. Trudne nie jest już budowanie. Trudne jest zrozumienie, co w ogóle budować.

To nie jest nowa myśl. Po prostu branża w końcu nadała jej nazwę stanowiska.

Co to oznacza, jeśli coś budujesz

Trend FDE to sposób, w jaki branża przyznaje coś, co wielu founderów wie z własnego doświadczenia.

Przekazanie briefu zespołowi deweloperskiemu i czekanie na efekt nie działa tak dobrze, jak się wydaje. Coś ginie po drodze. Zespół buduje to, co mu powiedziano, a niekoniecznie to, czego naprawdę było trzeba. A zanim ktokolwiek to zauważy, prawdziwy czas i pieniądze są już wydane.

To nie jest kwestia braku umiejętności. To kwestia odległości. Deweloper był za daleko od problemu, żeby wyłapać rozjazd.

Lepsze podejście to ktoś blisko problemu przez cały czas. Ktoś, kto rozumie kontekst biznesowy, a nie tylko specyfikację techniczną. Ktoś, kto wychwyci rozjazd, zanim zrobi się drogi.

Brzmi to oczywiście. W praktyce jest zaskakująco rzadkie, i właśnie dlatego to dziś jedna z najbardziej poszukiwanych kompetencji w Dolinie Krzemowej.

Dlaczego w Rocksoft brzmi to znajomo

Kiedy czytałam o tym, co robią Forward Deployed Engineers, cały czas myślałam o tym, jak pracujemy my.

Zanim ruszy jakikolwiek build, robimy Discovery Workshop. To uporządkowana sesja, na której ustalamy, czego naprawdę potrzeba, zanim ktokolwiek napisze linijkę kodu. Nie dlatego, że to proces, którego się trzymamy, tylko dlatego, że widzieliśmy, co się dzieje, gdy się go pominie.

A co się dzieje, gdy się go pominie?

Budujesz niewłaściwą rzecz, i to bardzo dobrze.

W usłudze AI Engineering Partner działa to samo myślenie. AI potrafi generować szybko. Nasi inżynierowie pilnują, żeby to, co powstaje, było właściwe, bezpieczne do wdrożenia i naprawdę powiązane z potrzebami biznesu.

Do niedawna nie wiedziałam, że „Forward Deployed Engineer” to nazwa stanowiska. Ale idea, która za nim stoi, czyli najpierw zrozum problem, potem buduj, to coś, co robimy od samego początku.

Szerszy wniosek

Dolina Krzemowa zaczyna nadawać nazwę stanowiska czemuś, co najlepsze zespoły software'owe zawsze robiły po cichu.

Firmy, które najwięcej wyciągają z AI i z oprogramowania w ogóle, to nie te, które poruszają się najszybciej. To te, które mają kogoś w pokoju, kto zadaje właściwe pytania, zanim ruszy build.

Tym właśnie jest Forward Deployed Engineer. A jeśli ta koncepcja do ciebie przemawia, to pewnie dlatego, że różnicę między zespołem, który zrozumiał twój problem, a takim, który go nie zrozumiał, znasz już z własnego doświadczenia.

Autor:Emilia CzyżO autorze

Content Marketerka w Rocksoft. W dzień gotuje content, wieczorem jedzenie. Po pracy miłośniczka jogi i książek.