Принятие решений в проекте: типы решений, DACI и RAPID, ADR, эскалация и допуски

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

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

1. Решение как объект управления

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

Джефф Безос в письме акционерам за 2015 год разделил решения через метафору дверей. Односторонняя дверь (Type 1) — прошёл и не вернулся: решение необратимо или обратимо ценой, сопоставимой с проектом. Двусторонняя дверь (Type 2) — можно вернуться, потеряв немного. Ценность письма не в классификации, а в описанной патологии: организации, вырастая, применяют тяжёлый процесс Type 1 к решениям Type 2 — и получают медлительность, падение изобретательности и уход людей.

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

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

2. Стоимость задержки решения

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

$$C_{\text{задержки}} = \underbrace{n_{\text{людей}} \cdot c_{\text{день}}}{\text{простой и работа впустую}} + \underbrace{V{\text{день}} \cdot P_{\text{сдвига}}}_{\text{сдвиг ценности вправо}}$$

Второе слагаемое — обычная стоимость задержки из потоковой экономики (как её считать — в статье про Lean). Практический вывод: если цена дня ожидания превышает разницу в ожидаемой ценности между лучшим и вторым вариантом, спорить дальше нерационально. Когда матрица даёт 3,80 против 3,65 при погрешности оценок ±0,5, разница меньше шума, а неделя обсуждения стоит вполне конкретных денег.

Last responsible moment (Мэри и Том Поппендик, «Lean Software Development») — момент, после которого невыбор начинает стоить дороже выбора: следующая альтернатива закрывается, работа блокируется, цена отката растёт. Принцип требует большей дисциплины, чем «решай сразу»: определить этот момент и поставить дату в календарь, назвать информацию, которая должна появиться к дате, и организовать её появление (спайк, замер, интервью, нагрузочный тест), а также сознательно удерживать варианты открытыми.

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

3. Кто решает: пять моделей распределения прав

Консент — не консенсус, и это различие практически важнее прочих. Консенсус спрашивает «все ли за?» и проваливается на первом же равнодушном участнике. Консент спрашивает «есть ли аргумент, почему это навредит?» — ищет возражения и проходит, если их нет (Sociocracy 3.0). Достаточно заменить на встрече «кто за?» на «есть ли возражения, которые нужно услышать до решения?».

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

4. DACI и RAPID: фреймворки прав на решение

DACI (Atlassian Team Playbook) распределяет четыре роли. Driver двигает решение: собирает варианты, назначает встречи, следит за датой — но не решает. Approver принимает решение и строго один: двух Approver’ов не бывает, это либо согласование, либо скрытый конфликт. Contributors дают экспертизу; их мнение обязано быть услышано, но не обязано победить. Informed узнают о решении после — потому что их работа изменится.

RAPID от Bain (материал Bain) раскладывает то же мельче, и буквы намеренно идут не в порядке процесса: Recommend готовит рекомендацию и отвечает за её содержание; Agree обязан согласовать и фактически имеет право вето (юристы, безопасность, комплаенс); Perform будет исполнять и привлекается рано; Input даёт вход без права вето; Decide решает — тоже один. Главная ценность RAPID — явное отделение Agree от Input: львиная доля тягучих согласований возникает потому, что человек с мнением ведёт себя как человек с вето, и никто не может сказать, кто он на самом деле.

RACI из главы про делегирование описывает работу: кто делает, кто отвечает за результат, с кем консультируются, кого информируют. DACI и RAPID описывают решение: кто выбирает вариант.

Путаница идёт от совпадения буквы A и от реального пересечения: Accountable за компонент часто и есть Approver для решений по нему. Но не всегда: Accountable за миграцию — тимлид, а Approver решения «переносим дату релиза» — спонсор. Правило: вопрос «кто это сделает» — берите RACI; вопрос «что мы выбираем» — DACI или RAPID. Симптом смешения: матрица ответственности есть, всё расписано, а решения принимаются в коридоре.

5. Допуски и эскалация: как не принимать чужие решения

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

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

Тема: [Эскалация] Интеграция с биллингом: нужен выбор до 24.06, рекомендован вариант Б

