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