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

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

Но у меня здесь возникает другой вопрос:

Что именно мы пытаемся узнать с помощью этого измерения?

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

Для начала: что именно мы логируем?

Под учётом времени могут скрываться совершенно разные механики. Я бы разделил их как минимум на четыре группы:

1. Учёт рабочего дня - когда человек пришёл и ушёл.

2. Учёт времени по задачам - сколько часов ушло на конкретную работу.

3. Учёт доступности - был ли сотрудник online, away, offline, на встрече и так далее.

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

Формально во всех четырёх случаях мы измеряем что-то связанное со временем сотрудника, но задачи у этих измерений совершенно разные. Если команда поддержки должна обеспечить присутствие на линии с 09:00 до 18:00, информация о присутствии имеет прямой смысл. Если компания работает по Time & Materials и выставляет клиенту часы, нужен учёт трудозатрат.

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

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

Когда измеряем не то, что на самом деле хотим узнать

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

Что из этого было работой? Если смотреть по активности в IDE - два часа. Если по клавиатуре и мыши - немного больше, а если по времени за компьютером - почти весь период.

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

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

И здесь появляется классическая проблема метрики-прокси.

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

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

Восемь часов присутствия легко превращаются в восемь часов имитации присутствия

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

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

С точки зрения системы контроля всё прекрасно, только мы всё ещё ничего не знаем о результате.

В 2022 году Microsoft использовала для похожего эффекта термин productivity paranoia. В исследовании Work Trend Index 87% сотрудников говорили, что считают себя продуктивными, при этом 85% руководителей отмечали, что в условиях гибридной работы им стало сложнее быть уверенными в продуктивности сотрудников.

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

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

А исследования что говорят?

Я не хочу строить эту статью только на собственных ощущениях, поэтому отдельно посмотрел, что вообще известно про электронный мониторинг сотрудников. В метаанализе 2022 года авторы объединили 70 независимых выборок и 233 эффекта.

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

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

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

Когда учёт времени действительно нужен

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

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

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

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

Во всех этих случаях логирование отвечает на конкретный вопрос.

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

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

«Не работал 37 минут»

Отдельно мне интересна практика фиксации так называемого «нерабочего состояния». Допустим, сотрудник должен отдельно отмечать, что в течение рабочего дня отсутствовал 15, 30 или 40 минут.

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

Но если перед нами разработчик, аналитик или Product Manager, ситуация уже не настолько однозначная. Что в таком случае означает «не работал»: отошёл от компьютера, не двигал мышкой, не писал сообщения, не менял задачу?

А если человек разговаривал с коллегой не в корпоративном мессенджере, читал документацию с телефона или просто думал над решением? Чем подробнее мы пытаемся определить «рабочее состояние» человека интеллектуального труда через наблюдаемую активность, тем страннее становится само определение работы.

Контроль иногда нужен. Но контроль чего?

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

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

Вопрос только в точке наблюдения.

В продуктовой и программной разработке мне гораздо интереснее смотреть на систему работы:

• сколько работы мы начинаем и заканчиваем;

• как долго задача проходит систему;

• где она ждёт;

• где появляются очереди;

• насколько предсказуем наш поток;

• сколько работы одновременно находится в процессе;

• как часто результат приходится переделывать;

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

Тот же Lead Time расскажет о способности системы поставлять результат гораздо больше, чем информация о том, сидел ли конкретный разработчик за компьютером 7 часов 42 минуты. Но здесь тоже есть важная оговорка: любую метрику можно испортить, если превратить её в индивидуальный KPI.

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

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

Иногда желание контролировать время говорит не о сотруднике

Есть ещё одна сторона, которую сложнее измерить. Почему вообще появляется запрос: «Я хочу знать, чем сотрудник занимается каждую минуту»?

Иногда причина вполне рациональна: например, есть реальная проблема с дисциплиной, SLA или доступностью. Но иногда это попытка компенсировать отсутствие другого управленческого инструментария.

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

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

Доверие не означает отсутствие правил

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

Например:

• понятно, когда команда должна быть доступна;

• понятно, какие встречи обязательны;

• понятно, как сообщить, что тебя сегодня не будет;

• понятно, какие обязательства команда на себя принимает;

• понятно, что считается завершённой работой;

• понятно, как мы замечаем проблему и когда её эскалируем.

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

Пять вопросов перед тем, как включить очередной таймер

Если бы мне нужно было принять решение о новом механизме учёта времени в команде, я бы сначала попробовал ответить на несколько вопросов.

1. Какую конкретно проблему мы решаем?

Формулировки вроде «хотим повысить эффективность» здесь недостаточно. Проблема должна быть конкретной: пропадает покрытие поддержки, мы не понимаем себестоимость проектов, систематически срываем сроки или не знаем распределение нагрузки.

2. Почему для решения проблемы нужны именно данные о времени?

Возможно, нам на самом деле нужен Lead Time, статистика инцидентов, данные о загрузке системы или понятные критерии результата. Само наличие удобного таймера ещё не означает, что время является правильным сигналом.

3. Какое решение мы примем после получения данных?

Допустим, сотрудник провёл в системе 6 часов 43 минуты вместо восьми. Что именно мы из этого узнаем и какое управленческое решение примем дальше?

Если ответа нет, ценность самой цифры становится сомнительной.

4. Можно ли собрать менее подробные данные?

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

5. Как система изменит поведение людей?

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

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

Так нужно логировать рабочее время или нет?

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

Для меня важнее другой принцип:

Не стоит измерять человека только потому, что человека измерить проще, чем результат его работы.

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

Или мы на самом деле хотим понять, хорошо ли человек работает?

Если вопрос последний, ответ почти наверняка будет сложнее, чем количество часов между «пришёл» и «ушёл». И это, пожалуй, нормально: управление людьми и сложными системами вообще редко помещается в один таймер.

Источники и исследования

• Microsoft Work Trend Index, 2022. Материалы о разрыве в восприятии продуктивности сотрудниками и руководителями и понятии productivity paranoia.

• Backhaus N. The impact of electronic monitoring on employees' job satisfaction, stress, performance, and counterproductive work behavior: A meta-analysis. Computers in Human Behavior Reports, 2022.

• Carayon P. Two key factors that belong in a macroergonomic analysis of electronic monitoring: Employee perceptions of fairness and the climate of organizational trust or distrust. Applied Ergonomics, 1992.