stakeholder-map

stakeholder-map 技能概览

stakeholder-map 是一项实用的规划技能，帮助你把混乱的项目梳理成清晰的 Power × Interest 利益相关方地图和沟通计划。无论是上线、变更项目、跨职能推广，还是其他利益相关方密集的项目，当你需要判断谁应该被告知、谁需要被征询、谁要被重点管理、谁只需持续关注时，都适合使用 stakeholder-map 技能。

stakeholder-map 的用途

它真正要解决的，不只是把利益相关方列出来，而是降低协同风险。这个技能能帮助你尽早识别决策者、阻力点、影响者和下游使用者，从而为每一类人设定合适的沟通频率、语气和渠道。

哪些人最能受益

它特别适合项目经理、产品负责人、项目群经理、PMO 团队，以及任何在复杂项目开始前需要做利益相关方沟通准备的人。尤其适用于 stakeholder-map for Project Management 这类场景：当项目横跨多个职能部门时，你需要的不只是头脑风暴式名单，而是一份可审计的沟通计划。

这个技能的优势在哪里

stakeholder-map 技能轻量，但决策导向很强：它先聚焦矩阵，再把地图落到行动上，把每个象限直接关联到对应的沟通策略。相比通用提示词，它更适合需要可重复流程的场景，也更能减少“谁该沟通、怎么沟通”的猜测成本。

如何使用 stakeholder-map 技能

安装并找到该技能

先通过你的 skills manager 按 stakeholder-map 的安装流程完成安装，然后优先打开技能文件。在这个 repo 中，主入口是 pm-execution/skills/stakeholder-map/SKILL.md，不需要再去找额外的脚本或参考目录。

提供有用的项目背景

stakeholder-map 的使用效果最好时，你会提供一段简短的项目说明、目标、时间线、组织架构、已知风险，以及任何已确认的利益相关方。如果你只说“做一张利益相关方地图”，输出通常会比较泛；如果你补充了项目范围、地域、依赖领域和决策负责人，地图质量会明显更高。

把模糊需求改写成更好的提示词

一个好的提示词应该说明项目正在发生什么变化、谁会受到影响，以及你希望得到什么样的输出。例如：“为我们的 Q3 CRM migration 生成 stakeholder-map。包含高管、sales ops、support、security 和 regional managers。我需要一张 power/interest 矩阵，以及一份带更新频率、负责人和渠道的沟通计划。”

按正确顺序使用工作流程

先输入源材料，再一次性让它完成利益相关方识别、象限归类和沟通计划。如果你已经大致知道受众构成，可以要求它分别优先处理 external partners、executive sponsors 和 operational teams，这样计划就不会把高权力群体和高兴趣群体混在一起。

stakeholder-map 技能 FAQ

stakeholder-map 只适合 Project Management 吗？

不完全是。stakeholder-map 技能在 Project Management 场景里最显眼，但它同样适用于产品发布、流程变更、内部沟通规划和跨职能运营调整。只要这项工作涉及多个利益相关方，而且他们的诉求不同，它就能派上用场。

使用它需要完全准确的源数据吗？

不需要，但输入越好，结果越好。如果你有组织架构图、项目简报或团队名单，就直接提供；如果没有，也至少给出简洁的项目说明、可能受影响的团队，以及已知的决策者，让技能去推断其余信息。

它和普通提示词有什么不同？

普通提示词往往只停留在“列出利益相关方”。stakeholder-map 会把结果推进到可执行交付物：一张 Power × Interest 矩阵，再加上按象限拆分的沟通动作。这就是头脑风暴和真正能拿去做利益相关方管理之间的差别。

什么情况下不该用 stakeholder-map？

如果任务太小，不值得单独做利益相关方分层，就可以跳过。或者，如果你只需要给单一受众写一条简单状态说明，也没必要用它。另一个不适合的情况是：你完全没有项目背景，也无法判断谁可能会受到影响。

如何改进 stakeholder-map 技能

提供更精准的输入，而不只是更多文字

质量提升最大的来源，是把项目范围、决策节点，以及已经参与的人或职能明确写出来。补充上线日期、合规敏感度、依赖关系和已知阻力点等信息；这些细节能帮助 stakeholder-map 技能把人放进正确象限，而不是靠猜。

直接指定你要用的输出格式

告诉它你需要表格、叙述式计划，还是两者都要。例如，可以要求输出 stakeholder name、power、interest、likely concerns、recommended cadence 和 owner。这样结果更容易直接放进 deck、tracker 或工作文档里，不用再返工改写。

针对薄弱环节继续迭代

如果第一版太宽泛，可以要求生成第二版，把 internal 和 external stakeholders 分开，或者只展开高权力群体。如果沟通计划太笼统，可以进一步指定渠道级别的细节，比如 1:1s、steering updates、demos 或 email summaries，然后再根据项目节奏微调沟通频率。