Люди и роли: методология

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

Инженер продукта: роль по функции

Product Architecture Framework (PAF, автор — Сергей Тихомиров) определяет роль через объект управления и функцию. Инженер продукта — тот, кто выбирает свойства продукта и отвечает за результат: если это делаете вы, вы инженер продукта, как бы ни называлась должность. Из пяти ролей PAF обязательна одна, и команда может состоять даже из одного человека, если сама проходит весь жизненный цикл своего объекта.

Роль PAF	Объект управления	За что отвечает	Кто это в классической структуре
Инженер продукта	Продукт	Выбирает свойства продукта, которые дают монетизируемую ценность	Product Owner, Product Manager
Инженер по развитию бизнеса	Бизнес-юнит	Ценность юнита в деньгах; работает с инженером роста, управляет инженерами продукта	Head of Product, руководитель направления, владелец P&L
Менеджер портфеля	Портфель бизнес-юнитов	Баланс маржинальности, каннибализация, распределение ресурса между командами	CPO, руководитель группы продуктов
Инженер роста	Модель роста	Привлечение новых клиентов и рост их ценности	Growth PM, продуктовый маркетолог
Менеджер продуктовых процессов (Product Ops)	Процессы управления продуктом	Как устроены общая база знаний и правила работы агентов	Аналог скрам-мастера; в большинстве корпораций роли нет, функцию берёт энтузиаст

Если роли в структуре нет, её функцию не оставляют пустой. Нет Product Ops — правила и структуру базы знаний на старте ведёт сам руководитель. Руководитель формально PO, а ведёт несколько команд — он уже менеджер портфеля, и его объект — зависимости между командами.

PO и PM: кто решает, кто готовит основание

Здесь PM — проектный менеджер, отвечающий за доставку, а не продакт-менеджер. В PAF такой роли нет, а из пяти его классических функций четыре дублируются с PO: план, статусы, зависимости, риски. Разделение проходит по одному вопросу: PO решает, что обещать и при каком основании, PM обеспечивает, чтобы основание появилось вовремя.

Вопрос	PO	PM
Что должно быть правдой для цели и какой нужен порог уверенности	Решает	—
Давать ли дату наружу	Решает	Готовит основание
Какие проверки поднимут уверенность	Определяет	Планирует в спринт и доводит
Дожать подтверждение смежника	—	Делает
Ритм команды и ритуалы	—	Ведёт полностью
Отчёт наверх	Говорит	Генерирует и проверяет полноту

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

Три ловушки и что с ними делать:

PM ведёт свои оценки уверенности, и числа расходятся — уверенность ведёт только PO.
PM становится секретарём — ему возвращают разблокировку как главную работу.
PM даёт даты наружу — любая дата наружу только после PO, без исключений для «мелких».

Техлид и инженеры

Методология не заменяет процесс разработки: под ней допустим любой scrum или kanban. Меняются три вещи. В спринт попадают задачи на выяснение — spike, PoC, замер реального времени ответа смежной системы — и занимают ёмкость наравне с фичами.

Цель спринта может звучать не «сделали», а «выяснили»: получили письмо владельца системы, прогнали тест против реального API. У техлида появляется право сказать: «беру проверку, а дату по интеграции назову после неё». Это не отказ, а перенос обещания на момент, когда оно обосновано.

Техлид даёт то, чего не даст никто другой: техническую правду о том, что именно доказал тест — прогон на моках или против реальной системы. Ещё он даёт ранний сигнал деградации — «отвечают вместо двух дней девять» — и возражения, когда руководитель переоценивает готовность. Инженерам добавляется одно: закрывая spike, записывать не «сделано», а что выяснили.

Линейный PM и стажёр: делегирование

Опытный PM забирает поток целиком по контракту из трёх пунктов: он ведёт обещания своего потока сам, вы не смотрите внутрь, ни одна дата не уходит наружу без вашего гейта. Это единственный поток, где руководитель может не знать деталей.

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

Агенты: что забирают и что не отдают никому

Агенты бывают трёх классов. Claude Code работает над файлами и git по команде и даёт одинаковый результат на одних и тех же правилах. Hermes Agent работает постоянно, помнит контекст и учится на повторяющихся задачах, а OpenClaw — шлюз, который видит поток в мессенджерах и почте.

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

