Такие случаи мы стали записывать в отдельный внутренний дайджест и назвали его «Онтология сопротивления». И вот что мы заметили: почти каждый отказ работать с ИИ показывает место, где процесс держался на человеке с контекстом в голове. Так, каждый кейс помог нам найти узкие места в наших рабочих процессах и устранить их.
Ранее мы подробно писали о том, как выстраиваем AI-first-подход внутри компании. В этой статье покажем кейсы сопротивления, которые встречались в нашей команде. Можно с уверенностью сказать, что подобные кейсы актуальны для многих компаний, которые уже раздали ИИ-инструменты командам и не видят обещанного эффекта.
1. «Все и так это знают»: правило, которое не записали
Показательный случай, с которого мы начали смотреть на сопротивление иначе. Frontend-разработчик сделал задачу по фильтрации и сортировке каталога на веб-странице, применив Delivery Kit (набор спецификаций, разработанных внутри команды разработчиков Napoleon IT). Но аналитик вернул задачу обратно, так как в проекте есть “всем известное” правило: при перезагрузке страницы примененные фильтры и сортировка должны сохраняться. Требование действует на весь проект, но нигде оно не записано, есть только в голове “старичков”. Новый разработчик не мог знать об этом правиле.
Здесь явно подсвечивается момент, что любое правило должно быть задокументировано для оперативного онбординга как новых сотрудников, так и ИИ-агентов. Когда контекст перестают докармливать вручную, сразу видно, сколько требований нигде не живёт
2. «Я пробовал год назад, не понравилось»: давний негативный опыт
Самая частая реакция на старте активного внедрения. Сотрудник ссылается на опыт, полученный на моделях прошлого поколения, и решение принимает, не повторяя новых попыток.
ИИ-компании за год выпускают по несколько новых поколений моделей. Человек оценивает инструмент, которого больше нет, и не перепроверяет повторно, потому что вопрос для него закрыт.
Что диагностируем: сотрудник не успел проверить актуальные возможности ИИ на своих рабочих задачах. Презентации и обучение по возможностям ИИ не решают эту проблему: сотрудник видит, как технология работает на чужих примерах, но не понимает, насколько она полезна именно в его работе.
3. «Пусть сам догадается»: проверка модели вместо работы
Бывают случаи, когда сотрудники сознательно не пишут в промпт часть контекста, который держат в голове и который уже обсудили с коллегами, полагая, что ИИ сам додумает, что имеется в виду.
Сотрудник перестаёт использовать ИИ как инструмент и начинает тестировать его на знание проекта. Доказательство срабатывает, потому что модель действительно знает проект хуже. Разница в том, что на это ушёл рабочий день.
Что диагностируем: сотрудники боятся изменений и не чувствуют себя в безопасности, полагая, что их может заменить ИИ. Здесь важно донести сотруднику, что цель не заменить сотрудника, а ускорить его работу, убрать рутинные операции, закрывать больше рабочих задач за единицу времени.
О том, как меняется набор навыков специалиста в такой связке, у нас есть отдельный материал про ключевые компетенции в эпоху ИИ.
4. «Чтобы я был уверен»: лишняя ручная проверка
Сотрудник не позволяет агенту выполнять некоторые виды работ (например, декомпозировать задачи в трекере, хотя это заложено в процессе) и создаёт все тикеты руками. Причина: сотрудник не хочет, чтобы от его лица генерировались задачи, которые могут быть по-разному восприняты коллегами из других отделов.
Что диагностируем: команде было выдано готовое решение без детального пояснения, как оно устроено внутри. Человек достраивал механику по своим представлениям, находил там угрозу для себя и ставил ручной гейт. Чтобы такие случаи не повторялись, проводим регулярные ретро с командами, куда внедряем ИИ, для понимания как они ведут тот или иной процесс.
5. «ИИ не работает»: приговор инструменту по одному провалу
Сотрудник дважды пробует собрать с ИИ внутренний аналитический отчёт. Первый подход занимает 4 часа, второй около 8, оба раза в цифрах находятся расхождения. Руками тот же отчёт собирается за 1,5 часа. Вывод по итогу: оформление хорошее, к содержанию доверия нет.
Формально это отказ от инструмента по одному классу задач. По факту сотрудник сделал ровно то, что должен был: перепроверил цифры и нашёл расхождения до того, как отчёт куда-то ушёл. Спорить с такой позицией бессмысленно и вредно.
В модели компетенций Anthropic это соответствует фреймворку 4D: делегирование, описание, критическая оценка и ответственность. Чтобы делегировать задачу ИИ, сначала нужно описать сам процесс: источники данных, порядок действий и правила проверки результата. Если процесс существует только в голове одного сотрудника и он ее не может делегировать другому человеку, то передать задачу ИИ тоже не получится. В этом случае проблема не в модели, а в неготовности процесса к гибридизации.
Ключевая ошибка: раскатали ИИ на всё сразу
ИИ дали всей команде для внедрения в текущие процессы, ничего в самих процессах не поменяв. Скорость отдельных операций выросла, а узкие места, размытые требования и суета вокруг приоритетов остались на месте.
«Мы пытались внедрить ИИ сразу во все процессы, вместо того чтобы собрать одну команду и перестроить процесс на ней. Так ускоряется не работа, а хаос», – говорит Евгений Жорницкий, операционный директор Napoleon IT.
О том, что чаще всего ломается при внедрении, мы писали подробно в материале «Внедрение ИИ в бизнес: что ломается чаще всего и как это починить».
Что делать с сопротивлениями в команде
- Соберите отказы письменно. Заведите один файл и вносите туда каждый случай, когда сотрудник отказывается использовать ИИ-инструменты: кто, на какой задаче, дословная формулировка причины. Через месяц получите карту процессных дыр, собранную людьми, которые в этих процессах работают.
- Разберите каждый отказ. Мы привели примеры самых частых кейсов. Возможно, в вашей компании будут другие примеры.
- Начните с одного контура, а не со всей компании. Пока процесс не перестроен, ИИ ускоряет и то, что потом переделывают.
- Проверьте, где у вас живут требования уровня проекта. Если ответ «в головах сотрудников», ИИ покажет это первым же провалом, и стоить это будет дороже, чем несколько дней на их документирование.
Если вы перестраиваете разработку или другие отделы под ИИ и упираетесь в то же самое, гибридные специалисты Napoleon IT работают в связке с собственной ИИ-инфраструктурой и приходят в проект уже с перестроенным процессом. Расскажите о своей задаче, обсудим, как это можно реализовать.
