Карта ролей AI для команд, где AI делает работу

Где работа теряется

Команды редко теряют работу потому, что её никто не трогал. Обычно она теряется потому, что несколько человек думают, что финальное решение примет кто-то другой.

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

Название должности это не решает. «Engineer», «product manager», «CTO» или «founder» могут описывать роль на бумаге, но не говорят команде, кто может одобрить изменение промпта, отклонить сомнительный результат, выбрать источник данных или остановить плохой релиз. Когда такие решения остаются расплывчатыми, работа утекает сквозь щели.

Именно поэтому нужна карта ролей. Она превращает широкие названия в понятные решения. Без неё команды попадают в привычный цикл. Один человек просит AI сделать работу. Другой смотрит на результат. Третий считает, что первые двое уже проверили риски. И никто не владеет финальным решением.

Простой пример из продукта показывает проблему. Команда использует AI, чтобы писать onboarding-письма и контент для help center. Marketing правит тон, engineering подключает инструмент, support замечает фактические ошибки, legal переживает из-за формулировок. Текст выходит в прод с опозданием, потому что каждый ждёт, что кто-то другой скажет: «Да, это верно и это можно безопасно выпускать».

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

Командам не нужно больше должностей. Им нужна чёткая ответственность за решения, проверки и финальное утверждение.

Четыре роли простыми словами

Команды путаются, когда «делать работу» и «отвечать за результат» смешиваются. Если AI берёт на себя большую часть исполнения, четыре роли помогают держать задачу видимой от начала до конца.

Operator запускает задачу. Этот человек даёт промпт, собирает контекст, запускает инструменты и двигает работу вперёд.

Reviewer проверяет результат. Этот человек ищет ошибки, слабую логику, пропущенные крайние случаи и всё, что нельзя выпускать дальше.

Architect решает, как должна идти работа. Этот человек выбирает схему, ограничения, инструменты и технические компромиссы до того, как команда начнёт масштабировать задачу.

Domain owner решает, что значит «хорошо». Этот человек отвечает за бизнес-результат, задаёт правила и принимает финальное решение, когда приоритеты конфликтуют.

Одна задача, четыре касания

Возьмём простую задачу: добавить email-уведомление, когда платёж не прошёл. Operator просит AI набросать поток, обновить код и подготовить тесты. Reviewer проверяет логику сообщения, случаи отказа и то, доказывают ли тесты что-то реальное.

Architect решает, где должно жить это уведомление, как должны работать повторные попытки и стоит ли использовать существующую событийную систему или быстрый патч. Domain owner решает, когда пользователи должны получать уведомление, что должно быть в тексте и должен ли support тоже получить копию.

Все четыре роли касаются одной задачи, но не принимают одно и то же решение. В этом и смысл. В хорошей карте ролей никто не предполагает, что щель закроет кто-то другой.

Один человек может совмещать две роли, особенно в маленькой команде. Основатель может быть domain owner и reviewer. Старший инженер может быть operator и architect. Это работает, если человек прямо говорит, какую роль он играет в данный момент.

Но некоторые решения всё равно требуют одного понятного владельца. Влияние на пользователя и бизнес-правила принадлежат domain owner. Технический дизайн принадлежит architect. Проверка качества принадлежит reviewer. Исполнение задачи принадлежит operator.

Если два человека делят одно решение, задержки начинаются быстро. Если никто не владеет им, AI выдаёт результат, все думают, что прогресс уже есть, а работа тихо исчезает.

Что делает operator

Operator ближе всех к повседневному AI-исполнению. Этот человек запускает промпты, включает инструменты, следит за очередями задач и держит работу в движении. Если эта роль никем не занята, задачи застревают на полпути, потому что все думают, что AI уже всё сделал.

