Горизонты планирования: день, неделя, квартал, год и недельный обзор

Проблема: один план на все случаи жизни

Типичная личная система планирования у разработчика выглядит так: есть список задач и есть календарь. И то и другое живёт в горизонте примерно «эта неделя, плюс-минус». Всё, что дальше, существует в виде смутного ощущения: «надо бы разобраться с метриками», «когда-нибудь дочитаю эту книгу», «в этом году хочу вырасти до senior».

Такая система не «плохая» — она просто одномерная. У неё один горизонт, и поэтому она систематически теряет два класса вещей.

Первый класс — крупное и несрочное. Рефакторинг, который окупится через полгода, изучение новой области, документация к своему сервису. У этих дел нет дедлайна, поэтому в недельном списке они всегда проигрывают. Не по разу — а каждую неделю. Через год выясняется, что за пятьдесят итераций система ни разу не выбрала важное.

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

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

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

Точность плана и горизонт: почему нельзя планировать год как неделю

Главный факт, из которого всё вытекает: точность любого плана падает с горизонтом, и падает быстро.

Идея «конуса неопределённости» пришла из оценки программных проектов. Барри Бём в Software Engineering Economics (1981) показал разброс оценок трудоёмкости на разных стадиях проекта: на старте фактические затраты укладывались в интервал примерно от 0.25× до 4× от оценки, и коридор сужался по мере прохождения этапов. Стив Макконнелл популяризовал эту картинку в Software Estimation: Demystifying the Black Art (2006).

И сразу — честная оговорка, потому что конус часто цитируют как закон природы. Тодд Литтл в работе «Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty» (IEEE Software, 2006) проанализировал сотни проектов в Landmark Graphics и обнаружил, что коридор сужается гораздо медленнее, чем предсказывает конус: даже когда проект был пройден на 80%, отношение оставшегося факта к оставшейся оценке всё ещё гуляло в разы. Вывод для нас важнее самой картинки: конус — это лучший случай, достижимый при активном снижении неопределённости, а не автоматическое свойство времени. Само по себе приближение дедлайна оценки не улучшает.

Отсюда практическое правило, которое стоит принять раньше любых техник:

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

Второй известный эффект — ошибка планирования (planning fallacy). Бюлер, Гриффин и Росс (JPSP, 1994) показали классическую картину: студенты, оценивая срок собственной дипломной работы, в среднем ошибались на недели, причём даже «пессимистичная» оценка («если всё пойдёт плохо») оказывалась оптимистичной. Ключевое: опыт не лечит. Люди, которые уже много раз опаздывали, продолжают давать те же оценки, потому что при оценке смотрят на план («вот шаги, вот сколько они займут»), а не на историю («вот сколько заняли похожие задачи»).

Канеман и Тверски назвали это противопоставлением внутреннего и внешнего взгляда («Intuitive prediction: biases and corrective procedures», 1979). Внешний взгляд формализовали в прогнозирование по референтному классу: не оценивать задачу изнутри, а найти класс похожих завершённых задач и взять их распределение. Бент Фливбьорг описал метод для крупных проектов в «From Nobel Prize to Project Management: Getting Risks Right» (Project Management Journal, 2006).

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

Откуда взялись горизонты: короткая история

Две линии здесь стоит различать.

Линия «цикл с проверкой» — Шухарт, Деминг, Scrum, ретроспектива. Её тезис: план ценен не сам по себе, а тем, что создаёт ожидание, с которым потом можно сравнить факт. План, который никто не сверял с реальностью, — это не план, а список пожеланий. Именно поэтому обзор (review) в этой статье не менее важен, чем планирование.

Линия «разные горизонты» — Друкер, rolling wave, Гроув, Аллен. Её тезис: детализация должна убывать с расстоянием. В проектном управлении это называется rolling wave planning: ближайший интервал расписан подробно, следующий — крупными блоками, дальний — списком тем. По мере движения «волна» детализации сдвигается вперёд. Формулировка есть в PMBOK, но идея старше и работает на любом масштабе, включая личный.

