Привет, Хабр! Меня зовут Василий, я директор SaaS-направления в Аспро — мы разрабатываем систему управления проектами Аспро.Cloud.
Руководитель хочет знать одну простую вещь: движется ли работа. Самый очевидный способ проверить это — посмотреть, кто сейчас занят делом. Отсюда растет соблазн поставить трекер экрана или систему учета активности: если видно, что человек за компьютером и что-то делает, значит, дело идет.
Загвоздка в том, что активность и результат — разные вещи, и трекер умеет отвечать только на вопрос про активность. В итоге руководитель ставит трекер экрана. Через неделю у него дашборд с зелеными полосами: все на месте, часы залогинены, активность стабильная.
Дедлайн по проекту все равно горит.
Он смотрит на цифры еще раз. Активность есть. Результата нет.
Трекер экрана показывает присутствие. Для управления командой нужен результат. Дальше разберем, почему трекер почти всегда путает эти два понятия и что показывает происходящее внутри работы точнее, чем зеленый статус на экране.
Почему мониторинг дает только иллюзию контроля
Даже сами компании, которые ставят трекеры, все чаще не верят в их эффект. По данным SuperJob (февраль 2025, опрос 300 HR-менеджеров российских компаний):
Показатель |
Значение |
Компании, которые следят за активностью сотрудников на ПК |
19% (снижение на треть с 2023 года) |
Компании, считающие такую слежку излишней мерой |
59% |
Компании, не видящие эффекта от мониторинга |
53% |
HR, считавшие контроль полезным в 2023 году |
56% |
HR, считающие контроль полезным в 2025 году |
26% |
За два года доля компаний, которые вообще следят за активностью сотрудников, снизилась почти на треть. Практика показала: сам факт наблюдения ничего не гарантирует — этим и объясняется такое падение.
Ольга Гордякова, кандидат психологических наук из Института психологии РАН, объясняет причину в комментарии для АиФ: тотальный контроль переключает фокус сотрудника с результата на процесс. Человек начинает работать на то, чтобы выглядеть занятым, а не на то, чтобы довести задачу до конца. Доверие заменяется страхом, страх включает защитную реакцию — имитацию деятельности вместо настоящей работы.
Проблема не только психологическая. У метода есть слепая зона именно там, где чаще всего теряется время.
Допустим: сотрудник онлайн весь день, статус зеленый с утра до вечера, экран активен. Задача при этом просрочена на неделю.
Причина обычно не в человеке за монитором. Задача застряла на согласовании у другого отдела, а потом еще три дня ждала ревью — и все это время трекер честно показывал, что сотрудник был на месте.
Трекер экрана видит одного человека перед одним монитором. Он не видит, что происходит с задачей между людьми — а именно на стыках между отделами чаще всего и теряется время.
Получается, мониторинг не решает ни задачу доверия, ни задачу видимости. Нужен другой инструмент — метрики, которые считают не активность человека, а движение самой задачи.
Метрики эффективности команды — throughput, cycle time и что с ними делать
Здесь ничего сверхнового. База знакома любому, кто работал с Agile:
Метрика |
Что показывает |
Throughput (пропускная способность) |
сколько задач команда закрывает за период |
Cycle time (время цикла) |
сколько времени задача реально идет от старта до готового результата |
Соблюдение дедлайнов |
укладывается команда в сроки и насколько |
Доля возвратов на доработку |
какой процент закрытых задач приходит обратно из-за брака |
Разница с трекером экрана принципиальная. Эти метрики считаются по движению задачи на доске — время от колонки до колонки, число закрытых карточек за спринт — а не по тому, сколько минут человек провел перед монитором. Можно быть максимально активным перед экраном и не продвинуть ни одну задачу. Можно закрыть три задачи, будучи оффлайн половину дня из-за созвонов и переговоров с клиентом.
Отчет по затраченному времени на каждом этапе задачи
Сама по себе ни одна из этих метрик не панацея. Стоит превратить любую из них в единственную цель — и появляется новая проблема, похожая на трекер экрана, только в других декорациях.
Закон Гудхарта — почему одна метрика становится поводом для читерства
Как только throughput становится официальной целью команды — тем, по чему оценивают работу — с ним начинают происходить странные вещи.
Допустим, по итогам спринта смотрят только на количество закрытых задач. Через месяц кто-то замечает: одна большая задача превратилась в пять маленьких карточек. Throughput формально вырос. Объем сделанной работы остался прежним — задачу просто раздробили под метрику.
Закон Гудхарта: когда показатель становится целью, он перестает быть хорошим показателем.
Люди рационально реагируют на то, что от них меряют. Если оценивают скорость закрытия задач, будут оптимизировать скорость закрытия задач, а не результат для клиента.
Рабочий прием, который закрывает эту проблему — смотреть не одну метрику, а пару с противоположным давлением:
Метрика растет |
Что проверить |
Что это может означать |
Throughput |
доля возвратов на доработку |
скорость шла в ущерб качеству |
Соблюдение дедлайнов (100%) |
доля задач, закрытых с оговорками в комментариях |
дедлайн формально закрыт, работа не доведена до конца |
Cycle time сократился |
доля задач, закрытых без полного тестирования |
ускорение достигнуто за счет пропущенных проверок |
Пара метрик закрывает читерство. Но метрика может ошибаться и по другим причинам, поэтому важно различать три ситуации, а не сваливать их в одну.
Метрика соврала из-за читерства. Описано выше, лечится парной метрикой.
Метрика соврала не по вине человека. Плохой cycle time — из-за чужого согласования или больничного. Метрика в этом случае — повод открыть карточку задачи и посмотреть историю: где она стояла, кто ее держал, что написано в комментариях.
Метрика права. Человек реально не успевает, реально делает много возвратов, реально не укладывается в сроки — без блокеров и без читерства, просто не справляется в текущем темпе или объеме работы. Это тоже нормальный результат работы с метриками: она показала проблему раньше, чем это стало бы очевидно по факту сорванного релиза. Дальше нужен разговор с конкретикой — что мешает, чего не хватает, где нужна помощь или перераспределение задач.
Не только разработка
Эта же логика работает не только в разработке. Метрики результата переносятся на любую роль в агентстве, если доска задач настроена одинаково для всех отделов:
Роль |
Throughput |
Пара для проверки |
Дизайнер |
количество согласованных макетов за спринт |
доля макетов на повторной правке после утверждения |
Поддержка |
количество закрытых обращений |
доля обращений, открытых повторно в течение недели |
Маркетинг |
количество запущенных материалов/кампаний |
доля материалов, отклоненных на согласовании у клиента |
Принцип один и тот же для каждой роли: объем сделанного всегда смотрим вместе с долей возвратов на доработку.
Контроль и видимость — разные вещи
На уровне любой из этих ролей разница с трекером экрана сводится к одному и тому же — к разнице между контролем и видимостью:
Контроль |
Видимость |
|
Что видит руководитель |
что делает каждый человек прямо сейчас |
где находится каждая задача и кто перегружен |
Что нужно для этого |
слежка за экраном |
нормально устроенная доска задач |
Что чувствует сотрудник |
наблюдение |
прозрачность процесса |
Руководителю не нужно видеть, сколько минут человек провел в почте. Ему нужно видеть, что задача Х застряла третий день, а у Игоря пять задач в работе одновременно, хотя у Марии — одна. Первое требует слежки за экраном. Второе требует всего лишь нормально устроенной доски задач.
Как внедрить без сопротивления
Дальше — как перейти на метрики результата так, чтобы команда не восприняла их как трекер экрана под другим названием.
Начните с одной пары метрик. Четыре метрики одновременно команда воспримет как новый вид контроля под другим названием
Показывайте отчет команде, а не только себе. Люди спокойнее относятся к метрике, если видят те же цифры, что и руководитель
Пересматривайте метрику раз в месяц. Проверяйте, не начала ли команда ее оптимизировать вместо того, чтобы работать
Все три правила решают одну и ту же задачу — не дать метрике превратиться в новый повод для тревоги, которым изначально и был трекер экрана. Для старта достаточно готового отчета по доске, которая уже используется в команде — не нужно строить новую систему с нуля.
Итог
Вернемся к руководителю с зелеными полосами на дашборде из начала статьи. Трекер честно показывал максимум присутствия, какой только можно измерить. Просто присутствие и результат — это два разных вопроса, и трекер умеет отвечать только на первый.
Мониторинг активности отвечает на вопрос, был ли человек на месте. Метрики результата отвечают на вопрос, движется ли работа.
Закон Гудхарта напоминает: даже правильная метрика ломается, если сделать ее единственной целью. Нужна пара метрик и привычка заглядывать внутрь, даже если цифра права.
А у вас в команде метрики уже прижились, или каждая попытка их внедрить превращается в новый повод для читерства?
Комментарии (17)
WhoIsJohnGolt
13.08.2026 08:54Здесь, кмк, надо ещё на шаг назад посмотреть: почему технические метрики используются для любых задач? Есть задачи, где нужно чисто технически что-то сделать, причём либо сразу понятно, что, либо не сразу, но долго думать не придётся. А есть задачи типа RnD (но тоже в ИТ), где даже нельзя заранее предсказать, не только время выполнения, но и в принципе, получится ли приемлемый результат - в этом случае какие метрики использовать?
vasya_project Автор
13.08.2026 08:54Справедливо, throughput и cycle time в чистом виде тут не подойдут, потому что неизвестна не скорость, а сам факт результата. Для RnD метрика должна быть другой: не "сколько сделано", а "уложились ли в отведенный таймбокс на исследование" плюс итог по факту: гипотеза подтвердилась, опровергнута или нужно продолжать. По сути закрытие вопроса, а не закрытие задачи. Если гипотезы идут потоком, можно смотреть долю подтвердившихся - но это уже не про скорость, а про качество попаданий.
DizzyJump
13.08.2026 08:54А чем будем измерять качество гипотез?
vasya_project Автор
13.08.2026 08:54Качество гипотезы меряется не в моменте, а по критерию, который зафиксировали до старта эксперимента - что именно будет считаться подтверждением. Грубо: если заранее договорились, какой метрикой мерим успех и какой порог считаем значимым, то по итогу просто смотришь, дотянула гипотеза до порога или нет. Без этого любая оценка гипотезы задним числом - уже подгонка под факт.
SER_26
13.08.2026 08:54Для полноты: в предложенном наборе метрик эффективности нужна ещё модификация метрики для учёта сложности задачи. Добавив классы размера и измеряя метрики внутри классов, будет более информативна картина. Агрегированную тоже считать можно, но тогда с весами для каждой задачи на базе классов размера (а не самопределённых командой story points).
Надеюсь, в разрабатываемом продукте это есть.vasya_project Автор
13.08.2026 08:54По сути согласен - throughput без нормализации по сложности можно легко раздуть, взяв в спринт задачи попроще. Весовая схема на классах размера честнее самоопределенных story points, потому что команда не может подстроить оценку под метрику так же легко. Про продукт - сторипоинты и cycle time есть. Тут еще нужно смотреть специфику работы команды, но думаю, что адаптировать можно.
ANDREY-17_05
13.08.2026 08:54Поправьте меня если я ошибаюсь, но вся эта тема с "метриками" - чисто от неспособности бизнеса перестать мыслить марксистскими шаблонами. Т.е. бизнес видит в программисте источник прибавочного продукта и хочет чтобы програмист выдавал больше прибавочного продукта в единицу времени и не хочет платить программистам адекватную компансацию за труд. Причем бизнес хорошо понимает, что физический труд узкоспециализированного рабочего дает бизнесу прибавочный продукт пока рабочий трудится, а вот интеллектуальный труд программиста позволяет бизнесу получать прибавочный продукт даже после того, как программист уволился иногда и много лет...
Вполне понятно, что сообщество IT специалистов будет всячески бороться с такой наглой эксплуатацией своего интеллектуального труда и вполне резонно будет искать пути обхода процесса присвоения результатов труда без адекватной оплаты...
Я понимаю, что есть люди и среди программистов которые сами не против контроля, т.к. им так проще. Контроль часто нужен молодым специалистам... Но большинство творцов (в любой сфере - ученые, инженеры, музыканты и программисты) - люди увлеченные своим делом и работающие не потому, что за спиной стоит надсмотрщик и не потому, что есть нечего, а потому, что интересно.
Контроль для таких людей это еще и неприятный контрбонус в психологическом плане - сигнал неадекватности (ибо кто и зачем будучи в здравом уме будет контролить человека, который увлеченно работает, если этолько целью не является ч-то "отжать" не заплатив).
Поэтому вопрос - зачем в принципе тратить силы и средства на войну продакт-программист, вместо того чтобы использовать инструменты, позволяющие разрешить этот конфликт "на корню"? Зачем жить в парадигме "выиграл/проиграл" и тратить на это эмоциональные и финансовые ресурсы, вместо того, чтобы изменить парадигму взаимоотношений на "выиграл/выиграл" с чёткими правилами игры и алгоритмами создающими у программиста краткосрочную и/или долгосрочную финансовую заинтересованность давать больше результата и/или более качественный результат в единицу времени?
SER_26
13.08.2026 08:54Это у Вас марксисткие шаблоны, Вы же два абзаца про прибавочную стоимость и т.д. говорите тут.
Метрики нужны для управления бизнесом в первую очередь и выявления слабых мест в нём, а контроль сотрудников тоже нужен, но он вторичен. Например, известно, что 85% проблем с качеством - проблемы руководителей, а не исполнителей (программистов). Аналогично и со временем (проценты только другие будут).
"увлеченно работает" 1) не равно "делает то, что нужно" и 2) не означает, что у сотрудника все хорошо со всеми навыками (и навыки развивать нужно всем, а не только "молодым специалистам"). И лентяи в этом мире существуют. Контроль тут везде поможет.
Следовательно, "неадекватность" (не соответствие ситуации) в такой ситуации у того, кто говорит "мне и почти всем контроль вообще не нужен".
А правильные метрики и правильное их применение и есть "инструменты, позволяющие разрешить этот конфликт". Если же кто-то из руководителей их применяет неверно, или не объясняет их смысл сотрудникам, это не вина инструмента.
vasya_project Автор
13.08.2026 08:54Про войну продакт-программист - метрики из статьи как раз не про “отжать больше”, а про обратное: они защищают человека от произвольных претензий. Если задача стояла три дня на чужом согласовании, а не потому что программист ленился - это видно по истории карточки, а не по тому, сколько минут человек провёл за работой в редакторе кода. То есть нормально устроенная доска работает в обе стороны: руководителю - видимость, где реально затык, сотруднику - защита от “почему не сделано” на пустом месте.
Согласен, что конфликт лучше решать не через противостояние, а через общую выгоду для обеих сторон. Только это не отдельный инструмент вместо метрик, а то, для чего они и нужны при вменяемом использовании. Если метрику приняли как повод для давления - это не метрика виновата, а то, как ее применили.
ANDREY-17_05
13.08.2026 08:54Только это не отдельный инструмент вместо метрик,
А с этим никто и не спорит
ANDREY-17_05
13.08.2026 08:54Это у Вас марксисткие шаблоны, Вы же два абзаца про прибавочную стоимость и т.д. говорите тут.
Очень интересно. Положим вам лично не нравится Маркс, но это ж не отменяет того, что IT бизнес живет в парадигме борьбы с наемными рабочими - в точности как это Маркс описал. А если бизнес так живет, несмотря на то что мягко сказать не эффективно устраивать войну внутри своей компании то что это если не "неспособность перестать мыслить марксистскими шаблонами")
Но не получается, и не получится. А всё потому, что погроммисты не дураки и вертели веcь этот kpi .Война погромист<>продакт будет вечной.
И посыл у коллег такой именно потому, что кто бы что не затирал про "средство разрешения конфликтов" и про "выявление слабых мест" в 99.9% случаев метрики используются и в IT компаниях, и в производственных компаниях как средство усиления эсплуатации и борьбы с наемными рабочими за ЗП - работай больше, получай также или меньше.
Вопрос же я другой задал - зачем жить в этой порочной парадигме "выиграл/проиграл", если бизнес заинтересован в долгосрочном развитии?
Войну это не заканчивает, само собой. Просто обходить одну метрику легко, а две сразу без потерь в другой - запарно
Посыл статьи и большинства менеджеров в этом - в желании "выиграть".
"неадекватность" (не соответствие ситуации) в такой ситуации у того, кто говорит "мне и почти всем контроль вообще не нужен".
А кто так говорит? Можете цитату этого человека привести? Прямо очень интересно кто так говорит.
увлеченно работает" 1) не равно "делает то, что нужно" и 2) не означает, что у сотрудника все хорошо со всеми навыками (и навыки развивать нужно всем, а не только "молодым специалистам"). И лентяи в этом мире существуют.
Тогда вопрос - как и почему так хреново организован процесс/проект, что можно увлеченно работать, но делать не то, что надо? Есть еще один аналогичный вопрос - если у сотрудника "не все хорошо с навыками" то почему вопрос обучения или подбора стоит позади вопроса метрик - как лошадь после телеги?
Поправьте меня если я ошибаюсь но как мне кажется разгадка тут мировозрегюнческая - вы не интересовались самоорганизующимися системами и их внедрением в производственные процессы и считаете, что контроль "великого менеджера" (а именно царственная палка и пинок священноменеджерской ноги или барский пряник от "великого") это единственный способ организации производственных систем и управления ими.
Но это не так - прямой контроль, кгут и пряник это не самые эффективные и далеко не самые надежные инструменты в долгосрочной перспективе.
А правильные метрики и правильное их применение и есть "инструменты"
Тут бы я поставил точку. Абсолютно корректная фраза..
Но опять же тут есть вопрос у которого нет решения - кто и как определяет что такое "правильная" метрика и "правильный" инструмент кто и исходя из чего их определяет? Каковы критерии "правильности" кто и исходя из чего их определяет? Каковы границы применения метрик, как и на основании чего их определить?
Вы абсолютно правы - метрики это просто инструмент. Как топор. Топором можно и деревья рубить и людей убивать и то и другое может быть и злом и добром в зависимости от контекста. Так же и использование метрик.
И мой месидж о том как этот инструмент используется.
Т.е. о том, что кратно более эффективна организация труда, в которой обход правил и метрик становится не "сложным" а "бессмысленным", а их соблюдение и выполенение становится из "необходимости" "потребностью". Одновременно при таком подходе обсуждение что более эфективно кнут (метрика за невыполнение которой работника наказывают морально или рублем и которую он априори будет пытаться обойти) или пряник (финансовая и/или моральная заинтересованность в выполнении метрики), а также обсуждение вопрос нахождения метрик обход которых сотрудниками "запарен" отходит на третий план.
И самое главное в этом, что такая организация труда не возможна в парадигме "выиграл/проиграл", т.е. в борьбе против экэксплуатации и для своей реализации требует перехода к парадигме сотрудничества - "выиграл/выиграл"
SER_26
13.08.2026 08:54"многа букафф". И много неверных догадок. Предлагаю остановиться, я, как минимум, уже ничего не добавлю.
кратно более эффективна организация труда, в которой обход правил и метрик становится не "сложным" а "бессмысленным", а их соблюдение и выполенение становится из "необходимости" "потребностью".
И
перехода к парадигме сотрудничества - "выиграл/выиграл"
Вот эти положения верны. В нормально построенных организациях так и есть. Не до идеала, но хоть стремятся. И приведённые выше метрики этому вполне могут помочь.
Но учитывая всё, что Вами выше написано - так и напишите статью с описанием самоорганизующихся систем в менеджменте, а также проработанного и проверенного инструмента или алгоритма, описанного в последнем абзаце первого Вашего комментария. А не критикуйте без конкретных (!) предложений.
Если же нигде в мире такого и нет (при том, что 15 соц.стран когда-то было, в которых марксизм был идеологией, да и на Западе много экспериментов было), то есть повод задуматься о реалистичности Ваших идей.вам лично не нравится Маркс
Пример домысливания Я нормально к Марксу отношусь. Но Вы Маркса использовали в обсуждении измерительного инструмента (а статья только об этом) с посылом, что предложенный инструмент - средство эксплуатации.
в 99.9% случаев метрики используются и в IT компаниях, и в производственных компаниях как средство усиления эксплуатации и борьбы с наемными рабочими за ЗП
Ссылку на достоверное исследование, где про 99.9% говорится, пожалуйста. Иначе - снова домысливание.
разгадка тут мировозренческая
нет, как минимум, не с моей стороны. Вы плохо знакомы с теорией и с практикой менеджмента. Так как наивны вопросы типа: "почему так хреново организован процесс/проект", "почему вопрос обучения или подбора стоит позади вопроса метрик " - организован так, потому, что менеджеры ещё больше сотрудников ошибаются, а метрики работу менеджеров в первую очередь и измеряют, так как за команду они отвечают. А обучение и подбор стоят до метрик, разумеется, но PDCA цикл никто не отменял. Метрики для С этого цикла и нужны. И метрики не обязательно "прямой контроль, кгут и пряник". Измышления про "пинок" и прочее даже не буду комментировать.
ANDREY-17_05
13.08.2026 08:54"многа букафф"
Пример домысливания
В моем посте есть и “домысливание”, и “натяжки”. Подтверждаю)
НО!
Применяются они ограниченно, намеренно и осознанно - только и исключительно как иллюстрация вашей манеры диалога (манеры неконструктивно обвинять собеседника в том, чего им НЕ писалось и НЕ утверждалось на основе собственных домыслов и натяжек). Мне это не понравилось ибо такая манера не способствует поиску ответов на проблемы управления. Поэтому я решил, что зеркальный ответ поможет вам понять насколько неприятен и неразумен был выбранный вами тон)))
Теперь “по делу”:
Про статью - вы правы. Статья или серия про промышленное управление и место самоорганизующихся систем, будет, я думаю, “в тему” и полезна)
Задача которую ставит текущая статья:
Как оценивать эффективность команды без слежки"
Предлагаемое решение:
смотреть на пару метрик с противоположным давлением. Контроль экранного времени (слежка) - это менее эффективно.
Я же предлагаю посмотреть на проблему контроля глубже.
И мне приятно что наш с вами диалог, который пока был больше похож на срач, тем не менее позволил вам правильно сформулировать более общую проблему контроля, чем это предложено в статье:
организован так, потому, что менеджеры ещё больше сотрудников ошибаются
Про проблему “производства неэффективности менеджментом” на западе с прошлого века говорят и то, что об это наконец “в голос” заговорили в IT, а менеджмент, судя по статьям и коментам, начинает признавать объективную реальность - позитивно.
И в этом плане более интересно - "как в принципе эффективно организовать процесс контроля", а для этого очень интересно было бы обсудить:
Связь задач и инструментов контроля с целями и задачами компании (критерии качества контроля, критерии достижения компанией целей и алгоритмы их связи)
Связь задач и инструментов контроля с внутренней средой компании и целями компании (та самая проблема влияния ошибок построения внутренней среды и определения целей на качество контроля вокруг которой строились комментарии и которую вы все же сами выделили),
Связь задач контроля (которые логично вытекают из задач компании и ее внутреннего ландшафта) с алгоритмами контроля и инструментами, которые используются для контроля
SER_26
13.08.2026 08:54Вы пытаетесь занять доминирующую позицию "в белом пальто", на самом деле занимаясь наездом. Бессмысленная затея. По сути, как писал выше, мне нечего тут добавлять. Публикуйте статью с доказанными масштабно (не на уровне семейной компании) на практике эффективными системами контроля и т.д., там всё и видно будет. Только общим уровнем ограничиваться не надо, пожалуйста, это ничего не покажет, выше есть конкретные показатели, которые Вам не понравились, не забудьте описать заслуживающие Ваше одобрение, активно и эффективно применяемые.
Хорошо, если после её публикации тут дадите знать, чтобы не пропустить.
oldd
Метрики для погромистов придумывают уже не одно десятилетие. То строчки считают, то закрытые задачи, то время над задачей. Но не получается, и не получится. А всё потому, что погроммисты не дураки и вертели веcь этот kpi .
Война погромист<>продакт будет вечной.
vasya_project Автор
Так в статье с этим никто и не спорит - в лоб про закон Гудхарта же. Задачу дробят под throughput, тесты режут под cycle time обходят любую метрику, если она одна.
Разница не в том, что придумали какую-то нечитерскую метрику, а в том, что смотреть надо парой с обратным давлением: throughput растет - смотри на возвраты. Если растут оба - читерство видно сразу, а не через квартал, когда релиз уже горит.
Войну это не заканчивает, само собой. Просто обходить одну метрику легко, а две сразу без потерь в другой - запарно
vasya_project Автор