Прежде чем просить AI что-то сделать, operator собирает контекст, который модель сама не угадает. Это часто текущий тикет, прежние решения, исходные файлы, правила стиля, заметки клиентов и жёсткие ограничения. Хорошие operator не отправляют размытые запросы и не надеются на магию. Они формулируют задачу так, чтобы у модели было достаточно фактов и на первом проходе получился полезный результат.

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

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

У operator также должна быть чёткая точка остановки. Этот человек может делать черновик, перезапускать задачу, сравнивать варианты и упаковывать результат для следующего шага. Но он не должен один утверждать финальные факты, принимать бизнес-риск, объединять код или выкатывать изменения в продакшен. Такая граница делает ответственность видимой.

Полезное правило простое: operator быстро двигает работу вперёд, но останавливается перед финальным утверждением, если результат может повлиять на клиентов, деньги, безопасность или живые системы.

Что делает reviewer

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

Хороший reviewer задаёт простые вопросы. Использовал ли AI правильные числа, имена и источники? Не противоречит ли черновик прежнему решению? Соответствует ли он нужной структуре и тону? Может ли следующий человек использовать его без догадок?

Если что-то не так, reviewer возвращает работу с точными исправлениями. «Нужно доработать» слишком расплывчато. «Замени таблицу цен на актуальные цифры, убери неподтверждённое утверждение в третьем абзаце и используй шаблон release note» даёт operator реальный следующий шаг.

Reviewer должен одобрять только работу, которая действительно проходит по планке. «Почти нормально» создаёт дорогие исправления позже. Одно слабое одобрение может превратиться в баг, плохое сообщение клиенту или документ, которому никто не доверяет.

Такую проверку легко пропустить и дорого пропустить. В oleg.is Oleg Sotnikov использует ту же идею в работе по AI-first delivery через code review, проверку тестов, проверку документации и согласование релизов. Инструменты быстро делают черновик, но человек всё равно решает, что верно и что уже готово.

Reviewer также должен отслеживать повторяющиеся ошибки. Если AI постоянно выдумывает крайние случаи или operator снова и снова пропускает нужный формат, кто-то должен зафиксировать этот шаблон и сообщить о нём. Тогда команда сможет поправить промпт, ужесточить чек-лист, обновить шаблон или изменить передачу задачи. Review перестаёт быть просто воротами и начинает улучшать всю систему.

Что делает architect

Architect решает, как работа движется от запроса к результату. Если operator запускает процесс, а reviewer проверяет результат, architect строит сам процесс, который используют оба.

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

На раннем этапе architect принимает четыре решения: рабочий процесс, инструменты внутри него, правила, снижающие риск, и точки передачи между AI и людьми.

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

Такие решения влияют на всю команду. Если architect слишком мягкий, люди тратят время на исправление ошибок, которых можно было избежать. Если architect слишком жёсткий, каждая задача ждёт согласования, и скорость исчезает.

Представьте продуктовую команду, которая использует AI для release notes, ответов поддержки и test cases. Architect может разрешить AI самостоятельно публиковать внутренние test cases, требовать проверку для customer-facing release notes и заставлять эскалацию для любого ответа поддержки, где упоминаются billing, security или потеря данных. Это не микроменеджмент. Это простой контроль риска.

Architect также пишет правила fallback. Если модель не проходит тест, просит инструменты, которые ей нельзя использовать, или два раза подряд выдаёт неопределённый результат, система должна передать задачу человеку. Без догадок.

Небольшие команды часто отдают эту роль founder или fractional CTO. Это хорошо работает, пока компания ещё учится понимать, где AI может действовать самостоятельно. Со временем architect продолжает настраивать промпты, тесты, права доступа и маршрутизацию, пока работа перестаёт проваливаться сквозь щели.

Что делает domain owner

Domain owner решает, что значит «правильно» для бизнеса. Это звучит очевидно, но именно здесь многие AI-heavy команды ломаются. AI может генерировать варианты, operator может запускать задачу, а reviewer может ловить очевидные проблемы. Но никто из них не решит, подходит ли результат для выручки, нагрузки на поддержку, доверия клиентов или юридического риска.

