stakeholder-update

干系人更新

如果您看到不熟悉的占位符，或需要确认哪些工具已连接，请参阅 CONNECTORS.md。

根据受众和更新节奏生成干系人更新。

用法

/stakeholder-update $ARGUMENTS

工作流程

1. 确定更新类型

询问用户需要哪种更新：

• 每周：关于进展、阻碍和后续步骤的常规节奏更新
• 每月：包含趋势、里程碑和战略对齐的高层摘要
• 发布：关于功能或产品发布的公告，包括细节和影响
• 临时：针对特定情况的一次性更新（升级、转向或重大决策）

2. 确定受众

询问更新面向的对象：

• 高管 / 领导层：高层级、以结果为导向、战略性框架、简明扼要
• 工程团队：技术细节、实现背景、阻碍，以及需要做出的决策
• 跨职能合作伙伴：适度的背景细节，聚焦共同目标和依赖关系
• 客户 / 外部人员：以益处为重点、时间线清晰、不使用内部术语
• 董事会：以指标为驱动、战略性、关注风险、非常简洁

3. 从已连接的工具中获取背景信息

如果已连接 ~~项目跟踪工具：

• 拉取路线图条目和里程碑的状态
• 找出自上次更新以来已完成的条目
• 标出有风险或被阻塞的条目
• 拉取 Sprint 或迭代进度

如果已连接 ~~聊天工具：

• 搜索相关的团队讨论和决策
• 查找频道中提出的阻碍或问题
• 找出异步做出的关键决策

如果已连接 ~~会议转录工具：

• 拉取近期会议纪要和讨论摘要
• 从相关会议中找出决策和行动项

如果已连接 ~~知识库：

• 搜索近期会议纪要
• 查找决策文档或设计评审记录

如果未连接任何工具，请用户提供：

• 自上次更新以来完成了哪些工作
• 当前的阻碍或风险
• 已做出或需要做出的关键决策
• 接下来的计划

4. 生成更新内容

使用下方的模板和框架，针对目标受众组织更新内容。

面向高管：TL;DR、状态颜色（G/Y/R）、与目标相关的关键进展、已做出的决策、带缓解措施的风险、具体请求，以及下一个里程碑。控制在 300 字以内。

面向工程团队：已交付内容（附链接）、进行中的工作（附负责人）、阻碍、需要做出的决策（附选项和建议），以及接下来的计划。

面向跨职能合作伙伴：即将到来且会影响他们的事项、需要他们提供的支持（附截止日期）、影响其团队的决策，以及可供征求意见的领域。

面向客户：新增内容（以益处的方式呈现）、即将推出的内容、已知问题及变通方法，以及如何提供反馈。不使用内部术语。

发布公告：已发布的内容、其重要性、关键细节（范围、可用性、限制）、成功指标、推广计划，以及反馈渠道。

5. 审核与交付

生成更新内容后：

• 询问用户是否需要调整语气、详细程度或重点
• 主动提出按交付渠道（电子邮件、聊天消息、文档、幻灯片）进行格式化
• 如果已连接 ~~聊天工具，主动提出起草消息以便发送

按受众划分的更新模板

管理层 / 领导层更新

管理层关心：战略背景、目标进展、需要他们协助的风险、需要他们输入的决策。

格式：

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]

客户更新建议：

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

状态汇报框架

绿色 / 黄色 / 红色状态

绿色（按计划进行）：

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

黄色（存在风险）：

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

红色（偏离轨道）：

• 明显落后于计划
• 存在重大阻塞项或风险，且没有明确的缓解措施
• 如果没有重大介入（削减范围、增加资源、延长时间线），将无法兑现承诺
• 当你确实需要帮助时使用红色，不要等到为时已晚。

何时更改状态

• 一旦出现风险的第一个迹象就转为黄色，不必等到确定情况很糟糕
• 当你已用尽自身所有办法且需要上报时转为红色
• 只有在风险真正解决、而非仅仅暂停时，才可恢复为绿色
• 更改状态时记录变化内容——“因 [原因] 转为黄色”

风险沟通

风险管理的 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 有什么反馈？"比"有什么想法吗？"更好。
• 将反馈清晰记录下来，并承诺落实（或说明无法落实的原因）
• 提前说明当前阶段哪些类型的反馈是可执行的

输出格式

保持更新内容便于快速浏览。关键点使用加粗，列表使用项目符号。面向管理层的更新应少于 300 字。工程类更新可以更长，但仍应结构清晰，便于快速浏览。

提示

• 干系人更新中最常见的错误是把重点埋在后面。应从最重要的内容开始。
• 状态颜色（绿/黄/红）应反映实际情况，而非盲目乐观。黄色并不代表失败，而是良好的风险沟通。
• 请求应具体且可执行。"我们需要帮助"不是一个请求。"我们需要在周五前就 X 做出决定"才是。
• 面向高管时，应以成果和目标而非活动和任务来表述一切。
• 如果有坏消息，应率先说明，不要把它藏在好消息后面。
• 内容长度应与受众的注意力相匹配。高管只需要几个要点，工程团队则需要他们所需的细节。