stakeholder-identification

利益相关方识别

目的

在接触任何人之前，先绘制所有利益相关方的全貌。这项技能会产出一份全面、兼顾公平性的利益相关方名单——不仅包括显而易见的赞助方和用户，也包括把关者、受影响的社区，以及团队容易忽略的声音。

大多数 PM 的利益相关方名单都是凭记忆在五分钟内列出来的。名单总能涵盖高管、产品团队同事和最活跃的用户，却总会漏掉那些承受产品后果、却没有组织权力影响产品决策的边缘化用户群体。这项技能会促使团队放慢节奏，以更有条理的方式展开头脑风暴，为后续每项参与决策奠定基础。

请在 stakeholder-mapping（负责确定优先级）之前，以及 stakeholder-engagement-advisor（负责规划面向各利益相关方的沟通）之前使用。识别应先于优先级排序——你无法为尚未列出的人确定优先级。

输入

最适合提供： 你要为其绘制利益相关方全貌的计划、产品或决策。 也有帮助： 你已有的利益相关方名单（这项技能的任务是找出遗漏者）、组织背景和受影响的社区。

随调用一并提供的内容——技能名称后面的文本、粘贴的背景信息，或附加的 ARGUMENTS: 行——都算作已回答的问题。请使用这些信息，并跳过其中已涵盖的提问；不要重复询问。

没有准备任何信息？也没关系。 这项技能会先询问计划是什么、会影响哪些人，然后进行兼顾公平性的全面排查。

调用示例： 识别将所有客户迁移到新计费系统（目标 Q4 完成）涉及的利益相关方。

关键概念

盟友、受众、影响者——这三类有助于厘清利益相关方与你的工作之间的关系。盟友会积极支持计划；受众会受到计划影响；影响者虽不直接受影响，却能影响舆论或决策。按此分类，可以看出你需要争取谁、告知谁、说服谁——这对应三种不同的沟通工作。

R/P/D 标记——将每位利益相关方标记为资源提供者（预算、人员、权限）、许可方（批准推进、监管许可）或决策者（拥有最终决定权）。这能快速揭示谁可以为计划提供资金、阻止计划或批准计划启动，以及谁只是感兴趣。一位利益相关方可以拥有多个标记。

公平性视角——有意识地拓展名单，纳入那些经常被排除在外的利益相关方：边缘化用户群体、一线员工、下游社区，以及承受产品后果却缺乏组织权力影响产品设计的人群。缺少这一步，团队就会优先满足声音响亮、资源充足的群体，开发出令沉默的大多数失望的产品。

一级、二级、三级影响——追踪产品影响如何从直接用户向外扩散，波及间接受影响群体。某项功能改变支持专员的工作方式（一级），会影响客户对服务的体验（二级），进而影响公司的声誉和客户流失率（三级）。沿着这条链追踪，可以发现只从单一层面思考时容易遗漏的利益相关方。

留意偏见与假设——团队进行明确检查：我们下意识地列出了谁？名单中缺少谁？我们把谁的视角当成普遍视角？这一步会在盲点演变成需求缺口之前，将其指出来。

识别与确定优先级——应将“哪些人存在”与“哪些人最重要”分开处理。此技能的目标是列出完整名单，而非排定优先级。混淆这两个步骤会导致团队过早排除尚未了解清楚的利益相关方。优先级排序应在 stakeholder-mapping 中进行。

应用

步骤 1 — 畅想，不作筛选

快速列出所有可能的利益相关者，不受任何限制：与这项计划有关联的个人、团队、组织和社群。不要自行删改。写下所有可能与之有利害关系的人，即使他们似乎不太可能参与其中。

如果以小组形式开展，先静默进行 4-6 分钟，再分享结果。

步骤 2 — 分类

将每位利益相关者归入以下一个或多个类别：

• 盟友 — 谁积极支持这项工作，或会从它的成功中受益？
• 受众 — 谁会直接或间接受到结果的影响？
• 影响者 — 谁会影响决策、舆论或采用情况，但并未直接参与？

注意：一位利益相关者可以归入多个类别。这些重叠之处——例如同时也是关键影响者的盟友——往往意味着这类关系具有最大的杠杆效应。

步骤 3 — 标注 R/P/D

为每位利益相关者标注其是否提供：

• R — 资源（预算、人员、数据、访问权限）
• P — 许可（批准、法律许可、签字核准）
• D — 决策权（对范围、优先级或发布拥有最终决定权）

任何拥有 P 或 D、但未列入名单的利益相关者，都是一个缺口，日后可能成为阻碍。

步骤 4 — 纳入公平性视角

