FDE: кто отвечает за результат у клиента

Павел Голубев рассказывает об изменении клиентской инженерной работы в Microsoft. Раньше его подразделение создавало решения без прямой оплаты со стороны заказчика: экономический смысл заключался в росте потребления Azure. Такая модель оставляла свободу в выборе технологий, но затрудняла оценку вклада конкретной команды.

В новой структуре, по словам Павла, инженерным подразделениям поставили более прямую финансовую цель — деньги за работу с клиентом. Часть проекта может финансироваться из инвестиционного бюджета Microsoft, но прежний принцип бесплатного внедрения ради будущего потребления перестаёт быть основой. Для руководителя это меняет повседневную работу: приходится раньше участвовать в продажах, оценивать стоимость обязательств и сопоставлять будущие проекты с доступными инженерами. Павел описывает перестройку, в которой ещё остаются неурегулированные процессы, а не завершённую универсальную модель FDE.

Инженеров подключают к разговору раньше, чем прежде. Вместо запроса на агентов для определённого документооборота они могут услышать амбицию компании стать мировым лидером. На встрече с немецкой строительной компанией обсуждение начиналось именно на уровне бизнес-намерений. Задача FDE-руководителя — превратить их в конкретные сценарии, определить возможный формат работы и понять, какие специалисты понадобятся.

Планирование осложняет бюджетный цикл клиента. Перспективная программа может принести работу лишь к апрелю, тогда как свободные инженеры есть уже сейчас. Удерживать их до решения дорого; отправить на другую долгую работу — значит рисковать доступностью команды позже. Поэтому воронка продаж и распределение людей связаны.

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

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

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

При этом защита от риска не сводится к повышению цены. Бизнес-программные менеджеры переводят обещания в договор: фиксируют контрольные точки и условия пересмотра. Если через несколько месяцев становится понятно, что исходная идея не работает, стороны могут изменить объём или завершить сотрудничество с оплатой уже выполненной части. Такой механизм не отменяет неизвестность, но делает её управляемой и ограничивает последствия ошибочного стартового предположения.

Конкретный пример — автоматизация документооборота нефтяной компании в Латинской Америке. Сотрудники вручную готовили отчёты и документы для многочисленных контрагентов. С бизнесом согласовали сокращение времени подготовки, а внутренняя IT-команда обозначила требования безопасности. После начала работы обнаружилось, что сотрудники с одинаковыми должностями имели разные права на почту, документы и SharePoint. Отдельному агенту пришлось бы воспроизводить сложную логику доступа, что не укладывалось в небольшой проект.

Команда предложила использовать Copilot Studio: в описанном сценарии агенты действовали с правами запускающего пользователя. Бизнес был готов освоить интерфейс, но IT выступила против самостоятельного создания решений, опасаясь потери контроля. Компромисс сохранил создание агентов за IT: бизнес обращался к ней с запросами. Это добавляло организационный шаг, зато позволяло внедрить решение. Павел оценивает результат как удовлетворительный для сторон: сроки подготовки сократились, а внутренняя команда сохранила понятную роль. Технически более свободный вариант оказался организационно неприемлемым.

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

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

Павел описывает отраслевые подразделения, региональные команды и смешанные инженерные группы. В них работают разработчики, специалисты по данным и технические программные менеджеры. Его ответственность за Data Science проходит поперёк линейной структуры: распределением людей формально занимаются их менеджеры, а он участвует в профессиональной работе и контроле качества. Опытный специалист также может стать руководителем проекта или выполнять архитектурную работу.

На самом проекте дисциплины не превращаются в изолированные участки. Команда совместно распределяет задачи: например, кто займётся оценкой качества, а кто — обработкой данных. Работа рядом с инженерами заказчика включает передачу практик разработки, а не только готового кода. Павел упоминает быстрые итерации и использование агентов. Конкретное распределение дальнейшей поддержки в разговоре подробно не раскрывается; зато обучение клиентской команды названо явной частью совместной работы.

FDE требует быстро разбираться в незнакомой отрасли, договариваться и действовать при неполных вводных. Между продажей проекта и его стартом состав исполнителей может измениться: нужный специалист уже занят, и новому человеку приходится быстро набирать контекст. Название роли меняется, но сама задача — построить полезное решение в чужой организации — существовала и раньше.

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