Отдельно отмечу Энди Гроува (High Output Management, 1983). Он описывал планирование как производственный процесс с тремя входами: спрос среды, текущее состояние системы, и разница между ними. И настаивал, что планирование — это не про то, «что мы будем делать», а про то, «что мы сделаем сегодня, чтобы изменить положение завтра». Для личного квартального плана это лучший из известных мне вопросов-фильтров.

Каскад: четыре контура с разной частотой

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

Большинство личных систем ломается именно на пунктирных стрелках. Годовой план пишут в январе и открывают в декабре — контур разомкнут, и всё, что он даёт, — чувство вины. Работает не план, а петля.

Второе наблюдение: частота обзора должна соответствовать скорости изменений на этом горизадонте. Дежурная неделя меняет вашу ёмкость радикально и приходит раз в 6–8 недель — значит, она обязана быть видна на месячном и квартальном горизонте, а не всплывать в понедельник. А вот «кем я хочу быть через три года» не меняется от того, что вы подумаете об этом в четверг вечером; ежемесячная рефлексия на эту тему — трата.

Горизонт дня: самый переоценённый

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

Поэтому дневной план — это не список задач, а три решения:

1. Что главное. Одна вещь, ради которой день считается удачным. Не три — одна. Формулировка «выкатить фича-флаг для нового пайплайна в стейджинг» годится, «поработать над пайплайном» — нет.
2. Куда это положить во времени. Конкретный блок в календаре с началом и концом. Подробно — в статье про календарь (https://courses.digitable.life/post/time-management/05-calendars/).
3. Какая первая физическая операция. «Открыть pipeline/config.go, добавить ключ enable_v2 со значением false и прогнать локальный тест» — вот это точка входа.

Третий пункт не украшение. Это план-намерение (implementation intention) в терминологии Питера Голльвицера: формула «когда наступит ситуация X, я выполню действие Y». Мета-анализ Голльвицера и Ширана (Advances in Experimental Social Psychology, 2006) по 94 исследованиям даёт средний эффект величиной d ≈ 0.65 — это заметно. Работает не «намерение сделать», а привязка действия к триггеру.

Полезная привычка — вечерняя пятиминутка вместо утренней. У этого есть два основания. Первое практическое: утром вы стартуете уже готовым, не тратя лучшее время на разбор. Второе — эффект, описанный Масикампо и Баумайстером («Consider it done!», JPSP, 2011): незавершённые задачи создают навязчивые мысли, но составление конкретного плана снимает этот эффект почти так же, как реальное завершение задачи. То есть план на завтра, написанный вечером, буквально помогает не думать о работе вечером.

Типичные ошибки дневного горизонта:

• Список на 12 пунктов. Это не план, а инвентарь. День вмещает 2–4 содержательных блока плюс мелочь, всё остальное — самообман. См. ошибку планирования выше.
• Планирование дня без взгляда на календарь. Классика: список составлен, а в дне четыре встречи и полтора свободных часа.
• Дневной план как единственный горизонт. Если вы планируете только день, вы каждый день оптимизируете локально и системно проигрываете крупному-несрочному.
• Переписывание плана как деятельность. Если на дневное планирование уходит больше 10 минут, это уже не планирование, а прокрастинация в приличной форме (https://courses.digitable.life/post/time-management/10-procrastination/).

Горизонт недели: главная единица инженера

Неделя — самый полезный горизонт для разработчика, и это не случайность.

• Неделя — естественный период рабочего ритма: она содержит и встречи, и время на сосредоточенную работу, и переживает один-два «плохих дня» без потери смысла.
• Ротация дежурств почти везде недельная. Дежурная неделя — это не «неделя минус немного», это качественно другой режим.
• Цикл ревью тоже недельный по своей природе: PR, отправленный в понедельник и слитый в четверг, — нормальная единица потока.
• Спринт (одна-две недели) и недельные синки задают внешнюю синхронизацию, на которую вы всё равно завязаны.

Райнертсен в The Principles of Product Development Flow (2009) объясняет, почему фиксированный такт (cadence) сам по себе ценен: он делает координацию дешёвой. Если все знают, что вопросы решаются на еженедельной точке, никому не нужно дёргать друг друга по мере поступления. Для распределённой команды это ещё важнее: такт заменяет синхронное присутствие.

Практически недельный горизонт отвечает на четыре вопроса:

1. Какие проекты активны на этой неделе (не «существуют», а именно движутся)?
2. Какой у каждого следующий конкретный шаг?
3. Что я кому обещал и когда это ждут?
4. Что застряло и чего оно ждёт — моего действия, чужого ответа, внешнего события?

Разумный объём: 3–5 активных проектов для инженера без управленческой нагрузки. Больше — и вы платите за переключение контекста больше, чем получаете от параллелизма. Это прямое следствие ограничения незавершённой работы, разобранного в https://courses.digitable.life/post/time-management/07-personal-kanban/: закон Литтла не делает исключений для личной работы.

Недельный обзор: процедура целиком

Недельный обзор (weekly review) — центральная практика GTD и, пожалуй, единственная, которая работает даже если всё остальное из GTD вы не взяли. Аллен формулирует её назначение прямо: система заслуживает доверия ровно настолько, насколько регулярно вы её пересматриваете. Без обзора списки протухают, вы перестаёте им верить и возвращаетесь к памяти и панике.

Обратите внимание на переход Активный → Резерв. Это самая недооценённая часть обзора: честно снять с активных то, что неделю не двигалось. Без этого список активных проектов за квартал разбухает до пятнадцати пунктов, каждый из которых вызывает лёгкое чувство вины, и весь список перестаёт что-либо значить.

Сценарий обзора на 45–60 минут

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

Фаза 1. Собрать (10 минут). Опустошить все входящие: почта, мессенджеры, блокнот, заметки в телефоне, стикеры, папка «Загрузки», открытые вкладки браузера. Не обрабатывать — только собрать в одно место. Механика подробно в https://courses.digitable.life/post/time-management/02-capture-and-inbox/.

Фаза 2. Посмотреть назад (10 минут). Открыть календарь прошедшей недели — не память, а календарь. Пройти по слитым PR, закрытым тикетам, инцидентам. Вопросы: что реально заняло время? Совпало ли это с тем, что я планировал? Какая оценка оказалась неверной и на сколько?

Здесь есть исследование, которое стоит знать. Ди Стефано, Джино, Пизано и Стаатс в работе «Making Experience Count: The Role of Reflection in Individual Learning» (HBS working paper 14-093) провели полевой эксперимент в колл-центре: группа, которая тратила 15 минут в конце дня на письменную рефлексию, показала результаты примерно на 20% лучше контрольной. Оговорка: это одна отрасль, короткий период и специфическая задача; переносить цифру буквально на инженерную работу нельзя. Но направление подтверждается: время, потраченное на осмысление опыта, не вычитается из производительности, а добавляется к ней.

Фаза 3. Обработать (10 минут). Разобрать собранное по схеме диаграммы выше: отсев, календарь, активные проекты, резерв. Правило двух минут (если делается меньше чем за две минуты — сделать сразу) работает, но осторожно: во время обзора оно легко превращается в час мелких дел. Держите таймер.

Фаза 4. Обновить списки (10 минут). Пройти по списку проектов: у каждого активного должен быть следующий физический шаг, а не название темы. Пройти по списку «жду ответа»: где я жду больше недели и надо напомнить. Снять с активных то, что не двигалось.

Фаза 5. Спланировать неделю (10 минут). Посмотреть на календарь следующей недели — сначала на ёмкость: сколько там встреч, есть ли дежурство, отпуск коллеги, релиз. Потом положить в свободные окна главные блоки. Правило: планировать примерно 60% номинально свободного времени, остальное уйдёт на реактивное.

Фаза 6 (раз в месяц, ещё 15 минут). Пройти по областям ответственности: мои сервисы, ревью, наставничество, обучение, здоровье. Вопрос по каждой: «эта область получала внимание в этом месяце?» Область без внимания три месяца подряд — либо она не ваша (снимите), либо у вас копится проблема.

Шаблон файла обзора

Простой текстовый файл в репозитории заметок работает лучше сложного приложения: его видно в git-истории, он ищется грепом, и его не нужно чинить.

# Обзор недели 2026-W29

## Факт: что произошло
- Слито 6 PR, из них 2 крупных (миграция кэша, ретраи в клиенте).
- Инцидент во вторник, 3.5 часа: таймауты в billing-api. Постмортем — мой.
- Дежурство: нет. Следующее — W33.

## Оценки против факта
- «Миграция кэша — 2 дня» → заняла 4. Причина: не учёл прогрев на проде.
- «Ретраи — полдня» → полдня. ОК.
- Вывод: задачи, где есть выкатка на прод, стабильно занимают ×2.

## Обещания
- [x] Ревью PR #412 для Ани — сделал в среду.
- [ ] Схема ретеншена для Максима — обещал в четверг, не сделал. Перенёс, написал.

## Застряло / жду
- Доступ к метрикам платёжного шлюза — жду SRE с 09.07 (2 недели!). Эскалировать.
- RFC про идемпотентность — жду комментариев, дедлайн для комментариев 24.07.

## Снимаю с активных
- «Разобраться с трейсингом» — три недели без движения. В резерв, вернусь в Q4.

## Следующая неделя
Ёмкость: 4 встречи, вторник целиком на планировании квартала. Реально ~2.5 дня фокуса.
1. Постмортем по billing-api — вторник, 10:00–12:00.
2. Схема ретеншена — среда, 10:00–13:00.
3. Начать RFC по идемпотентности v2 — четверг, 10:00–12:00.
Резерв: пятница после обеда — буфер, не планирую ничего.

Сбор фактов автоматом

Фазу «посмотреть назад» удобно начинать не с чистого листа. Небольшой скрипт собирает объективную канву недели, и дальше вы уже думаете, а не вспоминаете.

#!/usr/bin/env bash
# Черновик фактов для недельного обзора: что реально произошло за N дней.
# Запускать в корне рабочего репозитория; вывод вставлять в файл обзора.
set -euo pipefail

DAYS="${1:-7}"
SINCE="$(date -u -d "${DAYS} days ago" +%Y-%m-%d)"
ME="$(git config user.email)"

echo "== Мои коммиты с ${SINCE} =="
git log --since="$SINCE" --author="$ME" --no-merges \
        --pretty=format:'%ad  %s' --date=short
echo

echo
echo "== Слитые PR =="
gh pr list --state merged --limit 100 \
   --search "author:@me merged:>=${SINCE}" \
   --json number,title --jq '.[] | "#\(.number) \(.title)"'

echo
echo "== PR, которые ждут моего ревью (это тоже моя загрузка) =="
gh search prs --review-requested=@me --state=open --limit 50 \
   --json number,title,repository \
   --jq '.[] | "#\(.number) \(.repository.name) — \(.title)"'

echo
echo "== Мои открытые PR старше 3 дней (застряли?) =="
gh pr list --author "@me" --state open --limit 50 \
   --json number,title,createdAt \
   --jq --arg d "$(date -u -d '3 days ago' +%Y-%m-%d)" \
       '.[] | select(.createdAt < $d) | "#\(.number) \(.title)"'

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

Горизонт квартала: где принимаются настоящие решения

Квартал — горизонт, на котором вы что-то реально решаете. День и неделя почти целиком определены прошлыми обязательствами; год слишком расплывчат. Двенадцать-тринадцать недель — достаточно, чтобы закончить крупную вещь, и достаточно мало, чтобы ошибка не стоила года.

Квартальный такт закрепился в индустрии через OKR: Энди Гроув ввёл его в Intel, Джон Дорр принёс в Google. Разбор самих OKR — в следующей статье (https://courses.digitable.life/post/time-management/09-goals-and-okr/); здесь нас интересует именно такт, независимо от формы целей.

Три вопроса квартального планирования

1. Какая у меня ёмкость? Не «сколько рабочих дней в квартале», а сколько реально остаётся на проектную работу. Арифметика отрезвляет:

# Реальная ёмкость инженера в квартале.
# Коэффициенты — не наука, а средние по опыту команд; замените своими,
# как только накопите 2–3 квартала фактических данных.

RABOCHIH_DNEY = 65          # ~13 недель по 5 дней

otpusk = 5                  # запланированный отпуск
prazdniki = 3
dezhurstvo = 5              # одна дежурная неделя за квартал
bolezn_ozhidaemo = 2        # база: почти у всех что-то бывает

dostupno = RABOCHIH_DNEY - otpusk - prazdniki - dezhurstvo - bolezn_ozhidaemo

# Доля дня, уходящая не на «свою» проектную работу:
# ревью чужого кода, встречи, поддержка, вопросы в чате, найм.
DOLYA_NAKLADNYH = 0.40

proektnyh_dney = dostupno * (1 - DOLYA_NAKLADNYH)

print(f"Календарных рабочих дней:      {RABOCHIH_DNEY}")
print(f"Доступно после вычетов:        {dostupno}")
print(f"Реально проектных дней:        {proektnyh_dney:.0f}")
print(f"Это примерно {proektnyh_dney / RABOCHIH_DNEY:.0%} от календаря")

# Вывод: ~30 проектных дней на квартал.
# Крупная задача с выкаткой на прод — это 5–10 таких дней.
# Отсюда предел: 2–3 крупные ставки за квартал, не пять.

Цифра «около 30 дней» обычно шокирует. Но именно она объясняет, почему квартальные планы из семи пунктов не выполняются никогда: в них заложено вдвое-втрое больше, чем физически помещается. Заметьте, что дежурная неделя вычтена целиком — не потому, что на дежурстве нельзя работать, а потому что на дежурстве нельзя рассчитывать на длинные блоки, а крупные задачи требуют именно их (https://courses.digitable.life/post/time-management/01-attention-and-energy/).

2. Какие 2–3 ставки? Ставка — это то, что должно измеримо сдвинуться. Хорошая формулировка ставки содержит наблюдаемое состояние мира, а не деятельность:

• Плохо: «заниматься наблюдаемостью».
• Лучше: «все запросы к billing-api покрыты трейсингом, p99 виден в дашборде, дежурный может по алерту дойти до конкретного эндпоинта за 5 минут».

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

Rolling wave: как выглядит квартал в календаре

Три вещи в этой диаграмме сделаны намеренно.

Дежурство отмечено как отдельная полоса с нулевой ёмкостью. Это не «неделя, на которой я чуть медленнее». Прерывания на дежурстве по природе непредсказуемы, а стоимость возврата в контекст после прерывания велика — Глория Марк и коллеги в «The Cost of Interrupted Work» (CHI 2008) фиксировали порядка 23 минут до возврата к исходной задаче. Планировать на дежурную неделю крупную задачу — гарантированный способ не сделать ни её, ни дежурство спокойно.

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

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

Горизонт года: направление, а не задачи

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

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

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

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

Разумный формат годового документа — страница текста, не таблица:

• Где я сейчас: роль, сильные и слабые стороны, что раздражает.
• Куда двигаюсь: 2–3 фразы про направление, без метрик.
• Что для этого нужно освоить: 1–2 области, не пять.
• Чего в этом году не будет: явный список.
• Крупные календарные точки: отпуска, конференции, известные релизы.

И один нюанс про формулировки. Годовые цели в стиле «получить повышение» опасны тем, что результат зависит не только от вас: от бюджета компании, наличия позиции, менеджера. Устойчивее формулировать через то, что вы контролируете: «закрыть три из четырёх пунктов из матрицы компетенций для senior и получить письменную обратную связь по каждому». Подробнее про то, как цели ломаются и когда вредят, — в https://courses.digitable.life/post/time-management/09-goals-and-okr/.

Как горизонты ломаются: типичные ошибки

Планирование не в том горизонте. Самая частая. Признаки: в годовом плане стоят задачи с датами; в дневном списке — «подумать о карьере»; на квартальном планировании обсуждают, кто ревьюит конкретный PR. Лечится вопросом: «какое решение здесь принимается и когда его можно будет проверить?»

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

Каскад без обратной связи. Годовые цели спускаются в квартал, квартал в неделю, но факты недели никогда не поднимаются наверх. В результате квартальный план третий раз подряд содержит одну и ту же не сдвинувшуюся ставку, и никто не задаёт вопрос «а почему она не движется?».

Слишком много горизонтов. Видел системы с шестью уровнями и еженедельным обходом всех. Планирование начинает занимать 3–4 часа в неделю и умирает от веса. Разумный бюджет — около 2% рабочего времени: 45–60 минут в неделю на обзор, 5–10 минут в день, 2–3 часа раз в квартал. Всё, что сверх, требует обоснования.

Обзор без выбрасывания. Если из обзора список только растёт, обзор не выполняет свою главную функцию. Каждый обзор должен что-то удалять.

Дежурства, отпуска и релизы не учтены в ёмкости. Инженерная специфика, которую общие книги по продуктивности почти не затрагивают. Календарь дежурств — входные данные квартального плана наравне с целями.

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

Специфика распределённых команд

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

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

Личный обзор стоит частично публиковать. Три-пять строк в командный канал раз в неделю: что сдвинулось, что застряло, чего жду от кого. Это дешевле любого статус-митинга и одновременно решает вашу задачу — фиксирует факт.

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

Когда всё это не работает

Честно про границы применимости.

Полностью реактивные роли. SRE в тяжёлом продакшене, дежурный инженер поддержки, разработчик на этапе аварийной стабилизации. Здесь недельный план бессмыслен — работает только дневной горизонт плюс квартальный (для того, что вы всё-таки пытаетесь изменить системно). Не пытайтесь натянуть недельное планирование на неделю, состоящую из инцидентов; лучше зафиксируйте, сколько недель в квартале такие, — это само по себе аргумент в разговоре с менеджером.

Очень короткие циклы обратной связи. Если вы работаете в стартапе на стадии поиска, квартальный план устаревает за две недели. Тогда каскад сжимается: день — неделя — месяц, а годовой горизонт остаётся только личным (навыки, здоровье, деньги), не продуктовым.

Периоды перегрузки и истощения. Если недельный обзор регулярно не делается не из-за лени, а потому что на него физически нет ресурса, — это сигнал не про дисциплину, а про нагрузку. Планирование не лечит перегрузку и не заменяет разговор о ней с менеджером; попытка «просто лучше планировать» в таком состоянии чаще усиливает чувство неадекватности. Об этом бережно и подробно — https://courses.digitable.life/post/time-management/15-burnout/. Если состояние длится месяцами и затрагивает сон, здоровье и способность радоваться вещам вне работы, это тема для разговора со специалистом, а не для очередной методики.

Люди, которым структура даётся тяжело нейробиологически. Для части людей (СДВГ и смежные особенности) стандартный недельный обзор длиной час — заведомо невыполнимая процедура. Рабочий компромисс: резко укоротить (10 минут, три вопроса), привязать к внешнему триггеру и делать вдвоём с коллегой (body doubling). Хуже всего здесь — универсальный совет «просто делайте регулярно».

Мини-итог

• Точность плана падает с горизонтом; конус неопределённости — лучший случай, а не автоматика. Поэтому на разных горизонтах принимаются решения разного типа: далеко — направления и ставки, близко — действия.
• Каскад: год задаёт критерий отбора, квартал — ставки и отказы, неделя — активные проекты, день — блоки и точку входа. Обратная связь снизу вверх важнее каскада сверху вниз.
• День планируется тремя решениями (что главное, когда, с чего начать), а не списком из двенадцати пунктов. Вечернее планирование выгоднее утреннего.
• Неделя — главная единица инженера: она совпадает с ротацией дежурств, ритмом ревью и спринтом. Активных проектов 3–5, не больше.
• Недельный обзор — единственная практика, которую стоит взять, если брать только одну. 45–60 минут: собрать, посмотреть назад, обработать, обновить, спланировать. Каждый обзор должен что-то удалять.
• Квартал — горизонт реальных решений: 2–3 ставки, явный список отказов и честный расчёт ёмкости (обычно около 30 проектных дней из 65 календарных).
• Год — направление и критерий отказа, а не список задач. Формулируйте через то, что контролируете.
• Бюджет на всё планирование — около 2% рабочего времени. Больше — система начинает обслуживать себя.
• Планирование не лечит перегрузку. Если обзор не делается из-за нехватки ресурса, проблема не в методе.

Источники

• David Allen. Getting Things Done. Penguin, 2001 (переизд. 2015) — горизонты фокуса и процедура еженедельного обзора.
• Peter Drucker. The Effective Executive. Harper & Row, 1967.
• Andrew Grove. High Output Management. Random House, 1983 — планирование как производственный процесс.
• Donald Reinertsen. The Principles of Product Development Flow. Celeritas, 2009 — гл. 7 о такте и синхронизации.
• Barry Boehm. Software Engineering Economics. Prentice Hall, 1981 — исходные данные для конуса неопределённости.
• Steve McConnell. Software Estimation: Demystifying the Black Art. Microsoft Press, 2006.
• Todd Little. Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty. IEEE Software, 23(3), 2006 — критика конуса на реальных данных.
• R. Buehler, D. Griffin, M. Ross. Exploring the «planning fallacy». JPSP, 67(3), 1994.
• D. Kahneman, A. Tversky. Intuitive prediction: biases and corrective procedures. TIMS Studies in Management Science, 12, 1979 — внутренний и внешний взгляд.
• B. Flyvbjerg. From Nobel Prize to Project Management: Getting Risks Right. Project Management Journal, 37(3), 2006 — прогноз по референтному классу.
• P. Gollwitzer, P. Sheeran. Implementation intentions and goal achievement: a meta-analysis of effects and processes. Advances in Experimental Social Psychology, 38, 2006.
• E. J. Masicampo, R. Baumeister. Consider it done! Plan making can eliminate the cognitive effects of unfulfilled goals. JPSP, 101(4), 2011.
• G. Di Stefano, F. Gino, G. Pisano, B. Staats. Making Experience Count: The Role of Reflection in Individual Learning. HBS Working Paper 14-093.
• G. Mark, D. Gudith, U. Klocke. The Cost of Interrupted Work: More Speed and Stress. CHI 2008.
• T. Amabile, S. Kramer. The Progress Principle. Harvard Business Review Press, 2011 — дневниковое исследование о ценности видимого прогресса.
• The Scrum Guide, 2020 — спринт как фиксированный такт с обзором и ретроспективой.
• Project Management Institute. PMBOK Guide — rolling wave planning.

Что дальше

Мы разобрали такт: с какой частотой смотреть на систему и какие решения принимать на каждом горизонте. Осталось самое спорное — содержание этих решений. Что вообще считать хорошей целью, почему SMART чаще мешает инженеру, чем помогает, как устроены OKR и в каких условиях они превращаются в ритуал, и почему у постановки целей есть документированные побочные эффекты вплоть до ухудшения результата. Об этом — Цели: SMART, OKR, антицели и почему цели часто вредят.