Календарь как главный инструмент: time blocking, day theming, календарная гигиена

Проблема: у списка задач нет размерности «время»

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

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

Календарь — единственное место, где заявка на ваше время и фактическая ёмкость дня находятся в одной системе координат. Именно поэтому Дэвид Аллен в GTD называет календарь «жёстким ландшафтом» (hard landscape) и требует класть туда только то, что действительно привязано ко времени, — см. https://courses.digitable.life/post/time-management/03-gtd/. Мы пойдём дальше Аллена: для инженера календарь полезно использовать шире, чем как список обязательств перед другими людьми, — но с оговорками, которые разберём честно.

Откуда всё это взялось: короткая история

Две вехи здесь важнее остальных.

Питер Друкер, «The Effective Executive» (1967). Друкер первым сформулировал мысль, которая сегодня звучит банально, а тогда была новой: у работника умственного труда время дробится по умолчанию, и единственный способ получить крупный блок — целенаправленно его собрать. Он предлагал сначала три-четыре недели вести хронометраж (не по памяти, а фактический), потом убирать лишнее, потом консолидировать остаток. Обратите внимание на порядок: измерение, потом чистка, и только потом планирование. Большинство людей начинают с третьего шага и удивляются, что не работает.

Пол Грэм, «Maker’s Schedule, Manager’s Schedule» (2009). Тезис: менеджер живёт в сетке получасовых слотов, и для него встреча — это стоимость самой встречи. Создатель (программист, писатель) работает единицами в полдня, и для него встреча в середине дня стоит не час, а два обрубка, ни в одном из которых нельзя взяться за сложное. Это ключевая асимметрия, из-за которой «поставь мне тридцать минут, тебе же несложно» — не безобидная просьба. Эссе не научная работа, а наблюдение, но оно даёт словарь, которым удобно объяснять коллегам, почему вы двигаете их встречу к краю дня.

Что говорят исследования — и чего они не говорят

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

Планы-намерения работают, и это самый крепкий результат. Питер Голльвитцер показал, что формулировка вида «если наступит ситуация X, я сделаю Y» (implementation intention) резко повышает шанс, что действие произойдёт, по сравнению с намерением «я собираюсь сделать Y» (Gollwitzer, American Psychologist, 1999). Мета-анализ 94 исследований дал средний размер эффекта d ≈ 0.65 — это много для поведенческой психологии (Gollwitzer & Sheeran, Advances in Experimental Social Psychology, 2006). Запись «вторник 10:00–12:00 — рефакторинг слоя кэша» — это ровно такое «если-то»: триггером служит время и место. Это главный научный аргумент в пользу блокирования времени: не «блок делает вас продуктивнее», а «привязка намерения к конкретному моменту сильно повышает вероятность старта».

План освобождает голову. Масикампо и Баумайстер показали, что незавершённая задача занимает когнитивные ресурсы (эффект Зейгарник), но составление конкретного плана её выполнения снимает навязчивость почти так же хорошо, как само выполнение (Masicampo & Baumeister, JPSP, 2011). Практический вывод: запись «когда» ценна даже если план потом изменится.

Оценки времени систематически занижены. «Ошибка планирования» описана Канеманом и Тверски (1979) и экспериментально подтверждена Бюлером, Гриффином и Россом (JPSP, 1994): люди предсказывают срок по оптимистичному сценарию и почти не используют собственную историю похожих задач. Для календаря это значит: блок, в котором вы «точно успеете», в среднем короче нужного. Работающее противоядие — сегментация: заставить себя перечислить подшаги перед оценкой заметно уменьшает занижение (Kruger & Evans, «If you don’t want to be late, enumerate», JESP, 2004).

