Jak zatrudnić Forward Deployed Engineera: brief, próba pracy i odbiór
Zacznij od procesu klienta, który ma się zmienić. Opisz wynik, dostęp do systemów i osobę, która odbierze pracę. Następnie porównaj kandydatów na tej samej próbie. Poniżej proponuję sposób wyboru FDE na stałe lub do konkretnego wdrożenia AI.
Dobry brief ogranicza zgadywanie po obu stronach. Kandydat wie, co ma zbudować. Firma wie, po czym oceni wynik. Ten tekst opisuje mój proponowany sposób pracy. Przykładowe zadanie i kryteria poniżej można dopasować do własnego procesu.
Najpierw zakres roli, potem nazwa stanowiska
W ogłoszeniu Neurons Lab architekt odpowiada za stronę techniczną wdrożenia, a Engagement Principal za zakres handlowy i zobowiązania wobec klienta. To konkretny podział, zapisany w ofercie pracodawcy. Własny zespół również potrzebuje wskazanych właścicieli tych decyzji.
W briefie określiłbym, kto rozmawia z użytkownikami, kto pisze kod i kto dopuszcza zmianę do produkcji. Potem ustaliłbym, kto wspiera system po starcie. Jedna osoba może pełnić kilka ról, jeśli ma na to czas i potrzebne uprawnienia.
Sam tytuł nie opisuje tych granic. Porównanie ról po stronie produktu i wdrożenia u klienta pomaga ustalić, jakiego zakresu firma potrzebuje.
Stały zespół czy zlecenie jednego wdrożenia
Stała rola ma sens, gdy firma ma ciągłą kolejkę wdrożeń i chce zachować wiedzę o produkcie we własnym zespole. Musi też zapewnić prowadzenie tej osoby, dostępy i współpracę z właścicielami procesów. Sam zakup czasu inżyniera nie rozwiąże braku tych warunków.
Do projektu o wąskim zakresie można wybrać zewnętrznego wykonawcę. Wtedy brief powinien wyznaczać koniec prac, sposób odbioru i to, co przejmie zespół klienta. Jeśli utrzymanie ma zostać u wykonawcy, trzeba opisać je osobno. Nie zakładałbym, że wynika automatycznie ze słowa wdrożenie.
Gdy nie ma jeszcze właściciela procesu ani zgody na dostęp do danych, zacząłbym od ustalenia zakresu. To może być krótka praca rozpoznawcza. Jej wynikiem jest decyzja, co budować oraz jakie warunki trzeba spełnić przed startem.
Brief na jedną stronę
Poniższy przykład dotyczy fikcyjnego zespołu obsługi zgłoszeń. Kwoty, terminy i progi błędów pozostają do ustalenia z właścicielem procesu. Brief ma pozwolić kandydatowi zadać trafne pytania.
| Pole | Przykładowa treść |
|---|---|
| Proces | Konsultant czyta zgłoszenie, szuka odpowiedniej instrukcji i przygotowuje szkic odpowiedzi. |
| Pierwszy zakres | System proponuje odpowiedź ze wskazaniem źródła. Konsultant zatwierdza ją przed wysłaniem. |
| Dostęp | Kopia bazy wiedzy i testowa kolejka zgłoszeń. Dostęp do produkcji wymaga osobnej zgody. |
| Odbiór | Wspólny zestaw przypadków, wynik obecnego procesu i uzgodnione progi dla nowego rozwiązania. |
| Wyłączenia | Brak samodzielnych zwrotów pieniędzy, zmian uprawnień i wysyłki do klienta. |
| Przekazanie | Kod, testy, opis uruchomienia, obserwacja błędów i przećwiczony powrót do poprzedniej wersji. |
Przy każdym polu wskazałbym osobę, która może udzielić odpowiedzi. Brak dostępu do API to zależność do rozwiązania przez właściciela systemu. Kandydat powinien ją wykryć i opisać, zanim poda plan prac.
Granice działań agenta warto ustalić już w briefie. Pokazuję jak podzielić działania na dozwolone, wymagające zgody i zakazane na przykładach pracy z systemami firmy.
To robię na co dzień: doradzam przy strategii AI i buduję agentów, którzy przeżywają demo.
Płatna próba pracy na wspólnym zadaniu
Zaproponowałbym krótki, płatny etap na danych syntetycznych lub przygotowanych do tego celu. Czas, wynagrodzenie i prawa do efektów trzeba uzgodnić przed startem. Zadanie powinno mieścić się w tym czasie i sprawdzać pracę, której wymaga stanowisko.
Każdy kandydat dostaje ten sam opis procesu, ten sam interfejs testowy i te same ograniczenia. Może zadawać pytania. W odpowiedzi zespół powinien przekazać te same ustalenia wszystkim osobom, które nadal wykonują próbę.
W przykładzie ze zgłoszeniami poprosiłbym o mały wycinek: pobranie sprawy, wybór źródła i szkic do zatwierdzenia. Dodałbym błąd API oraz dokument bez odpowiedzi. Chcę zobaczyć, jak kandydat opisze granicę działania i pokaże przypadek, którego system nie obsłużył.
Narzędzia AI mogą być częścią próby, jeśli zasady dopuszczają je dla wszystkich. Kandydat nadal powinien wyjaśnić własne decyzje, sprawdzić wygenerowany kod i umieć zmienić rozwiązanie podczas rozmowy.
The Agentic Architect
Praktyczne wzorce, case studies, rozbiory projektów agentowych i nowinki o AI. Zero spamu, raz w tygodniu.
Dostaniesz jednego maila z prośbą o potwierdzenie. Wypiszesz się jednym kliknięciem. Polityka prywatności
Oceń decyzje i dowody, które można sprawdzić
| Obszar | Dowód w próbie pracy |
|---|---|
| Rozpoznanie problemu | Kandydat wskazuje użytkownika, brakujące dane i warunki, bez których nie poda wiarygodnego planu. |
| Integracja | Pokazuje przebieg zwykłego żądania oraz obsługę błędu i ponownej próby. |
| Ocena jakości | Zapisuje oczekiwany wynik przed testem. Raport zawiera też przypadki zakończone błędem. |
| Granice dostępu | Rozdziela odczyt, zapis i zgodę człowieka. Wyjaśnia, co trafia do logów. |
| Przekazanie | Druga osoba potrafi uruchomić przykład i odtworzyć wskazany błąd z opisu. |
To moja propozycja kryteriów, bez uniwersalnego progu zaliczenia. Firma powinna wcześniej wskazać warunki konieczne. Jeśli kandydat naruszy ustaloną granicę dostępu, efektowne demo nie usuwa tego problemu.
Po próbie poprosiłbym o zmianę jednego założenia. Na przykład baza wiedzy ma dwie sprzeczne instrukcje. Kandydat może wtedy opisać, co sprawdzi i kto rozstrzygnie konflikt. Ta rozmowa pokazuje, czy rozumie własne rozwiązanie.
Odbiór wdrożenia i praca po starcie
Pierwszy etap kończyłbym działającym fragmentem procesu, który można obejrzeć i przetestować. Następny wymaga sprawdzenia przypadków błędnych oraz warunków dostępu. Uruchomienie na produkcji powinno mieć właściciela i drogę powrotu do wcześniejszej wersji.
Przed odbiorem inna osoba uruchamia system z opisu. Sprawdza alarm, odtwarza awarię i przywraca poprzednią wersję. Zespół zapisuje też, kto płaci za użycie modeli i kto odpowiada za błędy po zakończeniu projektu.
Jeśli firma chce zlecić taki zakres, opis mojej usługi wdrażania AI w systemach klienta pokazuje, od czego zaczynamy rozmowę. Brief jest punktem wyjścia do ustalenia prac i ich wyceny.
Przed publikacją ogłoszenia lub wysłaniem zapytania uzupełnij jedną stronę briefu. Wpisz właściciela procesu i osobę od dostępów. Dopiero wtedy ustal zadanie, na którym da się porównać kandydatów.
