利益相关者更新
如果您看到不熟悉的占位符或需要检查已连接了哪些工具，请参阅 CONNECTORS.md。
生成针对特定受众和节奏定制的利益相关者更新。
用法
/stakeholder-update $ARGUMENTS
工作流程
1. 确定更新类型
询问用户需要什么类型的更新：
- 周报：关于进展、阻碍和下一步的常规节奏更新
- 月报：更高级别的摘要，包含趋势、里程碑和战略对齐情况
- 发布公告：功能或产品发布的公告，包含详情和影响
- 临时报告：针对特定情况的一次性更新（升级上报、方向转变、重大决策）
2. 确定受众
询问更新面向谁：
- 高管/领导层：高层级、关注结果、战略框架、简洁
- 工程团队：技术细节、实现背景、阻碍因素、需要决策的事项
- 跨职能合作伙伴：符合上下文的详细程度，重点关注共同目标和依赖关系
- 客户/外部人员：关注收益、清晰的时间线、不使用内部术语
- 董事会：指标驱动、战略性、关注风险、非常简洁
3. 从已连接工具中提取上下文
如果 ~~项目跟踪器 已连接：
- 提取路线图项目和里程碑的状态
- 识别自上次更新以来已完成的项目
- 找出有风险或受阻的项目
- 提取冲刺或迭代的进展
如果 ~~聊天 已连接：
- 搜索相关的团队讨论和决策
- 查找在渠道中提出的阻碍或问题
- 识别异步进行的关键决策
如果 ~~会议转录 已连接：
- 提取近期的会议记录和讨论摘要
- 查找相关会议的决策和行动项
如果 ~~知识库 已连接：
如果没有连接任何工具，请用户提供：
- 自上次更新以来完成了什么
- 当前的阻碍或风险
- 已做出或需要做出的关键决策
- 接下来的计划
4. 生成更新
使用下面的模板和框架为目标受众构建更新内容。
针对高管：要旨、状态颜色（绿/黄/红）、与目标相关的关键进展、已做决策、带缓解措施的风险、具体的请求事项、下一个里程碑。控制在
300 字以内。
针对工程团队：已交付内容（附链接）、进行中内容（附负责人）、阻碍因素、需要决策的事项（附选项和建议）、接下来的工作。
针对跨职能合作伙伴：即将到来的影响他们的内容、你需要他们提供什么（附截止日期）、影响他们团队的决策、欢迎提供意见的领域。
针对客户：新功能（以收益角度陈述）、即将推出的功能、已知问题及临时解决方案、如何提供反馈。不使用内部术语。
针对发布公告：发布了什么、为什么重要、关键细节（范围、可用性、限制）、成功指标、发布计划、反馈渠道。
5. 审查和交付
生成更新后：
- 询问用户是否想调整语气、详细程度或重点
- 提供为交付渠道格式化的选项（邮件、聊天消息、文档、幻灯片）
- 如果 ~~聊天 已连接，提供起草待发送消息的选项
按受众分类的更新模板
高管/领导层更新
高管想知道：战略背景、目标进展情况、需要他们帮助的风险、需要他们意见的决策。
格式：
状态：[绿色 / 黄色 / 红色]
要旨：[一句话——最重要的信息]
进展：
- [已实现的成果，关联目标/OKR]
- [已达成的里程碑及其影响]
- [关键指标变化]
风险：
- [风险]：[缓解计划]。[如有需要请说明请求事项]。
需要决策：
- [决策事项]：[选项及建议]。需在[日期]前确定。
下一个里程碑：
- [里程碑] — [日期]
高管更新提示：
- 先说结论，而不是过程。高管想知道"我们交付了 X，它推动了 Y
指标的变化"，而不是"我们开了 14 次站会，解决了 23 个工单。"
- 控制在 200 字以内。如果他们想要更多，他们会问。
- 状态颜色应反映你真实的评估，而不是你认为他们想听到的内容。黄色不是失败——这是良好的风险管理。
- 只包含你需要帮助的风险。不要列出你已经在处理的风险，除非他们需要知道。
- 请求必须具体："周五前就 X 做出决定"而不是"需要支持"。
工程团队更新
工程师想知道：清晰的优先级、技术背景、解决阻碍因素、影响他们工作的决策。
格式：
已交付：
- [功能/修复] — [PR/工单链接]。[如有显著影响请说明]。
进行中：
- [任务] — [负责人]。[预计完成时间]。[如受阻请说明]。
决策：
- [已做决策]：[理由]。[如有 ADR 链接请附上]。
- [需要决策]：[背景]。[选项]。[建议]。
优先级变更：
- [什么变了以及为什么]
即将开始：
- [下个任务] — [说明为什么这些是接下来要做的]
工程更新提示：
- 链接到具体的工单、PR 和文档。工程师想点击进去看详情。
- 当优先级变化时，解释原因。当工程师理解原因时，他们会更有认同感。
- 明确说明什么在阻碍他们以及你正在做什么来解除阻碍。
- 不要用不影响他们工作的信息浪费他们的时间。
跨职能合作伙伴更新
合作伙伴（设计、营销、销售、支持）想知道：即将发生的事情如何影响他们、他们需要准备什么、如何提供意见。
格式：
即将到来：
- [功能/发布] — [日期]。[这对你的团队意味着什么]。
我们需要你做什么：
- [具体请求] — [背景]。请在[日期]前完成。
已做决策：
- [决策] — [对你的团队的影响]。
欢迎提供意见：
- [我们期待收到反馈的主题] — [如何提供反馈]。
客户/外部更新
客户想知道：什么是新的、什么即将推出、对他们有什么好处、如何开始使用。
格式：
新功能：
- [功能] — [以客户语言表达的收益]。[如何使用/链接]。
即将推出：
- [功能] — [预期时间]。[为什么对你重要]。
已知问题：
- [问题] — [状态]。[如有临时解决方案请提供]。
反馈：
- [如何分享反馈或请求功能]
客户更新提示：
- 不使用内部术语。没有工单编号。没有技术实现细节。
- 一切从客户现在可以做什么的角度来陈述，而不是你构建了什么。
- 诚实地对待时间线，但不要过度承诺。"本季度晚些时候"比一个你可能达不成的日期要好。
- 仅在已知问题影响客户并且你有解决方案计划时才提及。
状态报告框架
绿色 / 黄色 / 红色状态
绿色（正常）：
- 按计划推进
- 无重大风险或阻碍
- 有望达成承诺和截止日期
- 在事情确实进展顺利时使用绿色——而不是作为默认设置
黄色（有风险）：
- 进展慢于计划，或风险已出现
- 缓解措施正在进行中但结果不确定
- 如果没有干预或范围调整，可能会错过承诺
- 主动使用黄色——越早标记风险，你的选择就越多
红色（偏离轨道）：
- 显著落后于计划
- 重大阻碍或风险，无明确缓解措施
- 如果没有重大干预（削减范围、增加资源、延长时限），将无法达成承诺
- 在确实需要帮助时使用红色。不要等到为时已晚。
何时更改状态
- 在风险出现的第一时间就变为黄色，而不是在确定情况不好时
- 在已经用尽自身选项需要升级上报时变为红色
- 仅在风险真正得到解决时回到绿色，而不是仅仅暂停
- 更改状态时记录变化原因——"因[原因]变为黄色"
风险沟通
ROAM 风险管理框架
- 已解决：风险不再是问题。记录解决方式。
- 已负责：风险已确认，有人在积极管理。说明负责人和缓解计划。
- 已接受：风险已知，但我们选择继续推进而不采取缓解措施。记录理由。
- 已缓解：已采取措施将风险降低到可接受水平。记录了已做的工作。
有效沟通风险
- 清晰陈述风险："存在[某事]发生的风险，因为[原因]"
- 量化影响："如果发生，后果是[影响]"
- 说明可能性："这[很可能/有可能/不太可能]，因为[证据]"
- 提出缓解措施："我们正在通过[行动]来管理"
- 提出请求："我们需要[具体帮助]来进一步降低此风险"
风险沟通的常见错误
- 将风险埋没在好消息中。当风险重要时，优先提及风险。
- 模糊不清："可能会有一些延迟"——明确说明什么、多久以及为什么。
- 提出风险时不带缓解措施。每个风险都应该附带一个计划。
- 等待太久。及早沟通的风险是规划输入。延迟沟通的风险是救火。
决策文档化（ADR）
架构决策记录格式
记录重要决策以供将来参考：
# [决策标题]
## 状态
[已提议 / 已接受 / 已废弃 / 已被 ADR-XXX 取代]
## 背景
什么情况需要做出决策？有哪些力量在起作用？
## 决策
我们决定了什么？清晰直接地陈述决策。
## 后果
此决策的影响是什么？
- 积极影响
- 消极影响或已接受的权衡
- 这会在未来开启或阻止什么
## 考虑的替代方案
评估了哪些其他选项？
每个选项：是什么，为什么被拒绝？
何时编写 ADR
- 战略产品决策（针对哪个市场细分、支持哪个平台）
- 重大技术决策（架构选择、供应商选择、自建 vs 购买）
- 有争议的决策（记录理由供将来参考）
- 会限制未来选择的决策（选择技术、签订合作伙伴关系）
- 预期将来会被质疑的决策（趁背景还新鲜时记录下来）
决策文档化提示
- 在决策做出时编写 ADR，而不是数周后
- 包括谁参与了决策以及谁做了最终决定
- 慷慨地记录背景——未来的读者不会有今天的背景信息
- 记录事后看来是错误的决策是可以的——添加"已被取代"的链接
- 保持简短。一页比五页好。
会议引导
站会/每日同步
目的：发现阻碍因素、协调工作、保持动量。
格式：每个人分享：
- 自上次同步以来完成了什么
- 接下来要做什么
- 什么在阻碍他们
引导提示：
- 控制在 15 分钟内。如果有讨论浮现，线下进行。
- 聚焦阻碍因素——这是站会最有价值的部分
- 跟踪阻碍因素并跟进解决方案
- 如果没有需要同步的内容，取消站会。尊重大家的时间。
冲刺/迭代规划
目的：承诺下一个冲刺的工作。对齐优先级和范围。
格式：
- 回顾：上冲刺交付了什么、什么结转了、什么被砍掉了
- 优先级：本冲刺最重要的事情是什么
- 容量：团队能承担多少（考虑带薪休假、值班、会议）
- 承诺：从积压中选择符合容量和优先级的任务
- 依赖关系：标记任何跨团队或外部依赖
引导提示：
- 带着建议的优先级顺序来。不要要求团队从零开始排序。
- 对过度承诺说"不"。承诺更少并可靠交付更好。
- 确保每个任务都有明确的负责人和明确的验收标准。
- 标记范围界定不清或隐藏了复杂性的任务。
回顾会议
目的：反思什么做得好、什么不好、以及需要改变什么。
格式：
- 设定基调：提醒团队目标并营造心理安全感
- 收集数据：什么做得好、什么不好、什么令人困惑
- 生成洞察：识别模式和根本原因
- 决定行动：挑选 1-3 个在下个冲刺尝试的具体改进
- 结束：感谢大家的诚实反馈
引导提示：
- 营造心理安全感。人们必须感到安全才能诚实。
- 聚焦于系统和流程，而不是个人。
- 限制在 1-3 个行动项。超过这个数量，什么都不会改变。
- 跟进上期回顾的行动项。如果你从不跟进，人们就不再参与。
- 偶尔变换回顾形式以防止僵化。
利益相关者评审/演示
目的：展示进展、收集反馈、建立一致性。
格式：
- 背景：提醒利益相关者目标和上次展示的内容
- 演示：展示已构建的内容。使用真实产品，而不是幻灯片。
- 指标：分享任何早期数据或反馈
- 反馈：留出结构化时间进行提问和输入
- 后续：接下来是什么以及下次评审的时间
引导提示：
- 尽可能演示真实产品。幻灯片不是演示。
- 框架化反馈收集："你对 X 有什么反馈？"比"有什么想法吗？"更好
- 可视化地记录反馈并承诺解决（或解释为什么不解决）
- 设定在当前阶段哪些反馈是可操作的预期
输出格式
保持更新易于快速浏览。关键点用粗体，列表用项目符号。高管更新应在 300
字以内。工程更新可以更长，但仍应为快速浏览而结构化。
提示
- 利益相关者更新最常见的错误是埋没重点。从最重要的事情开始。
- 状态颜色（绿/黄/红）应反映现实，而不是乐观。黄色不是失败——这是良好的风险沟通。
- 请求应具体且可操作。"我们需要帮助"不是请求。"我们需要在周五前就 X
做出决定"才是。
- 对高管来说，一切从成果和目标的角度来陈述，而不是活动和任务。
- 如果有坏消息，开门见山。不要把它藏在好消息后面。
- 更新长度与受众的注意力相匹配。高管得到几个要点。工程团队得到他们需要的细节。