Переключение стоит дорого, и цена не мгновенная. Софи Леруа описала «остаток внимания»: после переключения часть когнитивных ресурсов остаётся на предыдущей задаче, особенно если та не была доведена до естественной точки (Leroy, OBHDP, 2009). Глория Марк с коллегами в полевых наблюдениях за офисными работниками получила знаменитую цифру среднего возврата к прерванной задаче — около 23 минут — и показала, что работа после прерывания идёт быстрее, но ценой роста стресса и нагрузки (Mark et al., CHI 2008). Важная оговорка: 23 минуты — это медиана возврата к той же задаче в конкретной выборке, а не универсальная константа «встреча стоит вам 23 минуты». Использовать её как аргумент можно, как точный расчёт — нет.

Дни без встреч измеряли. Исследование 76 компаний, описанное в HBR (Laker et al., 2022), показало улучшение автономии, кооперации и субъективной продуктивности при введении одного–двух дней без встреч, с ухудшением части метрик при трёх и более. Это опросные данные с самоотчётами, а не рандомизированный эксперимент, — относитесь как к сильному индикатору, а не доказательству.

Чего наука не подтверждает. «Закон Паркинсона» («работа заполняет отпущенное на неё время») — сатирическое эссе в The Economist 1955 года, а не результат исследования. Дедлайн действительно влияет на поведение, но выводить из афоризма «ставь блоки покороче, и всё будет успеваться» — подмена. Точно так же нет доказательств, что конкретно «правило 90 минут» или «работа только по ультрадианным циклам» даёт прирост: это популяризация физиологических наблюдений, а не проверенный протокол работы.

Time blocking: механика

Time blocking — практика, при которой каждый рабочий отрезок дня заранее назначен конкретной работе. Полезно различать три разные вещи, которые часто путают.

Time boxing — про ограничение (спайк на исследование: два часа, потом решение «продолжаем/нет»). Time blocking — про размещение. Day theming — про группировку. Они комбинируются: тематизированный день, внутри него блоки, внутри отдельных блоков — таймбоксы.

Базовый цикл выглядит так.

Состояние «Недооценён» — не сбой, а главный источник данных. Кэл Ньюпорт в описании своего time-block planning прямо говорит, что переписывает план по нескольку раз за день и это нормальная работа метода, а не его провал: план — это гипотеза о дне, а не обещание.

Как выглядит настроенный день

Что здесь принципиально:

1. Крупный блок стоит первым, до того как день начнёт наполняться чужими запросами. Утренний блок защищён самим фактом, что его ещё не успели перебить.
2. Коммуникация собрана в пачки, а не размазана. Ревью, почта, ответы — это отдельный режим работы, а не фон.
3. Есть явный буфер. Полностью забитый календарь ломается от первого же инцидента. Практическое правило — оставлять незанятыми 20–30% рабочего дня; это не лень, а запас на дисперсию.
4. Планирование завтрашнего дня — тоже блок. Пятнадцать минут в конце дня стоят дешевле, чем полчаса растерянности утром.

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

Практический вывод из квадрантов: работа из верхней половины должна получать блоки, и желательно в те часы, когда у вас пик — см. https://courses.digitable.life/post/time-management/01-attention-and-energy/. Работа из нижней половины блоков не заслуживает, но заслуживает пачек: три «мелких» дела, размазанные по дню, стоят дороже, чем те же три подряд.

Фрагментация: главный враг, который не виден в статистике

Стандартная жалоба «у меня весь день во встречах» обычно неверна арифметически. Три часа встреч из девяти — это треть дня. Проблема не в объёме, а в раскладке.

Обе картинки — один и тот же день: шесть получасовых встреч, час обеда, пять часов формально свободного времени. В первом случае максимальный непрерывный отрезок — шестьдесят минут. С учётом того, что перед встречей вы не станете погружаться в сложное, а после встречи нужно время на вход, реальный фокус в варианте A близок к нулю. Вариант B при тех же трёх часах встреч даёт два блока по два с половиной часа.

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

Ниже — скрипт, который считает это по выгрузке календаря в формате iCalendar (RFC 5545); Google Calendar, Outlook и Fastmail все умеют отдавать .ics.

