Привет, Хабр! Меня зовут Василий, я директор SaaS-направления в Аспро — мы разрабатываем систему управления проектами Аспро.Cloud.

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

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

Дедлайн по проекту все равно горит.

Он смотрит на цифры еще раз. Активность есть. Результата нет.

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

Почему мониторинг дает только иллюзию контроля

Даже сами компании, которые ставят трекеры, все чаще не верят в их эффект. По данным SuperJob (февраль 2025, опрос 300 HR-менеджеров российских компаний):

За два года доля компаний, которые вообще следят за активностью сотрудников, снизилась почти на треть. Практика показала: сам факт наблюдения ничего не гарантирует — этим и объясняется такое падение.

Ольга Гордякова, кандидат психологических наук из Института психологии РАН, объясняет причину в комментарии для АиФ: тотальный контроль переключает фокус сотрудника с результата на процесс. Человек начинает работать на то, чтобы выглядеть занятым, а не на то, чтобы довести задачу до конца. Доверие заменяется страхом, страх включает защитную реакцию — имитацию деятельности вместо настоящей работы.

Проблема не только психологическая. У метода есть слепая зона именно там, где чаще всего теряется время.

Допустим: сотрудник онлайн весь день, статус зеленый с утра до вечера, экран активен. Задача при этом просрочена на неделю.

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

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

Получается, мониторинг не решает ни задачу доверия, ни задачу видимости. Нужен другой инструмент — метрики, которые считают не активность человека, а движение самой задачи.

Метрики эффективности команды — throughput, cycle time и что с ними делать

Здесь ничего сверхнового. База знакома любому, кто работал с Agile:

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

Отчет по затраченному времени на каждом этапе задачи

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

Закон Гудхарта — почему одна метрика становится поводом для читерства

Как только throughput становится официальной целью команды — тем, по чему оценивают работу — с ним начинают происходить странные вещи.

Допустим, по итогам спринта смотрят только на количество закрытых задач. Через месяц кто-то замечает: одна большая задача превратилась в пять маленьких карточек. Throughput формально вырос. Объем сделанной работы остался прежним — задачу просто раздробили под метрику.

Закон Гудхарта: когда показатель становится целью, он перестает быть хорошим показателем.

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

Рабочий прием, который закрывает эту проблему — смотреть не одну метрику, а пару с противоположным давлением:

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

Метрика соврала из-за читерства. Описано выше, лечится парной метрикой.

Метрика соврала не по вине человека. Плохой cycle time — из-за чужого согласования или больничного. Метрика в этом случае — повод открыть карточку задачи и посмотреть историю: где она стояла, кто ее держал, что написано в комментариях.

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

Не только разработка

Эта же логика работает не только в разработке. Метрики результата переносятся на любую роль в агентстве, если доска задач настроена одинаково для всех отделов:

Принцип один и тот же для каждой роли: объем сделанного всегда смотрим вместе с долей возвратов на доработку.

Контроль и видимость — разные вещи

На уровне любой из этих ролей разница с трекером экрана сводится к одному и тому же — к разнице между контролем и видимостью:

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

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

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

• Начните с одной пары метрик. Четыре метрики одновременно команда воспримет как новый вид контроля под другим названием

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

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

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

Итог

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

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

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

А у вас в команде метрики уже прижились, или каждая попытка их внедрить превращается в новый повод для читерства?