Приоритизация: матрица Эйзенхауэра, ABC, MoSCoW, «съешь лягушку»

В предыдущей статье — GTD Дэвида Аллена целиком — мы разобрали, как довести список дел до состояния «всё выгружено, всё сформулировано как физическое действие». Теперь у вас на руках честный инвентарь: 60–200 открытых пунктов. Проблема ровно в том, что список честный. Он не помещается в неделю, и никакой метод сбора эту арифметику не изменит.

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

Ниже — четыре классических метода. Для каждого: происхождение (часто оно объясняет ограничения), механика, инженерная адаптация, точка поломки и что об этом известно из исследований. В конце — то, что я бы советовал собрать из них лично для себя.

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

Специфика разработки ломает наивную приоритизацию тремя способами.

Стоимость переключения нелинейна. Классическая работа Rubinstein, Meyer & Evans (2001) в Journal of Experimental Psychology: Human Perception and Performance показала, что переключение между задачами добавляет измеримый штраф, и штраф растёт со сложностью и незнакомостью задач (APA). Полевое исследование Gloria Mark с коллегами («The Cost of Interrupted Work: More Speed and Stress», CHI 2008) дало оценку в среднем около 23 минут до возврата к прерванной задаче (PDF). Для инженера это значит: список из десяти «мелких важных дел» на день может стоить дороже, чем две крупные задачи, хотя по сумме оценок он «легче».

Срочность приходит извне и не спрашивает. Дежурство (on-call), сломанный CI, ревью, которое блокирует чужой релиз, — всё это генерируется другими людьми и системами. Ваш собственный приоритетный список конкурирует с чужими приоритетами, а не с вашей ленью.

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

Краткая история: откуда взялись методы

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

Матрица Эйзенхауэра

Происхождение

Дуайт Эйзенхауэр в речи 1954 года в Северо-Западном университете процитировал «бывшего президента одного колледжа»: «У меня есть два вида проблем — срочные и важные. Срочные не важны, а важные никогда не срочны» (The American Presidency Project). Сам Эйзенхауэр никакой матрицы не рисовал. Двумерную сетку из этой мысли сделал Стивен Кови в «7 навыках» (1989), назвав её «матрицей управления временем». Название «матрица Эйзенхауэра» — маркетинговое переприсвоение, случившееся уже в 2000-х. Знать это полезно: за методом нет ни исследовательской программы, ни валидации — есть удачная риторическая фигура.

Механика

Правила простые: Q1 — делать; Q2 — планировать; Q3 — делегировать или снижать издержки; Q4 — не делать. Ценность матрицы в одном наблюдении: работа сама по себе дрейфует в Q1, и единственный способ этому противостоять — заранее отдать календарные слоты под Q2. Если Q2 не защищён временем, он не существует.

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

Единственный по-настоящему сильный эмпирический аргумент за матрицу — не в её пользу как инструмента, а в пользу проблемы, которую она называет. Zhu, Yang & Hsee («The Mere Urgency Effect», Journal of Consumer Research, 2018) в серии экспериментов показали: люди систематически выбирают задачу с искусственным признаком срочности вместо объективно более выгодной несрочной, даже когда награда за вторую заметно выше и обе одинаково выполнимы (DOI). Эффект усиливался у тех, кто считает себя «занятым». То есть перекос в сторону срочного — не характер и не распущенность, а устойчивое когнитивное искажение.

А вот доказательств, что рисование матрицы этот перекос лечит, практически нет. Это типичная ситуация для тайм-менеджмента: систематический обзор Aeon, Faber & Panaccio (2021, PLOS ONE) по 158 работам нашёл, что практики тайм-менеджмента умеренно связаны с производительностью и заметно сильнее — с благополучием, но качество исследований по отдельным техникам низкое (PLOS ONE).

Где ломается

