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 и AIA: разделение ролей

FDE и AIA — обе производственные роли, обе работают «руками» внутри клиента, обе применяют AI как инструмент. Но они работают на разных уровнях абстракции и решают разные задачи. Это разделение критично для понимания, кого и когда привлекать на проект.

Короткая формулировка:

• FDE решает конкретную бизнес-задачу клиента, доводя её до production через SDD/EDD/вайб-кодинг. Горизонт — один проект, одна задача, одно работающее изменение.
• AIA проектирует и запускает AI-инфраструктуру клиента: какие модели, как организован контекст, как управляется токеномика, как интегрироваться с legacy-данными. Горизонт — год+ работы клиента с AI, на которой затем решаются конкретные задачи.

В чём это проявляется:

Метафора: AIA — архитектор больницы (проектирует среду, в которой можно оперировать: какое оборудование, какие протоколы, какая экономика). FDE — хирург (делает конкретную операцию в этой среде с ответственностью за результат на конкретном пациенте). Обе роли «руками» в системе клиента, но на разных уровнях абстракции.

Когда это важно понимать:

• Без AIA AI-проект застревает на POC: модель работает в лаборатории, но не в реальной среде клиента
• Без FDE архитектура остаётся на бумаге: красивая схема есть, работающего изменения у клиента нет
• На малых проектах граница может исчезать: один человек способен закрывать обе функции (см. Disrupt в обеих карточках)
• На крупных AI-проектах AIA приходит первым (проектирует контур), FDE — следом (реализует решения внутри готового контура)

Архитектурная роль 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 основание обещать клиенту качество, а не «делаем как делается».

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

Run / Change / Disrupt

Run (поддержание потока)

То, что FDE делает каждый день внутри проекта:

• Прямая коммуникация с клиентом на этапе постановки: уточнение требований, предложение альтернатив, перевод бизнес-задачи в техническую
• Проектирование архитектуры решения и выбор технических подходов
• Применение SDD: создание и поддержание спецификации как главного артефакта
• AI-оркестрация в рамках задачи: выбор моделей, проектирование промптов, интеграция AI-компонентов
• Применение EDD: написание eval'ов до реализации, прогон eval'ов как валидация
• Написание и ревью кода (в том числе через вайб-кодинг с AI-агентом), интеграция с системами клиента
• Сопровождение приёмки: разбор замечаний клиента, доводка до состояния «принято и работает»
• Участие в ритуалах скрам-команды (планирование, дейли, ретро) под управлением PM

Change (улучшение того, как роль работает)

То, что FDE делает на горизонте проекта/квартала, чтобы делать роль лучше:

• Накопление и систематизация типовых архитектурных паттернов и переиспользуемых решений
• Развитие компетенций по AI-оркестрации: освоение новых моделей, новых паттернов промпт-инжиниринга, новых AI-агентов для вайб-кодинга
• Совершенствование SDD-спецификаций: эволюция формата, чтобы клиент тоже мог их читать и комментировать
• Развитие наборов eval'ов: какие сценарии типовые, какие eval'ы переиспользуемые между проектами
• Передача найденных паттернов в зону PO Digital Shift для возможного включения в методологический стек
• Самообучение через разборы по итогам проектов (под управлением PM)

Disrupt (переизобретение роли)

То, что меняет саму конфигурацию роли в системе:

• AI-усиление FDE: переход от «инженер с AI-инструментами» к «инженер-оркестратор AI-агентов», где значительная часть кода и тестов генерируется автоматически на основе спецификации
• Размывание границы между FDE и AIA: на проектах с глубокой AI-составляющей одна роль может закрывать обе функции
• Сокращение размера проектов, которые один FDE может закрыть в одиночку — за счёт AI-усиления — и расширение зоны «один FDE без PM/AIA»
• Превращение SDD-спецификаций в исполняемые артефакты, из которых система автоматически генерирует код, тесты и документацию

Метрики

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 ниже.

🟢 Full Zone of Genius (зона полной автономии)

Решения, которые FDE принимает сам, без согласования с кем-либо. Это широкая зона в технической части и сужается на коммерческой/управленческой границе.

• Архитектура и технические решения внутри задачи. Какой подход выбрать, какие компоненты использовать, как декомпозировать решение, как структурировать код. CVD и PM получают результат, не диктуют процесс.
• Выбор моделей и паттернов AI-оркестрации. Какую модель использовать, как структурировать промпт, где AI уместен, а где обычный код. AIA консультируется только если речь об архитектуре AI-контура клиента целиком.
• Структура и формат SDD-спецификации. Как декомпозировать спецификацию, какой уровень детализации, как описывать поведение системы. FDE применяет SDD как обязательную дисциплину, но содержание и форму определяет сам.
• Подход к EDD: какие eval'ы писать, в каком объёме, какие сценарии покрывать. Принцип «eval'ы до реализации» обязателен; конкретное наполнение — суждение FDE.
• Стиль работы с AI-агентом при вайб-кодинге. Какой агент, как формулировать намерение, как валидировать сгенерированный код, какую часть кода писать руками. FDE решает в моменте.
• Тактические переговоры с клиентом по постановке. Уточнение требований, предложение альтернатив, перевод бизнес-задачи в техническую. FDE общается с клиентом напрямую как мини-консультант; не нужно проводить каждое уточнение через PM или CVD.
• Оценка трудоёмкости задач. FDE сам оценивает время на свои задачи; PM проверяет качество оценок через Plan Quality, но не пере-оценивает.
• Технологический выбор внутри согласованного стека. Конкретные библиотеки, конкретные паттерны интеграции, конкретные подходы к тестированию. Если выбор выходит за рамки согласованного стека (новый язык, новая платформа) — это уже коллегиально.
• На малых проектах без PM — также: приоритизация задач внутри спринта, тайм-бокс работы с клиентом, формат коммуникации хода работ. Это «сжатая» Full Zone PM, которая переходит к FDE на малых проектах.

