干系人识别与分析
§1摘要与结论
别名：stakeholder analysis、stakeholder identification、干系人分析、干系人识别 | 英文：Stakeholder Identification and Analysis | 类型：方法 / process
§2局部关系图
§3原理 · 为什么
需求风险很大一部分来自被遗漏的角色：系统的成功取决于所有受影响方的接受，而不仅仅是委托方的满意。干系人识别与分析把「谁重要、谁受影响、谁有权否决」作为显式工作，避免需求工作只反映声音最大者。分析不仅列名单，还要理解每类干系人的关注点、影响方式与相互依赖，从而决定参与深度与沟通方式。由于组织与系统边界会变化，识别是持续活动，而不是项目初期一次性完成的清单。识别还须刻意覆盖容易被忽视的角色，如运维、支持、监管与未来的维护者，他们的诉求常在交付后才暴露，代价最高。对间接干系人，如受系统决策影响的公众或下游系统，也应纳入考虑，尽管其诉求可能需要通过代理方式表达。因此，干系人分析不是需求工作前的一次性准备，而是贯穿始终的对齐机制，确保系统在漫长的演化中始终服务于真实的相关方，而非立项时的一纸假设。角色会随系统演进与新场景出现而变化，识别因此需要持续维护而非一次完成，并在变化时评估其对需求的连带影响。
§4机制 · 如何运作
其运作包含识别、分析与维护三步。识别从系统边界与业务目标出发，枚举所有受影响或能施加影响者；分析针对每类角色评估其关注点、影响力、态度与对系统成功的权重，据此区分必须参与、需要告知与可暂不介入者；维护则随系统与组织演进而更新视图，并在新角色出现时补做分析。分析结果直接指导获取活动的安排：高权重的角色应深度参与场景生成与需求确认，约束型角色则需确保其强制要求被完整捕获。冲突在此阶段被识别并登记，而不是留待实现阶段爆发；对权力与利益不匹配的角色，还需设计相应的沟通与仲裁路径，防止其诉求被长期忽视后以否决的方式集中释放。对关键角色的关注点与权力变化应保持敏感，当组织调整或角色更替时及时更新分析，防止判断停留在旧结构上，从而在需求决策中持续反映当前的真实格局。分析结论应转化为可执行的参与计划，而不是停留在名单与标签上，否则分析成果难以真正影响需求决策。
§5工程 · 怎么落地
实践中使用结构化问题引导识别：谁会使用、谁为系统付费、谁维护、谁受结果影响、谁能阻止项目、谁提供输入或消费输出。对每类干系人记录其关注、影响力、期望参与方式与已知冲突。把监管、法律与安全相关角色单列，确保强制约束不被遗漏。让关键角色在需求评审与验收中实际参与并留下意见记录。随系统边界、组织结构或使用场景变化定期复核名单。对新出现或此前被忽略的角色及时补做分析，并评估对既有需求的影响。对关键干系人应明确其代表性与决策权限，避免出现看似参与却无法代表其群体的名义角色。可将干系人与其关注点整理为一张可维护的视图，随评审与验收活动更新，使参与情况有据可查，也便于新成员快速理解该项目需要向谁负责、与谁协商。对影响力与关注度都高的角色，应建立定期沟通机制以保持对齐，及时消化其关注点的变化与新增诉求。
§6权衡卡
更广的参与能减少遗漏，但会带来协调、沟通与决策成本，角色过多时容易陷入无休止的争论而无法收敛；识别不足则会在后期遭遇抵制或合规问题。
因此识别与分析应平衡覆盖与效率，依据系统风险与责任边界决定参与深度，并对被排除者说明理由。
- 分析也容易被简化为一次性的名单而失去作用：列出了角色却没有真正让其参与，只是制造覆盖的假象。
- 此外，不同角色权力不对称，若完全按影响力排序又可能忽略受影响最深却话语权最弱的群体。
- 其成效应由是否减少了因角色遗漏造成的重大变更来衡量；分析结果也应随项目推进持续校核，而不是在立项后便被束之高阁。
- 把所有角色都纳入决策会使项目寸步难行；因此需要明确「谁拍板、谁咨询、谁知会」的分工，在覆盖与效率之间取得平衡，并对分工本身保留复核的机制。
- 参与范围的划定本身也应被记录与复核，以适应组织与业务的变化，并在必要时解释为何某些角色被排除在外。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7学习路径条
§8案例带
OpenSpec 规约驱动解析
对比规约驱动开发工具链 OpenSpec 与 Superpower 的元模型、工件依赖 DAG 与安全门控，提炼「规约先于实现」工程形态的解析案例。
技术知识中枢交付法
从模糊需求到上线，把 AI Agent 驱动的端到端交付固化为四阶段加双共识加迭代的可迁移方法论的实战提炼案例。
§9信源与核验
核验结论：干系人包括最终用户、运维、开发、采购、监管等多类角色；仅关注客户会遗漏强制约束与运行期诉求 [OFF-012]
§10原始关系清单
展开：本节点的全部原始关系边（2 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 依据推导 | → ESS-F-02 | 干系人与需要 E-308 | 干系人识别与分析以干系人概念为依据 |
| 前置依赖 | → MTH-F-02 | 需求获取 E-311 | 先识别干系人再开展需求获取 |