program-working-time-accounting

«Спросил себя: в какой программе я провёл больше всего времени за прошлую неделю? Подумал: «Наверное, IDE — я же разработчик». Посмотрел данные учёта рабочего времени программы: IDE — 14 часов. Браузер — 31 час. Slack — 18 часов. То есть я «разработчик», который пишет код 14 часов в неделю, а 49 часов (втрое больше!) сидит в браузере и чатах. Вот где правда. Программа для учёта это показала. Без неё я бы продолжал думать, что я «пишу код».»

Современный рабочий день — это парад разных программ. Браузер. IDE. Email-клиент. Slack. Excel. Notion. Figma. Zoom. Каждая — для своей задачи. Вместе — это сложная экосистема, в которой теряется понимание того, на что на самом деле уходит ваше время. Учёт рабочего времени программы (то есть каждого отдельного приложения) раскрывает эту правду — и она часто шокирует больше, чем любые другие управленческие открытия.

В этой статье разберём, почему учёт рабочего времени программы за программой является критически важным для продуктивности, как категоризировать приложения на «creators», «communicators» и «consumers», и как выявить «тихих пожирателей» времени. Со ссылками на ТК и подходы Друкера, Ньюпорта и Клира.

Парадокс «творца в браузере»: когда инструменты замещают работу

Есть фундаментальный парадокс современной интеллектуальной работы: программы, которые должны были помогать создавать, — замещают само создание. Вместо того чтобы писать код, программист часами ищет решение на Stack Overflow. Вместо того чтобы писать статью, копирайтер изучает «примеры» в Google. Вместо того чтобы обрабатывать данные, аналитик читает Reddit на тему «как обработать данные».

Учёт рабочего времени программы делает этот парадокс видимым. Разложим типичный день разработчика:

Программа Заявленное назначение Реальный % дня
IDE (VS Code, IntelliJ) Написание кода 18%
Браузер (документация, Stack Overflow) «Исследование» 35%
Slack Рабочая коммуникация 22%
Email Согласование 8%
Jira / Trello Управление задачами 5%
Терминал Выполнение команд 6%
Прочее Разное 6%

«Разработчик» 18% времени пишет код. 65% времени — в программах для поддержки работы (коммуникация, исследование, координация). Это не критика. Это реальность. Но без учёта рабочего времени программы за программой эта реальность невидима.

«Я провёл учёт рабочего времени программы для всей команды разработчиков — анонимизированно. Средний % времени в IDE: 22%. Это означает, что мы платим профессионалам в среднем 35–45 тыс. руб/мес за то, чтобы они писали код меньше пятой части рабочего дня. Остальное — коммуникация, «исследования», координация. Мы не обвиняем людей. Мы поняли: проблема системная. Каждое «короткое совещание», каждый «быстрый запрос в Slack», каждое «уточнение» отрывает их от настоящей работы.»

Питер Друкер в The Effective Executive сформулировал жёстко: работа, для которой вы нанимали человека, должна занимать большую часть его времени. Если вы нанимали программиста писать код, но код занимает 18% дня — у вас не «продуктивный программист». У вас программист, который тратит большую часть своих высокоинтеллектуальных ресурсов на функции, которые могли бы выполняться иначе.

Категоризация приложений: «Creators», «Communicators», «Consumers»

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

Creators (создатели) — программы, в которых вы создаёте рабочую ценность:

  • IDE для разработчика (код)
  • Figma для дизайнера (дизайн)
  • Word / Google Docs для копирайтера (текст)
  • Excel для аналитика (модели)
  • CRM для продавца (запись клиентов)

Communicators (коммуникаторы) — программы для координации с другими:

  • Slack, Teams, Discord
  • Email
  • Zoom, Meet
  • WhatsApp / Telegram (для бизнеса)

Consumers (потребители) — программы, в которых вы потребляете контент:

  • Браузер (новости, статьи, YouTube)
  • Социальные сети
  • Stack Overflow, Reddit (часто маскируются под «работу»)

Учёт рабочего времени программы позволяет автоматически классифицировать ваш день по этим трём категориям и увидеть реальную картину:

Категория Типичный % дня Здоровый %
Creators 15–30% 50–60%
Communicators 30–50% 15–20%
Consumers 25–40% 10–15%

Друкер формулировал это через концепцию «работника знаний»: «Важнейший вопрос — делаете ли вы правильные вещи, а не делаете ли вы вещи правильно». Если вы разработчик, который 80% времени проводит не в IDE — вы делаете неправильные вещи правильно. Технически качественно. Стратегически — ничего.