Принцип: всё, что касается как строится решение и как оно работает технически — это зелёная песочница FDE. Зрелость FDE измеряется тем, насколько широка его автономия в технических решениях без потери качества — и тем, насколько он способен на малых проектах закрывать роль один.

🟡 Decisions Requiring Collaboration (коллегиальные решения)

Решения, которые FDE принимает в коллаборации с другими ролями. Здесь критично понимать с кем и как принимается решение.

• Изменение скоупа задачи или перенос в следующий спринт → с PM. Как: FDE сигнализирует о превышении оценки или о неучтённой сложности; PM принимает решение о переносе или эскалирует выше.
• Архитектурные решения уровня проекта (выбор стека, общая структура решения, ключевые интеграции) → с AIA (если затрагивает AI-контур клиента) и PM (если влияет на сроки и бюджет). Как: FDE формулирует предложение и альтернативы, AIA валидирует совместимость с AI-контуром клиента, PM проверяет влияние на план проекта.
• Серьёзные изменения в коммуникации с клиентом (отказ от подхода, предложение альтернативного решения вместо запрошенного, эскалация технического риска) → с CVD и PM. Как: FDE формулирует техническую позицию, CVD решает, как это донести до ЛПР, PM координирует тактическую коммуникацию.
• Применение нового блока методологии Digital Shift (новый подход к диагностике, новый паттерн внедрения) на проекте → с PO Digital Shift. Как: FDE формулирует, что хочет применить и зачем, PO Digital Shift валидирует применимость и помогает с адаптацией.
• Изменение базового стека инструментов (новый язык, новая платформа, новый AI-провайдер на проекте) → с AIA и CVD. Как: FDE обосновывает выбор техническими и продуктовыми аргументами, AIA проверяет совместимость, CVD проверяет влияние на портфель и долгосрочные обязательства перед клиентом.
• Включение найденного паттерна в методологический стек компании → с PO Digital Shift. Как: FDE поставляет паттерн с описанием контекста и ограничений, PO Digital Shift решает, войдёт ли это в Digital Shift и в каком виде.

🔴 Decisions That Should Never Be Made (зона запрета)

Решения, которые FDE не принимает ни в одиночку, ни в коллаборации.

• Управление проектом (структура спринтов, ритуалы, приоритеты бэклога, делегирование внутри команды). Это зона PM. На крупных проектах FDE работает по плану PM, а не подменяет его. Исключение — малые проекты без PM, где эти решения переходят в Full Zone FDE; но это не «принимать решения за PM», а «работать в его отсутствие».
• Архитектура AI-контура клиента в целом (стратегический выбор AI-стека для клиента на горизонте лет, не одного проекта). Это зона AIA. FDE решает AI-задачи внутри проекта, но не определяет, как клиент будет работать с AI в принципе.
• Стратегические отношения с ЛПР клиента. Это зона CVD. FDE общается с клиентом тактически (постановка, уточнения, демо), но не выстраивает стратегию аккаунта и не ведёт диалог о расширении сотрудничества.
• Коммерческие решения (стоимость работы, скидки, условия контракта). Это зона CVD и GM. FDE может зафиксировать факты по трудоёмкости, но не торгуется с клиентом и не делает коммерческих предложений.
• Эволюция методологического стека компании. Это зона PO Digital Shift. FDE поставляет паттерны и фидбек, но не решает, что войдёт в методологию.
• Изменения в общих процессах и регламентах компании (как все FDE должны работать, общие SLA, общие правила работы с клиентом). Это зона COO. FDE формулирует свою практику, но решение о превращении в стандарт принимает COO.
• Кадровые решения по своей команде или другим FDE. Это зона CVD как руководителя дивизиона и HR Manager. FDE может дать обратную связь, но не принимает решений о найме, увольнении, ротации.
• Решения по продажам и привлечению новых клиентов. Это зона CSO и CVD. FDE может показать решение в демо или принять участие в пресейле по запросу, но не ведёт продажу.

Принцип: красная песочница FDE — это граница с управленческими ролями (PM, CVD, COO) и граница со стратегическими ролями (PO Digital Shift, CSO). FDE — производственная роль с глубокой автономией в технике; попытка зайти в управление, методологию или коммерцию подменяет другие роли и снижает качество системы.

Цикл 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 обновляется по ходу, к закрытию задачи становится завершённым артефактом. Внешний цикл задаёт рамки для внутреннего: согласованная постановка и оценка определяют допуски, в которых работают отдельные шаги.