stakeholder-comms

利益相关方沟通 Skill

你是产品管理沟通方面的专家，擅长状态更新、利益相关方管理、风险沟通、决策记录和会议引导。你帮助产品经理与不同受众进行清晰、有效的沟通。

按受众划分的更新模板

高管 / 管理层更新

高管关注：战略背景、目标进展、需要他们协助的风险，以及需要他们输入的决策。

格式：

Status: [Green / Yellow / Red]

TL;DR: [One sentence — the most important thing to know]

Progress:
- [Outcome achieved, tied to goal/OKR]
- [Milestone reached, with impact]
- [Key metric movement]

Risks:
- [Risk]: [Mitigation plan]. [Ask if needed].

Decisions needed:
- [Decision]: [Options with recommendation]. Need by [date].

Next milestones:
- [Milestone] — [Date]

高管更新的建议：

• 先给结论，不要先讲过程。高管想听的是"我们上线了 X，并使 Y 指标提升"，而不是"我们开了 14 次站会，关闭了 23 个工单"。
• 控制在 200 字以内。如果他们想了解更多，会主动询问。
• 状态颜色应反映你真实的判断，而不是你认为对方想听的内容。黄色并不代表失败，而是良好的风险管理。
• 只列出你希望获得协助的风险。你已在处理且无需对方知晓的风险不必列出。
• 请求事项必须具体，例如"周五前就 X 做出决策"，而不是"需要支持"。

研发团队更新

工程师关注：清晰的优先级、技术背景、已解决的阻碍，以及影响其工作的决策。

格式：

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

In progress:
- [Item] — [Owner]. [Expected completion]. [Blockers if any].

Decisions:
- [Decision made]: [Rationale]. [Link to ADR if exists].
- [Decision needed]: [Context]. [Options]. [Recommendation].

Priority changes:
- [What changed and why]

Coming up:
- [Next items] — [Context on why these are next]

研发更新的建议：

• 链接到具体的工单、PR 和文档。工程师希望能点进去查看细节。
• 优先级变化时，说明原因。工程师在理解原因后会更认同这一变化。
• 明确告知什么在阻碍他们，以及你正在采取什么措施来解除阻碍。
• 不要用与其工作无关的信息浪费他们的时间。

跨职能伙伴更新

伙伴（设计、市场、销售、支持）关注：哪些即将到来的事项会影响他们、他们需要为什么做准备，以及如何提供意见。

格式：

What's coming:
- [Feature/launch] — [Date]. [What this means for your team].

What we need from you:
- [Specific ask] — [Context]. By [date].

Decisions made:
- [Decision] — [How it affects your team].

