利益相关者思维

学习指南与笔记

谁会受到影响，关心什么？用于决策跨越多个团队或利益时。

学完后你将能够

区分正式权力与实际影响力。
按各群体的关注点与证据需求调整沟通。

它是什么？

利益相关者思维系统识别所有能影响变更、执行变更或承受变更后果的人群，梳理各方不同的诉求、顾虑与所需证据，让跨团队决策真正平稳落地而非陷入暗中抵触。

利益相关者地图识别能影响或会经历变更的人，并按角色、影响力和关注度调整参与方式。

核心问题: 谁会受到影响，关心什么？
何时使用: 用于决策跨越多个团队或利益时。

工具与方法

核心方法与工具

影响力—关注度—受影响矩阵按决策影响力与实际受影响程度梳理审批者、运维、用户及弱势受影响群体。
分群体关切与证据台账列出各群体的核心顾虑，以及回应其关切所需的具体证据或支持路径。
分层征询—知情—共建机制事先明确谁参与共同设计、谁在决策前接受征询、谁在上线前获得操作指引。

操作流程：一步步想清楚

按顺序完成以下步骤，并运用上面的工具。每一步先写下答案，再进入下一步。

列出受影响的人
纳入决策者、交付人员、用户、支持团队及不易被看见的受影响群体。 [1] 来源: UK Office for National Statistics — Stakeholder mapping（在新标签页打开）
绘制关注点
评估影响力、关注度、顾虑及每个群体需要的证据。 [1] 来源: UK Office for National Statistics — Stakeholder mapping（在新标签页打开）
设计参与方式
确定谁需要征求意见、保持知情和参与决策，并随立场变化更新地图。 [1] 来源: UK Office for National Statistics — Stakeholder mapping（在新标签页打开）

马上练习

为一项服务变更绘制至少五类相关者，说明决策前要征询谁以及原因。

可视化指南

流程图: 利益相关者思维 — **流程图**从情境出发，经过有意识的步骤，形成输出

详细案例

核心推演场景

情境: 团队调整内部服务的访问规则。

思维转换: 向用户、安全审核人、服务负责人和支持人员了解各自影响。

决策输出: 在更改规则前设计分阶段沟通与支持路径。

02 / 推行强制多因素身份验证

情境: 安全团队宣布周五一刀切启用新认证规则，引发外勤与客服团队强烈抵触。

思维转换: 在强制切换前，分别梳理共用终端人员、值班工程师与服务台坐席的真实使用场景。

决策输出: 为共用终端配备硬件令牌、分批引导注册，并提前为服务台配齐应急重置手册。

03 / 下线旧版内部接口

情境: 平台团队计划下线 v1 内部接口，但三个下游调用方团队正处于各自的版本交付高峰。

思维转换: 摸清各调用方的迁移工作量与风险窗口，提供自动兼容适配层与一键迁移脚本。

决策输出: 将下线里程碑与各团队发布周期对齐，在不引发冲突升级的前提下按期下线旧接口。

以上案例用于演示该思维方式如何改变决策路径，不代表实测结果。

练习与持续学习

常见误区与局限: 正式权力低不代表受到的影响小；地图应持续更新，而非归档了事。

如何持续精进

01 · 入门认知认识到正式职权不高的人群（如一线运维、客服与终端用户）往往承受着最大的日常操作冲击。
02 · 日常训练在宣布跨团队变更前，先写出各群体的头号顾虑（如“这会增加半夜告警吗？”“会让操作变慢吗？”）并准备好证据。
03 · 进阶精通邀请受影响最大的审慎质疑者参与早期设计走查，把他们指出的边界情况转化为上线前的加固措施。

不要只依赖单一思维方式，可与其他思维方式组合使用。浏览全部思维方式

复习与整理笔记

记住这个核心

可落地的决策需要考虑谁受影响、他们需要什么，以及谁能影响结果。

你的笔记提纲

选一个自己的问题，为每项提示写下简短答案。尝试方法后，再回来补充。

人员：列出受影响群体，包括正式权力较小的人。
利益：记录需求、影响力、顾虑和缺席的声音。
参与：明确谁在何时需要什么证据。

检查是否真正理解

先不看笔记作答，再展开参考答案进行比较。

发起人是唯一重要的利益相关者吗？

对照参考答案

不是。使用者、运营者、合作伙伴和受影响群体，即使没有预算审批权，也可能决定采用效果与后果。

利益相关者图应如何随时间变化？