Forward Deployed Engineer (FDE) / Продуктовый инженер

Зачем эта роль

FDE существует, потому что у каждого проекта на стороне клиента должен быть инженер, который доводит изменение до production и несёт ответственность за результат, а не за «сданный код». Без FDE проект превращается либо в чистую T&M-разработку (заказчик пишет ТЗ, исполнитель кодит, ответственность за работающий результат размыта), либо в консалтинг без рук (диагноз есть, изменение в бизнесе клиента не происходит).

FDE — единственная роль в системе NOTA, выполняющая Forward Deployed Engineer-функцию в полном смысле (в логике Palantir, OpenAI). Это архитектор + промпт-инженер + мини-консультант в одном лице, развёрнутый внутри клиента. PM и AIA — поддерживающие специализации вокруг FDE, но не FDE сами.

Из чего вырастает FDE

FDE — это эволюция из роли разработчика всех грейдов, но не «старший разработчик» и не «техлид». Это качественно другая конструкция, в которой в одном человеке объединены две классические функции, исторически разделённые в IT:

• Бизнес-аналитик — тот, кто говорит с клиентом, понимает его бизнес и переводит бизнес-задачу в техническое требование
• Разработчик — тот, кто реализует техническое требование и доводит до работающего решения

В классической T&M-модели эти функции распределены между разными людьми: бизнес-аналитик сидит с клиентом и пишет ТЗ, разработчик читает ТЗ и пишет код. Это создаёт цепочку «бизнес → ТЗ → код» с двумя промежуточными переводами и потерей контекста на каждом стыке. Итерации медленные, постановка часто оторвана от того, что реально нужно бизнесу, а разработчик не понимает, что и зачем он строит.

FDE объединяет обе функции в одном человеке. Он сам сидит с клиентом, сам формулирует, что нужно делать, сам специфицирует и сам реализует. Промежуточных переводов нет. Контекст не теряется. Это и есть «развёрнут внутри клиента» — FDE не получает ТЗ через посредника, он сам и есть посредник между клиентом и работающим решением.

Что делает такое объединение возможным

Объединить бизнес-аналитика и разработчика в одном человеке стало реалистично за счёт трёх дисциплин и инструмента, которые меняют экономику инженерной работы:

• SDD (Specification-Driven Development). Главный артефакт работы — не код, а спецификация поведения системы: что должно происходить, при каких входах, какие границы, как реагировать на ошибки. Спецификация пишется на человеческом языке (часто структурированном Markdown), её может читать и комментировать клиент. Архитектура и код — производные от ясной спецификации; без спецификации AI генерирует мусор. Спецификация живёт всю жизнь решения и обновляется как первичный артефакт.
• EDD (Evaluation-Driven Development). Эволюция TDD под AI-эпоху. До реализации задачи пишется не «unit-тест на функцию», а evaluation — критерии оценки результата, включая нечёткие («ответ должен звучать естественно», «решение должно покрывать кейс X»). Eval'ы прогоняются как часть цикла разработки и валидируют недетерминированные AI-компоненты, для которых классические тесты не работают.
• Вайб-кодинг как стиль работы. FDE не пишет основной объём кода руками — он формулирует намерение в диалоге с AI-агентом, который генерирует код по спецификации. Качество результата зависит не от мастерства типизации, а от мастерства формулировки задачи и архитектурного видения. Вайб-кодинг без SDD/EDD — это «надеемся, что заработает»; вайб-кодинг с SDD/EDD — это управляемое промышленное производство кода.

Эти три дисциплины вместе сжимают инженерный труд: то, что раньше требовало бизнес-аналитика + старшего разработчика + младшего разработчика, теперь делает один FDE, который думает на уровне спецификации и оркестрирует AI на уровне реализации. Это не удешевление за счёт качества — это качественно другой способ работы, в котором ответственность не размывается между ролями.

Архитектурная роль FDE в NOTA

Ключевое отличие FDE от классического разработчика — ответственность за приёмку клиентом. Не «я написал, проверьте и подпишите», а «бизнес-изменение работает в production и принимается клиентом как ценность». На малом проекте один FDE способен закрыть весь путь сам: от первого диалога с клиентом и постановки до промышленного запуска и сопровождения. На крупном проекте FDE работает в связке с PM и AIA, но физически остаётся развёрнутым внутри клиента — в его контексте, в его инфраструктуре, в его темпе.

FDE — несущая роль для способности компании производить реальные изменения у клиента, а не «выполнять заказы». Скорость итераций FDE-команды выше, чем в классической T&M-разработке, за счёт сжатой передачи между ролями и устранения промежуточных переводчиков «бизнес → ТЗ → код».

Продукт должности

Production-quality результат на стороне клиента — не «сданный код», а работающее изменение в бизнесе клиента, за которое инженер несёт ответственность от постановки до приёмки. Покрывает полный стек: проектирование архитектуры, AI-оркестрация, написание и ревью кода, интеграция, тестирование через EDD-методологию. На входе работает с клиентом напрямую как мини-консультант — уточняет постановку, предлагает альтернативы, переводит бизнес-задачу в техническую. Применяет SDD как обязательную дисциплину: спецификация — главный артефакт, AI-генерация — производное от ясной архитектуры. Скорость итераций выше, чем в классической T&M-разработке, за счёт сжатой передачи между ролями.