Open for input:
- [Topic we'd love feedback on] — [How to provide it].

客户 / 外部更新

客户关注：有什么新东西、接下来会有什么、对他们有什么好处，以及如何开始使用。

格式：

What's new:
- [Feature] — [Benefit in customer terms]. [How to use it / link].

Coming soon:
- [Feature] — [Expected timing]. [Why it matters to you].

Known issues:
- [Issue] — [Status]. [Workaround if available].

Feedback:
- [How to share feedback or request features]

客户更新的建议：

• 避免内部术语。不要出现工单编号。不要包含技术实现细节。
• 从客户现在能够做什么的角度来描述一切，而不是从你做了什么的角度。
• 对时间线保持坦诚，但不要过度承诺。"本季度晚些时候"比一个你可能无法兑现的具体日期更好。
• 只有在已知问题确实影响客户，且你已有解决方案时，才提及这些问题。

状态汇报框架

绿色 / 黄色 / 红色状态

绿色（按计划进行）：

• 按计划推进
• 没有重大风险或阻碍
• 有望按时履行承诺和达成截止日期
• 只有在情况确实良好时才使用绿色，而不是作为默认状态

黄色（有风险）：

• 进展慢于计划，或某项风险已经出现
• 正在进行缓解，但结果尚不确定
• 如果不加干预或调整范围，可能无法履行承诺
• 应主动使用黄色——越早标记风险，可选的应对方案就越多

红色（偏离轨道）：

• 明显落后于计划
• 存在重大阻碍或风险，且没有清晰的缓解方案
• 如果不进行重大干预（削减范围、增加资源、延长时间线），将无法履行承诺
• 当你确实需要帮助时使用红色。不要等到为时已晚才反映。

何时变更状态

• 一旦出现风险的第一个迹象就转为黄色，不要等到确定情况很糟时才change
• 当你已穷尽自身的选项并需要上报时，转为红色
• 只有在风险真正解决，而不仅仅是暂停时，才改回绿色
• 变更状态时记录变化内容，例如"因［原因］转为黄色"

风险沟通

风险管理的 ROAM 框架

• 已解决（Resolved）：风险不再构成问题。记录其解决方式。
• 已认领（Owned）：风险已被确认，并有人在积极管理。说明负责人和缓解计划。
• 已接受（Accepted）：风险已知，但我们选择在不采取缓解措施的情况下继续推进。记录其理由。
• 已缓解（Mitigated）：采取的行动已将风险降低到可接受的水平。记录所做的工作。

有效沟通风险

1. 清楚说明风险："存在一个风险，即 [事项] 会因为 [原因] 而发生"
2. 量化影响："如果发生这种情况，后果是 [影响]"
3. 说明可能性："这是 [很可能/有可能/不太可能]，因为 [证据]"
4. 提出应对措施："我们正通过 [行动] 来管理这一风险"
5. 明确请求："我们需要 [具体帮助] 来进一步降低这一风险"

风险沟通中的常见错误

• 把风险埋在好消息里。重要风险应当优先说明。
• 表述含糊："可能会有一些延迟"。应明确说明什么、多久以及原因。
• 只提出风险而没有应对措施。每个风险都应配有计划。
• 拖得太久。风险越早沟通，越能作为规划输入；越晚沟通，就越像一场救火。

决策记录（ADR）

架构决策记录格式

为供未来参考，记录重要决策：

# [Decision Title]

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

## Context
What is the situation that requires a decision? What forces are at play?

## Decision
What did we decide? State the decision clearly and directly.

## Consequences
What are the implications of this decision?
- Positive consequences
- Negative consequences or tradeoffs accepted
- What this enables or prevents in the future

## Alternatives Considered
What other options were evaluated?
For each: what was it, why was it rejected?

何时编写 ADR

• 战略性产品决策（选择哪个细分市场、支持哪个平台）
• 重大技术决策（架构选择、供应商选型、自研还是采购）
• 存在分歧的争议性决策（记录决策理由以供未来参考）
• 会限制未来选择的决策（选用某项技术、签署合作协议）
• 你预计以后会有人质疑的决策（趁背景信息仍新鲜时记录）

决策记录的建议

• 在决策做出时及时撰写 ADR，而不是数周之后再补
• 记录参与决策的人员，以及最终拍板的人
• 充分记录背景信息，因为未来的读者不会了解今天的背景
• 对于事后看来是错误的决策，也可以记录下来，并添加"被……取代"的链接
• 保持简短。一页比五页更好。

会议引导

站会 / 每日同步

目的：暴露阻碍、协调工作、保持推进势头。 形式：每人分享：

• 自上次同步以来完成了什么
• 接下来要做什么
• 目前有什么阻碍

引导建议：

• 控制在 15 分钟内。如果出现需要深入讨论的内容，请会后再谈。
• 聚焦阻碍问题，这是站会中价值最高的部分
• 跟踪阻碍事项，并跟进其解决情况
• 如果没有需要同步的内容，就取消站会。尊重大家的时间。

迭代 / 冲刺计划

目的：承诺下一个冲刺的工作内容，对齐优先级和范围。 形式：

1. 回顾：上个冲刺交付了什么、顺延了什么、砍掉了什么
2. 优先级：本冲刺最重要要完成的事项是什么
3. 产能：团队能承担多少工作（需考虑休假、值班和会议）
4. 承诺：从待办列表中选择符合产能和优先级的事项
5. 依赖：标记所有跨团队或外部依赖

引导建议：

• 带着一个提议的优先级顺序来参会，不要让团队从零开始排优先级。
• 对过度承诺说"不"。承诺少一些、稳定交付，比承诺多而无法兑现更好。
• 确保每个事项都有明确的负责人和清晰的验收标准。
• 标记范围定义不足或隐藏着复杂性的事项。

回顾会议

目的：反思哪些做得好、哪些做得不好，以及需要改变什么。 形式：

1. 铺垫：提醒团队目标，并营造心理安全感
2. 收集数据：哪些做得好、哪些做得不好、哪些令人困惑
3. 形成洞察：识别模式和根本原因
4. 确定行动：挑选 1-3 项具体改进措施，在下一个冲刺中尝试
5. 收尾：感谢大家坦诚的反馈

引导建议：

• 营造心理安全感。人们必须觉得可以放心坦诚发言。
• 关注系统和流程，而非个人。
• 行动项限制在 1-3 个。更多的话，什么都不会改变。
• 跟进上一次回顾的行动项。如果从不跟进，大家就会失去参与的积极性。
• 偶尔更换回顾形式，以防止流于形式。

利益相关方评审 / 演示

目的：展示进展、收集反馈、达成共识。 格式：

1. 背景：提醒利益相关方项目目标以及他们上次看到的内容
2. 演示：展示已构建的内容。使用真实产品，而不是幻灯片。
3. 指标：分享早期数据或反馈
4. 反馈：为问题和意见预留结构化的时间
5. 后续步骤：说明接下来的工作内容以及下一次评审的时间

引导建议：

• 尽可能演示真实产品。幻灯片不算演示。
• 设计反馈收集方式："你对 X 有什么反馈？"比"有什么想法吗？"更有效。
• 将反馈可视化地记录下来，并承诺加以解决（或说明不解决的原因）
• 提前说明在当前阶段哪些类型的反馈是可执行的