Этот человек расставляет приоритеты, когда цели конфликтуют. Если изменение может повысить конверсию, но увеличить число возвратов, решение принимает domain owner. Если более быстрая поставка означает больше ошибок в крайних случаях, domain owner решает, какой уровень риска команда готова принять. Без такого владельца решения работа движется дальше, но компромисс никому не принадлежит.

Хороший domain owner отвечает на несколько прямых вопросов. Что считается готовым для этой функции? Какая метрика сейчас важнее всего? Какие ошибки команда может выдержать, а какие недопустимы? Что должно происходить, когда пользователь выходит за пределы обычного сценария?

Крайние случаи — большая часть этой роли. AI хорошо работает с шаблонами. Бизнес-правила часто устроены сложнее. У startup может быть billing-поток, где большинство клиентов попадают в стандартный план, но у некоторых есть индивидуальные контракты, отложенные счета или правила возврата. Domain owner решает, как должны работать такие случаи. Если этот человек не отвечает, AI будет угадывать, а догадки превращаются в тикеты в support.

Эта роль отвечает за результат, а не только за запрос. «Сделайте новый onboarding-flow» — это запрос. «Снизьте отток без роста нагрузки на support» — это результат. Разница очень важна.

В здоровой карте ролей domain owner обычно — это человек, который ближе всего к бизнес-результату. Ему не обязательно писать промпты или проверять код. Но ему нужно принимать ясные решения, делать это быстро и нести ответственность, когда результат выходит в прод.

Как распределить роли шаг за шагом

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

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

Затем разложите каждый процесс простыми словами:

1. Опишите процесс как короткую цепочку действий. Держите его простым, например: «приходит тикет, AI предлагает исправление, человек проверяет, код выкатывается, проблема закрывается».
2. Отметьте, кто запускает процесс, кто проверяет результат, кто говорит да или нет и кто перезапускает процесс, если AI уходит в сторону.
3. Поставьте одно реальное имя у каждой точки решения. Один человек может совмещать две роли в маленькой команде, но у каждого решения всё равно должен быть один владелец.
4. Добавьте правила остановки для результата AI. Заранее решите, когда работа должна остановиться: если нет исходных данных, если тесты не прошли, если неясно влияние на клиента или если задача касается денег, безопасности или юридических условий.
5. Прогоните карту на одном живом процессе в течение двух недель. Не раскатывайте её на всю компанию в первый день.

Этот двухнедельный тест очень важен. Вы увидите задержки, которые на бумаге казались безобидными. Возможно, reviewer проверяет работу только два раза в неделю. Возможно, domain owner подключается слишком поздно. Возможно, operator постоянно подаёт в модель плохой контекст, и одна и та же ошибка повторяется снова.

Во время теста ведите заметки. Считайте, сколько раз AI потребовалась повторная попытка, как часто вмешивался человек и где работа ждала решения. Эти цифры показывают, где карта слишком тонкая.

Если команде нужен простой старт, выберите один процесс с понятным результатом и низким риском. Хорошо подходят triage багов или внутренняя документация, потому что там легче увидеть границы. Когда один процесс заработает, перенесите структуру на следующий.

Простой пример из одной продуктовой команды

Небольшая SaaS-команда хочет изменить billing. Они планируют добавить prorated charges, когда клиент переходит с monthly plan на annual plan в середине цикла. Звучит рутинно, но ошибки в billing очень быстро превращаются в возвраты, тикеты в support и недовольных клиентов.

Operator запускает работу. С помощью AI этот человек пишет краткую спецификацию, превращает её в задачи и генерирует test cases для upgrade, downgrade, неудачных карт, дублирующихся счетов и отменённых подписок. В здоровой карте ролей operator двигает задачу вперёд, но не принимает финальные решения по рискованным крайним случаям.

