Ловушка миграции на ИИ: старые цепочки согласования тормозят команды

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

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

На бумаге команда выглядит быстрее.

Но работа часто останавливается в том же месте.

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

Это и есть ловушка миграции на ИИ. Инструмент ускоряется, а путь принятия решений — нет.

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

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

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

Ни одна из этих задержек не возникает из-за инструмента. Они возникают из-за того, кто имеет право сказать «да».

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

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

Почему старые цепочки согласования тормозят скорость

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

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

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

Ни один отдельный шаг не звучит драматично. Вместе они могут превратить задачу на пятнадцать минут в задачу на три дня.

Вот почему команды чувствуют растерянность после внедрения инструмента. ИИ работает. Черновики лучше. Первый проход быстрее. А скорость поставки почти не меняется, потому что работа всё равно сидит в человеческой очереди.

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

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

Лучшие черновики помогают, но не разжимают застрявшие решения. Сильное предложение, сгенерированное ИИ, всё равно ждёт, если рядом с работой никто не может его утвердить. Отполированный ответ поддержки всё равно лежит без движения, если каждую необычную ситуацию должен смотреть директор. Чистое продуктовое ТЗ всё равно буксует, если один человек должен благословить каждое изменение.

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

Признаки того, что команда сменила инструменты, но не полномочия

Быстрая ИИ-настройка с медленной цепочкой согласования создаёт более аккуратные очереди, а не более быструю поставку. Работа делается раньше, но никто не может её выпустить, пока не отреагируют те же несколько людей.

Обычно это видно в ежедневном поведении ещё до того, как это появится в отчётах.

Один из очевидных признаков — растущая очередь на проверку. Черновики, сводки, тикеты, макеты и код вроде бы готовы, но они висят в чатах, документах или на досках задач в ожидании ответа сверху. ИИ убрал задержку на создание, поэтому узкое место в согласовании стало заметнее.

Ещё один признак — постоянные просьбы разрешения даже на мелкие изменения. Кто-то обновляет статью помощи, переписывает письмо или меняет подпись в форме, а потом просит менеджера это одобрить. Это не здоровая осторожность. Обычно это значит, что никто не понимает, кто владеет обычными решениями.

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

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

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

Обычно вместе встречается несколько паттернов:

• Время на создание работы сокращается, но не на выпуск.
• Участники команды чаще спрашивают «Можно?» чем «Это сработало?»
• Менеджеры правят формулировки там, где должны задавать границы.
• Готовые результаты лежат без дела в общих папках и чатах.

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

Простой пример небольшой команды

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

В 9:00 основатель кидает запрос в чат. К 9:15 менеджер продукта с помощью ИИ готовит три версии нового письма и пишет короткий тикет с критериями приёмки. Раньше на это уходил час. Теперь — пятнадцать минут.

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

В 11:20 тестировщик превращает тикет в короткий чек-лист и проверяет письмо на staging. Есть одна проблема с отступом. Разработчик исправляет её за десять минут. Вторая проверка проходит успешно. К 11:45 работа готова.

Если смотреть только на инструменты, это выглядит как явная победа. Черновики стали быстрее. Написание тикета стало быстрее. Тестирование стало быстрее. Вся задача прошла путь от запроса до готовности к выпуску меньше чем за три часа.

Потом включается старая цепочка.

Маркетинг-лид должен утвердить весь текст для клиентов. Руководитель продукта должен согласовать все изменения перед релизом. Основатель по-прежнему даёт финальное добро на всё, что видят клиенты.

Никто из этих людей не касался работы, пока она двигалась. Маркетинг-лид занят на встречах до 15:00. Руководитель продукта смотрит её в 16:30 и говорит, что всё нормально. Основатель видит сообщение в 19:40, но хочет проверить его только утром следующего дня.

Команда выпускает изменение в 10:15 следующего дня.

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

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

Задержка возникла не из-за софта. Она возникла из-за людей, которые держат полномочия, уже не нужные для такого маленького изменения.

Как заново распределить полномочия принимать решения

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

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

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

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

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

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

Зафиксируйте правила письменно

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

Делайте это конкретно. «Инженеры могут выпускать исправления, которые не меняют биллинг, безопасность или поведение публичного API» — это понятно. «Используйте здравый смысл» — нет.

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

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

Где согласование всё ещё необходимо

Некоторые согласования должны оставаться. Ошибка в том, чтобы оставить их везде.

Юридическая служба, безопасность и финансы всё ещё должны участвовать, когда риск реален. Изменение договора, обновление цен, правило хранения данных или платёжный процесс могут быстро нанести вред клиенту. Рутинная работа — другое дело. Если кто-то использует ИИ, чтобы подготовить внутреннюю сводку или первую версию ответа поддержки, дополнительное согласование часто добавляет задержку, но не добавляет безопасности.

Сначала установите пороги, потом назначайте согласующих

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

Простой набор порогов может выглядеть так:

• Юристы проверяют изменения в условиях для клиентов, в тексте о конфиденциальности или в договорах с поставщиками.
• Безопасность проверяет всё, что касается производственных данных, контроля доступа или внешних подключений к моделям.
• Финансы проверяют изменения цен, возвраты выше заданной суммы или расходы сверх месячного лимита.
• Менеджер подключается только тогда, когда влияние на клиента, потери дохода или риск несоответствия проходят заданную границу.

Эти границы должны быть числовыми и понятными. «Спросите финансы, если возвраты превышают $500» работает лучше, чем «Проверьте с финансами крупные возвраты». Конкретные пороги снимают споры и сокращают задержку.

Типичные ошибки при переходе

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

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

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

Менеджеры также по привычке проверяют черновики. Раньше это казалось ответственным подходом. Теперь часто это неправильная точка контроля.

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

Короткий чек-лист помогает сделать проблему видимой:

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

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

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

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

Если эти цифры не меняются, переход всё ещё выполнен наполовину. Инструмент изменился. Полномочия — нет.

Быстрая проверка и следующие шаги

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

Используйте этот короткий аудит вместе с тимлидом, владельцем продукта или основателем:

• Может ли команда выпустить небольшое изменение, не спрашивая дважды?
• У каждого повторяющегося решения есть один понятный владелец?
• Есть ли у согласований временной лимит, например в тот же день или в течение 24 часов?
• Проверяют ли менеджеры результаты, метрики и влияние на клиентов вместо того, чтобы читать каждый черновик?
• Умеют ли люди отличать высокорисковое изменение от рутинного?

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

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

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

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

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

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

Некоторым командам нужен внешний взгляд, потому что внутри никто не может поменять правила, не упираясь в политику. Олег Сотников на oleg.is работает со стартапами и небольшими бизнесами как временный CTO, помогая делать внедрение ИИ практичным, а не просто добавлять ещё больше инструментов.

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