## Факты и почему это ваше решение
Нагрузочный тест 18.06: 120 запросов/с при требуемых 400. Биллинг подтвердил: доработка на их
стороне 6–8 недель, в квартальный план не входит. Прогноз релиза выходит за допуск по сроку:
сдвиг 22 рабочих дня при допуске 10. Выход за допуск (устав, п. 4.2) и переприоритезация в чужой
команде — вне моих полномочий.

## Варианты
А. Ждать доработку биллинга: релиз 12.09, бюджет +1,9 млн руб., риск повторного сдвига средний.
Б. Кэш на нашей стороне, окно рассинхрона 5 минут: релиз 04.08, бюджет +0,4 млн руб., принимаем
   риск расхождения остатков (согласовано с финконтролем 19.06).
В. Урезать объём до 3 сценариев из 7: релиз 28.07, бюджет без изменений, 4 сценария в след. квартал.

## Рекомендация и что нужно от вас
Вариант Б: сохраняет дату, риск ограничен и обратим (кэш снимается за 2 дня), вчетверо дешевле А.
Нужно одно из двух: (1) утвердить вариант Б; либо (2) поднять приоритет нашей задачи у руководителя
биллинга — тогда работает вариант А.

## Дедлайн
24.06, 18:00. После этой даты вариант Б не помещается в релизное окно, и решение по умолчанию — В.

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

6. Фиксация решения: ADR

ADR (Architecture Decision Record, а на практике — Any Decision Record) придумал Майкл Найгард в заметке «Documenting Architecture Decisions» (2011); экосистема шаблонов собрана на adr.github.io. Формат родился из наблюдения: новый человек видит систему и не понимает, почему она такая, а старожилы либо ушли, либо помнят неточно.

Главная ценность ADR — не решение, а контекст и отвергнутые варианты. Решение видно из кода, конфигурации или регламента; из них не видно, какие ограничения действовали, что мы знали и чего не знали, какие альтернативы проиграли и почему. Именно этого не хватает через год, когда ограничение исчезло, а решение осталось: половина «глупых легаси-решений» — это разумные решения, чей контекст умер, а запись не велась.

Управленческий угол отличается от архитектурного тремя вещами. У управленческого решения есть Approver по имени — в архитектурном ADR это часто «команда». У него есть дата пересмотра, потому что контекст (люди, рынок, регулятор, спонсор) меняется быстрее технологий. И оно почти всегда затрагивает людей, поэтому в следствиях обязано быть написано, кто и что теперь делает иначе. Детали формата, стили шаблонов (Nygard, MADR, Y-statements) и практика ведения каталога — в статье про ADR; здесь не дублируем.

Полный пример ADR по управленческому решению:

# ADR-021. Фиксируем дату и мощность команды, объём делаем плавающим

- Статус: accepted (2026-06-11) · заменяет ADR-014 (superseded) · пересмотр: после релиза 2.0
- Decide / Approver: Ирина К., спонсор · Driver: менеджер проекта · Agree (вето): юридический отдел
- Contributors: тимлид, аналитик, руководитель поддержки · Informed: команда, продажи, поддержка

## Контекст
Требование регулятора вступает в силу 01.10.2026, штраф — до 4% оборота подразделения. Оценка объёма
по 85-му перцентилю: 7,5 месяца работы при 4,5 месяцах календаря. Состав команды зафиксирован
(5 инженеров); найм двух дополнительных занял бы 3–4 месяца, из них 1,5 — онбординг. За два прошлых
квартала команда приняла 34 запроса на изменение объёма, не сняв ни одного, — это и есть механизм,
из-за которого прошлый релиз опоздал на 11 недель. Юристы подтвердили (письмо от 04.06): регулятор
требует 9 сценариев из 21, остальные 12 — наше желание.

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

## Решение
Дата 01.10 и состав команды неизменяемы. Релиз 1.0 сокращается до 9 обязательных сценариев плюс
буфер; остальные 12 уходят в релиз 2.0 с датой 15.12 без обязательств. Новый запрос принимается
только вместе с ответом «что выпадает из релиза 1.0»; приоритет внутри 12 необязательных сценариев
определяет руководитель поддержки, полномочия менеджера — до 5 человеко-дней за фазу.