"""Метрики фрагментации календаря по .ics-выгрузке.

Зависимости: pip install icalendar
Сложность: O(n log n) по времени (сортировка событий), O(n) по памяти.
"""
from datetime import datetime, date, time, timedelta
from icalendar import Calendar

WORK_START = time(9, 30)
WORK_END = time(18, 30)
MIN_DEEP_BLOCK = timedelta(minutes=90)  # порог «в это окно можно взяться за сложное»


def busy_intervals(ics_path: str, day: date) -> list[tuple[datetime, datetime]]:
    """Возвращает занятые интервалы дня, обрезанные рабочими часами."""
    with open(ics_path, "rb") as f:
        cal = Calendar.from_ical(f.read())

    lo = datetime.combine(day, WORK_START)
    hi = datetime.combine(day, WORK_END)
    out = []
    for ev in cal.walk("VEVENT"):
        # события «весь день» и отклонённые приглашения не занимают время
        if str(ev.get("TRANSP", "OPAQUE")) == "TRANSPARENT":
            continue
        start, end = ev["DTSTART"].dt, ev["DTEND"].dt
        if not isinstance(start, datetime):
            continue
        start, end = start.replace(tzinfo=None), end.replace(tzinfo=None)
        start, end = max(start, lo), min(end, hi)
        if start < end:
            out.append((start, end))
    return sorted(out)


def merge(intervals):
    """Схлопывает пересекающиеся интервалы: наложенные встречи не удваивают занятость."""
    merged = []
    for start, end in intervals:
        if merged and start <= merged[-1][1]:
            merged[-1] = (merged[-1][0], max(merged[-1][1], end))
        else:
            merged.append((start, end))
    return merged


