在推动实际业务的发展进程中，产品经理有时会需要做好进度管理的工作，即在“速度”和“进展”等维度上进行把控，以推动业务的实际落地。那么，进度管理应该怎么做，才更加有效和高效？在本篇文章里，作者便结合实践经验，针对进度管理这件事进行了解读，一起来看。

在明确项目范围的阶段，项目经理或产品经理承担着“领头羊”的角色，告诉大家应该做些什么事情，保证大方向不走偏；而在正式Kick Off后，团队成员开始干活了，项目经理就摇身一变，成为确保团队不走歪路，时刻提振团队士气的“牧羊犬”了。在这个阶段，项目的进度管理尤其重要。下面我将结合切身实践，与大家一起探讨进度管理应该怎么做好。

一、什么是项目进度

“进度”，顾名思义即为工作进展的速度。本质上，项目的进度管理就是对时间进行管理。重点落在“速度”和“进展”上：

• 速度，即为时间节点。时间是不可再生的，也是非常容易衡量的一个指标。时间节点能很清晰的定义，是否延误一目了然；
• 进展，即为工作成果。这是项目是否在往前推进的衡量指标，有可交付的工作成果，那就是有进展，项目就能正常推下去。

如果你是一位项目经理或产品经理，肯定思考过项目的整体工期需要多久，在哪个阶段该完成哪部分的工作；如果你是一位研发或测试，也肯定被质问过估算的项目工期是否合理，是怎么估算出来的，有没有压缩的空间…这些，都是项目进度的体现。

1. 进度延误的原因

造成进度延误的原因有很多，我从自身的经验出发，将其分为两类。

主观原因：

• 团队衔接不紧密，前置工作没有妥善的交付给下一环节；
• 没有提前准备好软硬件的开发环境，导致被迫等待；
• 产品策略没有想清楚，导致后期出现重大bug；
• 产品设计出现bug，导致返工；
• 团队人员休婚假/产假/陪产假/病假去了；
• ……

客观原因：

• 因物流原因，设备来晚了/损坏了；
• 因疫情原因，需现场施工的人员被封控了；
• 因大雨/台风/大雪导致测试场地无法被使用；
• 协调预约好的场地、人员被鸽了；
• 地震了
• ……

还有一种情况，叫”老板觉得你慢了”。可能老板远见卓识、高屋建瓴的意识到未来可能存在的某种风险，让你安排加快进度，还给了一个死节点。

看到这里是不是有些上火，别急，只要思想不滑坡，方法总比困难多。

2. 进度管理的意义何在

很多人都听说过”帕金森病”，病人会在静止的时候手抖，行动迟缓，难以保持姿势平衡，多发于老年人。但是你知道另一种“帕金森综合症”吗，这种“病”可是无论男女老幼，只要身在组织内就有可能发作。

帕金森定律，是指工作会自动地“膨胀”占满所有可用的时间。如果安排给一个任务的时间有富余，人们就会放慢节奏并消耗掉所有的富余。听起来有点拗口，但是拿你学生时期赶暑假作业来做个对比，你的感受就非常深刻了。

在放假伊始，你给自己制定了非常详细的计划，要求自己每天都做一部分作业，争取提前一个月完成，并在剩下的一个月里提升自己，下个学期要惊艳所有人！

前两三天还可以严格执行，越往后生活中的小诱惑就不断干扰着你，今天要陪朋友打球，明天要去看望外公，后天要逛公园…时间越来越少，deadline越来越近，平均每天要完成的作业越来越多。直到还剩最后两三天，只好把同学的作业借来抄抄敷衍了事。

工作中也常常如此，一个任务交付下来，无论是否简单，往往也只会在deadline前完成，甚至产生延误。而项目的工作是环环相扣紧密连接的，你的交付产生延误往往就会对其他人甚至项目的整体进度产生影响。这就是项目进度管理的意义所在，保障进度，防止延误。按照时间轴进行延展，一个详细的进度计划，能安排好团队人员的具体工作，方便计算成本和跟踪项目进度。

二、进度管理的方法路径

项目进度管理的核心在于“拆解”，我们要尽可能细致的拆分出工作的活动清单、所需资源及活动历时。围绕这个核心理念，我们将项目进度管理拆分成七个步骤。

总的来说，第②到第⑥步属于进度管理的核心动作。

第①步规划进度管理，和规划范围管理一样，属于为项目甚至企业制定标准。这一过程的输出，也就是“进度管理计划”。进度管理计划是项目工作开展的指导文件，也是企业经验的一部分，但并不会对具体的项目工作有指导作用。规划范围管理的宗旨在于“滚动式规划”，就是提醒项目管理人员在制定项目实际计划时遵循以下原则：

• 只对近期需完成的工作进行详细规划；
• 对长期的工作暂时只在较高层次进行粗略规划；
• 从时间长度看，项目的计划必然是渐进明细，从粗到细的。