## Следствия
Плюсы: дата защищена; спор об объёме перенесён с релиза на приоритет внутри бэклога; у команды
появился явный критерий отказа. Минусы: продажи не смогут обещать 12 сценариев к октябрю — сообщено
21 клиенту, у 3 это в договоре и требует допсоглашения (владелец — руководитель продаж, срок 20.06).
Новые обязанности: менеджер ведёт публичный список выпавшего; поддержка еженедельно подтверждает
приоритет; спонсор рассматривает изменения свыше 5 человеко-дней за 2 дня.

## Как поймём, что решение было ошибочным
- Если к 15.07 обязательный минимум прогнозируется позже 20.09 — урезали недостаточно.
- Если из 12 отложенных сценариев к декабрю понадобятся меньше 4 — мы недооценили долю
  необязательной работы, и это надо учесть в следующих оценках.
- Если «изменений в обход правила» окажется больше 3 за квартал — проблема в полномочиях.

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

7. Когнитивные ловушки решений

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

• Письменное решение до обсуждения. Документ на 1–2 страницы рассылают заранее, встреча начинается с 10 минут тишины на чтение. Убивает три ловушки сразу: якорение первым выступившим, HiPPO (написанный аргумент нельзя перекричать) и групповое мышление (комментарии пишут до того, как услышат большинство). Практика описана Amazon в письме акционерам 2017 года.
• Pre-mortem (Гэри Кляйн, HBR 2007): «Сейчас декабрь, проект провалился с треском — напишите почему». Работает потому, что меняет задачу с «оцените риски» (люди осторожничают и говорят общее) на «объясните известный факт».
• Red team / адвокат дьявола. Назначенный человек обязан атаковать рекомендацию; ключевое слово — назначенный: добровольный критик платит социальную цену, назначенный выполняет работу. Роль передают по кругу.
• Взгляд снаружи: не «сколько займёт наш проект», а «сколько заняли последние семь похожих» — см. главу про оценку и Флювбьерга (reference class forecasting).
• Заранее записанные критерии остановки — единственная защита от невозвратных затрат: критерий, придуманный после старта, всегда подстраивается под желание продолжать.

8. Инструменты выбора

Взвешенная матрица критериев считается как $S_j = \sum_i w_i \cdot s_{ij}$, где $w_i$ — вес критерия (сумма равна 1), $s_{ij}$ — оценка варианта $j$ по критерию $i$ по шкале 1–5. Задача: как доставлять уведомления пользователям.

Формально победил вариант Б. Практически матрица не выбрала за вас: 3,80 против 3,65 при погрешности ±0,5 балла — это ничья. И в этом её польза. Она делает веса предметом явного разговора (спор о том, вправду ли срок вдвое важнее стоимости владения, продуктивнее спора о вариантах); показывает чувствительность (снизьте вес срока до 0,15 — выигрывает вариант В); ловит подгонку — если ответ известен заранее, оценки лидера подозрительно ровно ложатся на 5. Правила гигиены: критериев не больше семи; веса назначают до оценок и не меняют после; критерий, где все варианты получили одинаковый балл, вычёркивают.

Матрица предполагает, что свойства вариантов известны. Когда они неизвестны, нужно дерево решений с ожидаемой ценностью: $EV = \sum_i p_i \cdot v_i$ в узлах, где решает среда, и максимум в узлах, где решаем мы. Самое ценное в дереве — количественный ответ на вопрос «стоит ли купить информацию вместо того, чтобы принимать решение». Спайк, прототип, пилот на одном регионе — покупка реального опциона: платим немного, чтобы потом выбирать, зная больше (разбор — у Маттса и Маассена, «Real Options Underlie Agile Practices»).

from dataclasses import dataclass, field

@dataclass
class Node:
    """Узел дерева решений; суммы — в тыс. руб. чистой ценности.
    kind: 'decision' — выбираем мы (максимум), 'chance' — выбирает среда (среднее), 'leaf' — исход."""
    name: str
    kind: str = "leaf"
    value: float = 0.0                       # ценность исхода (только для листа)
    cost: float = 0.0                        # немедленные затраты на вход в ветку
    prob: float = 1.0                        # вероятность ветки; осмысленна под 'chance'
    children: list = field(default_factory=list)

