关于 Stakeholder Analysis
Stakeholder Analysis 是用于项目相关方识别与管理的技能，适合项目启动、需求准备和变更管理。它提供权力／兴趣矩阵、RACI、相关方登记表及沟通计划等分析框架。
主要功能
- 01识别项目相关方
- 02权力／兴趣矩阵分类
- 03RACI 职责分配
- 04维护相关方登记表
- 05制定沟通计划
适用场景
- 01准备项目启动与规划
- 02安排需求收集访谈
- 03规划变更沟通与参与
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/stakeholder-analysis确认已加载。
详细介绍
利益相关者分析技能
目的
识别并分析项目利益相关者，确保在整个项目生命周期中妥善开展参与、沟通和管理。
适用场景
- 项目启动与规划
- 需求收集准备
- 变更管理规划
- 沟通策略制定
- 风险评估（利益相关者相关风险）
利益相关者识别
利益相关者来源
- 项目发起人和高管
- 业务负责人和部门主管
- 最终用户（内部和外部）
- IT 和开发团队
- 外部供应商和合作伙伴
- 监管机构
- 客户
识别技巧
- 审查组织架构图：识别受影响的部门
- 与团队一起头脑风暴：谁会受到影响？谁有影响力？
- 审查文档：以往项目、合同
- 访谈：询问“我还应该和谁沟通？”
- 流程分析：谁负责执行每个步骤？
权力／利益矩阵
矩阵
High Power │ Keep Satisfied │ Manage Closely │
│ (Latents) │ (Key Players) │
├────────────────┼────────────────┤
Low Power │ Monitor │ Keep Informed │
│ (Apathetics) │ (Defenders) │
└────────────────┴────────────────┘
Low Interest High Interest
象限策略
密切管理（高权力、高利益）：
- 定期进行 1:1 会议
- 让其参与关键决策
- 提供详细进展
- 征求其意见并获得批准
- 示例：项目发起人、业务负责人、CTO
令其满意（高权力、低利益）：
- 定期提供高层级进展
- 提供执行摘要
- 仅在重大决策时让其参与
- 不要用过多细节造成负担
- 示例：CFO、CEO、董事会成员
及时告知（低权力、高利益）：
- 定期更新（电子邮件、简报）
- 让其参与 UAT 和反馈
- 倾听其顾虑
- 是获取详细需求的绝佳来源
- 示例：最终用户、团队负责人
监控（低权力、低利益）：
- 尽量减少投入
- 仅进行常规沟通
- 留意其利益或影响力的变化
- 示例：未直接参与项目的外部供应商
RACI 矩阵
定义
- R - 负责执行：完成工作
- A - 最终负责：批准／签字确认（每项任务仅限一人）
- C - 需征询意见：提供意见（双向沟通）
- I - 需知会：了解进展（单向沟通）
模板
| 活动 | PM | BA | 开发负责人 | 业务负责人 | 最终用户 |
|---|---|---|---|---|---|
| 需求收集 | A | R | C | C | C |
| BRD 批准 | I | R | I | A | I |
| 技术设计 | I | C | R/A | I | I |
| 开发 | I | I | A | I | I |
| UAT 规划 | C | R | C | A | C |
| UAT 执行 | I | C | I | C | R |
| 上线批准 | C | I | C | A | I |
规则
- 每项任务恰好有一位最终负责者
- 每项任务至少有一位负责执行者
- 不要安排过多的 C（避免会议疲劳）
- 与利益相关者确认
利益相关者登记表
模板
| ID | 姓名 | 职位 | 部门 | 权力 | 利益 | 参与度 | 沟通偏好 | 备注 |
|---|---|---|---|---|---|---|---|---|
| SH-001 | John Smith | 销售副总裁 | 销售 | 高 | 高 | 项目倡导者 | 电子邮件、每周 1:1 | 关键发起人 |
| SH-002 | Sarah Lee | 支持经理 | CS | 中 | 高 | 支持 | Slack、Sprint 演示 | 优秀的 UAT 负责人 |
| SH-003 | Mike Chen | CFO | 财务 | 高 | 低 | 中立 | 每月执行摘要 | 预算审批 |
| SH-004 | Lisa Wong | 最终用户 | 运营 | 低 | 高 | 支持者 | 团队会议 | 主题专家 |
| SH-005 | Tom Brown | IT 总监 | IT | 高 | 中 | 抵触 | 1:1 会议 | 安全顾虑 |
参与程度
- 项目倡导者：积极推动项目
- 支持：态度积极，有求必应
- 中立：既不支持也不反对
- 抵触：持怀疑态度，可能会反对
- 敌对：积极阻挠项目
参与策略
拥护者 → 拥护者：借助其支持，让其参与沟通 支持者 → 拥护者：认可其贡献，赋予其所有权 中立者 → 支持者：沟通益处，解决顾虑 抵触者 → 中立者：了解顾虑，让其参与决策 敌对者 → 抵触者：进行一对一会谈，寻找共同点，必要时向上级反映
沟通计划
模板
| 利益相关者群体 | 信息需求 | 频率 | 渠道 | 负责人 |
|---|---|---|---|---|
| 执行团队 | 项目状态、风险、决策 | 每月 | 电子邮件报告、会议 | PM |
| 业务负责人 | 详细进展、阻碍因素 | 每周 | 状态会议 | PM |
| 开发团队 | 需求、优先级 | 每日 | 站会、Slack | BA |
| 最终用户 | 培训、时间表、变更 | 按需 | 电子邮件、Teams | BA |
沟通渠道
- 正式沟通：电子邮件、演示文稿、报告
- 非正式沟通：Slack/Teams、简短通话
- 会议：一对一会谈、团队会议、研讨会
- 文档：Confluence、Notion、SharePoint
利益相关者参与技巧
建立关系
- 了解他们的目标和挑战
- 使用他们熟悉的语言（技术或业务）
- 及时响应，值得信赖
- 履行承诺
- 肯定他们的贡献
管理抵触情绪
- 倾听以理解（而非为了回应）
- 提出深入的问题
- 找出抵触情绪的根本原因
- 直接解决顾虑
- 寻找双赢的解决方案
- 必要时向上级反映
管理预期
- 明确范围和时间表
- 尽早沟通风险
- 少承诺，多交付
- 记录决策和协议
- 定期更新状态
特定领域的利益相关者
电子商务
- 产品经理、商品管理
- 营销（促销、营销活动）
- 客户服务
- 履约/仓库
- 支付/财务
- IT/安全
ERP
- 财务（CFO、Controller、会计师）
- HR（CHRO、薪资管理）
- 供应链（采购、物流）
- 制造（工厂经理）
- IT（CIO、企业架构师）
- 合规/审计
CRM
- 销售（销售副总裁、销售经理、销售代表）
- 营销（CMO、营销运营）
- 客户服务（支持经理）
- IT（CRM 管理员）
- 执行层（CEO、收入负责人）
CDP
- 营销（CMO、营销活动经理）
- 数据/分析（首席数据官）
- IT/工程（数据工程师）
- 隐私/法律（DPO、法律顾问）
- 客户体验
最佳实践
✅ 建议：
- 定期更新利益相关者分析
- 根据利益相关者调整沟通方式
- 记录与利益相关者的互动
- 庆祝利益相关者的贡献
- 主动应对难以沟通的利益相关者
❌ 避免：
- 想当然地认定利益相关者的需求
- 忽视“难以沟通”的利益相关者
- 对所有人过度沟通
- 忘记形成反馈闭环
- 突然告知利益相关者坏消息
工具
- Lark/Notion：利益相关者登记表数据库
- Figma/Miro：权力/利益矩阵可视化
- Lark Meetings：会议记录和行动事项
- Email/Slack：定期沟通
后续步骤
完成利益相关者分析后：
- 制定沟通计划
- 规划需求引导日程
- 识别变更管理需求
- 为需求研讨会做好准备
参考资料
- PMBOK Guide - 利益相关者管理
- BABOK Guide - 利益相关者分析
- Influence Without Authority（Cohen & Bradford）
评论
支持 Markdown