项目经理经常会被一些不了解的人问

，“项目经理不就是管进度的么？”，可见管理进度是项目经理多么重要的一个职责，当然这样问的小伙伴多少对项目经理的职责缺乏理解
，但不妨碍进度管理是项目经理重要职责这一事实。接下来我们就来看看怎么做好进度管理

，要如何一步步做好项目的进度管理。

一
、制定计划

互联网软件项目

，唯快不破的文化氛围下，造成程序员对于计划往往不屑一顾
，经常会有这样的反对声音
，“计划赶不上变化，做计划有什么意义”，那是不是制定计划真的不重要呢？那必然不是，那计划的价值究竟是什么呢？

1.1 为什么需要计划

其实
，无论是在传统项目管理中
，还是敏捷迭代中，计划都是完成目标的第一步
。

美国质量管理专家沃特·阿曼德·休哈特（Walter A. Shewhart）首先提出的，由戴明采纳、宣传的著名的管理理论“PDCA环”，也称为戴明环，其中P（Plan）计划就是第一步

，然后才是行动D（Do)，C(Check)检查，A（Action）改进（行动，跟前面的行动有点重叠，我更愿意将它解释为改进。

图1.PDCA循环

《高效能人士的七个习惯》这本书提到一个概念
，可以帮助大家重新理解计划的价值。

任何事情都是先在头脑中构思，也就是智力上的第一次创造，然后再付诸实践，也就是体力上的第二次创造

头脑中的第一次创造，就是计划

，也是头脑中对于未来的一种正向的预想，有助于我们实现计划。所以如果你想让你的项目顺利交付，就好好的做计划
，制定计划的过程也可以帮助我们发现问题和风险。

1.2 那么如何做计划呢

提到制定计划，大家应该都听过WBS（Work Breakdown Structure)，什么是WBS，又该如何来制定WBS。学习过PMP的人应该对这个词不会陌生，WBS就是工作分解结构，把项目工作拆解为具体的
，易于管理的子任务

。

这里需要遵循的原则就是不漏不重
，以及适度，不漏就是需要考虑把与项目范围相关的所有事项都包括在内
，不重就是避免任务和任务之间交叉，WBS分解后的最小工作包都需要分别对应到人
，明确交付的时间节点
，如果出现重叠就会造成职责不清
。

拆分的颗粒度是越细越好吗
？如果每个任务都拆分到1个小时以内
，是不是会更加好管理，但实际上这是不可能的，因为任务拆得太细，会使管理成本急剧上升。我们的2周一个迭代的管理中，一般任务颗粒度在4~16小时，大部分任务控制在1天以内
，这样我们每天在晨会跟进任务的时候
，就可以看出是否存在延期

，及时发现问题并作出调整
。

原则解释起来简单
，但是在实际操作中
，却非常容易犯错
。尤其是不漏
，项目中就经常会出现这样的情况，项目临近尾声，才发现按照产品要求
，此需求需要完成另一套环境上进行测试验证，而实际在评估的过程中根本没有把此项工作考虑在内。

另外

，开发同学评估工作时，往往容易忽视研发以外的工作评估，例如，环境部署
、数据验证（一些数据统计类的需求

，由于测试环境数据不足或者无法真实模拟真实数据
，还需要考虑在预发环境中进行数据验证工作量）等等。那么如何来避免呢？

我们在实践过程中积累了一套创建任务的规范，此规范除了建立统一的管理规范以外，也起到了提醒和检视的作用
。这份规范包括两部分：任务的标题规范、任务内容规范

图2.任务创建方法

1、任务的标题规范，分为三个部分

1）标明角色，是前端、后端、还是测试

2）需求内容，把此任务对应的需求名称简要描述作为任务的一部分

3）具体内容，是完成开发任务，还是完成前后端联调，亦或是测试任务。

简单来说，标题中的这三部分就是2W1H（Who
、What、How）

2、任务中具体内容部分

1) 预计工时
，任务的颗粒度需要控制在4~16个小时之间

2) 截止日期
，这部分表示完成这个任务的时间W（When）

这个规范一个任务需要包括3W1H这四个方面展开的
。