那么项目的实际计划应该如何制定，工作中又该如何控制项目进度呢？让我和你一起，细细琢磨这两个问题。

三、定义活动及排列活动顺序

1. 定义活动

在项目的范围管理一文中，我们谈到了要创建工作分解结构（WBS），把项目可交付成果和项目工作分解成较小的且更易管理的单元，这些单元又叫“工作包”。其实，定义活动就是对WBS的进一步细化。所谓的活动，就是为完成工作包所必须开展的工作。活动是项目工作拆解的最小颗粒度。

举个简单的例子深化理解，一个智能音箱的研发项目可以拆解为ID设计、结构设计、硬件设计、嵌入式开发、语音识别算法开发等多个环节。硬件设计可以进一步拆解为电源管理模块设计、无线通信模块设计、MCU及外围设计、喇叭及拾音器设计等多个版块内容。一般而言，工作分解结构拆分到这个层级就可以了，即为工作包。

而针对无线通信模块设计这一个工作包，可以进一步细化，包括元器件选型，原理图设计、layout设计、单板测试、性能测试等。这些就是需要项目成员具体落地的具体行动，也叫活动。这些具体而微的活动，就是我们今天重点讨论的对象。

经过工作分解和活动细化，我们可以得到一份清单，包含了项目所需的全部活动，且对活动内容有着详细描述，这就是活动清单。活动细化的过程是需要项目群体成员共同参与的，而非一言堂。整合形成活动清单的过程，也是项目成员渐进明细的了解应做哪些事情的过程。活动清单应该至少包含活动编号、名称、用时、责任人、活动描述、成果描述这些内容。

2. 排列活动顺序

活动清单乍看上去是零散而庞杂的，无法清晰看出哪些是影响项目整体进度的关键环节，需要对其进行梳理。梳理的第一步，就是将活动的先后顺序排列出来。

先给大家出一个小学三年级数学题：妈妈让小明招待客人，洗茶杯2分钟，拿茶叶1分钟，买水果10分钟，水果摆盘要3分钟，茶水泡开要8分钟，问最快多长时间客人可以喝上热茶吃上点心？

能同时做的事要尽量同时做，可以节省时间。我们可以教小明先去洗茶杯，再去拿茶叶然后给客人沏茶，在等待茶叶泡开的时候去买水果，回来后进行水果摆盘。这样最快16分钟就可以招待上客人了。

这个生活例子揭示了项目活动之间的四种依赖关系：

• 强制依赖关系：工作中固有的依赖，是强制性的规律。如茶杯没洗好就不能泡茶，又如软件需求分析必须在对应的软件设计之前完成；
• 可自由处理的依赖关系：根据项目组的经验或偏好定义的依赖关系。如水果摆盘和洗茶杯无所谓先后，又如嵌入式开发和电气设计无所谓谁先谁后，可以同时开始；
• 外部依赖关系：通常是项目组与项目组外之间的活动关系。水果需要从水果店买，物料需要外部供应商供货都是外部依赖关系；
• 内部依赖关系：是受项目组控制的，项目内部活动的紧前关系。茶杯没洗好就不能泡茶同样也是内部依赖关系；又如硬件环境没准备好就无法进行嵌入式开发

知晓这四种依赖关系还不够，还需要有具体的方法来对活动关系进行表达，可以借助“网络图”，使用图形方式直观地描述项目活动的依赖关系，判断项目流程中的关键路径在哪里，并确认完成项目所需的最短时间。

绘制网络图时，需要使用带线箭头将各个活动连接起来。以下是一个简单的app项目进度网络图，不考虑返工的情况下，需要14个活动。

在绘制网络图时，需要注意以下原则：

• 必须正确表达项目中活动之间的逻辑关系；
• 不能出现循环回路，不能出现判断逻辑。注意和流程图之间的区分；
• 箭头都是从左往右单向的，表示时间的流逝。不能出现双向箭头；
• 只能有一个起始点和一个终点。

四、估算活动资源及持续时间

项目上所说的资源，常常指代各项活动所需的材料、人员、设备。在活动定义清楚后，就要对所需的资源进行估算。资源的估算与成本的估算紧密相关。

在纯软件的开发项目上，资源往往就是电脑和人，还是以app的开发为例：

• 用户需求调研、用户需求分析、可行性分析、产品验收：产品经理；
• 数据库设计、软件概要设计：软件架构师；
• 源代码编写、程序单元测试：安卓开发工程师、苹果开发工程师、前端工程师；
• UI设计、切图：UI设计师；
• UI还原度测试、系统测试：测试工程师。