Reviewer на один час замедляет команду и экономит ей неделю. Этот человек читает черновик AI и замечает плохие допущения. В черновике забыли налоговые правила для одного региона, неверно обработали account credits и предположили, что любое изменение плана должно выставляться сразу. Всё это несложно заметить, если внимательно посмотреть, но AI часто пишет с ложной уверенностью.

После двух похожих billing-проблем за месяц подключается architect. Этот человек не переписывает каждый тикет. Он исправляет систему, которая снова и снова создаёт один и тот же беспорядок. В AI-prompts добавляют обязательный billing-шаблон, перед touching invoices появляется контрольная точка review, а команда собирает небольшой test dataset с реальными кейсами смены плана.

Domain owner принимает решение, когда на кону деньги. Если бизнесу нужна скорость, этот человек может сначала одобрить ограниченный релиз для аккаунтов с меньшим риском. Если на той неделе важнее точность finance, он может отложить запуск, пока команда не проверит все пути по налогам и возвратам.

Такое разделение делает ответственность понятной. Operator создаёт, reviewer проверяет, architect улучшает процесс, а domain owner решает, какой риск должен принять бизнес.

Распространённые ошибки, из-за которых возникают щели

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

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

Команды также попадают в неприятности, когда architect начинает отвечать за ежедневную доставку. Architect должен задавать структуру: стандарты, границы, передачи и пути отказа. Если этот человек каждый день сам дожимает тикеты до конца, структура устаревает, и никто не обновляет правила, по которым работает AI.

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

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

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

Быстрая проверка перед следующей автоматизацией

Команды обычно добавляют ещё больше AI до того, как исправят ответственность. Именно так работа уходит сквозь щели: модель что-то сделала, кто-то мельком посмотрел, и никто не знал, у кого финальное решение.

Прежде чем автоматизировать ещё один шаг, проверьте несколько базовых вещей:

• Дайте каждому процессу одного названного владельца. Не отдел и не «product team».
• Напишите правило проверки для каждого действия AI. Решите, что может пройти само, что требует проверки человеком, а что должно остановиться до одобрения.
• Объясните reviewer, как выглядит отказ. Неверные факты, пропущенные крайние случаи, сломанное форматирование или рискованное изменение без объяснения должны легко называться.
• Убедитесь, что architect видит повторяющиеся шаблоны. Повторные ошибки важнее единичных.
• Попросите domain owner зафиксировать компромиссы между скоростью, точностью, стоимостью, юридическим риском и влиянием на клиента.

Небольшая команда может проверить это за один день. Возьмите один процесс, например AI-черновики release notes или ответы поддержки, и поставьте имена рядом с каждым решением. Если вы не можете сделать это на одной странице, процесс ещё не готов к большей автоматизации.

Что делать дальше

Выберите один процесс, который ломается маленькими, но дорогими ошибками. Хорошими первыми кандидатами обычно бывают bug triage, ответы поддержки, проверка релизов или внутренняя отчётность. Если люди уже говорят: «Я думал, это сделал AI», вы, вероятно, нашли правильную точку старта.

Сделайте первую карту ролей на одной странице. Вверху укажите название процесса, затем назначьте operator, reviewer, architect и domain owner. Для каждой роли добавьте по одному короткому предложению: что этот человек решает, что проверяет и когда работа двигается дальше. Если сейчас один человек совмещает две роли, запишите это. Скрытое пересечение ролей создаёт больше проблем, чем размер команды.

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

Обычно это самый быстрый способ сделать карту ролей полезной, а не декоративной. Грубая одностраничная версия, которой люди реально пользуются, лучше отполированной схемы, которую никто не открывает.

Если вашей команде нужна внешняя помощь, Oleg Sotnikov на oleg.is работает как fractional CTO и startup advisor. Он помогает командам превращать внедрение AI в понятную ответственность, циклы проверки и практичные правила работы вместо набора быстрых, но разрозненных результатов.