Сотрудник говорит «с ИИ медленнее»: как это проверить

Руководитель раздал команде инструмент. Через месяц один из инженеров приходит и говорит: с ИИ у меня получается медленнее, чем руками. Дальше обычно происходит одно из двух. Либо руководитель решает, что человек саботирует, и начинает давить. Либо решает, что инструмент не тот, и сворачивает внедрение.

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

Эту развилку подробно разбирали основатели школы менеджмента Стратоплан Александр Орлов и Слава Панкратов в подкасте Михаила Омельченко «Купили ИИ, а команда им не пользуется». Больше шестнадцати лет они учат тимлидов и директоров, через открытые программы у них проходит 600–700 человек в год – выборка жалоб на внедрение у них приличная. Ответ, к которому они приходят, звучит неудобно для обеих сторон: по одному человеку вывода не получится сделать никак.

Почему одного сотрудника недостаточно

Сотрудник взял новый инструмент и выбирает, на чём его пробовать. Выбирает он почти всегда одинаково: «вот это я знаю, как сделать руками, а вот это не знаю – дай-ка попробую с ИИ». Логика человеческая и понятная. Только в этот момент в замере оказывается сразу две переменные: незнакомый инструмент и незнакомый тип задачи. Получилось медленнее – а из-за чего именно, не знает ни он, ни вы.

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

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

С ИИ ровно та же арифметика. Сгенерировать текст или код стало быстрее, а отсмотреть, сверить и переписать – нет. На части задач эта разница пока не в пользу инструмента, и признать это честнее, чем объяснять сопротивлением.

Первое, что надо проверить, – как вы это внедряли

Прежде чем разбираться с самим замером, посмотрите на историю вопроса.

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

Механика простая: ответственность рождается из добровольного выбора. Человек, который сам выбрал инструмент, сам за него и отвечает, и отрицательный отчёт для него невыгоден – он признаёт, что ошибся в собственной инициативе. Когда такой человек говорит «медленнее», это данные. Когда так говорит человек, которому инструмент выдали, это может быть и данными, и итальянской забастовкой: мы месяц поиспользуем, вы сами увидите, что это ерунда.

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

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

Схема, которая отвечает вместо догадок

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

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

Что важно зафиксировать до старта:

• Один тип задач. Конкретный повторяющийся кусок: разбор входящих обращений, подготовка статус-отчёта, ревью требований. «Месяц работы» сравнивать не с чем.
• Одинаковый вход. Группы получают задачи из одной очереди, а не «сложные – опытным».
• Срок, названный заранее. Две-три недели. Срок, который вы двигаете по ходу, превращает замер в поиск подтверждений.
• Метрика результата. Сколько обращений разобрано и сколько вернулось на переделку. Расход токенов сюда не годится: он показывает нагрузку на инструмент и ничего не говорит о сделанной работе.
• Условие провала. Что именно вы увидите, чтобы признать «на этом участке не работает». Без этого условия эксперимент заканчивается тем, что внедрение продлевают ещё на месяц.

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

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

Чемпион полезнее среднего

Пока идёт замер, у вас появляется второй источник данных, который часто ценнее итоговых цифр.

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

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

Соберите схему замера на своей ситуации

Проектирование такого замера – ровно та задача, где модель полезна: нужно разложить ситуацию на переменные, назвать то, что вы не заметили, и выдать таблицу, с которой можно идти к команде. Ниже она запускается на двух моделях, которые в нашем бенчмарке сильнее всего в планировании: Kimi K3 и GPT-5.6 Sol. Запустите как есть или замените описание ситуации на своё.

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

Чего этот замер не покажет

Замер не ответит, была ли у команды проблема. Если инструмент ускоряет генерацию, а у команды скорость генерации не была узким местом, никакая контрольная группа этого не исправит – вы получите аккуратно измеренное отсутствие эффекта. В подкасте это описывают так: принесли пилу людям, которым нечего пилить. Проверять надо было раньше, на этапе согласия по проблеме. Что происходит, когда таких проверок не делает целая отрасль, видно по годовым замерам внедрения: доля пользующихся растёт, измеримая отдача стоит на месте.

Не ответит он и на вопрос, стоит ли менять сам процесс. Требовать использования ИИ в потоковых процессах – в поддержке, в разборе почты, в массовом обслуживании – можно и нормально: там уже была система, вы меняете в ней один узел. Почему при этом общий мандат «все пользуемся ИИ» ломается о команду, которая делится на трети, мы разбирали в отдельной статье.

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

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

Что сделать на этой неделе

Если у вас прямо сейчас лежит такая жалоба, порядок действий короткий.

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

Вывод «инструмент не работает» стоит ровно столько же, сколько вывод «сотрудник саботирует», пока за ним не стоит сравнение. Разница между руководителем, который догадывается, и руководителем, который знает, – это одна контрольная группа.

Читайте также

Уйдут первыми: главный кадровый риск ИИ – это мидлы

Репетиция сложного разговора с ИИ: опыт 40 тысяч менеджеров

ИИ на рабочем месте: внедрение растёт, отдача застряла

Промпт-инжиниринг работает: одна модель, два результата