风险与沟通
风险是「还没发生的坏事」，问题是「已经发生的坏事」。项目失控往往不是能力问题，而是风险没有被说出口、干系人没有被对齐。本篇把两件事放在一起讲：用风险管理把不确定性变透明，用结构化沟通让信息在正确的人之间流动。
风险 vs 问题 vs 假设
| 名词 | 定义 | 示例 |
|---|---|---|
| 风险 | 未来可能发生并带来负面影响的不确定事件 | 第三方服务可能涨价 |
| 问题 | 已发生、需立即处置 | 第三方已停止免费额度 |
| 假设 | 未经证实就当真的前提（风险的来源） | 假设现有用户会接受改版 |
先分清三者再动手：风险靠「提前应对」、问题靠「立即处置」、假设靠「尽快验证」（验证方法与产品方向的实验互链）。
风险管理五步
| 步骤 | 动作 | 产出 |
|---|---|---|
| 识别 | 全员头脑风暴：技术 / 需求 / 进度 / 外部依赖 / 资源 | 风险清单 |
| 评估 | 定概率（高/中/低）× 影响（高/中/低） | 概率-影响矩阵 |
| 应对 | 对高风险项制定应对策略 | 风险登记表 |
| 跟踪 | 定期复查概率与影响是否变化 | 更新后的登记表 |
| 复盘 | 沉淀哪些风险常被低估 | 风险检查表（喂给下一项目） |
应对四策略
| 策略 | 做法 | 适用 |
|---|---|---|
| 规避（Avoid） | 消除风险源 | 换掉不稳定的第三方方案 |
| 转移（Transfer） | 风险代价转给他人 | 外包、保险、购买 SLA |
| 减轻（Mitigate） | 降低概率或影响 | 提前做技术验证（SPIKE） |
| 接受（Accept） | 明知风险但接受，保留应急计划 | 概率影响双低，或应对成本更高 |
风险登记表模板
markdown
| ID | 风险描述 | 类别 | 概率 | 影响 | 等级 | 应对策略 | 负责人 | 触发器 | 状态 |
|----|---------|------|------|------|------|---------|--------|--------|------|
| R1 | 第三方地图配额不足 | 外部 | 高 | 高 | 🔴 | 减轻：预研自建方案 | 张三 | 配额>80% | 跟踪中 |触发器是关键：没有触发条件的应对是空话——要写明「到什么信号出现时启动应急计划」。
干系人管理
识别与分析
| 干系人 | 关注点 | 影响力 | 期望参与度 |
|---|---|---|---|
| 赞助人（Sponsor） | 目标/预算 | 高 | 决策层，高风险才介入 |
| 业务负责人 | 范围与验收 | 高 | 需求决策、评审出席 |
| 最终用户 | 可用性 | 中 | 反馈与试用 |
| 开发团队 | 清晰与稳定 | 中 | 全程 |
权力-利益矩阵（Power-Interest）
| 权力 \ 利益 | 低利益 | 高利益 |
|---|---|---|
| 高权力 | 令其满意（Manage Satisfied） | 重点管理（Manage Closely） |
| 低权力 | 监督即可（Monitor） | 随时告知（Keep Informed） |
常见错误：把精力全花在「低权力高利益」的活跃用户身上，却忘了「高权力低利益」的赞助人只在出事时看一眼——他的第一印象来自你的汇报，所以要定期喂信息。
RACI：把「谁该知道」显式化
| 角色 | 含义 |
|---|---|
| R（Responsible） | 具体执行 |
| A（Accountable） | 最终负责（一个任务仅一个 A） |
| C（Consulted） | 事前征求意见 |
| I（Informed） | 事后知晓 |
一张 RACI 能消灭大部分「我不知道这事 / 我以为是你在做」的协作事故。
沟通机制设计
| 机制 | 频率 | 参会 | 目的 |
|---|---|---|---|
| 每日站会 | 日 | 开发团队 | 暴露阻塞（不解决细节） |
| 周度项目同步 | 周 | 全部干系人 | 进度、风险、决策 |
| 里程碑评审 | 按里程碑 | PO + 干系人 | 对成果做正式验收 |
| 一对一 | 每周/双周 | 经理 ↔ 成员 | 个人层面议题 |
| 异步文档 | 持续 | 全员 | 决策记录、进展可追溯 |
三条沟通纪律：
- 决策留痕：口头拍板 + 书面记录缺一不可，评审结论当日落到文档；
- 坏消息提前说：风险升级路径要明确——「什么时候该让谁介入」写在项目章程里，别让问题悄悄变大；
- 会议必须有产出：每个会结束前确认「决定 / 行动项 / 遗留问题」，无议程无结论的会直接取消（僵尸会议是团队最大的隐性成本）。
冲突处理：先分类型再选策略
| 冲突类型 | 特征 | 处理取向 |
|---|---|---|
| 目标冲突 | 该做什么优先级不一 | 回到产品/项目目标排序（见需求与范围） |
| 流程冲突 | 怎么做、标准不一 | 用 DoD/规范成文对齐（见方法论与流程） |
| 人际冲突 | 情绪与关系问题 | 一对一解决，不公开争论对错 |
Thomas-Kilmann 五种模式：回避 / 迁就 / 竞争 / 妥协 / 合作。技术分歧用「合作」找第三条路（先各退一步做验证实验）；原则性问题用「竞争」守住底线；琐事分歧快速「妥协」不内耗。
常见坑速查
| 坑 | 表现 | 应对 |
|---|---|---|
| 风险只是清单 | 开完会就锁进抽屉 | 每周例会过一遍登记表状态 |
| 概率影响打和牌 | 全部「中中」，分不出重点 | 强制排序，取 TOP10 深挖 |
| 报喜不报忧 | 风险到爆雷才被知道 | 建立无责的风险上报文化 |
| 干系人漏了关键人 | 上线前赞助人突然反对 | 权力-利益矩阵逐人核对 |
| 会议成瘾/无产出 | 周会 2 小时没结论 | 明确产出物，超时砍议程 |
| 冲突被压住 | 表面和气，底下对抗 | 识别类型，人际类尽快一对一 |
检查清单
- [ ] 已列出风险清单，按概率×影响排序并圈定 TOP10
- [ ] 高风险项都有应对策略 + 负责人 + 触发器
- [ ] 风险登记表在固定会议中被复查更新
- [ ] 干系人已完成识别与权力-利益矩阵分析，关键人沟通频率有安排
- [ ] 核心流程有 RACI，每任务仅一个 A
- [ ] 决策留痕、坏消息升级路径已写入项目约定
- [ ] 会议均有议程与产出，僵尸会议已被清理