Полгода назад я понял, что мы проигрываем не конкурентам и не техдолгу. Мы проигрываем времени суток. В этой статье — мой практический разбор того, как я замерял хронотипы команды, собирал телеметрию активности, анализировал коммиты и встречи, строил простенькую модель продуктивности и в итоге полностью перестроил рабочий график удалённой команды. Будет немного биологии, немного математики, немного кода и много личных факапов.
Когда я заметил, что дедлайны зависят от времени суток
Мы полностью удалённая команда из 11 человек. Бэкенд, фронтенд, один ML-инженер, я как тимлид. Разные города, разные часовые пояса, но в пределах плюс-минус трёх часов.
Сначала всё выглядело нормально: дейли в 11:00, груминг в 16:00, релизы по пятницам вечером. Классика.
Проблема началась, когда я стал замечать странную вещь. Самые сложные баги стабильно закрывались одними и теми же людьми — но только в определённое время суток. Один разработчик в 8 утра мог написать идеальную оптимизацию SQL-запроса, а в 18:00 делал детские ошибки. Другой наоборот — до обеда словно в тумане, а после 19:00 выдаёт архитектурные решения уровня senior+.
Сначала я списывал это на настроение. Потом на нагрузку. Потом на выгорание. Но когда я посмотрел статистику коммитов за 4 месяца, стало очевидно: у каждого есть выраженное "пиковое окно".
Вы когда-нибудь замечали за собой, что утром код пишется иначе, чем вечером? Не быстрее или медленнее — а именно иначе? С другим качеством, глубиной, вниманием к деталям?
Я начал копать в сторону циркадных ритмов. И понял, что мы строим процессы так, будто все люди — одинаковые биороботы с фиксированной прошивкой.
Спойлер: это не так.
Немного биологии, но без занудства
Циркадный ритм — это внутренние 24-часовые биологические часы. Они регулируют температуру тела, уровень кортизола, мелатонина, скорость реакции, внимание и даже болевой порог.
Есть три условных хронотипа:
утренний
вечерний
промежуточный
В IT, как ни странно, перекос в сторону вечерних типов. Но это не правило.
Я решил подойти к вопросу инженерно. Не на уровне ощущений, а на уровне данных. Мы сделали анонимный опрос по расширенной версии шкалы хронотипов, плюс я добавил несколько практических вопросов:
когда вам легче всего писать сложный код
в какое время вы бы поставили архитектурное ревью
когда вы максимально раздражительны
когда вам проще общаться
Ответы оказались очень контрастными. У нас было:
3 ярко выраженных утренних типа
4 вечерних
4 промежуточных
И тут я понял, что наш общий дейли в 11:00 — это ад для части команды. Для одних слишком рано, для других уже спад концентрации.
А теперь представьте: вы заставляете вечерний хронотип проводить сложные обсуждения архитектуры в 9 утра. Это почти как попросить его дебажить после трёх бессонных ночей.
Я решил собрать телеметрию и вот что из этого вышло
Я не хотел опираться только на субъективные ощущения. Поэтому собрал минимальную систему сбора активности.
Мы выгружали:
время коммитов
время PR и ревью
длительность митингов
активность в трекере задач
Плюс я попросил команду неделю носить трекеры сна и выгрузить данные о сне анонимно, без имён.
Вот кусок Python-кода, которым я агрегировал пики продуктивности по времени суток:
# language: python import pandas as pd import numpy as np def load_commits(path): df = pd.read_csv(path, parse_dates=["timestamp"]) df["hour"] = df["timestamp"].dt.hour return df def productivity_score(df): grouped = df.groupby("hour").agg({ "lines_added": "sum", "lines_removed": "sum", "complexity_delta": "mean" }).reset_index() grouped["activity_score"] = ( grouped["lines_added"].abs() + grouped["lines_removed"].abs() ) * grouped["complexity_delta"] return grouped.sort_values("activity_score", ascending=False) commits = load_commits("commits.csv") result = productivity_score(commits) print(result.head())
Потом я визуализировал это и увидел три чётких волны активности. Причём они почти идеально совпадали с хронотипами.
Самое интересное: количество строк кода было не так важно. В пиковые часы снижалось число откатов, снижалась плотность багов на 1000 строк и уменьшалось время ревью.
То есть мозг реально работает иначе в разные часы.
Алгоритм перестройки графика
Дальше я решил сделать то, что обычно никто не делает — отказаться от фиксированного рабочего окна.
Мы ввели три режима:
утренний слот 7:00–14:00
дневной слот 11:00–18:00
вечерний слот 15:00–22:00
Обязательное пересечение — всего 2 часа в день.
Чтобы минимизировать хаос, я написал небольшой сервис на Node.js, который автоматически распределял встречи так, чтобы они попадали в пиковые окна большинства участников.
// language: javascript (Node.js) function findOptimalMeetingSlot(participants) { const hours = Array.from({ length: 24 }, (_, i) => i); let scores = []; hours.forEach(hour => { let score = 0; participants.forEach(p => { if (hour >= p.peakStart && hour <= p.peakEnd) { score += 2; } else if (hour >= p.activeStart && hour <= p.activeEnd) { score += 1; } }); scores.push({ hour, score }); }); scores.sort((a, b) => b.score - a.score); return scores[0].hour; } const team = [ { peakStart: 8, peakEnd: 12, activeStart: 7, activeEnd: 15 }, { peakStart: 18, peakEnd: 22, activeStart: 15, activeEnd: 23 }, ]; console.log(findOptimalMeetingSlot(team));
Это примитив, но он сэкономил нам кучу нервов.
Архитектурные обсуждения стали ставиться в окна максимальной когнитивной ясности участников. Ретроспективы — в нейтральные периоды. А рутинные синки — в перекрывающиеся часы.
И знаете что? Производительность выросла не на 5 процентов. А примерно на 18 по внутренним метрикам скорости закрытия задач.
Что изменилось через три месяца
Через три месяца я сравнил показатели:
среднее время закрытия задач сократилось
количество ночных срочных фиксов уменьшилось
снизился уровень раздражительности на ретро
люди стали реже брать отгулы
Но самый неожиданный эффект — меньше конфликтов.
Когда человек работает в своём биологическом пике, он спокойнее. Меньше когнитивной усталости — меньше токсичности.
Конечно, не всё идеально. Иногда дедлайн всё равно требует синхронной работы. Иногда приходится жертвовать комфортом. Но это уже исключения, а не системная ошибка.
Если вы руководите удалённой командой — попробуйте задать себе вопрос: ваши процессы построены под календарь или под людей?
Мы в IT любим оптимизировать CPU, память, latency. Но почти не оптимизируем главный вычислительный блок — человеческий мозг.
А ведь это самый дорогой ресурс в проекте.
