В AI-командах за домен всё ещё должен отвечать человек

Почему это быстро становится проблемой

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

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

Большинство команд чувствуют одно и то же давление с трёх сторон: бюджет, риск и сроки. Сколько времени и денег стоит вложить в эту проблему? Что может сломаться, и кто заплатит за ошибку? Мы запускаемся сейчас, ждём неделю или урезаем scope?

AI может предложить умные варианты для каждого из этих вопросов. Но он не может нести бизнес-цену неверного выбора. Модель не будет сидеть на звонке с клиентом после плохого релиза. Она не объяснит инвесторам сорванный дедлайн. Она не будет разгребать очередь возвратов, когда короткий путь превратится в хаос.

Особенно остро это чувствуется в AI-first-операциях, где маленькая команда может выпускать удивительно много работы. Founder видит больше закрытых тикетов, больше набросанных фич и больше экспериментов одновременно. Это похоже на прогресс. А потом возникает более сложный вопрос: какая работа действительно важна, что сейчас можно считать приемлемым риском и когда «достаточно хорошо» — это действительно достаточно хорошо.

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

Такая инерция дорогая. Никто не говорит «да». Никто не говорит «нет». Люди продолжают полировать черновики, менять промпты и заново открывать один и тот же вопрос чуть другими словами.

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

Что на самом деле значит владение доменом

Команда может просить AI писать код, готовить тесты, резюмировать звонки и сортировать обратную связь. Но всё это само по себе не создаёт ответственность. Ответственность начинается тогда, когда один человек говорит: «Эта зона — моя, я её понимаю, решаю по ней и улучшаю», и вся команда знает, кто принимает финальное решение.

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

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

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

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

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

Почему AI не может полностью взять это на себя

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

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

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

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

Именно поэтому сильное лидерство AI-команды всё ещё требует человека-лида. Founder, product owner или fractional CTO делает больше, чем проверяет результаты. Он задаёт границу допустимого риска, решает, какой компромисс подходит бизнесу, и удерживает это решение, когда новые промпты приносят новые мнения. Без такого владельца у команды будет много правдоподобных ответов и никакой реальной ответственности.

Где обычно возникают самые трудные решения

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

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

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

Крупные клиенты тоже заставляют принимать трудные решения. Большой аккаунт может попросить особый workflow, нестандартную логику ценообразования или разовую фичу, которая ломает продуктовый план. AI может предсказать рост выручки. Но он не защитит продукт от превращения в набор исключений. Владелец должен сказать «да», «нет» или «не сейчас» — и жить с этим результатом.

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

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

Простой пример из стартапа

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

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

AI-инструменты не могут договориться, что делать первым. Ассистент для кода хочет немедленно исправить billing logic и уверяет, что может выкатить патч за два часа. Ассистент для поддержки советует остановить исходящие сообщения, сделать кредиты и отправить понятное объяснение затронутым клиентам. QA-инструмент находит крайние случаи с продлениями, налогами и старыми купонами, а потом предупреждает, что безопасный фикс потребует более широкого прогонa тестов.

Все три предложения сами по себе разумны. Но ни одно из них не решает, какой риск должен взять на себя бизнес.

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

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

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

Fractional CTO может помочь проверить план на прочность, особенно когда billing затрагивает архитектуру, аналитику и workflow поддержки. Но трудное решение всё равно остаётся за человеком, который владеет доменом и может сказать: «Сначала мы сделаем это, и завтра я отвечу за этот выбор».

Как назначать ответственного в команде с большим количеством AI

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

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

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

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

Ошибки, которые команды совершают, когда гонятся за полной автоматизацией

Команды, которые давят на полную автоматизацию, часто делают одну и ту же неудачную ставку. Они считают ответственность административной работой. Это не так. Самое дорогое по-прежнему — это здравый смысл. Кто-то должен решать, что важно, что может подождать и какой риск компания готова принять.

Одна из частых ошибок — называть домен «shared», потому что к нему прикасаются трое. На бумаге это выглядит справедливо. На практике обычно означает, что никто не отвечает за финальное решение. Когда растут жалобы, ломается прайсинг или релиз начинает бить по конверсии, команда теряет время на выяснение, кто принимает решение. Совместная работа может быть хорошей. Совместная ответственность обычно — нет.

Другая ошибка — позволять выводу модели задавать приоритеты. AI может сортировать баги, резюмировать звонки и подсказывать, что выглядит срочным. Но он не чувствует боль бизнеса, которая стоит за данными. Шумная проблема может подняться наверх просто потому, что пользователи часто о ней пишут, а тихая — ежедневно утекает выручкой. Человеку-лидеру нужно посмотреть на всю картину и сказать: «Нет, сначала идёт вот это».

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

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

Быстрая проверка, прежде чем считать, что всё уже закрыто

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

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

Инциденты сразу показывают, где есть разрыв. Когда релиз ломает биллинг или support automation начинает отправлять неверные ответы, команда уже должна знать, кто принимает решение. Ожидание подходящего group chat часто превращает маленькую проблему в проблему клиента.

Полезно записывать компромиссы, лежащие в основе текущего плана. Достаточно короткой заметки: что вы выбрали, что отвергли и какой риск приняли. Без этого AI-сводки расплываются, человеческая память расплывается, и команда снова и снова возвращается к одному и тому же спору каждую неделю.

Простой способ проверки — задать четыре вопроса:

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

Если ответы на эти вопросы размыты, значит, домен на самом деле не закрыт.

Недостаток ответственности можно заметить и по другим признакам. Приоритеты меняются от встречи к встрече. После релиза люди спрашивают: «Кто это одобрил?». Инциденты прыгают между engineering, product и support. Никто не может объяснить, почему команда выбрала именно этот путь. Это не проблема процесса. Это проблема ответственности.

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

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

Назначьте одного человека на каждый домен и держите scope узким. «Growth» — слишком широко. «Конверсия trial у self-serve пользователей» — уже понятно. «Инфраструктура» — слишком широко. «Uptime в production и облачные расходы» — уже понятно. Узкий scope делает решения чище, а реальная власть делает ответственность настоящей. Если человеку нужно одобрение трёх других людей, прежде чем действовать, значит, он этим не владеет.

Хорошо работает простой стартовый набор:

• Определите 3–5 доменов, где ошибка стоит дороже всего.
• Дайте каждому домену одного владельца, одну письменную цель и одно чёткое ограничение на то, что он может решать сам.
• Используйте AI, чтобы собирать контекст, сравнивать варианты и подсвечивать риски.
• Пусть владелец выбирает, объясняет компромисс и отвечает за результат.

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

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

Именно такую работу Oleg Sotnikov делает на oleg.is как fractional CTO и startup advisor. Он помогает стартапам и небольшим компаниям выстраивать чёткую ответственность за продукт, инфраструктуру и AI-driven разработку, чтобы команды могли двигаться быстрее, не отказываясь от человеческого здравого смысла.

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