Журнал решений: как фиксировать решения, чтобы аргументы сохранялись

Спросите команду, почему существует тот или иной регламент, и часто вы услышите паузу. Кто-то вспомнит встречу. Кто-то другой решит, что это было связано с поставщиком. Тот, кто знал правду, уволился в прошлом году. Решение осталось. Его причины — нет.

Это обычная ситуация, и она обходится дорого. Без понимания причин у команды есть два плохих варианта: соблюдать решение, которое больше не понятно, или отменить его и рискнуть вернуть проблему, которую оно решило. Журнал решений предлагает третий путь. Изучите запись, проверьте, сохраняются ли условия, и примите решение заново, осознанно.

Почему организации забывают причины своих решений

Три фактора мешают организации помнить о собственных решениях.

• Причины живут в разговорах. Решения принимаются на встречах, звонках и в переписках. Результат превращается в регламент или план. Контекст же редко доходит до финала.
• Люди уходят. Те, кто взвешивал варианты, меняют роли или покидают компанию. Их понимание ситуации уходит вместе с ними.
• Память переписывает сама себя. В исследовании 1975 года психолог Барух Фишхофф обнаружил, что, узнав результат, люди склонны считать его более предсказуемым, чем он был на самом деле. Он назвал это «ползучим детерминизмом». После случившегося разумное решение, которое привело к плохому результату, кажется неосторожным, а удачное — мудрым.

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

В руководстве по архитектуре Microsoft это сформулировано предельно ясно: решение, которое никогда не фиксируется, «скорее всего, будет забыто, что приведет к повторным спорам».

Чему научились команды разработчиков: архитектурные записи решений (ADR)

В программной инженерии есть проверенный ответ. В ноябре 2011 года Майкл Найгард предложил использовать архитектурные записи решений, или ADR: короткий документ для каждого важного решения, пронумерованный по порядку и хранящийся вместе с проектом. Его формат состоит из пяти частей.

• Заголовок. Короткая фраза с номером, например: «ADR 9: LDAP для мультиарендной интеграции».
• Контекст. Действующие факторы: технические, политические, социальные и локальные. Найгард рекомендовал делать этот раздел нейтральным — просто описанием фактов.
• Решение. Ответ на эти факторы, сформулированный полными предложениями в активном залоге: «Мы будем...»
• Статус. Предложено, принято, устарело или заменено, со ссылкой на актуальную версию.
• Последствия. Возникающий контекст. По словам Найгарда: «Здесь должны быть перечислены все последствия, а не только „положительные“».

Эта практика получила распространение. Thoughtworks включила облегченные ADR в кольцо Adopt своего Technology Radar (высший уровень рекомендации) и посоветовала хранить их в системе контроля версий, а не в отдельной wiki. В Microsoft Azure Well-Architected Framework запись решения названа одним из важнейших результатов работы архитектора решений. Их руководство предлагает два правила, которые стоит перенять: относитесь к журналу только как к документу, в который добавляются записи, и указывайте уровень уверенности в каждом решении.

Это применимо не только к разработке ПО. Больницы меняют процедуры госпитализации. Школы меняют правила оценки знаний. Агентства меняют поставщиков. У каждого такого решения есть контекст, варианты и последствия, и каждое из них позже будет поставлено под сомнение кем-то, кто не присутствовал при обсуждении.

Что должна фиксировать запись решения

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

• ID и заголовок. Номер и фраза, описывающая суть решения.
• Дата. Когда было принято решение, а не когда была сделана запись.
• Ответственный. Лицо, отвечающее за решение, и те, с кем проводились консультации.
• Контекст. Проблема, ограничения и противоречащие друг другу факторы.
• Рассмотренные варианты. Включая отклоненные и причины отказа. Это поле чаще всего отсутствует, хотя оно нужнее всего.
• Решение. Одно четкое предложение, начинающееся с «Мы будем...»
• Доказательства. Ссылки на данные, отчёты, аудиты или отзывы, на которых основывалось решение.
• Ожидаемый результат. Что должно стать истиной, если решение сработает, и к какому сроку.
• Уверенность. Высокая, средняя или низкая, с пояснением того, что остается под вопросом.
• Дата проверки. Когда решение будет сопоставлено с ожидаемым результатом.
• Статус. Предложено, принято, заменено или аннулировано, со ссылкой на актуальную версию.

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

Мы применяем этот же подход и к решениям по нашему собственному продукту. То, что было замечено, фиксируется отдельно от сделанных выводов, а противоречивые мнения сохраняются, а не сглаживаются. Каждое решение заслуживает как минимум такого внимания.

Связывайте каждое решение с его доказательствами и результатом.

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

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

Ссылка на результат. В дату проверки запишите, что произошло на самом деле, в сравнении с тем, что ожидалось. Если разрыв велик, выясните почему. Были ли доказательства слабыми? Изменились ли условия? Было ли решение верным, а результат — просто невезением? Ответ — это урок, и он должен быть частью той же цепочки. Наша статья о извлеченных уроках, которые меняют следующий проект объясняет, как сделать эти уроки эффективными.

Ссылка на последующие решения. Если решение отменяется, не редактируйте старую запись. Отметьте её как замененную и укажите на новую. История смены курса часто является самым ценным элементом журнала.

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

Сделайте процесс максимально легким, чтобы он не прекратился.

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

• Фиксируйте только значимые решения. Полезен тест Microsoft: фиксируйте решения, которые определяют структуру, влияют на ключевые качества или которые трудно отменить.
• Делайте записи краткими. Одна страница или меньше. Вместо копирования материалов просто давайте на них ссылки.
• Записывайте решение сразу. Запись, сделанная в ту же неделю, точна. Запись, сделанная спустя месяцы, — это лишь реконструкция.
• Храните записи там, где идет работа. Журнал, находящийся рядом с планами и процедурами, к которым он относится, читают. Журнал в отдельной папке — нет.
• Начните сейчас, а затем заполните пробелы. Начните с новых решений. Затем восстановите несколько наиболее важных прошлых решений, о которых чаще всего спрашивают, и пометьте их как «реконструированные».

Решение без обоснования — это просто инструкция. Решение с обоснованием можно проверить, сохранить или тщательно изменить.

Как Prism ведет учет решений

Prism хранит решения и знания организации как объекты с указанным уровнем доверия: утверждено, подтверждено доказательствами, наблюдаемо или сделано на основе выводов. Каждое решение связано со своими доказательствами, шагами по его реализации, результатами и уроками формата Pause and Learn. Если решение заменяется, предыдущее остается видимым. Ассистенты, которых уже использует ваша команда, также могут читать записи, поэтому обоснования всегда под рукой. Решения принимают люди. Prism сохраняет их причины.

Источники

1. Documenting Architecture Decisions. Michael Nygard, блог Relevance (теперь Cognitect), 2011.
2. Architecture decision record (Azure Well-Architected Framework). Microsoft Learn, 2024.
3. Decision Log (Code-With Engineering Playbook). Microsoft, 2024.
4. Lightweight Architecture Decision Records (Technology Radar). Thoughtworks, 2018.
5. Hindsight ≠ foresight: The effect of outcome knowledge on judgment under uncertainty. Journal of Experimental Psychology: Human Perception and Performance 1(3) (B. Fischhoff), 1975.

Комментарии

Ваше имяВаш комментарий

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

Оставить комментарий