name: 利益相关者沟通 description: 适应技术沟通给不同受众 - 工程师、产品经理、高管和客户。在跨职能沟通、翻译技术概念、向领导层汇报或与非技术利益相关者建立共享理解时使用。 argument-hint: <技术内容> for <受众> allowed-tools: Read, Glob, Grep, AskUserQuestion

利益相关者沟通技能

一个框架，用于适应技术沟通给不同受众，确保您的信息有效传达，无论是与工程师、产品经理、高管还是客户交流。

何时使用此技能

向非技术利益相关者展示技术决策
为不同受众级别编写状态更新
为业务合作伙伴翻译复杂技术概念
在工程、产品和业务团队之间建立对齐
与高管沟通（简洁、业务影响）
面向客户的技术沟通
跨职能项目协调

核心框架：受众优先沟通

基本问题

在沟通之前，问：“我的受众是谁，他们需要什么？”

不同利益相关者有不同的：

知识水平： 他们能吸收的技术深度
决策标准： 对他们决策重要的因素
时间限制： 他们能给予多少注意力
行动导向： 他们需要用这些信息做什么

四种受众类型

受众	主要关注点	沟通风格
工程师	如何工作	技术深度、实施细节
产品经理	做什么	功能、权衡、时间线影响
高管	为什么重要	业务影响、风险、所需决策
客户	如何帮助他们	好处、可靠性、信任

快速适应指南

对于工程师

关注：

技术架构和设计决策
实施方法和权衡
代码质量、测试和可靠性
性能特征和约束

避免：

过度简化的解释（他们会感到被轻视）
隐藏技术债务或已知问题
没有技术理由的模糊时间线

对于产品经理

关注：

功能能力和限制
时间线和范围权衡
用户影响和体验变化
依赖关系和路线图风险

避免：

深度实施细节（除非与决策相关）
没有上下文的专业术语
当存在权衡时的二元答案

对于高管

关注：

业务影响（收入、成本、风险）
需要他们输入的决策点
对战略目标的进展
资源影响

避免：

技术细节（除非特别要求）
没有提议解决方案的问题
冗长的解释（直接点）

对于客户

关注：

他们获得的好处和价值
可靠性和信任信号
清晰、无专业术语的解释
他们需要做什么（如果有的话）

避免：

内部技术细节
责备或借口
没有保证的不确定性

翻译原则

技术 → 业务翻译：

技术概念	业务翻译
“重构代码库”	“提高系统可靠性并减少未来错误”
“数据库迁移”	“升级数据基础设施以获得更好性能”
“技术债务”	“累积的捷径，减缓新功能开发”
“API速率限制”	“防止系统过载的保护”
“微服务架构”	“允许更快、独立更新的模块化设计”

公式：

[技术动作] → [业务好处] + [如果不做的风险]

示例：

技术：“我们需要从.NET 6升级到.NET 8”
业务：“升级我们的框架确保持续的安全支持，并使响应时间加快20%，避免当.NET 6支持在11月结束时出现安全漏洞”

沟通模式

高管摘要模式

对于任何高管沟通：

前线底线（BLUF）： 以结论或请求开头
上下文： 理解所需的最小背景
选项/推荐： 您建议什么以及为什么
请求： 您需要他们做什么

模板：

**摘要：** [一句话：这是什么以及您需要什么]

**上下文：** [2-3句话：为什么现在重要]

**推荐：** [您提议什么]

**请求：** [特定的决策或行动需要]

**细节：** [如果他们想深入了解可用]

跨职能更新模式

对于发送给混合受众的状态更新：

进展： 完成了什么（成就、指标）
计划： 下一步是什么（即将进行的工作、时间线）
问题： 什么在阻塞（问题、风险、需求）

模板：

## [项目名称] 更新 - [日期]

### 进展
- [带有指标或结果的成就]
- [带有指标或结果的成就]

### 计划
- [即将进行的工作] - [目标日期]
- [即将进行的工作] - [目标日期]

### 问题
- [问题]： [影响] - [提议的解决方案或请求]

技术决策模式

对于向非技术利益相关者沟通技术决策：

决策： 我们决定了什么
为什么： 业务理由（非技术细节）
影响： 对他们有什么变化
时间线： 何时发生

模板：

**决策：** 我们[决策]。

**为什么：** 这[业务好处]和[风险缓解]。

**影响：** [他们将看到/体验的不同之处]。

**时间线：** [何时生效]。