Главный потребитель и его требования

Главный потребитель: CVD (получает production-quality изменения у клиента как инфраструктуру портфеля).

CVD получает от FDE не «выполненную задачу разработки», а изменение в бизнесе клиента, которое можно конвертировать в признанную ценность (AVR) и в кейс. Конкретные требования:

• Бизнес-изменение работает в production и принято клиентом. Не «код прошёл ревью», а «процесс работает на стороне клиента, ЛПР видит эффект». Если код сдан, но клиент не пользуется — это не результат FDE.
• Качество восприятия клиентом «выше ожиданий». Клиент должен оценивать техническую работу как минимум выше базового уровня. Технический рейтинг ниже «выше ожиданий» — сигнал, что FDE сделал «нормально», но не сделал то, чем CVD будет хвастаться в квартальном обзоре.
• Сроки соблюдаются с точки зрения клиента, не только с точки зрения PM. Клиент должен воспринимать работу как предсказуемую — это не то же самое, что внутренняя On-Time у PM. Спринты могут быть в плане, а клиент чувствовать, что «всё тянется».
• Постановка не возвращается через CVD. FDE на этапе постановки сам уточняет с клиентом всё, что нужно для работы; CVD не должен переводить между клиентом и FDE на тактическом уровне.
• EDD и SDD как дисциплина, а не формальность. CVD должен видеть, что тесты пишутся до реализации (EDD), а спецификация существует и обновляется (SDD). Это даёт CVD основание обещать клиенту качество, а не «делаем как делается».

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

Метрики

FDE измеряется композитом из 3 метрик, покрывающих все три ноги EEQ (Effectiveness / Efficiency / Quality) и ориентированных на главный вопрос CVD: production-релизы выходят в темпе бизнеса, клиент доволен техническим качеством, обещания по срокам соблюдаются.

Логика композита: одна метрика — итоговый замер пропускной способности (релизы в production выходят в согласованном темпе, не накапливаются как незавершённое). Вторая — техническое восприятие клиентом (стандартизованный замер удовлетворённости качеством инженерной работы, отдельно от удовлетворённости продуктом). Третья — соответствие обещанным срокам (доля релизов, выпущенных в согласованную дату, отражающая предсказуемость как ключевое качество FDE-роли).

Метрики дополняют друг друга по логике «выпускаем / клиент доволен качеством / держим обещания». Если Production Delivery Rate высокий, но Client Technical Rating низкий — выпускаем много, но качество страдает; рано или поздно это всплывёт как технический долг или баги в production. Если Client-Perceived Timeliness высокий, но Production Delivery Rate низкий — выпускаем редко, но всегда вовремя; не используем потенциал команды. Если все метрики в зелёном — FDE работает в темпе и в качестве, контракт устойчив.

Полный список метрик с определениями и порогами — в свойстве Metrics ниже.

Цикл PDCA

FDE управляет двумя вложенными циклами с разной частотой. Внешний цикл — управление выполнением задачи целиком; внутренний — управление каждым шагом разработки внутри задачи.

Цикл управления шагом разработки (короткий, дневной/спринтовый)

• Plan — постановка шага: уточнение требования, проектирование подхода, написание EDD-eval'ов, обновление SDD-спецификации.
• Do — реализация: написание кода (в том числе через вайб-кодинг с AI-агентом), AI-оркестрация, прогон eval'ов, интеграция.
• Check — валидация шага: eval'ы прошли, спецификация соответствует, демо работает; самоконтроль качества кода.
• Act — корректировка следующего шага: уточнение спецификации, переоценка оставшейся работы в задаче, сигнал PM при превышении оценки.

Цикл управления задачей/изменением целиком (длинный, по периоду задачи)

• Plan — постановка задачи: диалог с клиентом и/или PM, формирование SDD-спецификации, оценка трудоёмкости, проектирование архитектуры решения.
• Do — реализация задачи: исполнение по шагам, ведение коммуникации с клиентом по ходу работ, координация с PM и AIA на стыках.
• Check — приёмка клиентом: демонстрация работающего изменения, разбор замечаний, оценка соответствия исходной постановке и качества.
• Act — закрытие задачи: фиксация трудоёмкости и причин отклонений, передача найденных паттернов в общую копилку команды, обновление SDD как наследия проекта, участие в разборе по итогам проекта под управлением PM.

Внутренний цикл (шаг) питает внешний (задача): EDD-eval'ы на каждом шаге накапливают доказательную базу качества к моменту приёмки; SDD обновляется по ходу, к закрытию задачи становится завершённым артефактом. Внешний цикл задаёт рамки для внутреннего: согласованная постановка и оценка определяют допуски, в которых работают отдельные шаги.