Почему трекер времени неправильно распределяет время (и как это исправить)
Открываешь отчёт автоматического трекера времени — DevPace, ActivityWatch, RescueTime, не важно какого — и что-то не сходится. Час явно рабочей переписки посчитан как «браузер» наравне с личными вкладками. Малоизвестная внутренняя программа целиком провалилась в категорию «Другое». Утренняя работа в новом инструменте вообще не появилась в разбивке. Первая реакция — решить, что трекер сломан или что конкретно этот продукт сделан небрежно. На практике это не поломка и не брак конкретного продукта: это структурное ограничение самого способа, которым любой автоматический трекер вообще определяет, чем занят человек.
Как автотрекер вообще решает, что к какой категории отнести
Автоматический трекер не читает содержимое экрана и не понимает смысл того, что делает человек, — это осознанный выбор в пользу приватности, а не недоработка. Вместо этого он смотрит на техническую сторону: какое приложение или процесс сейчас на переднем плане, как называется его окно, и по этому имени сопоставляет активность с одной из заранее заданных категорий — IDE, браузер, коммуникации, терминал и так далее. Это верно для всего класса подобных инструментов, включая DevPace и общеизвестные примеры вроде ActivityWatch и RescueTime: в основе у всех — таблица соответствий «имя процесса → категория», а не понимание задачи, которую человек в этот момент решает.
Такой подход работает быстро, не требует доступа к содержимому и хорошо покрывает распространённый софт: браузеры, IDE, мессенджеры, офисные пакеты давно известны и размечены. Но у любой эвристики есть край, за которым она перестаёт справляться, — и этот край не исключение, а встроенное свойство метода.
Три причины, почему классификация ошибается
Список известных приложений не бесконечен. Новый инструмент, редкая утилита, внутренний корпоративный клиент — что угодно, чего ещё не было в таблице соответствий, — не совпадёт ни с одной известной категорией. Это не единичный случай: софт выходит и обновляется постоянно, а любая таблица соответствий составлена на определённый момент и неизбежно отстаёт от него уже на следующий день.
Многофункциональные приложения не сводятся к одной категории. Самый частый пример — браузер. Он используется и для рабочей документации, и для личной переписки, и для отдыха на видео, но с точки зрения имени процесса это всегда один и тот же chrome.exe или firefox.exe. Трекер, который классифицирует по процессу, физически не может отличить рабочую вкладку от нерабочей внутри одного и того же окна — потому что на этом уровне видна только программа, а не то, что открыто внутри неё. То же самое происходит с терминалом, с редактором общего назначения, с почтовым клиентом, где рабочие и личные письма технически неотличимы друг от друга.
Пример: разработчик весь день держит открытым один и тот же браузер — в одной вкладке документация к используемому фреймворку, в соседней время от времени включён видеосервис на фоне. Для трекера это одна и та же категория «Браузер» на всю длительность, потому что и то, и другое происходит внутри одного процесса. Разделить их можно было бы только заглянув в заголовок конкретной вкладки или в содержимое страницы — а это уже не техническая категория активности, а содержимое, к которому персональный трекер сознательно не обращается.
Само приложение со временем меняется. Обновление программы иногда меняет имя исполняемого процесса, версии одного и того же редактора могут называться по-разному, а два визуально похожих приложения — быть совершенно разными процессами. Таблица соответствий, актуальная сегодня, через несколько обновлений может частично устареть, и то, что раньше корректно распознавалось, вдруг перестаёт совпадать с известным именем. То же самое происходит и с корпоративным софтом: внутренний таск-трекер или самописный клиент компании физически не может присутствовать ни в одной общей таблице соответствий заранее, потому что он существует только внутри одной организации и нигде больше.
Все три причины — не про качество конкретной реализации, а про природу подхода «категория по имени процесса». Более сложные способы категоризации (по содержимому окна, по контексту задачи) решали бы часть этих проблем, но требовали бы доступа к содержанию экрана — а это уже совсем другой уровень вмешательства в приватность, на который персональный трекер сознательно не идёт.
Как это выглядит на практике
Обычно проблема заметна одним из двух способов. Первый — необычно большая доля категории «Другое» в отчёте: было привычные 5%, а стало 20–30%, и непонятно, это несколько минут в незнакомом чате или два часа в рабочем инструменте, который трекер просто не узнал. Второй — время явно не там, где ожидалось: рабочая переписка в браузере посчиталась вместе с личным просмотром, потому что для трекера это одно и то же окно одного и того же процесса.
Пример: за неделю в «Другое» стабильно набегает по 20–30 минут в день. При ближайшем рассмотрении разбивки по приложениям там обнаруживается незнакомое имя процесса — оказывается, это внутренний таск-трекер компании, который агент ещё не научился узнавать. Ничего страшного не произошло, но теперь понятно: это не потерянное время, а рабочий инструмент, который просто пока не попал в нужную категорию.
Почему это не повод считать трекер бесполезным
Проблема не в том, что эвристика иногда ошибается — это неизбежно для любого инструмента такого класса. Проблема в том, что происходит с этой ошибкой дальше: если «Другое» или неверно посчитанная категория — это просто число в отчёте без возможности заглянуть глубже, ошибка становится невидимой, и человеку остаётся либо слепо доверять цифре, либо вовсе перестать пользоваться отчётом.
DevPace не оставляет категории непрозрачным куском времени. Помимо общей длительности категории, отдельно фиксируется, какие конкретно имена приложений и процессов в неё попали и сколько времени на каждое ушло. Открыв разбивку по приложениям, можно увидеть не абстрактный процент, а список: условно, «process_x.exe — 40 минут», «неизвестный клиент — 12 минут». Это превращает непрозрачную цифру в конкретный список вопросов, на которые легко ответить самому себе.
Каждая сессия подписана конкретной категорией — тот же принцип прозрачности применяется и к содержимому категории «Другое».
Что делать: донастройка категорий
Общий принцип одинаков для любого автоматического трекера, не только для DevPace: не останавливаться на агрегированном проценте, а при первом же подозрении проваливаться на уровень конкретных приложений.
Практический порядок действий:
- Смотреть не только на категорию, но и на разбивку по приложениям. Если категория выглядит непривычно большой или маленькой, разбивка по приложениям почти всегда сразу показывает, какое конкретно имя процесса за этим стоит.
- Проверять «Другое» в первую очередь, если его доля выросла. Рост с обычных 5% до 25% — это сигнал, который стоит проверить, а не молча принять как есть: появился новый инструмент, поменялась версия приложения, или в списке действительно оказалось что-то, не похожее на работу.
- Учитывать, что многофункциональные приложения размыты по определению. Если браузер или терминал показывает подозрительно много времени в одной категории, стоит помнить, что это агрегат всего, что происходило в этом окне, — трекер по устройству не может разделить рабочую и нерабочую активность внутри одного и того же процесса без доступа к содержимому, на который персональный трекер сознательно не идёт.
- Не считать разовую ошибку поводом обесценить весь отчёт. Одно неверно классифицированное приложение за неделю — это статистическая погрешность на общем фоне; поводом для внимания стоит считать устойчивый паттерн, а не единичный случай.
- Возвращаться к разбивке после заметных изменений в наборе инструментов. Если на работе перешли на новую CRM, сменили редактор кода или подключили новый корпоративный сервис, стоит один раз целенаправленно проверить, в какую категорию всё это попало, а не ждать, пока доля «Другое» вырастет сама и станет заметной задним числом.
Этот же принцип применим и за пределами DevPace. У ActivityWatch, как правило, категории настраиваются пользователем через собственные правила — это открытый инструмент, где размётка категорий изначально в руках самого человека. У RescueTime тоже, как правило, предусмотрена возможность вручную скорректировать категорию конкретного приложения или сайта, если автоматическая классификация показалась неверной. Общий вывод один: чем прозрачнее инструмент показывает, что именно легло в основу категории, тем проще заметить и поправить перекос, — и наоборот, инструмент, который показывает только итоговый процент без разбивки, оставляет пользователя один на один с цифрой, которую невозможно перепроверить.
Зачем вообще в это вникать
Здесь есть два уровня пользы. Первый — личное понимание: то, что попало в «Другое» или в чужую категорию, часто оказывается вполне рабочим инструментом, который стоит учитывать как рабочее время, а не как неопределённость. Второй — проверка на честность самого механизма. Трекер, который прозрачно показывает «вот что я не смог однозначно классифицировать», вызывает больше доверия, чем тот, который делает вид, будто распознал всё безошибочно, — потому что для любого автоматического трекера, будь то DevPace, ActivityWatch или RescueTime, стопроцентная точность классификации по имени процесса физически недостижима, и честнее показать это ограничение явно, чем спрятать его за красивым процентом.
Если хочется увидеть, как это выглядит на собственных данных, и самому проверить разбивку по категориям и приложениям вместо того, чтобы гадать по итоговому проценту — Посмотреть демо.
Смотрите также
- Трекеры времени: обзор всех типов и как выбрать
- Глубокая работа: почему процент важнее часов
- Когда вы на самом деле сосредоточены, а когда только кажется
Опубликовано: 26 июля 2026 г.