status-updates

面向不同受众的更新格式

领导层／高管更新

领导者需要：战略背景、与目标对应的进展、需要他们介入的风险，以及等待他们提供意见的决策。

模板：

Status: [Green / Yellow / Red]

Summary: [Single sentence — the one thing they must know]

Progress:
- [Outcome delivered, linked to OKR or strategic goal]
- [Milestone completed, with business impact noted]
- [Key metric shift]

Risks:
- [Risk statement]: [Mitigation underway]. [Specific ask if applicable].

Decisions required:
- [Decision topic]: [Options with a recommendation]. Needed by [date].

Upcoming milestones:
- [Milestone] — [Target date]

指南：

• 开门见山给出结论，而不是描述过程。领导者想知道的是“我们发布了 X，指标 Y 因此提升”，而不是会议和工单列表。
• 控制在 200 字以内。如果他们需要更多信息，会主动询问。
• 状态颜色应反映你真实的判断。黄色表示你具备健康的风险意识，并非失败。
• 只提出需要帮助的风险。除非领导层需要了解，否则省略你正在解决的风险。
• 请求必须明确具体：“请在周四前批准供应商选择”，而不是“需要达成一致”。

工程团队更新

工程师需要：清晰的优先级、技术背景、阻碍问题的解决方案，以及了解会影响其工作的决策。

模板：

Shipped:
- [Feature or fix] — [Link to PR/ticket]. [Impact note if relevant].

In flight:
- [Work item] — [Owner]. [Expected delivery]. [Blockers if any].

Decisions:
- [Decided]: [Rationale]. [Link to ADR if available].
- [Pending]: [Background]. [Options]. [Recommended path].

Priority shifts:
- [What moved and the reason behind it]

On deck:
- [Upcoming items] — [Why these are sequenced next]

指南：

• 提供工单、拉取请求和文档的链接。工程师希望深入了解具体内容。
• 优先级发生变化时，说明原因。理解缘由后，工程师会更投入。
• 指出阻碍他们推进的问题，并说明你的解决计划。
• 省略与他们工作无关的信息。

跨职能合作伙伴更新

设计、营销、销售和支持等团队的合作伙伴需要：提前获知影响其团队的变化、了解需要做哪些准备，以及提供意见的渠道。

模板：

Upcoming:
- [Feature or launch] — [Date]. [Implications for your team].

Action items for your team:
- [Specific request] — [Context]. Needed by [date].

Decisions finalized:
- [Decision] — [How it impacts your workflow].

Open for feedback:
- [Topic where input is welcome] — [How to submit it].

对外／面向客户的更新

客户需要：了解有哪些新内容、接下来会推出什么、能为他们带来什么好处，以及如何加以利用。

模板：

What's new:
- [Capability] — [Benefit stated in customer language]. [Link or instructions].

On the roadmap:
- [Capability] — [Approximate timing]. [Why it matters to you].

Known issues:
- [Issue] — [Current status]. [Workaround if one exists].

Share your feedback:
- [Channel or method for submitting feature requests and feedback]

指南：

• 去除内部术语。不提工单 ID，不提架构。
• 围绕客户现在能够实现什么来展开，而不是介绍团队构建了什么。
• 如实说明时间安排，但不要过度承诺。“本季度稍后”比一个可能无法兑现的日期更合适。
• 只有当已知问题对客户可见，且同时提供了解决方案时，才将其纳入。

红黄绿状态框架

定义

绿色（按计划进行）：

• 工作正按计划推进
• 没有重大风险或障碍
• 承诺和截止日期均可兑现
• 只有在进展确实顺利时才使用绿色，不要默认使用

黄色（存在风险）：

• 进展放缓，或风险已经显现
• 正在采取缓解措施，但结果仍不确定
• 如果不介入或调整范围，承诺可能无法兑现
• 尽早标记黄色——风险越早显现，可选方案就越多

红色（偏离计划）：

• 进度严重落后
• 存在重大障碍，且没有明确的解决方案
• 如果不进行大幅干预（缩减范围、增加资源或延长时间），承诺将无法兑现
• 当你已用尽自身可用方案且需要外部帮助时，将状态升级为红色

状态转换规则

• 一出现风险迹象就转为黄色，不要等到确定事情已经出问题
• 用尽所有可用手段且需要升级处理时，转为红色
• 只有在根本风险确实解决后才恢复为绿色，不能仅因风险暂时搁置就恢复
• 更改状态时始终记录原因：“因［说明］，状态转为黄色”

有效沟通风险

ROAM 分类

• 已解决：风险已不再存在。记录风险是如何消除的。
• 已认领：团队已意识到风险，且有人正在积极管理。注明负责人和缓解方案。
• 已接受：团队承认风险，但选择不采取积极缓解措施而继续推进。记录这样决定的理由。
• 已缓解：已采取措施，将风险降低到可接受的程度。记录具体措施。

五步风险沟通模式