def day_metrics(ics_path: str, day: date) -> dict:
    lo = datetime.combine(day, WORK_START)
    hi = datetime.combine(day, WORK_END)
    busy = merge(busy_intervals(ics_path, day))

    gaps, cursor = [], lo
    for start, end in busy:
        if start > cursor:
            gaps.append(start - cursor)
        cursor = max(cursor, end)
    if cursor < hi:
        gaps.append(hi - cursor)

    total_busy = sum((e - s for s, e in busy), timedelta())
    deep = sum((g for g in gaps if g >= MIN_DEEP_BLOCK), timedelta())
    return {
        "встреч_часов": round(total_busy.total_seconds() / 3600, 2),
        "свободно_часов": round((hi - lo - total_busy).total_seconds() / 3600, 2),
        "макс_окно_мин": int(max(gaps, default=timedelta()).total_seconds() // 60),
        "пригодного_для_фокуса_часов": round(deep.total_seconds() / 3600, 2),
        "число_окон": len(gaps),
    }


if __name__ == "__main__":
    print(day_metrics("calendar.ics", date(2026, 7, 14)))

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

Day theming: полезное ядро и вредная попса

Тематизацию дней популяризировал Джек Дорси, рассказывавший (Techonomy, 2011), что руководя одновременно Twitter и Square, отдавал понедельник управлению, вторник — продукту, среду — маркетингу и так далее. Историю пересказывают как рецепт, обычно опуская две детали: во-первых, это режим человека, у которого почти вся работа — это встречи и решения; во-вторых, оба проекта потом переживали серьёзные управленческие кризисы. Успех метода тут никем не измерен.

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

Рабочая раскладка недели для инженера в команде:

Как это применять, не превращая в догму:

• Тема — это приоритет по умолчанию, а не запрет. Во вторник можно сходить на срочную встречу; тема означает, что во вторник вы её по умолчанию отклоняете или переносите, а не то, что это физически невозможно.
• Договоритесь командой, а не в одиночку. «Вторник и среда — дни без встреч» работает, если общий; персональный запрет вы будете защищать в ручном режиме каждую неделю и устанете.
• Не берите больше двух-трёх тем. Пять разных тем на пять дней — это уже не группировка, а расписание пятиклассника, которое сломается на первой же неделе с отпуском коллеги.
• Учитывайте дежурства. Неделя на on-call не может быть неделей глубокой работы. Практичный вариант: на дежурной неделе тема одна на все дни — «поддержка, мелкие задачи, техдолг, документация», а крупные задачи не берутся вообще. Планировать двухнедельную фичу на неделю дежурства — гарантированная просрочка и лишний стресс.

Календарная гигиена: конкретные настройки

Здесь список того, что настраивается один раз и работает годами.

Рабочие часы и рабочее место. В Google Calendar — «Настройки → Рабочие часы и местоположение»; в Outlook — «Календарь → Рабочее время». Это не декорация: при попытке поставить встречу вне ваших часов организатор увидит предупреждение, а автоподбор времени перестанет предлагать ваши 8 утра. В распределённой команде это единственный масштабируемый способ сообщить свой график.

Сокращённые встречи по умолчанию. Включите «Speedy meetings» (Google) или «Shorten meetings» (Outlook): 30 минут превращаются в 25, 60 — в 50. Это даёт разрыв между встречами, в котором можно дойти до кухни, записать решение и войти в следующий контекст. У Microsoft есть ЭЭГ-исследование Human Factors Lab, где у участников без перерывов между видеовстречами накапливалась бета-активность, ассоциированная со стрессом, а короткие паузы этот рост прерывали (Microsoft WorkLab, 2021). Выборка там крошечная (14 человек) и это корпоративное исследование, а не рецензируемая публикация, — но само правило дёшево и не имеет минусов.

Дефолтная приватность и осмысленные названия. Блок «Работа» никому ничего не говорит и провоцирует коллег его перебить. Блок «Фокус: миграция схемы платежей (PAY-1421)» перебить психологически труднее — и вам самому не придётся вспоминать, что вы имели в виду. Если содержание чувствительное, ставьте видимость «занят» без деталей, но название всё равно должно быть внятным для вас.

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

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

Два календаря вместо одного. Личный и рабочий — отдельными календарями с шарингом занятости (free/busy), а не событий. Это решает и приватность, и двойное бронирование: врач в 15:00 виден коллегам как «занят» без подробностей.

Один часовой пояс как источник правды. В распределённой команде договоритесь о reference-таймзоне для расписания релизов и дежурств. Включите отображение второго пояса в интерфейсе (Google Calendar: «Настройки → Часовой пояс → Показывать дополнительный»). Отдельно: смены летнего времени в разных странах происходят в разные даты, и в марте-ноябре разница между Европой и США на две недели «уезжает» на час — регулярные встречи в этот период надо проверять руками.

Как обрабатывать входящее приглашение

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

Обратите внимание на узел M: правильная реакция на неизбежную встречу — перенести блок фокуса, а не вычеркнуть его. Вычеркнутый блок исчезает бесследно, перенесённый остаётся обязательством перед собой. Подробнее об отказах и асинхронной работе — https://courses.digitable.life/post/time-management/11-meetings/.

Где time blocking ломается

Метод продают как универсальный. Он не универсальный, и честно знать границы.

Реактивные роли. Дежурный по проду, инженер поддержки, тимлид в неделю релиза — у них доля непредсказуемой работы такая, что расписанный план будет переписан к обеду. Здесь работает не блокирование, а обратное: планировать только 40–50% времени, остальное держать пустым, а список задач вести в канбане с жёстким лимитом WIP (https://courses.digitable.life/post/time-management/07-personal-kanban/).

Хроническая недооценка. Если ваши блоки систематически коротки, календарь превращается в машину для генерации чувства вины: каждый день заканчивается тремя несделанными пунктами. Лечение — не «сильнее стараться», а техническое: считать коэффициент по факту (см. скрипт выше), умножать оценки на него и планировать меньше задач в день. Три блока по полтора часа реалистичнее, чем шесть по часу.

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

СДВГ и особенности исполнительных функций. Для части людей внешняя структура календаря — большая помощь, для части жёсткое расписание становится источником постоянного ощущения провала. Универсального ответа тут нет, и подбирать формат стоит эмпирически (или с помощью специалиста), а не по книге по продуктивности.

Планирование как форма прокрастинации. Красивый календарь даёт немедленное ощущение контроля, а сложная задача — нет. Если вы тратите на планирование больше 20–30 минут в день, вы, скорее всего, уже не планируете, а прячетесь. Подробно — https://courses.digitable.life/post/time-management/10-procrastination/.

Наблюдаемость календаря как надзор. В некоторых компаниях детально расписанный личный календарь начинают читать как отчёт о работе. Это организационная проблема, а не ваша; практический ответ — держать детали в личном инструменте, а в общий календарь выводить только занятость.

Типичные ошибки

• Планировать день от начала рабочего дня. Первые 15–30 минут почти всегда уходят на вход, почту и чат. Ставьте первый блок на 9:30, а не на 9:00, — так план сойдётся с реальностью.
• Ставить блок «поработать над проектом X». Слишком крупно, чтобы начать. Формулируйте как действие с наблюдаемым результатом: не «поработать над поиском», а «написать интеграционный тест на ранжирование по релевантности». Хорошее правило: название блока должно позволять через два часа однозначно ответить «сделал/не сделал».
• Не оставлять буфер. Календарь без буферов — это система без запаса прочности: один инцидент рушит весь день, и вы теряете доверие к собственному плану.
• Планировать сложное на послеобеденный провал. Если ваш пик в 10 утра, архитектурная задача в 15:00 — это самообман. Проверить свои пики: https://courses.digitable.life/post/time-management/01-attention-and-energy/.
• Заводить блок фокуса, но не выключать уведомления. Блок в календаре не защищает от Slack; защищает выход из Slack. Инструменты защиты — в https://courses.digitable.life/post/time-management/12-communication-load/.
• Копить встречи, которые уже не нужны. Ежеквартально проходите по повторяющимся событиям и спрашивайте: если бы этой встречи не было, стали бы мы её сейчас заводить? Обычно треть отваливается.
• Планировать нулевое время на ревью. Ревью чужого кода — это работа, которую все считают «в фоне», из-за чего она либо съедает фокус, либо не делается. Явные два блока по 30–40 минут в день решают обе проблемы.
• Считать календарь честным, когда он врёт. Если вы регулярно работаете не то, что записано, вы потеряли инструмент: календарь перестал быть моделью реальности. Лучше планировать грубее, но правдиво.

Недельный обзор в разрезе календаря

Полный ритуал недельного обзора разбирается в https://courses.digitable.life/post/time-management/08-planning-horizons/; здесь — только календарная его часть, двадцать минут в пятницу:

1. Ретроспектива по факту. Пройтись по прошедшей неделе и отметить, где план разошёлся с реальностью. Не для самобичевания — для калибровки оценок.
2. Посчитать метрики. Часы встреч, число окон, максимальное окно, часы, пригодные для фокуса. Записать числа: динамика за квартал скажет больше, чем ощущения.
3. Проверить следующую неделю на встречи-мины. Одиночная встреча в середине вторника — кандидат на перенос к краю дня, пока это ещё дёшево сделать.
4. Разместить крупные задачи. Взять два-три главных дела недели и поставить им блоки сейчас, а не «когда дойдут руки». Занятое место защищено; пустое — будет занято чужими встречами к среде.
5. Проверить обязательства с датами. Дедлайны, дежурства, отпуска коллег, релизные окна.
6. Отдых — тоже в календарь. Не как призыв к балансу, а прагматически: незапланированный отдых первым вытесняется работой. Тема устойчивого темпа — в https://courses.digitable.life/post/time-management/15-burnout/.

Инструменты

Отдельный разбор таск-трекеров и заметок будет в https://courses.digitable.life/post/time-management/13-tools/, но специфически календарные вещи стоит упомянуть здесь.

• Календарь как API. Формат iCalendar (RFC 5545) и CalDAV scheduling (RFC 6638) поддерживаются всеми крупными провайдерами. Метод freebusy.query в Google Calendar API отдаёт занятость без содержания событий — идеальная основа для собственных скриптов и дашбордов по фрагментации команды.
• Автоматическая дефрагментация. Clockwise и Reclaim двигают гибкие встречи, чтобы собирать более длинные окна. Работают тем лучше, чем больше людей в компании ими пользуется; в маленькой команде проще договориться словами.
• Focus time как тип события. В Google Calendar есть отдельный тип «Focus time», который умеет автоматически отклонять приглашения и глушить уведомления. Полезнее обычного события ровно тем, что виден коллегам как осмысленная категория.
• Автоматическое планирование задач в календарь. Motion, Sunsama и подобные раскладывают задачи из трекера по свободным окнам. Здравая идея, но помните про ошибку планирования: алгоритм раскладывает ваши оценки, и если они занижены, вы получите красиво заполненный нереалистичный день.

Мини-итог

• Список задач не имеет измерения времени; календарь — единственное место, где намерения сталкиваются с реальной ёмкостью дня.
• Самый крепкий научный аргумент за блокирование — эффект планов-намерений (Gollwitzer): привязка «что» к «когда и где» существенно повышает вероятность старта.
• Считать нужно не количество встреч, а длину непрерывного свободного окна. Меньше 90 минут — день не подходит для сложной работы, сколько бы часов формально ни было свободно.
• Time blocking, time boxing и day theming — три разные вещи; тематизировать дни инженеру полезнее по типу нагрузки, а не по проектам, и обязательно с учётом дежурств.
• Календарная гигиена — это разовые настройки: рабочие часы, сокращённые встречи, срок жизни у регулярных событий, разделение личного и рабочего, явные буферы.
• Метод ломается в реактивных ролях, при хронической недооценке и когда планирование подменяет работу. План — гипотеза о дне, а не обещание; переписывать его нормально.

Источники

• Peter Drucker. The Effective Executive. Harper & Row, 1967 — глава «Know Thy Time».
• Cal Newport. Deep Work. Grand Central, 2016; практика time-block planning на calnewport.com.
• Paul Graham. Maker’s Schedule, Manager’s Schedule, 2009.
• David Allen. Getting Things Done. Penguin, 2001 (переизд. 2015) — понятие hard landscape.
• P. Gollwitzer. Implementation intentions: Strong effects of simple plans. American Psychologist, 54(7), 1999.
• P. Gollwitzer, P. Sheeran. Implementation intentions and goal achievement: a meta-analysis. Advances in Experimental Social Psychology, 38, 2006.
• R. Buehler, D. Griffin, M. Ross. Exploring the «planning fallacy». JPSP, 67(3), 1994.
• J. Kruger, M. Evans. If you don’t want to be late, enumerate. JESP, 40(5), 2004.
• E. J. Masicampo, R. Baumeister. Consider it done! JPSP, 101(4), 2011.
• S. Leroy. Why is it so hard to do my work? OBHDP, 109(2), 2009.
• G. Mark, D. Gudith, U. Klocke. The Cost of Interrupted Work. CHI 2008.
• B. Laker et al. Dear Manager, You’re Holding Too Many Meetings. HBR, 2022.
• Microsoft WorkLab. Research proves your brain needs breaks, 2021.
• RFC 5545 — iCalendar, RFC 6638 — CalDAV Scheduling.

Что дальше

Календарь резервирует время, но не гарантирует, что внутри блока вы будете действительно работать над задачей: между «блок начался» и «я в потоке» лежит отдельный слой проблем — вход в контекст, прерывания, усталость внимания. Об этом — Фокус: помодоро, deep work и защита от прерываний.