Тип работы	Может взять агент	Остаётся человеку
Сбор: статусы, артефакты, выгрузки	Почти полностью	Проверка, что источник корректен
Подготовка: контекст к встречам, черновики, отчёты	Большую часть	Правка смысла и отправка
Наблюдение: латентность, тишина, протухшее знание	Полностью	Реакция на сигнал
Расчёт: уверенность, достижимость, ёмкость	Полностью, но только детерминированный агент	Решение по результату
Решения и отношения: обещания, правила, эскалации, переговоры	Ничего	Всё

Подключают агентов по уровню зрелости. В первый квартал работает только Claude Code: агенты поверх неустоявшихся правил автоматизируют хаос. Hermes с расписанием и ролевыми ботами — со второго квартала, шлюз к мессенджерам — только после согласования с безопасностью и только на чтение.

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

Почему так, а не по должностям

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

Два числа вместо одного. PM и PO по отдельности оценивают риски, оценки расходятся, руководитель не знает, кому верить.
Даты уходят наружу от разных людей. Смежник получил срок от PM, заказчик — от PO, и через месяц оба срока приходится объяснять.
Молчаливый техлид. Если техлид кивает, когда руководитель переоценивает готовность, ранний сигнал о деградации смежной системы не приходит никому.
Знание в одной голове. Ушёл человек — унёс часть контекста; как это выглядит на одном модуле, разобрано в статье «Bus Factor».

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

Артефакт: ролевая карта направления

Заполняется на одну страницу и кладётся рядом с планом квартала.

РОЛЕВАЯ КАРТА: <направление>, <квартал>

Инженер продукта (решает, что обещать): <имя>
Дата наружу уходит только после: <имя>; исключений для «мелких» нет

Поток <название>
  Владелец: <имя, роль>
  Режим: <зона целиком (опытный PM) | функция по всем потокам (стажёр)>
  PM готовит основание к гейту: <дата гейта>, сигнал не позже чем за <N дней>
  Техлид даёт: <что подтверждает, каким артефактом, раз в неделю>

Функции без отдельной роли
  <Product Ops / инженер роста / аналитик>: функцию выполняет <имя>, объём <часов в неделю>

Дубли функций (убрать до конца первого спринта)
  <функция>: сейчас делают <имя> и <имя>, оставить у <имя>

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

Зоны с одним носителем знания: <модуль или отношение> — <имя>, второй владелец <имя> к <дате>

С чего начать завтра

Выпишите пять функций PM и отметьте те, что в вашем направлении делает ещё и PO. Для каждого дубля назначьте одного владельца.
Введите правило гейта: любая дата наружу — только после инженера продукта. PM готовит основание, но число уверенности не ставит.
Если в команде есть стажёр, отдайте ему функцию хранителя артефактов по всем потокам, а не отдельную зону.
Добавьте техлиду один вопрос на дейли: «что изменилось по зависимостям?». Новых терминов не вводите.
Пройдите по критическим модулям с вопросом «кто встанет, если этот человек две недели недоступен?». Дальше — темы «Состав команды и устойчивость», «Навыки работы с ИИ» и «Команда агентов».

Источники

Гайд «PAF Product Ops для корпоративного PO», адаптация А. Ишманова: раздел 6 «Ролевая модель и адаптация к классической IT-структуре», П5 «Делегирование: опытный PM и стажёр», П5-бис «Роль классического PM в методологии», П9 «Команда агентов», Шаг 5 «Что меняется у техлидов и инженеров» — github.com/po-helper-org/docs.
Ролевая модель PAF: productframework.ru/ops/main и «Роли в эпоху ИИ», С. Тихомиров, CC BY-SA 4.0.
Подшаг «Roles: AI-Native роли пода» и операционная модель в репозитории po-helper-org/docs (ai-processes/STEP-0-FOUNDATION/3.roles.md, ai-processes/operating-model.md), выведены из PAF.
Карточка Hermes Agent (Nous Research) и презентация «Спринты под управлением руководителя».

Люди и роли