1. 直截了当地说明：“由于 [原因]，存在 [事件] 发生的风险”
2. 说明影响程度：“如果这一情况发生，后果是 [具体影响]”
3. 估计发生概率：“由于 [证据]，这种情况 [很可能 / 可能 / 不太可能] 发生”
4. 说明应对措施：“我们正通过 [已采取或计划采取的措施] 应对这一问题”
5. 说明所需支持：“要进一步降低这一风险，我们需要 [具体支持或决策]”

应避免的陷阱

• 将风险埋在积极进展中。风险重大时，应先说明风险。
• 含糊其辞：“可能会有一些延迟”——始终明确说明哪些事项可能延迟、延迟多久，以及原因。
• 只提出风险，却不附带行动计划。每项风险都应包含缓解措施或支持请求。
• 延迟披露。及早提出的风险是规划依据；太晚提出的风险则会演变为危机。

决策记录

轻量级 ADR 结构

记录重要决策，以便留存组织记忆：

# [Decision Title]

## Status

[Proposed / Accepted / Deprecated / Superseded by ADR-XXX]

## Situation

What circumstances necessitate this decision? What constraints and pressures exist?

## Resolution

What was decided? State the choice clearly and unambiguously.

## Tradeoffs

What follows from this decision?
- Benefits gained
- Downsides or compromises accepted
- Future possibilities opened or closed

## Options Evaluated

What alternatives were considered?
For each: a brief description and the reason it was not chosen.

何时创建决策记录

• 战略性产品选择（目标市场、平台支持、定价模式）
• 重大技术决策（架构方向、供应商选择、自建还是采购）
• 团队存在分歧的争议性决策（留存决策理由，以供日后参考）
• 会限制未来灵活性的决策（技术锁定、合作承诺）
• 预计日后会受到质疑的决策（趁背景信息仍记忆犹新时记录下来）

实用建议

• 在决策作出后尽快记录，而不是等几周再写
• 记录参与者，以及最终决策权归属
• 充分记录相关背景——未来的读者无法像今天的你一样了解当下情况
• 事后证明有误的记录仍然有价值；添加“已被以下决策取代”的引用
• 简洁有益。一页胜过五页。

会议引导模式

每日同步 / 站会

目标：发现阻碍、同步工作、保持推进势头。

每位参与者分享：

• 上次同步后完成的工作
• 当前关注重点
• 任何阻碍进展的问题

高效开展方式：

• 控制在 15 分钟以内。较长的讨论留待后续跟进。
• 优先处理阻碍——它们是任何站会中最具杠杆效应的事项
• 明确跟踪阻碍，并持续跟进直至解决
• 如果没有需要同步的内容，就取消会议。珍惜大家的时间。

迭代 / Sprint 规划

目标：就即将到来的周期内的工作达成一致，并对范围和优先级形成共识。

议程：

1. 简要回顾：已交付的内容、遗留的内容、已取消范围的内容
2. 声明优先级：即将到来的 Sprint 中最重要的成果
3. 评估产能：现实估算可投入时间，并考虑休假、值班职责和会议
4. 选择承诺事项：从待办列表中挑选符合产能和优先级的事项
5. 梳理依赖关系：标记任何需要跨团队或外部协调的事项

高效开展方式：

• 提前准备好建议的优先级排序。不要让团队从零开始排序。
• 避免过度承诺。可靠地交付较少内容，比一再错过目标更能建立信任。
• 每项入选事项都需要明确的负责人和清晰无歧义的验收标准。
• 提出那些存在隐藏复杂性或范围界定不足的事项。

回顾

目标：坦诚反思哪些做得好、哪些做得不好，以及团队将做出哪些改变。

流程：

1. 设定对话基调：回顾冲刺目标，营造心理安全感
2. 收集观察：哪些进展顺利、哪些未达预期、哪些方面造成了困惑
3. 找出规律：发现反复出现的主题和根本原因
4. 选定改进措施：承诺在下一个周期落实 1-3 项具体改变
5. 结束：肯定团队的坦诚

如何顺利开展：

• 心理安全感不可妥协。每个人都必须能够安心地坦诚发言。
• 将关注点放在系统和流程上，绝不针对个人。
• 行动项最多设为 1-3 项。再多就无法落实。
• 回顾上次回顾会的行动项。如果始终没有后续跟进，参与度就会下降。
• 定期轮换回顾会的形式，保持新鲜感。

利益相关者演示 / 评审

目标：展示进展、征求反馈并强化共识。

流程：

1. 交代背景：提醒利益相关者目标是什么，以及他们之前看过哪些内容
2. 现场演示：展示可运行的产品，而不是幻灯片
3. 分享数据：展示早期指标或用户反馈
4. 结构化反馈：引导问题聚焦于具体主题
5. 展望后续：预告接下来的安排，以及下次评审的时间

如何顺利开展：

• 尽可能始终演示真实产品。幻灯片无法替代产品演示。
• 精准提出反馈请求：“你对 X 有什么看法？”比“有什么想法？”效果更好。
• 清晰记录反馈，并承诺处理每一项，或解释为何不会处理
• 说明当前阶段哪些类型的反馈具有可操作性