项目韧性是什么
韧性指项目与团队面对扰动时的吸收、适应与恢复能力，覆盖人员变动、供应商断供、环境故障与需求突变等场景。它的实现方式不是加厚计划，而是设计出在部分能力失效时仍能继续交付的结构：关键角色互备、组件冗余、模块化交付与快速决策通道。韧性与效率存在权衡，适度冗余换取的是扰动下不中断的交付能力。
基本信息
| 三种能力 | 吸收扰动（扛住冲击）、适应变化（调整方式）、恢复能力（快速回到交付） |
|---|---|
| 设计手段 | 关键角色互备、组件冗余、模块化交付、快速决策通道 |
| 关键特征 | 关键知识不集中在单人身上，单点故障有备选路径 |
| 验证方式 | 演练与故障注入，而非纸面方案 |
| 成本特征 | 需要持续投入，属于效率的主动让渡 |
典型使用场景
- 核心技术骨干有离职或长期休假风险，需要提前安排互备与知识文档化
- 单一供应商或单条产线支撑关键交付，需要评估断供后的恢复时间
- 生产系统切换或大版本上线，需要明确的回退条件与决策授权
- 跨时区或分布式团队，本地成员缺位时要有人能接管现场事务
- 外部环境波动大（政策、汇率、供应链），需要定期检查方案在当前假设下是否仍然成立
韧性设计手段
韧性设计手段
关键角色互备：为每个关键职责设 AB 角，B 角参与真实决策而非旁听
关键组件冗余：备用供应商、灾备环境、并行链路
模块化交付：单模块故障不阻断整体发布
快速决策通道：紧急情况下授权先处置、事后补审批与复核
知识文档化：决策记录与操作手册随工作流更新，而非事后补写演练校验
| 场景 | 校验点 | 不合格信号 |
|---|---|---|
| 角色缺位 | AB 角能否接管并完成关键动作 | 接管时才发现权限与知识都不具备 |
| 供应商断供 | 备选导入需要多长切换时间 | 有备选名单但从未做过切换 |
| 环境故障 | 切换步骤与回切条件是否明确 | 步骤只存在于个人记忆里 |
| 需求突变 | 方案调整的决策周期 | 每次调整都要走完整审批链 |
韧性与效率需要权衡：冗余会占用资源与工期，但不做冗余的项目在一次冲击下就可能错过关键窗口。取舍依据是失控后果的可承受程度。