在明确所需资源后，就需要对活动的持续时间进行估算，这一步应由团队中最熟悉具体活动的个人或小组来执行。活动持续时间的计量单位是“人天”，2个人一起干3天才能做完，那这项活动就需6人天。需要注意，具体的开发工作量及测试工作量的评估，需要在需求导入成功后才可进行。

常见的估算活动持续时间的方法有三种：

1. 专家判断：请本领域经验丰富的人来判断；
2. 类比估算：借鉴相似活动或项目的历史数据，来估算当前活动或项目的持续时间。注意类比引用的项目，其复杂度和规模需要和本项目接近；
3. 参数估算：基于工作量和生产率的概念进行估算。如测试一个模块需要用时2天，那测试7个模块大约用时14天。

估算毕竟存在准确度的问题，有些时候还会采用加权的思想对估算结果进行修正。首先需要估算出该项活动的乐观时间、最可能时间、悲观时间，那期望的工期就是（乐观+悲观+4X最可能）/6。

需要注意，大家在估算活动持续时间时往往比较保守，会增加一定的安全冗余时间。这一点要有心理预期。

在各项活动的持续时间估算完成后，需更新在活动清单和网络图上。需将耗时最长的环节标注出来，这就是本项目的关键路径。

五、制定进度计划

很多人觉得制定进度计划就是画一个甘特图，或者觉得计划赶不上变化，干脆就不列计划了，这些都是常见的误解。其实制定进度计划的核心思想在于“规避风险”。

我们在绘制网络图时，有一个隐含的假设条件，那就是资源可以无限调用，人员也都是万能的。而实际情况往往是资源捉襟见肘，总有优先级更高的项目把你的人薅走；你的研发也都是新手，程序一跑就报错还找不到原因…

我给你推荐两个方法，留缓冲和做假设：

• 留缓冲：所有的活动都是越早开始约好，不给灵活机动的时间。同时将每个活动的安全冗余时间全部砍掉，集中到关键路径的末段作为缓冲。简单、粗暴、有效；
• 做假设：基于已有的进度计划，预置各种可能的场景，来评估项目进度计划在各种不利条件下的可行性，并准备应急预案。这种方法适用于风险可预见时，只能尽可能的减轻意外情况对项目的影响，用起来比较费脑子。

在调整好各项活动的持续时间后，需以甘特图的形式将计划整理公布出来。

六、在工作中控制项目进度

控制进度属于项目长期活动的一部分，并不是某种刻板僵硬的动作，而是需要结合项目实际灵活采用不同手段，来对项目的实际进展情况进行控制，使项目能够按时完成。控制进度的依据，就是项目进度计划。

1. 进度控制的步骤

项目管理工程师或项目经理在实际工作中，需要定期收集项目完成情况的数据，将实际完成情况与计划进行比较，若发现与计划存在偏差，需要采取一些纠偏措施，以让项目来到正常轨道上。进度控制的主要步骤如下：

• 分析进度，找出哪些地方需要纠偏。无论是进度延后还是进度提前，其实都应考虑纠偏。总的来说就是“调拨资源”，让项目的发展符合预期。但是进度提前的情况很少见，若真的发生可以考虑将人力调用到其他关键活动上，以规避风险，减少人力浪费；
• 确定应采取哪些具体的纠偏措施。方法很多，待会儿挨个来看；
• 将纠偏措施列入计划，并修改计划。纠偏措施也是一种动作，会对项目进度产生影响，因此需要在决定采取某种纠偏措施后及时更新项目计划；
• 重新估算项目进度，评估纠偏措施的效果如何。纠偏措施执行一段时间后，需要对效果进行评估、回顾，并决定是否采取进一步措施。

2. 压缩工期的方法

想要在有限的时间内完成被耽误的事，我教给你“八字真经”，又称“赵氏赶工箴言”，传男也传女。那就是：“摇人”、“加班”、“优化”、“躺平”。

• 所谓“摇人”，其实就是调拨更多的资源，人力也是一种资源。可以将团队成员替换为经验更加丰富的人，俗称“换老杆子”；也可以增加人手，安排赶工。会增加成本；
• “加班”很常见，但是不能为了压榨员工盲目的安排加班。一般是在关键路径上的关键节点产生延误风险时，安排周末或节假日加班；会影响情绪；
• 所谓“优化”，是指对工作环节和工作效率的优化。可以将关键路径上原来是先后顺序的活动调整为至少部分并行。会增加风险；
• 所谓“躺平”，当然不是真的两手一摊无所作为，而是适度的妥协与放弃。可以选择降低要求，或者缩减活动范围。可能会被客户骂。

一句话总结，项目的进度控制，就是拆解活动、做好预期、及时调整。项目就像是一艘小船，想要安全及时的到达彼岸，需要项目经理时刻保驾护航。当你制定好“航线图”，带领大副二副水手长向着黄金海岸靠拢时，记着盯紧罗盘、把稳船舵，时刻准备着调整风帆的朝向。