让里程碑评审避开误区见成效

对于软件项目管理来说，创建项目里程碑监督里程碑的完成，召开里程碑评审是一项基本要求。虽然每个软件项目都会进行以上这些活动，可是项目里程碑评审常常会流于形式，没有发挥作用，项目交付节点该延期还是延期，交付后的问题也是不断出现。

所以如此是因为我们对里程碑评审的理解存在一些误区。

误区一，里程碑评审只能设置在阶段末。

在《软件工程最佳实践》一书中，罗列出了13个典型的项目里程碑，分别是：

1. 需求审查。

2. 项目规划审查。

3. 成本及质量评估审查。

4. 外部设计审查。

5. 数据库设计审查。

6. 内部设计审查。

7. 质量规划及测试计划审查。

8. 文档规划审查。

9. 部署规划审查。

10. 培训规划审查。

11. 代码审查。

12. 每个开发测试阶段。

13. 顾客认可度测试。

从这个典型的里程碑列表来看，里程碑不仅可以设置在每个开发测试阶段，还可以设置在你想关注的可交付成果的检查点上。因为通常情况下，里程碑的结束是对可交付成果审查的直接结果。

误区二，把里程碑评审当做技术评审。

里程碑评审不是技术评审，而是管理评审。里程碑评审要确认的是可交付成果的审查结果，而不是可交付成果本身。可交付成果的问题，应当在之前的同行评审中去发现，应当在已经提交里程碑评审的审查结果中体现。里程碑评审要确认项目是否存在问题，问题应当如何解决，而不影响项目进度；要确认项目是否存在重大风险风险，风险应当采取什么缓解措施……而这些内容的确认，是依据项目已经完成的工作成果来进行，其中就包括了可交付成果的审查结果。

误区三，里程碑评审只关注进度。

虽然项目进度是里程碑评审关注的内容之一，但它并不是唯一要关注的内容。里程碑要评审项目的承诺、计划、状态和风险，进度计划只是其中之一。这四项评审内容中，最不容易确认的是项目的状态。项目的状态正常与否，不是通过项目报告中所有任务都完成，所有问题都解决，所有风险未发生这种结论就能做出判断的。如果仅仅是这样，里程碑评审就如走马观花一样，发现不了项目潜在的问题。里程碑评审也会流于形式。

正如前文所说，里程碑评审应由授权人员对项目的工作成果进行确认，评审人员应当符合项目的交付成果及其审查报告，从中判断项目是否有潜在的问题。这样的里程碑评审才会发挥效用。

以上是里程碑评审常见的一些误区。

里程碑评审是有效的项目管理手段，很多失败的项目都是由于没有进行里程碑评审，或者里程碑评审无效造成的。避开里程碑评审误区，加深里程碑评审的理解，让里程碑评审这一手段真正发挥作用是软件项目管理追求的目标。