«Анонимный отчёт учёта рабочего времени программы по всей команде: средняя creator-пропорция — 24%. Мы решили провести эксперимент: ввели «creator hours» 9–12 — в это время разрешены только creators-приложения, communicators и consumers заблокированы. За месяц creator-пропорция выросла до 41%. За три месяца — стабильно 45–50%. И именно тогда мы увидели реальный рост продукта, а не «много активности».»

→ О защите времени для creator-работы — в статье Таймер учёта рабочего времени: как синхронизировать команду

Тихие пожиратели: программы, которые крадут время незаметно

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

Тихий пожиратель №1: Браузер в пустом скролле

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

Тихий пожиратель №2: Slack в фоне

Slack будто бы «не открыт», но каждые 3–5 минут вы переключаетесь на него, чтобы проверить. За день — 80–120 переключений. Суммарно — 60–90 минут. Учёт рабочего времени программы показывает точно: сколько раз вы открыли Slack, сколько времени там провели.

Тихий пожиратель №3: Email-overcheck

«Посмотрю, что написал клиент» — и вы открываете Gmail каждые 10 минут. Это не «работа с клиентом» — это навязчивое поведение. Учёт рабочего времени программы фиксирует каждое открытие, и когда вы видите «Email — 92 переключения в день» — это момент осознания.

Тихий пожиратель №4: Excel / Sheets для администрирования

«Быстро обновлю табличку» — и вы уже час в Excel вместо работы над основной задачей. Особенно опасно, потому что Excel кажется продуктивной программой. Но если вы аналитик и тратите 35% времени в Excel на административные таблицы вместо настоящего анализа — это проблема.

Тихий пожиратель Как выявить Типичные потери/день
Браузер в скролле % времени в браузере > 30% и не на рабочих сайтах 1–2 часа
Slack в фоне Количество открытий Slack > 80/день 60–90 мин
Email-overcheck Количество открытий email > 20/день 30–60 мин
Excel-админ Excel у сотрудника, который не аналитик 1–3 часа

Джеймс Клир в Atomic Habits объясняет механизм: тихие пожиратели — это автоматические привычки, которые работают в фоне. Вы не замечаете их, потому что они стали невидимыми. Учёт рабочего времени программы делает их видимыми — и это первый шаг к изменению.

«Мой топ-5 тихих пожирателей за прошлый месяц: Slack — 38 часов, Gmail — 19 часов, Twitter (для «идей») — 14 часов, Notion (бесконечное переписывание) — 11 часов, YouTube («образование») — 8 часов. Итого: 90 часов в месяц — эквивалент 11 рабочих дней — на приложения, которые я считал «необходимыми» для работы. Только после учёта рабочего времени программы я понял масштаб.»

Контекст — это всё: «рабочий» Slack vs. «токсичный» Slack

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

Slack как инструмент (продуктивное использование):

  • 4–6 раз в день в отведённое время
  • 5–15 минут за сессию
  • Конкретные вопросы / ответы / координация
  • Закрывается после завершения задачи

Slack как пожиратель (токсичное использование):

  • 80+ проверок в день
  • 30 секунд — 3 минуты за раз (навязчивая проверка)
  • Много чтения чатов, которые не касаются вашей работы
  • Всегда открыт «в фоне»

Как различить по данным учёта рабочего времени программы:

Метрика Инструмент Пожиратель
Количество открытий/день < 10 > 50
Средняя продолжительность сессии 5–15 мин < 3 мин
Общее время/день 30–60 мин 90+ мин
Самая длинная сессия 15–30 мин < 5 мин

То же самое касается email, браузера и даже IDE (да, даже IDE может быть пожирателем — когда вы бесцельно переключаетесь между файлами вместо сфокусированного программирования).

«Я понял: проблема не в Slack как таковом. Проблема в том, как я его использую. Раньше — 120 проверок в день, постоянная тревога «что я пропустил». Теперь — 4 запланированные сессии по 10–15 минут: 9:30, 12:00, 14:30, 17:00. Учёт рабочего времени программы показывает: общее время в Slack упало на 70%, но качество коммуникации — выросло. Я даю более развёрнутые ответы в сосредоточенные сессии, чем в фрагментированных «проверках».»

Кэл Ньюпорт в Deep Work называет это «ритуализированная поверхностная работа» — поверхностная работа всё равно нужна, но она не должна навязчиво вторгаться в глубокую. Учёт рабочего времени программы даёт инструмент для построения такого ритуала.

Практическое упражнение: 3-дневный аудит программ

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

День 1: Наблюдение без изменений

Запустите учёт рабочего времени программы. Работайте как обычно. Не пытайтесь «выглядеть лучше». Цель — получить реальные данные. Вечером просмотрите отчёт. Обратите внимание на топ-5 программ по общему времени, топ-5 по количеству открытий, а также распределение по категориям: creators, communicators, consumers.

