The Forward Deployed Engineer — Paden Gayle (Рубрика #Books)

Paden Gayle начал писать книгу "The Forward Deployed Engineer" и на сайте O’Reilly сейчас доступны две главы: книга ещё пишется и выходит в формате Early Release. Но по этим главам у меня уже ощущение, что получится хорошая книга. Особенно понравились части про ответственность и согласование позиций разных стейкхолдеров.

FDE (Forward Deployed Engineer) — инженер, которого поставщик технологии встраивает в работу компании-заказчика. Он выясняет, какую проблему нужно решить, договаривается об объёме работ, строит систему и доводит её до production. Автор сравнивает эту роль с основателем внутри чужой компании. Масштаб ответственности похожий, а вот данные, инфраструктура, правила безопасности и люди принадлежат заказчику.

Мне понравилась точность этого противоречия: отвечать за результат приходится в среде, которой ты не управляешь. Если для запуска нужен доступ, согласование или решение другого человека, твоя работа — найти этого человека и довести вопрос до решения. Лично выполнять всё при этом совершенно необязательно.

А дальше начинается интересное: у «заказчика» оказывается несколько несовпадающих представлений об успехе.
- Тому, кто выделил бюджет, нужен экономический эффект.
- Руководителю процесса — понятные изменения и работающая команда.
- IT и безопасности — контролируемые доступы, данные и последствия ошибок.
- Пользователям — чтобы исчезла конкретная ручная возня.
- Внутреннему инициатору проекта — результат, за который он уже поручился перед коллегами.

В книге есть хороший приём: описать одно и то же решение на языке каждого из них, причём все описания должны быть правдой. Если одному обещаем работу без участия человека, а другому — обязательное подтверждение каждого шага, проблема уже в устройстве решения. Усреднить пожелания или выполнить просьбу самого громкого человека тут недостаточно.

И ответственность вполне совместима с границами. Автор подробно разбирает, как фиксировать объём работ, исключения, обязанности заказчика и проверяемые критерии готовности. Например, в книге есть такой критерий: пятничная выгрузка, занимавшая четыре часа вручную, автоматически появляется в общей папке к девяти. Сразу понятно, что принимать и кто может это проверить.

Отдельно интересна экономика этой позиции.

Почему на неё есть спрос?
Заказчику нужен работающий процесс в его системах, с его данными и ограничениями. По мысли автора, AI удешевляет написание кода, а выбор правильной задачи, согласования и ответственность остаются сложными. Когда реализация ускоряется, эти вопросы становятся ещё заметнее. Вдобавок теперь дешевле быстро построить и совершенно ненужную штуку :)

Откуда предложение?
Для поставщика AI такой инженер помогает превратить возможности продукта в результат, ради которого клиент продолжит платить. По логике книги, с кодинг-агентами один инженер может брать работу, раньше требовавшую небольшой команды: индивидуальное внедрение становится экономически доступнее. Это уже оформляется в отдельные направления бизнеса: AWS объявила о вложении $1 млрд в FDE.

Со стороны инженера я вижу привлекательность в самостоятельности, прямой обратной связи от пользователей и возможности влиять на весь путь от задачи до результата. Цена такой самостоятельности — переговоры, неопределённость и чужие ограничения. Совместить сильную инженерию с умением держать этот контекст непросто.

Пока это рекомендация первых двух глав. Но уже сейчас книга выглядит полезной и для техлидов, и для инженеров, которым приходится договариваться о том, что вообще стоит строить. За продолжением хочется следить.

#Books #AI #Engineering #Management #Product