Запись решения (ADR): чтобы через полгода помнили, почему так
Запись решения, или ADR (от английского architecture decision record), — короткая страница про одну развилку. В ней контекст, варианты, выбор и его минусы. Её пишут в момент выбора и потом не переписывают. Когда через полгода новый человек спросит, почему сделано именно так, ответ можно прочитать, а не вспоминать.
Когда брать метод и когда нет
Подходит
Выбор неочевиден, его трудно отменить, и через полгода кто-то спросит, почему сделали именно так. Чаще всего это развилки в устройстве системы: как считать, где хранить, от кого зависеть.
Не подходит
Решение тривиально и отменяется за час — хватит строчки в задаче. Если вариантов ещё нет, сначала соберите их и проверьте самые рискованные догадки.
Формат предложил Майкл Найгард в 2011 году. Он заметил, что без записанной причины новый человек либо слепо принимает старое решение, либо так же слепо его отменяет.
Как провести: 6 шагов
- Решите, нужна ли запись. Записывают выбор, который трудно отменить или о котором спросят через полгода. Если решение отменяется за час и никого не удивит, хватит строчки в задаче. Сомневаетесь — представьте, что автор ушёл из команды: поймут ли остальные, почему так?
- Опишите контекст фактами. Что заставило выбирать: цель, срок, ограничения, числа. Пишите без оценок «хорошо» и «плохо» — только то, что можно проверить. Переходите дальше, когда посторонний человек понимает, откуда вообще взялся вопрос.
- Выпишите все варианты, которые обсуждали всерьёз. Настоящих вариантов должно быть хотя бы два. Не добавляйте заведомо слабые для количества — читатель это заметит, и записи перестанут верить. У каждого варианта коротко назовите, что в нём хорошо и что плохо.
- Запишите выбор одной фразой и объясните его. Фраза звучит как «Мы будем…» или «Считаем…», а не «Предлагается рассмотреть». Причина опирается на факты из второго шага: срок, данные, стоимость. Если причину не получается назвать, выбор ещё не сделан.
- Назовите последствия — и хорошие, и плохие. Что станет проще, что сложнее и что теперь придётся делать. Минусы есть у любого решения; если вы их не видите, значит, ещё не нашли. Рядом с каждым минусом запишите, что вы с ним делаете.
- Поставьте статус, дату и условие пересмотра. Статус — «предложено», пока обсуждают, и «принято», когда решили. Условие пересмотра — число или событие, после которого решение открывают снова. Записи нумеруйте по порядку и храните в одном месте рядом с работой. Принятую запись не правят: если решение поменялось, пишут новую со ссылкой «заменяет решение 1», а старую помечают «заменено».
Пример: как считать дату доставки
Исходная ситуация
По плану MoSCoW к 31 октября клиент должен видеть точный день доставки с учётом загрузки склада, на это отведено 7 человеко-дней. Посчитать дату можно тремя способами: по данным склада, которые приходят раз в час, запросом к складу при каждом заказе или датой, которую склад ставит вручную раз в день.
Как заполнили запись
| Часть записи | Что записали |
|---|---|
| Контекст | Срок 31 октября, 7 человеко-дней; данные склада приходят каждый час |
| Вариант: данные раз в час | Уже работают, укладываемся в срок |
| Вариант: запрос при каждом заказе | Подрядчику нужно 3 недели — к 31 октября не успеть |
| Вариант: дата вручную | За день устаревает, каждый день ручная работа |
| Выбор | Считаем по данным раз в час: они уже работают |
| Плюс | Успеваем к сроку, не ждём подрядчика |
| Минус | За час место может кончиться — клиенту придёт письмо с новой датой |
| Минус | Данные не пришли — снова показываем «3–5 дней» |
| Статус и пересмотр | Принято 14 октября; пересмотрим, если дата сдвинется больше чем у 2 из 100 первых заказов |
Что получилось
Решение 1, принято 14 октября: дату доставки считаем по данным склада раз в час — так успеваем к 31 октября. От запроса при каждом заказе отказались, потому что подрядчик не успеет, от ручной даты — потому что она устаревает. Минусы — редкие письма с новой датой и «3–5 дней», если данных нет. Если дата сдвинется больше чем у 2 из 100 первых заказов, решение откроем снова.
Решение принято — работу можно передавать в разработку, это трек «Разработка».
Частые ошибки
- Не записывают отвергнутые варианты. В записи только «Считаем по данным раз в час» — и через полгода кто-то снова предлагает запрос при каждом заказе. Спор идёт по второму кругу. Как надо: запишите каждый вариант, который обсуждали всерьёз, и причину отказа.
- Показывают только плюсы решения. «Быстро, просто, надёжно» без единого минуса похоже на рекламу, а не на запись. Когда минус всплывёт, команда решит, что его скрыли. Как надо: назовите, чем платите за выбор, и что делаете с каждым минусом.
- Переписывают старую запись, когда решение поменялось. Старый текст правят под новое решение, и пропадает след, почему раньше думали иначе. Как надо: оставьте старую запись со статусом «заменено» и напишите новую со ссылкой на неё.
Как вести работу с агентом
Агент возьмёт на себя всю методологическую работу: проведёт метод по шагам, укажет на пропущенные детали, составит правильные вопросы и подскажет, как и где найти на них ответ. Агент не ограничивается одним методом, а ведёт работу по трекам, где каждый метод связан с остальными для получения нужного результата.