stakeholder-communication

干系人沟通

在正确的时间，以便于采取行动的形式，将正确的信息传达给正确的人。与技术栈无关。适用于任何需要与跨职能干系人协作的团队。

---

适用场景

• 撰写每周或每月状态更新
• 准备高管评审或董事会更新
• 向非技术受众分享技术决策
• 沟通延期、未达目标或质量问题
• 请求帮助、资源或决策
• 向上管理，与经理或项目赞助人沟通
• 为项目设计沟通节奏
• 起草内部公告

不适用场景

• 面向客户的沟通（使用营销／支持技能）
• 公开沟通或新闻稿（框架不同，影响也不同）
• 正在发生的事件中的沟通（使用 incident-response）
• 非时效性的内部文档（使用 documentation-strategy）
• 特定交付形式（幻灯片设计、邮件语气）——本技能关注内容和结构

---

必需输入

• 受众（具体是谁、他们的背景是什么、他们关心什么）
• 目的（告知、决策、升级、请求、庆祝）
• 实情（实际发生了什么）
• 媒介（邮件、文档、会议、幻灯片、聊天）
• 时间限制（他们何时需要这些信息）

---

框架：5 个问题

进行任何干系人沟通之前，先回答：

问题 1：受众是谁？

说具体些。“领导层”太笼统。CFO 和工程副总裁关心的事情各不相同。

针对每位明确的受众：

• 他们关心什么？（收入、风险、质量、速度、成本、客户）
• 他们已经了解什么？（可以省略的背景信息）
• 他们能接受多详细的信息？（高管想看要点；IC 想看细节）
• 你希望他们采取什么行动？（确认、决策、提供帮助、不采取行动）

问题 2：核心结论是什么？

如果他们只读一句话，你希望他们记住什么？

核心结论要放在最前面。始终如此。叙述用于支撑结论；数据用于证实结论。

这是大多数干系人沟通中最大的问题：人们从背景开始，一步步铺垫到结论。干系人想先知道结论。

问题 3：这意味着什么？

干系人会在心里追问“然后呢？”。要明确回答。

• “我们完成了里程碑的 80%。”→ 这意味着什么？
• “我们完成了里程碑的 80%，这会让上线时间比计划晚一周。”→ 这就是它的意义。

说明其影响，才能让信息变得可执行。

问题 4：你希望对方做什么？

沟通通常包含以下一种诉求：

• 告知： 无需采取行动，只是让他们了解情况。
• 决策： 需要做出决策；列出选项并给出建议。
• 升级： 遇到了阻碍；需要帮助。
• 请求： 提出具体请求（资源、引荐、审核）。
• 庆祝： 分享一项成果；无需采取行动，但士气很重要。

明确说明诉求。不要把请求藏起来。

问题 5：采用什么形式？

• 异步书面沟通（文档、邮件）：内容丰富、便于追溯决策、方便查阅
• 同步书面沟通（聊天、工单评论）：快速交流、对话式沟通
• 同步口头沟通（会议、电话）：交流细节、辩论、达成共识
• 混合形式（文档 + 会议）：提前阅读文档；在会议上做决策

大多数更新都适合异步书面沟通。把同步时间留给真正的讨论。

---

结构：倒金字塔

干系人沟通应像新闻报道，而不是议论文。

Headline (one sentence)

The "so what" and the request (one paragraph)

Status / progress (the body)

Risks and asks (what we need)

Detail / appendix (what curious readers want)

从底部开始删减。如果更新内容被缩短，顶部的信息也会保留下来。

---

更新模板

每周项目更新

**Project:** [Name]
**Status:** [On track / At risk / Off track]
**Headline:** [One-sentence summary]

**This week:**
- [Specific accomplishment]
- [Specific accomplishment]
- [Specific accomplishment]

**Next week:**
- [Specific plan]
- [Specific plan]