def ev(node: Node) -> float:
    """Ожидаемая ценность поддерева; затраты ветки вычитаются на входе. Обход в глубину,
    каждый узел посещается один раз: O(n) по времени, O(h) по памяти (h — глубина дерева)."""
    if node.kind == "leaf":
        return node.value - node.cost
    if node.kind == "chance":                                  # решает среда
        return -node.cost + sum(ch.prob * ev(ch) for ch in node.children)
    return -node.cost + max(ev(ch) for ch in node.children)    # решаем мы: берём лучшее

def leaf(name, value, prob): return Node(name, "leaf", value=value, prob=prob)

def vendor(p_holds):                         # вендор с заданной вероятностью выдержать нагрузку
    return Node("Взять вендора", "chance", cost=6_000, children=[
        leaf("держит нагрузку", 14_500, p_holds), leaf("не держит, доделываем", 3_000, 1 - p_holds)])

own = Node("Писать свой движок", "chance", cost=5_200, children=[
    leaf("уложились в план", 15_000, 0.5), leaf("затянули вдвое", 6_000, 0.5)])

# Спайк за 2 недели: платим 400, узнаём правду про вендора и ТОЛЬКО ПОТОМ выбираем
spike = Node("Спайк: нагрузочный тест вендора", "chance", cost=400, children=[
    Node("тест успешен", "decision", prob=0.6, children=[own, vendor(0.95)]),
    Node("тест провален", "decision", prob=0.4, children=[own, vendor(0.10)])])
root = Node("Чем закрыть маршрутизацию платежей", "decision", children=[own, vendor(0.6), spike])

for ch in sorted(root.children, key=lambda c: -ev(c)):         # альтернативы по убыванию ценности
    print(f"{ch.name:34} {ev(ch):>8.1f}")
# Спайк: нагрузочный тест вендора      6475.0
# Писать свой движок                   5300.0
# Взять вендора                        3900.0
print("Ценность информации:", round(ev(spike) - ev(own), 1))   # 1175.0

Прямой выбор «свой движок» даёт ожидаемые 5 300 тыс. руб., прямой выбор вендора — 3 900. Двухнедельный спайк ценой 400 даёт 6 475, потому что после него мы выбираем зная, а не гадая: чистая ценность информации — 1 175 тыс. руб., окупаемость почти втрое. Отсюда правило, которое стоит запомнить крепче арифметики: когда варианты близки, а неопределённость велика, правильный ход — не выбирать вариант, а купить информацию.

9. Решения в условиях разногласия

Единогласия не бывает, и требовать его — способ никогда не решить. Работающая норма называется disagree and commit и описана Безосом в письме акционерам за 2016 год: я не согласен, я это сказал, решение принято не в мою пользу — я исполняю его полностью и не саботирую. Существенны обе половины. Без первой получается фальшивое согласие: молчат на встрече и рассказывают правду в личке. Без второй — пассивный саботаж, самый дорогой исход: решение формально принято, фактически не выполняется, и никто не понимает, почему не работает. Протокол несогласия:

1. Возражение проговаривается до решения. Аргумент, придержанный до «я же говорил», — не несогласие, а ставка на провал.
2. Возражение записывается одной строкой: кто, против чего и какой наблюдаемый факт подтвердит его правоту — это превращает несогласие в прогноз.
3. Решение исполняется без оговорок. «Ну, я вообще был против» в разговоре с соседней командой — нарушение протокола.
4. Назначается точка пересмотра — дата или триггер, на которой смотрят, сбылся ли прогноз несогласного.
5. Если несогласный оказался прав, это фиксируют вслух. Иначе в следующий раз он промолчит, и вы потеряете самый ценный сигнал в проекте.

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

10. Журнал решений проекта

Decision log — одностраничная таблица в вики, репозитории или трекере (где угодно, лишь бы в одном месте), куда попадает каждое значимое решение проекта.

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

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

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

12. Как это выглядит в проде

Платформенная команда, 9 человек. Введено одно правило: у каждого вопроса в канале решений обязательны поля «кто решает» и «до какой даты». За квартал среднее время от постановки вопроса до решения упало с 11 дней до 3, число вопросов, висящих больше месяца, — с 14 до 1. Работает не процесс, а два поля: вопрос без владельца сразу видно, и кто-нибудь спрашивает «а кто Approver?».

