Почему опытные сотрудники увольняются после внедрения ИИ на работе

Что меняется после внедрения

Первый сдвиг обычно не технический. Он социальный.

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

Если модель пишет код, спецификации или ответы клиентам, все равно кто-то решает, что пойдет в релиз. Когда эта граница размыта, доверие быстро падает.

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

Очереди на проверку часто растут быстрее, чем выпуск результата. ИИ может за то же время создать десять черновиков, за которое раньше один человек делал один. Это звучит эффективно, пока одному опытному сотруднику не нужно проверить все десять. Его день превращается в отбор, исправления и объяснения. Более глубокая работа исчезает, и его роль начинает казаться бесполезной.

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

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

Когда люди обвиняют инструмент, они часто реагируют на путаницу.

Где ломается авторитет

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

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

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

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

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

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

Почему шумные приоритеты выталкивают людей

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

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

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

Типичная картина выглядит так. В начале недели у команды есть понятный план — улучшить один процесс поддержки клиентов. Ко вторнику продажи хотят показать кастомную демонстрацию ИИ. В среду кто-то просит внутреннего помощника для HR. В четверг руководство хочет новую форму оценки сгенерированного контента. По отдельности ни одна просьба не звучит безумно. Вместе они ломают весь темп.

Проблема не в дополнительной работе. Проблема в постоянном перезапуске.

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

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

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

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

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

Как слабый дизайн проверки создает еще больше работы

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

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

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

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

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

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

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

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

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

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

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

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

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

Как исправить это шаг за шагом

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

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

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

Уместите это на одну страницу. Если для объяснения нужен длинный документ, значит, процесс все еще слишком расплывчатый.

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

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

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

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

Ошибки, которые повышают вероятность ухода

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

Одна плохая ошибка — считать любое замечание сопротивлением. Staff engineer говорит, что результат ИИ создает скрытые баги, или продакт-лид говорит, что новый процесс добавляет время на проверку. Если в ответ звучит «тебе просто нужно адаптироваться», люди перестают поднимать проблемы. После этого они либо отстраняются, либо уходят.

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

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

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

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

Быстрые проверки на ближайшие две недели

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

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

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

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

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

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

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

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

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

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

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

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

Основатели часто упускают проблему, потому что видят план, а не ежедневное трение. Внешний оператор может помочь, когда менеджеры спорят, проверки зацикливаются или никто не может объяснить, почему задача стала занимать больше времени. Oleg Sotnikov на oleg.is работает как Fractional CTO и startup advisor, и именно такого рода уборка — ответственность, пути проверки и практичное внедрение ИИ — как раз та область, где внешний взгляд очень помогает.

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