**Risks / blockers:**
- [Risk + what we're doing about it / what we need]

**Metrics:**
- [Metric: value vs target]
- [Metric: value vs target]

状态标记（进展顺利／存在风险／进展偏离计划）必不可少。干系人会快速浏览并寻找它。

高管评审

**Headline:** [The summary, one sentence]

**Key points:**
1. [Point with one supporting sentence]
2. [Point with one supporting sentence]
3. [Point with one supporting sentence]

**Decisions needed:**
- [Decision A: options and recommendation]
- [Decision B: options and recommendation]

**Asks:**
- [Specific request]

**Detail:** [Linked doc or appendix]

高管会快速浏览；感兴趣时才会深入查看细节。

坏消息

最难写好的一类更新。

**Headline:** [The bad news, plainly stated]

**What happened:**
[Specific facts, no euphemisms]

**Impact:**
[Who's affected, how much, by when]

**What we're doing:**
[Specific actions and owners]

**What we need:**
[Specific asks, if any]

**Timeline:**
[When the next update will land]

不要弱化核心结论。面对坏消息，含糊其辞比坏消息本身更快地损害信任。

决策请求

**Decision:** [What needs to be decided]

**Context:** [The minimum needed to understand]

**Options:**
1. [Option A: description, pros, cons]
2. [Option B: description, pros, cons]
3. [Option C: description, pros, cons]

**Recommendation:** [Option X, because...]

**Need by:** [Date]
**Decision rights:** [Who decides]

提出建议很重要。不提出建议，就是把工作又推回给决策者。

---

语气与文风

面向不同受众

受众	语气	细节	长度
直属经理	坦诚、简洁	中等	中等
上一级经理 / VP	得体、精炼	少	短
跨职能同事	合作、具体	中等偏多	中等
高管 / 董事会	标题式、自信	少（可提供详细信息）	短
团队 / IC 利益相关者	详细、直接	多	长

应避免的做法

• 有把握时还含糊其辞。“我想，也许我们可能可以……”直接说出你的意思。
• **不确定时却表现得很有把握。**如果存在风险，就不要说“肯定会在周五发布”。把握好表达的分寸。
• **对非技术受众使用行话。**换成通俗易懂的说法。
• **把重点藏起来。**先说结论。
• **提出含蓄的请求。**明确说出你想要什么。
• **进展更新中 90% 是活动、10% 是结果。**聚焦结果；活动只是辅助证据。

---

工作流

步骤 1：明确受众和目的

开始写之前，先回答上面的 Q1-Q5。通常，这能在起草之前就理清要传达的信息。

步骤 2：起草标题

用一句话概括要点。如果你写不出标题，就说明你还没想清楚要传达什么。

步骤 3：按倒金字塔结构撰写

标题、意义、正文、请求、细节。

步骤 4：删减

初稿通常会长出 30-50%。

• 删除没有带来成果的活动
• 删除形容词（很棒、了不起、出色、令人兴奋）
• 删除填充词（只是、真的、非常、实际上）
• 有把握时，删除模棱两可的表达（有点、某种程度上、稍微）
• 删除不增加信息的句子

步骤 5：确认请求

重新阅读。请求是否明确？是否具体？是否写明截止日期？

步骤 6：检查受众

想象收件人正在阅读。对方能理解标题吗？你是否略过了对方需要的背景？是否提供了对方不需要的背景？

步骤 7：发送并跟进

发送后：

• 对的人看到了吗？在合适的渠道确认。
• 他们理解了吗？留意令人困惑的回复，并予以回应。
• 他们采取行动了吗？跟进迟迟未处理的请求。

---

沟通节奏设计

不同受众需要不同的沟通节奏。

高频（每周或更频繁）

• 直属团队、经理、赞助人
• 正在推进的项目利益相关者
• 做日常决策的人

中频（每两周至每月）

• 上一级经理
• 跨职能合作伙伴
• 相邻团队
• 战略利益相关者

低频（每季度）

• 高管评审
• 董事会更新
• 更广泛的组织
• 外部利益相关者（如适用）

合适的沟通节奏应取决于实际需要，而不是为了填满日历。有新进展时再更新；不要为了更新而凭空制造内容。

---

失败模式

重点前铺垫过长。 先用三段话交代背景，最后才说关键的一句话。先说重点。

状态：黄色。 连续三周状态都是黄色。没有变化的黄色就是红色。要如实说明进展。

更新内容没有明确请求。 “我们正在处理。”好，那你需要什么？如果没有需要，就说“无需采取行动”。

把坏消息夹在好消息中间。 “我们完成了 X 和 Y，但很遗憾，Z 延期了，不过我们也完成了 W。”坏消息会被淹没。如果这是重点，就先说坏消息。

大段文字。 太长了，没人会看。按结构精简。

活动不等于成果。 “与团队开会。审查计划。更新工单。”所以呢？“缩小范围以按时发布”才是成果。

给每类受众准备不同的更新。 维护 5 个版本会让工作量翻倍。准备一份核心更新，再调整表达方式。

把请求包装成状态更新。 在一大段状态说明中埋下请求。把请求单独提出，让它一目了然。

过于乐观的预测。 “我们下周就能恢复正轨。”结果没有。然后又一次没有。信任会逐渐消磨。诚实说明实际进展。

请求后没有跟进。 请求了决策；没有得到答复；然后就不管了。现在项目卡住了。继续跟进。

只有被迫时才传达坏消息。 利益相关者从别人那里，或从错过的截止日期中得知消息。信任会因此受损。主动沟通。

只为某一个人表演式沟通。 每次更新看起来都像是向老板推销。利益相关者看得出来。直截了当地说。

没有新消息时不沟通。 沉默比“本周没有变化”更糟。明确沟通频率，并坚持执行。

---

输出格式

项目沟通计划包括：

• 利益相关者地图： 人员姓名、他们的关注点及决策权
• 沟通频率： 向谁发送哪些更新，以及发送频率
• 模板： 重复使用的标准化更新格式
• 升级路径： 出现风险时应联系谁
• 决策日志： 持续记录已作出的决策、决策者及原因

对于单独的沟通内容：

• 标题： 核心结论
• 正文： 支撑内容的结构
• 请求： 明确提出的请求
• 发送对象与形式： 发送给谁，以及以何种形式发送

---

参考文件

• references/update-templates.md：常见利益相关者沟通的即用模板，并附有带注释的示例。