1. Важность не измеряется, а декларируется. Вы кладёте точку в «важно», потому что уже решили ею заняться. Матрица тогда не решение, а его оформление.
2. Срочность бинарна, а реальность — нет. «Срочно» склеивает «ценность обнулится через час» и «ценность обнулится в пятницу». Это разные экономики.
3. Q3 требует полномочий. Совет «делегируй» бессмыслен для инженера без подчинённых. Реальные операции в Q3 — это «согласовать перенос», «предложить асинхронный формат», «сделать за 15 минут вместо часа», «отказать вежливо».
4. Q4 в реальности почти пуст. Никто не планирует делать неважное и несрочное; туда попадает не работа, а прокрастинация — а с ней матрица не работает вообще (см. https://courses.digitable.life/post/time-management/10-procrastination/).

Чем чинить: стоимость задержки

Вместо вопроса «срочно ли это» задавайте «сколько мы теряем за неделю ожидания». Это идея Cost of Delay из работ Дональда Райнертсена («The Principles of Product Development Flow», 2009). Профили ценности во времени бывают качественно разные:

Практический приём для бэклога: рядом с задачей писать одну строчку — что произойдёт, если она не будет сделана через месяц. Если ответа нет, это Q4 независимо от того, как вам казалось.

ABC и ABCDE

Происхождение

ABC-приоритеты ввёл Alan Lakein в бестселлере «How to Get Control of Your Time and Your Life» (1973) — там же появился знаменитый вопрос-триггер: «What is the best use of my time right now?». Брайан Трейси в «Eat That Frog» (2001) расширил схему до ABCDE, добавив явные категории «делегировать» и «удалить».

Механика

• A — «должен сделать»; невыполнение имеет серьёзные последствия.
• B — «следует сделать»; последствия мягкие.
• C — «приятно сделать»; последствий нет.
• D — делегировать (кому-то, кто сделает это дешевле вас).
• E — eliminate, вычеркнуть навсегда.

Ключевое правило Трейси, которое обычно теряют при пересказе: никогда не делайте B, пока есть незакрытое A. И второе: если A несколько, они нумеруются — A-1, A-2, A-3 — и выполняются строго по порядку. Без принудительной нумерации метод вырождается.

Инженерная адаптация

Инженерный список на день после ABCDE выглядит так:

A-1  Починить флапающий тест в payments/e2e (блокирует релиз 4 команд)
A-2  Ревью PR #4821 — Аня ждёт с понедельника, ветка протухает
B-1  Дописать раздел про ретраи в RFC об идемпотентности
B-2  Обновить дашборд латентности — панель p99 врёт после миграции
C-1  Разобрать почту с рассылками
D    Выгрузка данных для маркетинга -> дать им готовый SQL и доступ, не делать самому
E    Переезд на новый линтер «потому что модно» -> закрыть тикет

Обратите внимание: у каждого A есть указание на последствие. Это единственная защита от инфляции.

Где ломается

Инфляция буквы A — главный и почти неизбежный отказ. Через две недели весь список состоит из A. Причина понятна: «серьёзные последствия» — субъективная категория, а тревога подталкивает завышать. Лечится двумя жёсткими правилами:

• Квота. Не более трёх A в день. Четвёртое A автоматически делает какое-то из существующих B — назовите вслух, какое именно.
• Проверка последствием. A обязано иметь конкретное предложение вида «если не сделаю до X, произойдёт Y, и это заметит Z». Нет Z — не A.

Второй режим отказа: ABC не различает размер. A-задача на четыре часа и A-задача на десять минут стоят в одном списке, и хочется начать с короткой — это ощущается как прогресс. Отсюда практика: приписывать грубую оценку (S/M/L) и планировать день как «одна L + две S», а не «пять A».

MoSCoW

Происхождение

MoSCoW придумал Дай Клегг в Oracle примерно в 1994 году, метод вошёл в DSDM (Dynamic Systems Development Method) и до сих пор описан в открытом своде знаний Agile Business Consortium (DSDM Handbook, глава про MoSCoW). Это единственный из четырёх методов, рождённый прямо в разработке ПО — и это заметно.

Расшифровка: Must have, Should have, Could have, Won’t have this time. Строчные «o» — просто для произносимости.

Механика и главное правило

MoSCoW осмыслен только внутри фиксированного таймбокса. Он отвечает не на вопрос «что важнее вообще», а на вопрос «что точно должно быть внутри вот этих двух недель, если всё пойдёт плохо».

Формальное правило DSDM: Must-have не должны занимать больше ~60% усилий таймбокса, а Could-have должны составлять около 20%. Эти 20% — не «бонус», а буфер: именно ими жертвуют, когда оценки поедут. Если Must — это 100% ёмкости, у вас нет плана, у вас есть обещание.

Категория Won’t have this time — самая недооценённая. Она не означает «никогда», она означает «мы явно решили не делать это в этой итерации» и делает отказ документированным. Половина ценности MoSCoW — в том, что список W существует и на него можно сослаться.

Пример: релиз сервиса нотификаций

MUST   (≈55% ёмкости спринта)
  - Доставка push и email по существующему контракту событий
  - Идемпотентность по ключу event_id — без неё дубли в проде
  - Метрики отправок и алерт на падение success rate ниже 98%

SHOULD (≈25%)
  - Ретраи с экспоненциальной задержкой (сейчас одна попытка)
  - Ручной ре-drive из админки для support-команды

COULD  (≈20%, буфер)
  - Шаблоны сообщений с локализацией
  - Дедупликация похожих уведомлений в окне 5 минут

WON'T THIS TIME
  - SMS-канал — нет договора с провайдером, решаем в следующем квартале
  - Пользовательские настройки частоты — требует UX-исследования

Где ломается

• Все категории становятся Must. Классический провал. Противоядие — считать проценты усилий, а не количество пунктов, и вслух проговаривать: «если Must это 90%, мы обещаем сдать всё при нулевом риске; готовы подписаться?»
• Нет упорядочивания внутри Must. MoSCoW — это классификация, а не сортировка. Внутри Must всё равно нужен порядок; берите ABC-нумерацию или зависимости.
• Плохо работает без таймбокса. В потоковой модели (kanban, непрерывная поставка) «Must have до когда?» не имеет ответа. Там уместнее WSJF/Cost of Delay или простая политика классов обслуживания — об этом в личном канбане.
• Личное применение ограничено. MoSCoW — командный, переговорный инструмент. Для собственного дня он избыточен; для планирования личной недели с фиксированным бюджетом времени — вполне работает.

«Съешь лягушку»

Происхождение и одна легенда

Брайан Трейси, «Eat That Frog!» (2001). Правило: с утра, первым делом, беритесь за самую неприятную и самую значимую задачу дня. Эпиграф книги приписывает Марку Твену фразу про лягушку на завтрак. Твен этого, по всей видимости, не говорил — исследователи цитат возводят мотив к французскому афористу Николя де Шамфору конца XVIII века (Quote Investigator). Мелочь, но показательная: значительная часть литературы по продуктивности держится на удобных апокрифах.

Что в правиле действительно работает

Механизм здесь не мистический, а вполне понятный:

• Снятие затрат на избегание. Прокрастинация дорога не потерянным временем, а фоновой тревогой. Мета-анализ Piers Steel (2007, Psychological Bulletin, «The Nature of Procrastination») связывает откладывание прежде всего с отвращением к задаче, импульсивностью и отдалённостью награды (PDF). Утренний старт бьёт по «отдалённости»: расстояние до начала становится нулевым.
• Защита самого чистого блока внимания. Утро (для большинства, не для всех) — единственное время, когда календарь ещё не разъеден встречами, а инбоксы не разогнались.
• Один якорь вместо пяти. Правило требует выбрать ровно одну задачу — это скрытая борьба с инфляцией приоритетов.

Где ломается

Хронотипы. «Утро» — не универсальная константа. Исследования хронотипов (Roenneberg и коллеги, концепция social jetlag) показывают устойчивые индивидуальные различия в пике работоспособности (Current Biology, 2012). Правильная формулировка правила: «съешьте лягушку в свой первый защищённый блок», а не «в 8 утра». Подробнее — в статье Внимание и энергия.

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

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

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

Как эти методы соотносятся

Они не конкуренты. Эйзенхауэр — про распределение бюджета внимания по типам работы. MoSCoW — про торг с внешним миром об объёме. ABC — про порядок внутри дня. Лягушка — про запуск.

Сборка: как это выглядит на практике

Поток одной задачи

Важная деталь состояния «Прервана»: перед переключением записывайте одну строку — что делали, где остановились, какая следующая команда. Это стоит 30 секунд и экономит те самые 20+ минут возврата.

Алгоритм выбора «что делать прямо сейчас»

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

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

Три вещи, которые здесь важны и которые обычно забывают:

1. Коммуникация собрана в два окна, а не размазана. Это снижает число переключений на порядок.
2. Буфер запланирован явно. Если в конце дня буфер не понадобился — это не «потерянные 30 минут», это подтверждение, что план был реалистичен.
3. Ревью — обязательство с таймбоксом. Не «когда дойдут руки», а слот с границей.

О том, как всё это заносить в календарь и защищать, — следующая статья про time blocking.

Недельный обзор: пять вопросов

Приоритизация без регулярной ревизии протухает за неделю. Минимальный ритуал (25–40 минут, пятница вечером или понедельник утром):

1. Что из прошлых Must не сделано и почему — не хватило времени или это было не Must?
2. Что переехало третий раз подряд? Такие пункты либо переводятся в Won’t, либо разбиваются на кусок в один час.
3. Какая доля прошлой недели ушла в Q1 (реактив)? Если больше половины стабильно — это системная проблема команды, а не личного планирования, и обсуждать её надо с менеджером, а не с собой.
4. Что из Q2 получило календарный слот на следующую неделю? Если ничего — план на неделю не готов.
5. Какие обязательства я взял на себя устно и не записал?

Подробный разбор ритуала и более длинных горизонтов — в статье про горизонты планирования.

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

Приоритизация без ёмкости. Расставили A/B/C, но не посчитали, сколько часов реально доступно. У инженера с четырьмя часами встреч в неделю, дежурством раз в месяц и ревью-нагрузкой честная ёмкость на «свою» работу — часто 20–25 часов из 40. Планируя 40, вы гарантируете провал и берёте вину на себя.

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

Приоритет без явного отказа. «Это самое важное» без «поэтому вот это я не делаю» — не приоритизация, а декларация намерений. Формулируйте парой: A-1 = миграция схемы; следовательно, ре-дизайн дашборда переезжает на следующую неделю, я предупредил Костю.

Приоритизация как способ отложить старт. Полчаса на перекраску тегов в трекере ощущаются как работа. Правило: если приоритизация занимает больше 10 минут в день и 40 минут в неделю — это прокрастинация в костюме планирования.

Игнорирование восстановления. Все четыре метода молча предполагают ровный уровень энергии. Он не ровный. Задача, «важная» в 10 утра, может быть физически невыполнимой в 17:30, и это не про мотивацию.

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

Когда приоритеты ставите не вы

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

• Показывать очередь, а не спорить о важности. «Сейчас в работе три вещи с дедлайном на этой неделе. Новая задача становится четвёртой. Какую из трёх двигаем?» Это переводит разговор из «мне некогда» в «выбор за вами» — и обычно завершается сам собой.
• Считать в неделях, а не в оценках. «Это два дня работы» приглашает к торгу. «Это будет готово к четвергу при текущей очереди» — нет.
• Документировать Won’t. Один канал/тред, где записаны явные отказы с датой и причиной. Через квартал это самый ценный документ на ревью.
• Различать приоритет и срочность в письме. «Важно» без даты — не задача. Просите у постановщика профиль стоимости задержки: что сломается и когда.

Мини-итог

• Приоритизация — процедура отказа. Метод, который не заставляет вас что-то явно не делать, бесполезен.
• Матрица Эйзенхауэра точно называет проблему (перекос в сторону срочного экспериментально подтверждён), но не решает её: важность в ней декларативна. Чините вопросом о стоимости задержки.
• ABC работает только с квотой (не больше трёх A) и явным последствием у каждого A. Иначе — инфляция.
• MoSCoW — командный инструмент фиксированного таймбокса; его сила в правиле «Must ≤ 60% ёмкости» и в существовании списка Won’t.
• «Съешь лягушку» — про запуск и снятие избегания; привязка к утру условна, привязка к первому защищённому блоку — нет.
• Все методы предполагают ровную энергию и полный контроль над календарём. Оба предположения ложны, и разница между «метод не сработал» и «условия не позволяли» — это как раз то, что стоит различать при разговоре с собой.

Источники

• Zhu M., Yang Y., Hsee C. K. «The Mere Urgency Effect». Journal of Consumer Research, 2018. https://doi.org/10.1093/jcr/ucy008
• Aeon B., Faber A., Panaccio A. «Does time management work? A meta-analysis». PLOS ONE, 2021. https://doi.org/10.1371/journal.pone.0245066
• Steel P. «The Nature of Procrastination: A Meta-Analytic and Theoretical Review». Psychological Bulletin, 2007. http://studiemetro.au.dk/fileadmin/www.studiemetro.au.dk/Procrastination_2.pdf
• Mark G., Gudith D., Klocke U. «The Cost of Interrupted Work: More Speed and Stress». CHI 2008. https://www.ics.uci.edu/~gmark/chi08-mark.pdf
• Rubinstein J., Meyer D., Evans J. «Executive Control of Cognitive Processes in Task Switching». 2001. https://psycnet.apa.org/doi/10.1037/0096-1523.27.4.763
• Agile Business Consortium. DSDM Handbook, глава MoSCoW Prioritisation. https://www.agilebusiness.org/dsdm-project-framework/moscow-prioririsation.html
• Reinertsen D. «The Principles of Product Development Flow», 2009 — экономические модели Cost of Delay.
• Covey S. «The 7 Habits of Highly Effective People», 1989 — привычка 3, матрица управления временем.
• Lakein A. «How to Get Control of Your Time and Your Life», 1973 — ABC-приоритеты.
• Tracy B. «Eat That Frog!», 2001 — ABCDE и правило лягушки.
• Quote Investigator. Разбор происхождения цитаты про лягушку. https://quoteinvestigator.com/2013/04/03/eat-frog/
• ВОЗ, МКБ-11: выгорание (QD85) как профессиональный феномен. https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281

Что дальше

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

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