Когда вы на самом деле сосредоточены, а когда только кажется
Почти у каждого есть представление о том, в какое время суток он работает лучше всего. “Я сова, вечером соображаю быстрее.” “У меня всё важное — с утра, пока никто не отвлекает.” Проблема в том, что это представление формируется один раз, обычно ещё в студенчестве или на первой работе, и потом просто не пересматривается. А реальный паттерн дрейфует: меняется график, меняются задачи, меняется сон — а самоощущение остаётся прежним.
Разобраться в этом мешает ещё и то, что “лучший час” — на самом деле два разных вопроса: когда легче всего входить в глубокую, непрерывную работу, и когда неизбежно приходится держать в голове много всего одновременно. Дальше разберём оба вопроса по отдельности — на реальных данных, а не по ощущениям.
Почему свою память нельзя использовать как источник данных
Память хорошо запоминает исключения. Один действительно продуктивный вечер намертво впечатывается как “вечер — моё время”, даже если за ним следовали три вялых вечера подряд, которые никак не запомнились. То же самое с утрами: одно совещание, сорвавшее фокус в 9:00, легко превращается в вывод “по утрам я не могу сосредоточиться” — хотя в остальные дни в 9:00 всё было в порядке. Ощущение своего лучшего часа — это, по сути, самый яркий эпизод, а не среднее по всем дням.
Как это устроено в DevPace
DevPace не спрашивает, когда вам кажется, что вы продуктивны — он собирает почасовую активность за скользящее окно (по умолчанию 30 дней) и строит из неё карту: по одной оси часы суток, по другой — дни недели, а цвет клетки показывает долю сфокусированной работы в этот час: от красного (низкий фокус) до зелёного (высокий). Такая карта устойчива к отдельным ярким или провальным дням именно потому, что это данные за месяц, а не воспоминание об одном вечере.
Иногда карта подтверждает ожидания — действительно зелёная полоса с 9 до 11. А иногда она показывает то, чего человек не ожидал: например, что реальный пик фокуса приходится не на утро, а на промежуток с 15 до 16, а привычные “продуктивные с утра” часы на самом деле красные — просто заняты переключениями между почтой и мессенджерами, которые ощущаются как работа, но ей не являются.
Так выглядит почасовой график в разделе “Паттерны” — реальные закономерности за месяц, а не догадка о собственном лучшем часе.
Это же скользящее окно объясняет, почему карту стоит пересматривать раз в месяц-два, а не один раз и навсегда: смена проекта, сезонная нагрузка на работе или новый график сна сдвигают паттерн, а окно подхватывает это автоматически — без необходимости заново вспоминать, каким был режим полгода назад.
Продуктивный час и раздробленный час — это разные вещи
На странице конкретного дня DevPace показывает два отдельных показателя: “самый продуктивный час” — час с наибольшей долей глубокой работы за этот день, и “самый раздробленный час” — час с наибольшим числом переключений между задачами на единицу активности. Первое время многие ожидают, что это один и тот же час: якобы “лучший” час дня должен одновременно быть и самым сфокусированным, и самым спокойным. На практике это почти всегда два разных часа, и в этом нет ничего странного.
Глубокая работа и раздробленность измеряют разные вещи. Доля глубокой работы показывает, сколько времени в течение часа шло непрерывное занятие одной категорией активности — код, документ, анализ. Раздробленность считает, сколько раз за этот же час внимание перескакивало между разными окнами и категориями. Час может быть очень фокусным просто потому, что в нём почти не было внешних поводов переключаться. А другой час может быть насыщен переключениями именно потому, что в это время требуется реагировать на внешние события — и это не связано с тем, насколько глубоко человек работал в первый час.
Например, у разработчика час с 10:00 до 11:00 может оказаться самым тихим за день: никто не пишет, встреч нет, задача одна — и DevPace фиксирует здесь высокую долю глубокой работы почти без переключений. А с 14:00 до 15:00 идёт обсуждение релиза: за час нужно свериться с таск-трекером, ответить в чате команде, посмотреть пул-реквест, вернуться к задаче, снова открыть чат. DevPace отмечает этот час как самый раздробленный за день — десятки переключений между приложениями. Формально это “хуже” по метрике непрерывности. Но по смыслу это совсем не потерянный час: именно в это время были приняты решения, которые определили, что делать дальше. Просто это другая по своей природе работа — координационная, а не исполнительская.
Похожая картина встречается и в других ролях, не только у разработчиков. У специалиста поддержки самым раздробленным часто оказывается время после обеда, когда одновременно разгребаются заявки в нескольких очередях, а самым сфокусированным — раннее утро, до того как включились чаты и созвоны. Метрика не привязана к конкретной профессии — она просто показывает, как реально прошёл час, вне зависимости от того, что было в календаре.
Если бы DevPace сводил всё к одному общему баллу “качество часа”, то продуктивный час получил бы высокую оценку, а час с обсуждением релиза — низкую, и это создавало бы ложное впечатление, что координационная работа — это проблема, которую надо устранить. На деле оба часа информативны сами по себе. Продуктивный час показывает, когда есть смысл ставить самую сложную задачу дня. Раздробленный час показывает, когда концентрация физически невозможна из-за характера работы — и это повод не планировать в это время ничего, что требует глубокого погружения, а не повод считать этот час потраченным зря.
Два раздельных показателя дают два разных практических вывода. Продуктивный час — ориентир для планирования: если он регулярно приходится на одно и то же время, туда стоит переносить задачи, которые требуют максимальной концентрации. Раздробленный час — сигнал для диагностики: если он каждый день совпадает с определённой встречей или процессом, это просто фиксация того, как устроена работа команды, а не повод для тревоги. Раздробленность становится проблемой только тогда, когда возникает без причины — например, в то же время, когда человек пытался в одиночку работать над сложной задачей.
Как найти свои продуктивные часы за 2 недели
Один день — не статистика. Единичный удачный или неудачный час может объясняться чем угодно: не выспался, отвлекли, повезло с тишиной в опен-спейсе. Чтобы получить рабочий ответ на вопрос “в какое время суток мне лучше работать”, одного дня недостаточно — нужна база хотя бы за пару недель. Практическая методика простая и не требует ничего, кроме обычного пользования DevPace:
- Дайте данным накопиться. Две недели — минимальный срок, за который в почасовой карте перестают доминировать случайные выбросы. За пять рабочих дней один плохой понедельник ещё способен перекосить картину; за десять он растворяется в остальных днях.
- Смотрите на тепловую карту в разделе “Паттерны”, а не на показатели одного дня. Карта строится по скользящему окну и заново показывает, где на самом деле сосредоточены зелёные часы — независимо от того, что произошло вчера.
- Ищите повторяющийся паттерн, а не разовое совпадение. Если один и тот же час зелёный три-четыре раза в неделю на протяжении двух недель — это сигнал. Если он зелёный один раз — это просто один хороший час.
- Не делайте выводов по одному дню, даже если он был очень ярким. Здесь работает тот же принцип, что и при чтении любых графиков продуктивности: разовая цифра ничего не доказывает без тренда за недели — этому посвящён отдельный разбор, как читать графики продуктивности и не обманываться.
- Используйте найденный паттерн, а не боритесь с раздробленными часами. Если зелёный час стабильно приходится на одно и то же время дня, переносите туда самую сложную задачу. А на стабильно раздробленные часы не планируйте ничего, что требует глубокого погружения — это время всё равно уйдёт на координацию, и это нормально.
По итогам двух недель обычно вырисовывается одна из двух картин: либо подтверждается то, что и так казалось (“да, я действительно собраннее с утра”), либо всплывает нечто, что самоощущение упускало — например, стабильно зелёный час в середине дня, который раньше считался “обеденным затишьем”, а на деле оказывается лучшим временем для сложной задачи. И то, и другое — уже не догадка, а основание для решения.
Бывает и так, что после двух недель карта не показывает выраженного пика — активность распределена ровно, без явных зелёных или красных зон. Это тоже результат, а не сбой: значит, рабочий день скорее определяется внешним расписанием — встречами, дежурствами, — чем внутренним ритмом, и искать “идеальный час” в этом случае бессмысленно; лучше ориентироваться на календарь, а не на самоощущение.
Зачем вообще это знать
Смысл не в том, чтобы искусственно втиснуть все важные задачи в один “идеальный” час — реальный рабочий день так не устроен, встречи и внешние обязательства никуда не деваются. Смысл в том, чтобы решения о том, когда планировать сложную задачу, а когда — рутину и переписку, опирались на пару недель данных, а не на историю из одного запомнившегося вечера. Это не гарантирует прирост производительности в процентах — этого DevPace и не обещает, — но даёт достоверную основу для таких решений вместо догадки.
Смотрите также
- Как читать графики продуктивности и не обманываться
- Глубокая работа: что это, как измерить и сколько её реально в дне
- Переключения контекста: сколько — это нормально
- Сколько можно работать без перерыва: что говорят данные
Опубликовано: 18 июня 2026 г. · обновлено: 26 июля 2026 г.