День 2: Категоризация и распознавание тихих пожирателей

Посмотрите на топ-программы со вчера. Категоризируйте каждую: Creator (создаёт ценность?), Communicator (координация с другими?), Consumer (потребление контента?). Выявите тихих пожирателей — программы, где соотношение «время vs. созданная ценность» разбалансировано.

День 3: Осознанный эксперимент

Выберите одно изменение на день: ограничить время в одном пожирателе, защитить время в creator-программе (90 минут непрерывного программирования с утра) или полностью заблокировать одного тихого пожирателя (закрыть Twitter / новости на день). Посмотрите, как изменятся ваши основные KPI.

День Действие Результат
1 Честные данные Карта вашего дня
2 Категоризация Выявление дисбаланса
3 Эксперимент Осознанное изменение

«Я провёл это упражнение со всей командой — каждый индивидуально. Анонимные результаты потом мы обсудили. Открытие №1: средний сотрудник проводит больше времени в Slack, чем в главной рабочей программе своей роли. Второе: 80% команды никогда раньше не анализировали, как на самом деле тратят время за программами. Третье: после 3-дневного аудита 90% команды добровольно изменили паттерны использования — без каких-либо приказов.»

Правовая рамка: что разрешено фиксировать

Учёт рабочего времени программы регулируется тем же набором законов, что и общий мониторинг ПК — но с важным уточнением.

Что разрешено:

  • Категоризация программ (рабочие / нерабочие / специфические)
  • Время, проведённое в каждом приложении
  • Количество переключений между приложениями
  • Общая статистика по программам за день / неделю / месяц

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

Что НЕ разрешено:

  • Запись содержания сообщений в Slack / email (нарушение тайны переписки)
  • Скриншоты конкретных документов без дополнительного согласия
  • Запись нажатий клавиш (кейлоггеры)
  • Доступ к личным программам / аккаунтам
Действие Законно? Основание
Время в программе ✅ Да ТК + уведомление работника
Количество открытий ✅ Да То же самое
Название программы ✅ Да То же самое
Содержание сообщений в программе ❌ Нет Тайна переписки
Скриншоты экрана ⚠️ Риск Только с явного согласия + соразмерность

«Юрист посоветовал: в приказе об учёте рабочего времени программы мы чётко указываем: «фиксируется время использования программ, не содержание». Это снимает все юридические риски и одновременно даёт 95% управленческой ценности. Остальные 5% (содержание) — не стоят юридических рисков.»

Закон о защите персональных данных дополнительно требует письменного согласия работника на обработку данных. Это согласие обычно содержится в трудовом договоре или отдельном документе.

→ О правовых границах учёта — в статье Time tracker: как выбрать и внедрить по закону

Выводы

Учёт рабочего времени программы — это наиболее детальный уровень понимания вашего рабочего дня. Без него вы видите общую картину «8 часов работы». С ним — точно знаете, что эти 8 часов складываются из 18 программ, из которых лишь 2–3 создают реальную ценность, а остальные — поддерживают, координируют или просто крадут время.

Что вынести из этой статьи:

  • Парадокс «творца в браузере»: программисты 18% дня в IDE, дизайнеры 22% в Figma
  • Категоризация: Creators (создают), Communicators (координируют), Consumers (потребляют)
  • Тихие пожиратели: Slack в фоне, email-overcheck, «исследование» в браузере
  • Контекст важнее программы: Slack 4 раза/день — инструмент, 80 раз — пожиратель
  • 3-дневный аудит часто шокирует больше, чем год разговоров о продуктивности
  • С правовой точки зрения: фиксируйте время, не содержание — и вы в безопасности

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

FAQ

Правильно ли считать, что много времени в IDE = продуктивность?

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

Как учёт рабочего времени программы справляется с гибридом «работа / личное» в одной программе?

Современные программы учёта различают не только приложения, но и сайты / домены внутри браузера. GitHub, Stack Overflow, документация языка программирования — категоризируются как «рабочие». Facebook, новостные сайты, YouTube (в общем) — как «личные». Настройки позволяют адаптировать под специфику вашей работы (например, для SMM-менеджера социальные сети — рабочие).

Будет ли команда воспринимать учёт рабочего времени программы как вторжение в личное?

Зависит от коммуникации. Ключевое сообщение: «Мы не смотрим на конкретные действия — только на категории и время. Данные доступны прежде всего самому сотруднику для самооценки. Руководитель видит агрегированные тренды, а не детали». При таком подходе команда обычно быстро привыкает и начинает использовать данные для собственного улучшения.

Register

Эффективный учет времени за компьютером

Обсуждение закрыто.