---
name: decision-record
description: 把已经做出的决策记成一条简短的决策日志：一句话写明决策，再写背景、考虑过的选项、为什么选这个、谁拍板、日期、状态，以及在什么情况下要重新讨论。参考架构决策记录（ADR）和决策日志的做法，适用于任何业务决策。用于团队刚做完一个决定、有人要求记录或整理某个决策，或者大家总在问“当初为什么这么做？”的时候。
---

# 决策记录

决策记录让六个月后的人不用去问当事人，也能明白当时决定了什么、为什么、什么时候该重新讨论。它记录的是已经做出的决策，而不是为某个决策辩护。写短一点：Michael Nygard 在 2011 年提出架构决策记录（ADR）格式的文章里说，整份文档应控制在 1 到 2 页；本技能的默认值是半页。

## 适用场景

- 团队刚做了一个难以撤回、或者以后会有人质疑的决定：工具、供应商、价格、制度、招聘计划、流程。
- 有人说“把这个记下来吧”，或者要求加一条决策日志。
- 某个讨论串里大家反复问“当初为什么选 X？”，而答案只在某个人脑子里。
- 不适用于做决策本身。要列出选项、让建议获批，先写一份决策备忘录，再把结果记在这里。

## 需要准备

- 决定了什么，由谁决定。拍板人不清楚的话，问一次；绝不猜。仍然不清楚就写“[拍板人未确认]”。
- 做出决定的日期。没有的话，用原始消息的日期，并标注“[取自消息日期]”。
- 当时摆在桌上的选项，以及其他选项为什么落选。如果只讨论过一个选项，就照实写；不要编造备选方案。
- 可选：讨论所在的消息串、会议纪要或文档，以及日志里上一条的编号。

## 步骤

1. **用一句主动语态的话写出决策。** Nygard 要求决策部分“用完整的句子、主动语态”来写，通常以“我们将”开头。例如：“我们将从 3 月 1 日起使用 Dealbook 作为 CRM。”
2. **用 2 到 4 句话写背景。** 迫使大家做选择的事实和压力：截止日期、成本、某个客户、某项限制。Nygard 说这一部分“是价值中立的，只是在描述事实”。观点放到理由里。
3. **列出考虑过的选项。** 每个选项一行，写出主要的取舍。Atlassian 的 DACI 方法会用一张表列出各选项的优点、缺点和成本。如果“维持现状”是真正考虑过的选项，也要列上。只列真正讨论过的选项。
4. **写出理由。** 2 到 4 条，回扣背景：为什么这个选项胜过其他选项。然后列出后果，好的坏的都写。Nygard 说：“所有后果都应列在这里，而不只是‘正面’的那些。”
5. **写明谁拍板、征求了谁的意见。** 拍板人只有一个（Atlassian 的 DACI 方法称之为 Approver，即“做出决定的那一个人（没错，只有一个！）”），再列出被征求意见的人。英国政府的 ADR 框架也会记录征求过意见的相关方。
6. **设定重新讨论的触发条件。** 一个会让这项决策重新打开的具体条件：日期、数字或事件（“销售超过 20 人时”“价格涨到超出预算时”“明年 3 月 1 日复审”）。本技能的默认做法：每条记录都要有触发条件；只有决策确实永久不变时才能写“不会重新讨论”，并说明原因。
7. **设定状态和编号。** 提议中、已采纳或已被取代。按顺序编号，编号永不复用，和 Nygard 的格式一致。如果这条取代了旧决策，把旧的那条标为“已被 #[n] 取代”并保留；Nygard 的做法是保留被推翻的决策，“但标记为已被取代”。

## 输出格式

```markdown
## #[编号] — [简短的名词短语标题]

**状态：** [提议中 / 已采纳 / 已被 #n 取代] · **日期：** [日期] · **拍板人：** [一个人名]  
**征求意见：** [姓名] · **来源：** [消息串、会议纪要或文档的链接]

**决策：** 我们将[一句话]。

**背景：** [2–4 句事实。]

**考虑过的选项：**
- **[选项 A，已选]：** [主要取舍]
- **[选项 B]：** [主要取舍]
- **[维持现状]：** [主要取舍，如果考虑过]

**理由：**
- [与背景对应的理由]

**后果：**
- [好的和坏的影响，对谁有什么变化]

**在以下情况重新讨论：** [具体日期、数字或事件]
```

## 示例

**输入：** 钉钉群聊摘要：“好，2 月 3 日林芳（COO）最终拍板：用 Dealbook，不用 FunnelHQ。何静和赵磊都参与了讨论。按我们 6 个销售算，FunnelHQ 销售版的费用大约是 3 倍，而且我们现在还没用营销自动化。Dealbook 有我们需要的邮件同步。缺点是如果市场部以后要用 FunnelHQ，还得再迁移一次。表格已经撑不住了，上个月漏跟进了 2 次。日志上一条是 #11。”

**输出：**

```markdown
## #12 — 销售团队的 CRM

**状态：** 已采纳 · **日期：** 2月3日 · **拍板人：** 林芳（COO）  
**征求意见：** 何静、赵磊 · **来源：** 钉钉群聊，2月3日

**决策：** 我们将把销售团队从共享表格迁移到 Dealbook。

**背景：** 6 人的销售团队用表格跟踪商机，表格已经撑不住了。上个月漏跟进了 2 次。我们需要 CRM 能同步邮件。我们目前没有使用营销自动化。

**考虑过的选项：**
- **Dealbook，已选：** 有我们需要的邮件同步；没有营销自动化。
- **FunnelHQ 销售版：** 含营销自动化，按 6 个销售算，费用约为 Dealbook 的 3 倍。

**理由：**
- 它能替代已经撑不住的表格，并且有我们需要的邮件同步。
- 按 6 个销售算，FunnelHQ 销售版的费用约为 3 倍，而我们还没用营销自动化。

**后果：**
- 销售把进行中的商机迁到 Dealbook，不再使用表格。
- 如果市场部以后需要 FunnelHQ，CRM 数据要再迁移一次。

**在以下情况重新讨论：** 市场部想用 FunnelHQ，或开始使用营销自动化。
```

## 发送前检查

- [ ] 决策是一句主动语态、别人能照着执行的话。
- [ ] 只写了一个拍板人，或者写了“[拍板人未确认]”。
- [ ] 列出的每个选项都真的讨论过；没有为了显得周全而添加选项。
- [ ] 后果里至少有一条成本或缺点。
- [ ] 重新讨论的触发条件是具体的日期、数字或事件。
- [ ] 事实、人名、数字和日期都来自原始材料。

## 常见错误

- 把讨论当成决策记下来。如果没有有权限的人说“同意”，状态就是“提议中”。
- 决策变了就去改旧记录。应该新写一条，把旧的标为已被取代；保留历史才是意义所在。
- 背景部分在为选择辩护。支持这个选择的论证放在“理由”里。