项目经理经常会被一些不了解的人问
，“项目经理不就是管进度的么
？”，可见管理进度是项目经理多么重要的一个职责

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

一、制定计划

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

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必备技能！