常见错误

错误1：对所有受众发送相同消息

问题： 向工程师和高管发送相同的沟通。

修复： 创建分层沟通：

高管摘要用于领导层
详细版本用于技术团队
面向客户版本（如果适用）

错误2：以技术细节开头

问题： 在为什么重要之前开始讲如何工作。

修复： 总是以业务影响开头，然后为那些想要的人提供技术细节。

错误3：假设共享上下文

问题： 使用他人不知道的缩写、项目名称或引用。

修复： 定义术语，提供上下文，链接到背景信息。

错误4：所有问题，没有解决方案

问题： 升级问题而没有提议解决方案。

修复： 总是带来选项。“我们有问题” → “我们有问题。我推荐X因为Y。”

错误5：对复杂问题的二元答案

问题： “我们可以”或“我们不能”没有细微差别。

修复： “可以，但有以下权衡”或“不是如所问，但这是我们可以做的。”

参考（需要时加载）

详细框架

受众适应矩阵： 按受众类型的完整沟通策略
技术翻译： 为非技术受众简化专业术语
高管沟通： 业务影响框架和简洁技巧
跨职能对齐： 在团队之间建立共享理解

示例场景

场景1：向高管解释延迟

**情况：** 功能发布因意外技术复杂性延迟2周。

**坏：** “API集成需要更长时间，因为第三方文档不正确，我们必须反向工程他们的认证流程，加上我们发现在队列处理中存在竞争条件，需要重构。”

**好：** “发布移至[日期] - 比计划晚2周。集成比基于可用文档估计的更复杂。我们已经对剩余工作进行了去风险处理，并对新日期有信心。影响：[业务影响]。除非您有问题，否则不需要您采取行动。”

场景2：混合受众的技术更新

**情况：** 数据库迁移成功完成。

**对于工程师：**
“迁移完成。230万条记录转移，零数据丢失。回滚脚本测试并可用。新索引在高流量端点上将查询性能提高40%。监控仪表板更新。待命运行手册在wiki中。”

**对于高管：**
“数据库升级完成。系统更快、更可靠。过渡期间无客户影响。通过提高效率每月节省成本$X。”

**对于客户（如果适用）：**
“我们已经升级了我们的系统，以更好地为您服务。您可能会注意到更快的加载时间。您无需采取任何行动。”

场景3：请求资源

**情况：** 关键项目需要额外工程师。

**坏：** “我们落后了，需要帮助。”

**好：** “请求：1名额外工程师用于[项目]直到[日期]。

为什么：当前速度使我们比[战略目标]落后3周。现在增加容量使能按时交付。

不行动的后果：[特定的业务后果]。

推荐：暂时从[低优先级工作]重新分配[名称]。

成本：[低优先级工作]延迟[X周]。

请求：在[日期]前批准重新分配以保持时间线。”

要避免的反模式

在书面沟通中

文本墙： 分成可扫描的部分
埋没要点： 把关键点放在前面
专业术语汤： 定义术语或使用简单语言
缺失请求： 清楚说明您需要什么

在口头沟通中

独白： 暂停提问和反应
防御姿态： 对反馈开放
过度解释： 匹配深度到受众兴趣
模糊承诺： 对下一步具体

成功指标

有效的利益相关者沟通实现：

理解： 他们掌握您所说的
对齐： 他们同意方向或知道如何不同意
行动： 他们可以采取适当的下一步
信任： 他们感到知情和尊重
效率： 双方的时间都没有浪费

用户界面

当用户直接调用时，此技能为特定受众适应技术内容。

执行工作流

解析参数 - 从$ARGUMENTS中提取技术内容和目标受众。格式：<技术内容> for <受众>。如果不完整，询问要适应什么内容以及为谁。
识别受众类型 - 分类目标受众（工程师、产品经理、高管、客户或混合）。
分析技术内容 - 识别需要翻译的专业术语、技术细节、缩写和实施细节。
应用翻译原则 - 使用公式将技术语言转换为适合受众的沟通：[技术动作] -> [业务好处] + [如果不做的风险]。
生成适应输出 - 为目标受众生成重写的内容，具有适当的深度、框架和行动导向。
建议沟通模式 - 根据内容类型推荐适当的格式（高管摘要、跨职能更新、技术决策模式）。

版本历史

v1.0.0 (2025-12-23)：初始发布，具有受众优先框架

利益相关者沟通技能Skill stakeholder-communication