Финтех, регуляторный проект. Все решения дороже 500 тыс. руб. оформляются как ADR с секцией «как поймём, что ошиблись». Через год из 18 записей 12 подтвердились, 4 были переиграны по собственным же критериям, 2 остались неопределёнными. Главный эффект культурный: признание ошибки перестало быть поражением — срабатывал заранее записанный критерий, а не чьё-то мнение.

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

Мини-итог

• У решения есть владелец, момент, обратимость и цена задержки. Нет имени — нет решения: его примет среда.
• Большинство решений в разработке — двусторонние двери, а обсуждаются как односторонние; тяжёлый процесс для обратимых решений — самый распространённый налог организаций, которые «стали серьёзнее».
• Last responsible moment требует даты, плана добычи информации и открытых вариантов. Без всех трёх это прокрастинация с решением по умолчанию.
• Консент — не консенсус, голосование в инженерии почти всегда ошибка, рабочая лошадка — консультативное решение. RACI про работу, DACI и RAPID про решение: Approver и Decide всегда один, а отделение вето (Agree) от мнения (Input) снимает большую часть согласований.
• Допуски дают автономию, а не контроль. Эскалация — подготовленное решение, которое нельзя принять на своём уровне: факты, варианты с ценой, рекомендация, что нужно от адресата, дедлайн и решение по умолчанию.
• Главная ценность ADR — контекст и отвергнутые варианты. Управленческий ADR добавляет имя Approver’а, дату пересмотра и критерий «как поймём, что ошиблись».
• Ловушки лечатся процедурами: письменное решение до обсуждения, pre-mortem, назначенный оппонент, взгляд снаружи, критерии остановки заранее.
• Когда варианты близки, а неопределённость велика — покупайте информацию, а не решение, а disagree and commit работает только целиком: несогласие записано как проверяемый прогноз, решение исполняется без оговорок, у прогноза есть дата проверки.

Источники

• Bezos J., письмо акционерам Amazon за 2015 год — решения Type 1 и Type 2, односторонние и двусторонние двери; за 2016 год — disagree and commit; за 2017 год — письменные нарративы вместо презентаций.
• Atlassian, DACI — роли Driver, Approver, Contributors, Informed и шаблон встречи; Bain & Company, RAPID — разделение Agree и Input, раннее подключение Perform.
• Nygard M., «Documenting Architecture Decisions», 2011; каталог шаблонов и инструментов — adr.github.io.
• Klein G., «Performing a Project Premortem», HBR 2007; Tversky A., Kahneman D., «Judgment under Uncertainty», Science 1974 — якорение и доступность.
• Arkes H., Blumer C., «The Psychology of Sunk Cost», 1985; Staw B., «Knee-Deep in the Big Muddy», 1976 — эскалация обязательств; Janis I., «Victims of Groupthink», 1972 — групповое мышление; McAfee A., Brynjolfsson E., «Big Data: The Management Revolution», HBR 2012 — про HiPPO.
• Flyvbjerg B., «From Nobel Prize to Project Management» — эталонное прогнозирование; Poppendieck M., Poppendieck T., «Lean Software Development», 2003 — last responsible moment.
• Matts C., Maassen O., «Real Options Underlie Agile Practices», InfoQ 2007 — покупка информации как опцион; Sociocracy 3.0 — консент и работа с возражениями.
• PRINCE2 — управление по отклонениям и допуски; ISO 21502:2020 — управление решениями.

Что дальше

Решение принято, записано и исполняется. Остаётся вопрос, который решает судьбу проекта не меньше самого выбора: как мы узнаем, что оно работает, — и узнаем ли вовремя. Любое решение — это прогноз, а прогноз без обратной связи превращается в веру. Механизм обратной связи называется контролем исполнения и устроен сложнее, чем «собирать статусы»: нужно отличать статус от прогноза, знать правила подсчёта готовности, считать отклонения от базового плана и видеть ранние индикаторы беды раньше, чем они станут очевидны всем. Вторая половина следующей главы — про то, как сделать, чтобы весь этот опыт (включая ADR, журнал решений и записанные несогласия) дожил до следующего проекта, а не остался в вики, куда никто не заходит.

Читайте: Контроль исполнения и извлечённые уроки: отчётность, освоенный объём, health check, база знаний