决策日志：如何记录决策以保留决策理由

当你询问团队某项政策存在的理由时，通常会听到一阵沉默。有人记得开过会，有人认为那是供应商的问题，而那个知情者去年已经离职了。决策留下了，但理由却消失了。

这种情况很常见，且代价高昂。失去理由后，团队只有两个糟糕的选择：要么执行不再理解的决策，要么撤销决策并冒着让旧问题卷土重来的风险。决策日志提供了第三种选择：阅读记录，检查当前条件是否依然成立，然后有目的地重新做出决策。

为什么机构会忘记决策初衷

有三种力量在削弱机构对自身决策的记忆。

• 理由存在于对话中。 决策是在会议、通话和消息记录中做出的。结果体现为政策或计划，但背景信息却鲜少被记录下来。
• 人员流动。 权衡方案的人员可能会调岗或离职，他们的理解也随之流失。
• 记忆会自我重写。 在 1975 年的一项研究中，心理学家 Baruch Fischhoff 发现，一旦人们知道了结果，就会认为结果比实际情况更具可预测性。他称之为“渐进决定论”。事后看来，一个结果不佳的正确决策会被视为粗心，而一个侥幸成功的错误决策会被视为英明。

最后一点最为关键。即使原班人马仍在，他们对决策理由的记忆也会受到后续发展的影响。只有在决策当时编写的记录，才能保留当时的已知信息、预期以及不确定性。

Microsoft 的架构指南直白地指出了其中的成本：如果不记录决策，“很可能会被遗忘，导致重复的争论。”

软件团队的经验：架构决策记录

软件工程领域有一个经过验证的答案。2011 年 11 月，Michael Nygard 提出了架构决策记录（Architecture Decision Record，简称 ADR）：为每个重大决策编写一份简短文档，按顺序编号并随项目保存。他的格式包含五个部分。

• 标题。 一个带有编号的简短名词短语，例如“ADR 9: 用于多租户集成的 LDAP”。
• 背景。 正在起作用的力量：技术、政治、社会和局部因素。Nygard 要求此部分保持价值中立，仅描述事实。
• 决策。 对上述力量的回应，使用主动语态的完整句子：“我们将……”
• 状态。 提议中、已接受、已弃用或已取代，并注明任何替代方案。
• 后果。 产生的后续影响。用 Nygard 的话说，“所有后果都应在此列出，而不仅仅是‘积极’的后果。”

这一实践得到了广泛传播。Thoughtworks 将轻量级 ADR 置于其技术雷达（Technology Radar）的 Adopt 环（即最高级别的推荐等级），并建议将其保存在源码控制系统中，而非独立的 wiki 中。Microsoft 的 Azure Well-Architected Framework 将决策记录视为解决方案架构师最重要的交付物之一。其指南还增加了两条值得借鉴的规则：将日志视为仅限追加（append-only），并在每次决策时记录置信度。

这些原则并不局限于软件领域。医院会更改入院流程，学校会更改评估政策，机构会更换供应商。每一项决策都有其背景、备选方案和后果，且稍后都会被不在场的人质疑。

决策记录应包含哪些内容

决策日志是这些记录的集合，并配有一个汇总索引。Microsoft 的工程手册将日志描述为包含元数据的执行摘要表，用于记录完整记录中的决策。下方的决策日志模板不仅适用于工程领域，每个字段都至关重要。

• ID 与标题。 一个编号和一个说明决策内容的短语。
• 日期。 做出决策的时间，而非记录编写的时间。
• 负责人。 对决策负责的人，以及咨询过的人员。
• 背景。 问题、约束条件以及相互冲突的力量。
• 考虑过的方案。 包括被拒绝的方案及其原因。这是最常缺失、也最常被需要的字段。
• 决策。 一个以“我们将……”开头的清晰句子。
• 证据。 决策所依据的数据、报告、审计结果或反馈的链接。
• 预期结果。 如果决策有效，应当实现的目标以及实现时间。
• 置信度。 分为高、中、低，并注明仍不确定的部分。
• 复核日期。 用于核对决策与预期结果是否一致的时间点。
• 状态。 包括：拟定、已接受、已取代或已废止，并附上任何替代方案的链接。

预期结果和置信度字段承担了决策 Journal 的功能。它们记录了你在得知结果之前所持的观点，而这正是事后聪明所会抹去的痕迹。

我们在产品决策上也秉持同样的习惯：将观察到的事实与推论分开记录，保留冲突的观点，而非将其抹平。每一项决策都值得如此严谨的对待。

将每项决策与其证据及结果关联起来。

一份独立的记录总比没有好；而一份关联起来的记录则有用得多。

链接回证据。 当决策引用了患者调查、成本分析或事故报告时，请直接链接到源文件。后续阅读者才能判断该证据是否依然有效。Microsoft 的指南也提出了同样的观点：缺乏依据的记录“会随着时间的推移而失去价值”。

向前链接至结果。 在复核日期，将实际发生的情况与预期情况并列记录。如果差距较大，请追问原因。是证据不足？环境发生了变化？还是决策本身是正确的，只是结果运气不佳？答案就是教训，它应当属于同一条链路。我们关于 能够改变下一个项目的经验教训 的文章阐述了如何让这些教训发挥作用。

横向链接至后续决策。 当一项决策被撤销时，不要修改旧记录。将其标记为“已取代”并指向新记录。方向转变的历史往往是日志中最有价值的部分。

一个假设性的案例展示了这一链路。某诊所决定将随访电话从护士转交给专门的协调员。记录中引用了通话完成率数据，指定运营经理为负责人，预期完成率将在三个月内提升，并设定了复核日期。复核时，完成率确实提升了，但护士的工作量并未如预期般下降。于是，一条新记录取代了第一条，调整了职责并链接回原记录。两年后，新任经理只需五分钟即可读懂整个故事。

保持轻量，以便持久使用。

决策日志的失败方式与大多数文档一样：它们变成了一种负担，然后被弃之不用。以下五条规则能让它们保持生命力。

• 仅记录重大决策。 Microsoft 的测试标准非常实用：即那些塑造结构、影响关键质量或难以逆转的决策。
• 保持每条记录简短。 一页以内。链接到支撑材料，而不是直接复制内容。
• 在做决定时立即记录。 同一周完成的记录是准确的；几个月后补写的只是重建。
• 记录应随工作流而动。 放在受其影响的计划和流程旁边的日志会被阅读；放在独立文件夹里的日志则不会。
• 现在开始，再补录少量记录。 从新决策开始。然后重建少数几个人们最常问起的过往决策，并将其标记为“重建”。

没有理由的决策只是指令；拥有理由的决策则可以被严谨地测试、保留或更改。

Prism 如何管理决策记录

Prism 将机构的决策和知识作为条目进行管理，并注明其 Trust 级别：已批准、有证据支持、已观察到或已推论。每项决策都关联其证据、执行步骤，以及随后的结果和“暂停与学习”教训。当决策被取代时，早期的记录依然可见。你的团队已经在使用的助手也可以阅读这些记录，因此当有人询问时，理由就在那里。决策由人做出，而 Prism 负责保留决策背后的理由。

来源

1. Documenting Architecture Decisions. Michael Nygard, Relevance (now Cognitect) blog, 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.

评论

您的姓名发表评论

评论将在我们的团队审核后显示。请勿包含患者或同事的个人隐私信息。

发表评论