Оценка эффективности работы с AI: что измерять вместо скорости

Почему старые привычки оценки ломаются в командах, где много AI

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

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

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

Старые привычки оценки не замечают этого сдвига. Многие менеджеры по-прежнему опираются на видимую активность, потому что её легко посчитать:

• количество строк кода
• закрытые тикеты
• слитые pull request’ы
• время в сети

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

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

Представьте простой пример. Инженер A использует AI и за день выпускает десять небольших изменений. Инженер B делает три, но убирает хрупкую зависимость, добавляет защитную проверку в CI и находит баг, который ударил бы по клиентам после релиза. Старые таблицы оценок часто будут на стороне Инженера A. Но команде обычно полезнее Инженер B.

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

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

Как выглядит хорошая работа сейчас

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

В оценке работы с AI скорость должна стоять ниже здравого суждения. Сильные люди сначала задают простые вопросы. Безопасно ли это автоматизировать? Нужна ли проверка человеком? Сэкономит ли это время в следующем месяце или создаст ещё больше уборки? Эти решения влияют на итог сильнее, чем сам объём выдачи.

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

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

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

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

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

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

Как выстроить честный процесс оценки

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

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

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

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

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

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

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

Для engineering management важнее последовательность, чем ложная точность. Если двое имели доступ к одним и тем же AI-инструментам, чьей работе вы доверили бы прод? В большинстве команд это доверие строится на качестве решений, предотвращении дефектов и заботе о системе.

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

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

Инженер A получает черновик от AI-помощника, приводит его в порядок и в тот же день открывает pull request. На бумаге это выглядит впечатляюще. Фича работает на хорошем сценарии, а демо проходит отлично.

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

К пятнице обе версии уже можно выпускать. Но лучшая оценка должна достаться только одной.

Что изменил аккуратный релиз

Инженер B добавила небольшой набор тестов для крайних случаев биллинга, закрыла релиз feature flag’ом и написала план отката, которым on-call-инженер может воспользоваться за минуты. Она также добавила простой лог для неудачных состояний оплаты, чтобы команда могла раньше заметить проблему.

Инженер A выкатил всё быстрее, но команда заплатила за эту скорость сразу. Поддержка получила обращения, потому что часть счетов выглядела неверно. QA пришлось заново проверять поток после hotfix. Продуктовому менеджеру пришлось полдня объяснять клиентам, почему суммы изменились. Код не просто создал баги. Он создал лишнюю работу для всех вокруг.

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

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

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

Ошибки, которые искажают оценки

Скорость легко считать, поэтому команды часто принимают её за признак сильной работы. В компаниях, где много AI, это быстро ломается. Человек может сделать вдвое больше тикетов, pull request’ов или запусков промпта и всё равно принимать худшие решения, создавать переделки и оставлять беспорядок для остальных.

Оценки идут не туда, когда менеджеры вознаграждают только объём результата. Больше текста, больше коммитов и больше feature flag’ов не означает лучший результат. Если инженер выпускает десять изменений с AI, а они создают баги, нагрузку на поддержку или работу по откату, команда заплатила за скорость будущей болью.

Ещё одна частая ошибка — путать умение пользоваться инструментом с качеством суждения. Кто-то может знать все shortcuts в Claude, GPT или в инструментах генерации кода. Это помогает, но это не то же самое, что выбирать безопасные компромиссы, замечать слабые допущения или понимать, когда рискованный шаг лучше не автоматизировать.

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

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

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

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

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

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

Где искать доказательства реального влияния

Скорость увидеть легко. Реальное влияние оставляет след.

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

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

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

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

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

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

Отзывы коллег полезны, если задавать узкие вопросы. Не спрашивайте: «Насколько комфортно было работать с этим человеком?» Лучше спросите, чем он владел, когда работа становилась грязной, объяснял ли он решения понятно и доводил ли дело до конца после встреч. Такие ответы сложнее подделать, и они показывают, кто уменьшает хаос.

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

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

Короткий чек-лист перед оценкой любого человека

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

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

Помогают несколько вопросов:

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

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

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

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

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

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

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

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

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

Пилот делайте простым. Берите примеры из ретроспектив, разборов инцидентов, потоков code review и заметок по релизам. Отмечайте решения, которые предотвратили переделки, сбои или баги, видимые клиентам. Сравнивайте self-review с оценками менеджера, чтобы рано заметить расплывчатые критерии. Убедитесь, что рубрика даёт кредит за cleanup, документацию и ownership.

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

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

Если вашей компании нужна помощь в выстраивании такого стандарта, Oleg Sotnikov на oleg.is работает со стартапами и небольшими командами как fractional CTO и advisor. Его опыт в создании AI-first среды разработки и управлении lean production-системами поможет превратить критерии оценки в то, чем менеджеры действительно могут пользоваться.