风险管理与变更管理

第 29 章 · 软件工程

不确定的事，先认出来再打算盘。 风险是「可能发生且会对目标产生负面影响」的不确定性——技术难点、依赖延期、人员变动、需求剧变都算。风险管理要识别、评估、应对；变更则无处不在，需求变、设计变、环境变，若没有变更控制与影响分析，容易改一处崩一处。本章讲识别技术、进度与外部风险、风险应对（规避、减轻、转移、接受）、变更控制流程与影响分析，以及在敏捷中的轻量变更管理。

一、识别技术、进度与外部风险

风险识别要回答：什么可能出问题、出了会怎样、概率与影响多大。常见维度：技术风险——新技术/架构不熟、性能/安全/兼容性未知、依赖不稳定、技术债高；进度风险——估算偏差、依赖延期、资源不足、需求蔓延；外部风险——政策与合规、供应商、市场与优先级变化、关键人离职。识别方式可包括：头脑风暴、检查清单、历史问题复盘、依赖与假设列表。识别后做简单评估：概率（高/中/低）× 影响（高/中/低），优先应对「高概率高影响」和「高影响」项。

技术风险

新技术不熟、性能/安全未知、依赖不稳、技术债高；通过 PoC、评审、分层与接口降低。

进度风险

估算偏差、依赖延期、资源不足、需求蔓延；通过缓冲、优先级、范围弹性应对。

外部风险

政策、供应商、市场与优先级变化、关键人离职；通过多源、合同与知识留存缓解。

三类常见风险及应对方向

风险优先级：概率 × 影响，优先高-高与高影响

二、风险应对：规避、减轻、转移、接受

对已识别的风险要选应对策略并落实行动：

规避 Avoid消除风险来源或不做该事。例：不用不成熟技术、不接不可控依赖。

减轻 Mitigate降低概率或影响。例：PoC 验证、评审、测试、缓冲时间、备份方案。

转移 Transfer把部分后果转给第三方。例：保险、合同条款、外包部分工作。

接受 Accept明知有风险但选择承担，可设触发条件与预案。例：低影响风险、成本过高才应对的。

四类风险应对策略

每条风险最好有负责人、应对动作、复查时间；风险清单定期回顾（如每 Sprint 或每发布），新风险纳入、已发生或已过期的关闭。

三、变更控制流程与影响分析

变更指对已定范围、设计、计划或配置的修改。若随意改而不评估影响，容易引入缺陷、延误、范围失控。变更控制通常包括：提出（谁、改什么、为什么）→ 影响分析（对进度、成本、质量、依赖的影响）→ 决策（采纳/拒绝/延后，谁拍板）→ 实施与沟通（按新方案执行、通知相关方）。影响分析要问：影响哪些模块/接口/文档/测试？是否需要回归？是否影响发布计划？依赖方是否要同步？小变更可走简化流程；大变更需评审与签字。

提出变更 → 影响分析 → 决策 → 实施与沟通

变更控制流程：提出 → 影响分析 → 决策 → 实施

四、在敏捷中的轻量变更管理

敏捷不反对变更，而是用 Backlog 与优先级吸收变更：新需求或变更不「插队」进进行中的 Sprint，而是加入 Product Backlog，由 PO 排优先级，在下一轮 Planning 或发布规划中纳入。这样变更可见、可排期、不破坏当前迭代承诺。若变更确实紧急且必须插入，则与团队协商：替换或缩减本 Sprint 范围，或接受延后发布。轻量变更管理要点：变更进 Backlog、PO 负责优先级、Sprint 内尽量不插单、紧急变更走明确例外流程（谁申请、谁批、如何补偿范围）。

敏捷中的轻量变更管理

变更不直接插队，而是进入 Backlog，由 PO 排序；Sprint 内目标稳定，变更在下一轮纳入。紧急变更需明确：谁申请、谁批、是否替换本 Sprint 范围或接受延期。

新需求/变更 → 写入 Backlog → PO 排优先级 → 下一 Planning 或发布规划纳入
Sprint 内插单为例外，需协商范围替换或延后，并记录原因

一句话： 风险分技术、进度、外部等，识别后评估概率与影响，优先应对高-高与高影响。应对策略：规避、减轻、转移、接受，并落实负责人与复查。变更控制：提出 → 影响分析 → 决策 → 实施与沟通；影响分析看模块、回归、计划与依赖。敏捷中变更进 Backlog、PO 排优先级、Sprint 内尽量不插单，紧急变更走例外流程。

小贴士： 做影响分析时列一张「会动到的清单」：哪些代码、配置、文档、测试、依赖方，改完按清单检查与通知，不容易漏。

五、小结

风险识别包括技术、进度、外部等维度；评估概率与影响后优先应对高-高与高影响。应对：规避、减轻、转移、接受，有负责人与复查。变更控制：提出、影响分析、决策、实施与沟通；影响分析覆盖模块、回归、计划与依赖。敏捷下变更进 Backlog、PO 排序、Sprint 内少插单，紧急变更走例外。下一章进入构建、打包与制品管理，从计划与协作过渡到「代码如何变成可部署的产物」。