针对名单提出以下问题：

• 谁会在经济、职业或日常体验方面，因这款产品而受到显著影响或承受后果？
• 谁承担了产品带来的成本或风险，却无权影响其设计？
• 我们认为他人能代表他们，因而遗漏了谁的观点？
• 谁是主要用户？谁是次要用户？谁会受到第三层影响？

将公平性视角发现的人员补充到名单中。这些利益相关者很可能会出现在利益相关者映射的 Q1 象限（影响大、权力小）——他们的声音最需要得到重视。

步骤 5 — 留意偏见和假设

作为小组，明确回答：

• 在步骤 1 中，我们默认首先提到了哪些人？
• 谁没有出现？为什么？
• 关于哪些人算是利益相关者，我们作出了哪些假设？

记录答案。这些答案将影响你的研究计划和招募策略。

步骤 6 — 缩小范围，确定优先对象

完整名单清晰可见后，找出在继续之前最需要深入了解的 2-3 位利益相关者。他们通常包括：

• 最需要获得其支持的高权力决策者
• 需求最不明确、影响最大的用户
• 最有可能成为阻碍者或持怀疑态度的人

针对每位优先利益相关者，记录：姓名、类别、R/P/D 标签，以及一句“我们需要从他们那里了解什么”。这些成果将直接用于利益相关者映射和利益相关者参与顾问。

示例

情境： 某产品团队正在规划一项新的受理工作流，用自助服务门户取代基于电子邮件的人工请求。初始利益相关者名单：运营副总裁、工程负责人、PMO 总监、企业客户。

不够完善（常见的默认做法）： 这份名单涵盖了显而易见的赞助者，以及最积极要求这项功能的客户群体。遗漏了：目前负责处理每一项人工请求的客户支持专员（现有工作流的主要日常用户）、IT 安全团队（P — 必须审批数据处理方式）、合规官（P — 涉及监管要求）、缺少技术人员、无法使用自助服务门户的小型企业客户（影响大、权力小的群体）。

运用公平性视角并标注 R/P/D 后，名单更完善：

• 运营副总裁（D，盟友）— 最终范围决策权
• 工程负责人（R，盟友）— 负责评估产能和技术可行性
• PMO 总监（P，影响者）— 必须审批流程变更
• 企业客户（受众）— 新门户的主要用户
• 客户支持专员（受众，R）— 目前处理每一项受理请求；若未征询意见，可能影响采用情况
• IT Security（P）— 必须审批数据处理方式
• 合规官（P）— 负责监管审查
• 小型企业客户（受众）— 所受影响各不相同；可能需要非自助服务渠道

第二份名单会带来不同的 PRD、不同的推出计划，以及不同的成功定义。

常见陷阱

把首次头脑风暴的结果当作最终名单。 初步梳理通常只能找出 60% 的利益相关者，并且总会漏掉不那么显眼的 40%。分类和公平性检查就是为了弥补这一缺口——跳过它们就失去了这项练习的意义。

列出角色或组织部门，而非具体人员。 “工程部门”不是利益相关者，掌控迭代产能的工程负责人方才是。含糊的类别名称会让你无法约定真正需要的沟通。

混淆识别与优先级排序。 在头脑风暴阶段，还未了解利益相关者的实际影响力或所受影响，就将其删去，这会导致影响大、权力小的声音悄然消失。先完成名单，再进行利益相关者映射。

跳过偏见与假设检查。 跳过这一步的团队往往自信名单已经完整。实际进行检查的团队则会发现，他们曾假设资源充足的用户代表能够代表所有人。明确指出盲点。

独自进行，未经外部验证。 一个人绘制的利益相关者图，只反映此人的人脉网络和假设。如果独自开展，请通过偏见检查找出自己的认知模型中缺失了哪些人，然后在继续之前找一位跨职能同事进行验证。

生成了完整名单，却没有记录后续步骤。 画布的结尾包含优先目标和行动安排，自有其道理。一份全面的利益相关者名单，如果没有附上“谁在何时与谁沟通”，那只是一份文档，而非计划。

参考资料

• stakeholder-mapping — 下一步：使用 Power × Interest 和 Impact × Power 网格对已识别的利益相关者排定优先级
• stakeholder-engagement-advisor — 确定优先目标后，为每位利益相关者制定沟通计划
• discovery-interview-prep — 将已识别的利益相关者作为招募研究对象的依据
• proto-persona — 识别出高优先级用户利益相关者后，制定基于假设的用户画像
• MITRE Innovation Toolkit — 利益相关者识别画布
• MITRE Innovation Toolkit — 社区地图