项目总是延期？你需要知道把控项目进展的优秀方法

项目进度管理一直是困扰 CTO 和项目经理们的问题 ，说好 Deadline 一延再延、明天上线今天又测出无数个 bug、花了大半年时间吭吭哧哧做出来的功能已经不符合市场需求····

因此今天介绍一套度量项目进展的方法——「 里程碑计划法」，结合本次 ONES 项目计划功能，推荐给为项目管理苦恼的团队。

在产品研发当中会出现这样的情况：产品经理把一堆需求交给程序员，希望他们一个月后做好。这样做的结果常常是：前半个月可能很悠闲，因为大部分人都有前松后紧的工作习惯。后半个月开始认真干活，倒数第三天紧赶慢赶总算码出来了，最后测试的时候又出了一堆问题来不及修改，于是只能推迟上线时间，每天加班熬夜修补……

当然还有第二种选择：第一周业务和产品人员列需求，列完需求技术人员一起参与评审。确定下来后开始设计，设计完成后再由产品评审。通过之后，第二三周编写代码，同时测试人员开始准备测试用例，最后一周测试，修复各类 bug，没有大问题的话月底即可上线。

在第二种选择中，增加了需求和设计的环节，并把每个环节都卡好了时间点和周期。没错，这里的需求评审和设计评审，可以看做这个项目当中的里程碑。

里程碑可以简单地理解为阶段性的胜利。完成调研、需求评审常常作为一个大型项目的里程碑，而小型项目则可能会将每周迭代的小版本作为里程碑。总结来说，里程碑指的是某一个时间点上可交付性的阶段性成果，或者说某个重要的事件。

大型项目常常涉及多个部门，执行高度分散化。在如此复杂的流程中，一个小小的错误经过时间和多个环节的累积可能触发连锁反应，导致最终结果出现问题。因此这类型项目往往需要一套工具或者解决方案，来帮助团队在项目的生命周期中追踪关键事件，预见风险和错误，缩小发现问题和处理问题之间的时间差。

以往软件厂商会针对这种情况向大企业提供定制，但是软件定制的周期十分漫长和繁琐，于是一部分大企业为了减少这种定制，选择雇佣专家来实施这一类解决方案，但这两种做法的成本都十分高昂。

里程碑计划法作为一套通用的底层模式，实施难度和成本相比前两者降低了不少。 各种工作场景的项目在里程碑模式下都可以抽象为一个时间轴来管理，只有时间轴上的各个里程碑得到满足，才算是在 Deadline 之前完成目标。

软件开发都会经历一定阶段，例如信息搜集阶段、需求分析阶段、设计阶段、开发和测试阶段。每个阶段都会产生交付物，每一份交付物的提交并通过就说明完成了一个阶段的工作。一般情况下是在确认这一份工作成果后，才会进入下一个阶段的工作。因此，每一份交付物的完成就可以设置为开发过程中的里程碑。

由于各个阶段经常是由不同部门、不同负责人来完成的，因此里程碑模式在这里的作用是帮助关联、捕获、评估不同部门和项目中的多个事件，度量项目进度，对未来可能出现的延误或者错误进行预警，使团队能够快速响应并采取行动。

1）首先是做好项目规划，为每个里程碑设置可量化的检验标准。很多团队都重视阶段性成果的提交而忽略检验环节，这导致了这些项目尽管像模像样地设置了里程碑，但效果依然没有改善。因此，一套清晰明确的标准是至关重要的。

2）除了方法论，你还需要一个好用的工具。运用 ONES 的「里程碑」功能，在合理评估工时的基础上，为每个里程碑设置明确的截止时间、前后置依赖关系和目标交付物。

3）设置好里程碑之后，还可以为里程碑设置基线版本，使用基线对⽐功能可以直观地展示里程碑完成度，方便监督和做出实时调整。

在里程碑开发模式下，每一阶段工作的推进，都尽力在前一阶段已被确认和修正过的工作成果的基础上，因此风险和错误的累加可以相对降低。以局部把控整体，使整体的开发质量得到保障。

与程序员有关的段子常常拿程序员与产品开玩笑，研发人员作为需求接收方似乎永远处于被动地位，于是只能周而复始每日熬夜加班完成无止境的需求。 如此一来，团队的研发进度和质量就得到保障。

但这种矛盾并非不可调和，如果项目经理和产品经理能够清晰地设定每个月的目标，并且在每周达成一个或多个里程碑，程序员做完这些事情就会意识到“这周的工作做完了”，成就感油然而生，这样一来，里程碑在这个过程中也起到了激励作用。

同时可以保证团队里每个人都知道整体进度，项目就不会失控。

里程碑用超越项目的维度来管理工作，串联起不同的职能部门，不同的项目。它能够帮助团队有效地：

（1）控制开发节奏

（2）预留缓冲时间

（3）激励团队成员

（4）分散/控制风险

如此一来，团队的研发进度和质量就得到保障。