任务是作为计划的一部分，有了任务，还需要做一个重要的动作就是核对任务，识别好相互之间的依赖关系，定义好任务的前后顺序，最后在团队中同步（邮件或者即时聊天工具）
。

二、设置检查点

检查属于项目管理中的监控过程组，没有检查的计划无法真正得到落实，因为计划是建立在假设的基础上的，而检查就是将假设与实际情况进行比较，及时发现问题
，作出调整
，以确保项目目标的达成
。

Scrum的特点就是及时检查
，及时反馈，具体的检查点有哪些呢？除了前面Daily Scrum（每日站会）
，还有Sprint Review（评审会）
。

瀑布型项目中也同样有检查点，他的检查点一般在阶段交付的检查上，称为交付的验收，也有一些方法是公用的
，瀑布模式中也同样可以安排日会，在项目前期需求比较模糊的阶段，或者项目冲刺阶段，都可以安排日会来每日同步进展和风险。

Scrum中的Daily Scrum通常在同一时间统一地点举行，一般会回答三个问题：昨天完成了什么
？今天计划完成什么？有没有什么问题或者风险
？可以帮助大家很好的同步团队进展，及时发现和解决项目问题
。

这里要特别注意在同步进展的时候
，经常出现的一个词，就是“差不多”
，这个功能是否已经完成了，团队成员回答“差不多吧”，或者“完成80%”。这个时候项目经理就要注意了
，在这个“差不多”中间其实“暗藏玄机”，可能就是一个风险信号
。听到这个词你需要停下来
，要求对方把详细的信息量化的表达出来，然后重新进行评估，分析具体的问题

，再有针对性的提出解决方案。量化的表达出来

，是问题被解决的基础。举个具体的例子：

项目团队来了一个新成员N，一天早会的时候
，跟进到他对应负责的需求时，他回答是"差不多吧
，加加班应该可以完成的"，这句话的潜台词其实是“按期完成存在风险”，因为当前他处于接口开发过程中
，于是我接着往下问，”具体有哪些接口，每个接口的进展情况分别是怎么样的呢？”于是这位同学回答说，“我需要回去整理一下”
。

早会后
，这位同学把所有接口的进展情况整理发到群里，可以看出其他接口都已经完成处于待自测状态，还有一个复杂接口还未完成，由于刚来项目组不久这个接口对他来说需要花费更多的时间去熟悉，团队其中一个组员看到他发出来的接口完成情况清单，随即自告奋勇决定帮助N同学完成待开发的接口功能，及时解除了风险。

三、适时调整

适时调整的方式有很多，快速可以处理的问题，我们会直接在Daily Scrum中就做出调整，如果Daily Scrum中无法及时解决的
，我们会在会后组织小会展开讨论
。一般会从范围
、进度
、成本三个角度考虑做出调整
，以满足交付要求
。

1)、范围的角度，需求、项目范围是否可调整

需求范围一样遵循2/8原则
，可以根据需要交付内容的优先顺序
，优先完成对客户重要的需求，或者计划时是否有备选方案可供调整
，比如简版的实现方案，出现延期时立即启用备选方案
。

2)
、成本的角度
，是否需要安排加班
，或者外包出去

加班或者外包出去，都会导致成本的增加，但是在面对团队人员有限
，或者短期工作量增加的情况
，短期加班或者将功能外包也是不错的选择。

3)、进度的角度，及时汇报或者升级风险

如果以上几个方面全部做出考虑，依然无法解决延期问题，那么及时汇报也是进度管理中非常关键的一个方面
，哪怕计划做得再好
，项目中总是会出现这样那样的意外情况
。

当意外情况发生的时候
，项目经理要做的要把项目进度及时的同步出来
，不要让项目进度成为你一个人知道的秘密。有些情况下

，团队内部无法做出调整时，可以在跟业务方
、其他重要项目干系人沟通的过程中得到支持，以帮助解决问题。

作者介绍
：傅益利

PMP/Prince2/CSM
；

现任国内500强公司PMO，项目管理经验超过10年。

近期热文
：

• 百万年薪PMO&项目经理职场影响力是如何炼成的
  ？【精华笔记】
• PMO&项目经理如何高效解决问题看这篇文章就够了
• 一图掌握项目管理的核心工具WBS工作分解结构
  ，PM必备技能！