DICE 框架用于 IT：项目风险评估

DICE框架：从项目启动第一天预测IT项目成败

波士顿咨询集团提出的DICE框架，可在项目启动前对成功概率进行量化评估。该公式综合考量四个关键因素：周期（D）、完整性（I）、承诺度（C1和C2）以及投入强度（E）。最终得分决定项目所处的风险区间：7–13分表示成功，14–17分为需警惕，18分及以上则预示失败。

每个参数按1（最优）到4（严重风险）打分。计算公式为：DICE = D + 2×I + 2×C1 + C2 + E。其中I和C1权重较高，凸显团队能力与领导支持的关键作用。

参数详解

周期（D）：沟通频率

衡量进度、问题和截止日期的审查频次。定期沟通有助于掌控项目节奏，又避免陷入微观管理。

| 分数 | 条件 |

|------|------|

| 1 | 每1–2周一次 |

| 2 | 每3–4周一次 |

| 3 | 每两个月一次 |

| 4 | 频率极低 |

完整性（I）：团队专业能力

评估团队成员（含负责人）的技术水平、经验与资历。乘以2的系数体现其核心影响：能力薄弱将显著推高风险，而提升则能带来明显正向回报。

| 分数 | 条件 |

|------|------|

| 1 | 专业人员组成 |

| 2 | 多数具备能力 |

| 3 | 多数能力不足 |

| 4 | 能力严重欠缺 |

承诺度（C）：协同与支持

分为C1（领导层）与C2（团队内部）。C1权重翻倍——自上而下的支持是抵御干扰的关键屏障。

C1（领导层）：

| 分数 | 条件 |

|------|------|

| 1 | 全力支持 |

| 2 | 中立态度 |

| 3 | 暗中反对 |

| 4 | 明确反对 |

C2（团队）：

• 主动接受；
• 无异议；
• 抵触（通过拖延实施破坏）；
• 强烈反对。

投入强度（E）：工作负荷压力

超出核心职责的时间占比。

| 分数 | 条件 |

|------|------|

| 1 | ≤10% 或为主要任务 |

| 2 | 11–20% |

| 3 | 21–40% |

| 4 | >40% |

实战案例：测试自动化项目落地

一个QA团队推行测试自动化框架。项目周期：一个季度，额外投入30%，无前期经验，负责人持乐观态度，团队热情高涨，但缺乏定期同步机制。

初始评估：

• D=4（无同步）
• I=4（无经验）
• C1=2（中立）
• C2=1（积极）
• E=3（30%）

DICE = 4 + 8 + 4 + 1 + 3 = 20（失败）。

根本原因：低估工作量，问题积压未解决，缺乏对缺陷的防护机制。

应对措施：

• 引入每周同步会议：D=1 → DICE降至17；
• 将周期延长至两个季度：E=2 → DICE降至16；
• 获得负责人主动支持：C1=1 → DICE降至14；
• 引入导师/专家：I=2 → DICE降至10；
• 组建有经验团队：I=1 → DICE降至8（成功）。

监控与应用建议

当发生关键变动时重新计算DICE：核心人员变更、新增任务等。在同步会议中检查D项表现，项目复盘可揭示估算偏差。

DICE适用于：

• 跨团队协作项目；
• 流程或架构调整；
• 需要行为模式转变的举措；
• 周期超过一个月的项目。

IT领域典型场景：持续集成/部署流水线、系统迁移、新型测试模型、组织文化变革。

集体评分可减少主观判断——意见分歧往往暴露隐藏风险。

核心启示：

• I与C1权重高：务必强化团队实力并争取领导支持；
• 高频同步（D=1）能迅速将项目从失败区拉入预警区；
• 团队抵触（C2=3–4）常是隐性破坏信号；
• 工作负荷超20%且无优先级保障，是项目失败的首要诱因；
• 事后分析不可省略，用于校准与经验沉淀。

— Editorial Team