04 利益相关者与边界：谁受影响、谁有事实、谁能决策

TL;DR：边界不是客观世界中等待被圈出的盒子，而是观察者为某个决策做的判断——把它视为事实会漏掉被外部化的成本。利益相关者地图回答三个问题：谁受影响、谁掌握事实、谁有权决策。这三个角色经常不是同一群人。定义问题时最常犯的边界错误是“把依赖团队和用户当作外部”，导致局部方案把成本转移到了边界外。

概念解释

边界是判断而非事实

这是从 系统、边界与目的 继承的核心观点：边界取决于观察者和当前决策目标，没有脱离问题的“正确边界”。同一个发布平台，对平台团队是产品，对业务团队是基础设施，对安全团队是风险控制——三种边界服务于三种决策。

利益相关者三类角色

关键：这三个角色经常不是同一群人。受影响的人可能没有发言权，掌握事实的人可能没有决策权，有权决策的人可能不直接受影响。定义问题时必须显式列出三类角色。

目录

五类边界检查

核心：边界外不是“不重要”，而是暂时当外生条件。对关键外生变量要记录假设，设触发条件：一旦它显著变化，就扩展边界。

利益相关者地图

## 利益相关者地图

### 受影响者（承受后果）
| 角色 | 受什么影响 | 有无发言权 |
|------|------------|------------|
| {角色} | {后果} | {有/无} |

### 掌握事实者（有一手信息）
| 角色 | 掌握什么信息 | 是否已被访谈 |
|------|--------------|--------------|
| {角色} | {信息类型} | {是/否} |

### 有权决策者（能拍板）
| 角色 | 决策权限 | 是否已对齐 |
|------|----------|------------|
| {角色} | {权限范围} | {是/否} |

### 被排除但可能重要的角色
| 角色 | 为什么暂时排除 | 何时扩展 |
|------|----------------|----------|
| {角色} | {理由} | {触发条件} |

软件工程示例

某团队定义“PR 评审等待过长”的问题边界：

利益相关者：

• 受影响：8 个开发者（等待中无法开始新任务），有发言权
• 掌握事实：CI 日志 + PR 时间戳（数据团队），尚未被访谈
• 有权决策：技术负责人（可改变评审流程），已对齐

缺口：掌握事实者（数据团队）未被访谈，当前用“感觉变慢了”代替数据——这是 问题定义总览：从现象到问题陈述 的“事实与解释分离”被违反的信号。

适用边界与误用

• 边界不是一成不变的：随着因果分析深入，可能需要扩展边界（如发现 CI 平台是瓶颈，就要纳入边界）。
• 不要为所有问题画完整地图：简单问题的利益相关者很明确，不必仪式化。
• 被排除的角色要记录：不是假装他们不存在，而是明确“为什么暂时不管”和“何时扩展”。
• 三类角色不重合是常态：不要假设“有权的人一定受影响”或“受影响的人一定有发言权”。

关联笔记

• 问题定义总览：从现象到问题陈述（边界是问题定义的结构维度）
• 系统、边界与目的（系统思维的边界概念，本专栏深化落地）
• 问题陈述：把现象转化为可操作的定义（问题陈述卡中的利益相关者字段）

参考资料

• Introduction to System Fundamentals — SEBoK
• Stakeholder Management — Project Management Institute
• 《系统之美：决策者的系统思考》— 德内拉·梅多斯