制订项目进度计划的讨论

今天来讨论一下怎么PMP的指导，我们应该怎么去制订项目进度计划。在这里想先讨论一下，项目开发到底需不需要制订计划。其实很多项目都是有计划的，只是在与计划的详细程度或者说是对计划的认识与理解的不同。就比如我早期在的公司中，所谓的计划其实是一个工作周期的承诺（而且是没有文档记录的），例如：老大：Jason，帮我开发一个集成微信与支付宝的SDK需要多长时间。我：大概需要两周吧老大：好的，那你今天开始做，两周后给我。我：回到工位上，开始埋头苦干了，老大每天过来问一次进度。两周后就拿出来一个SDK给老大。你说这不算计划吧，其实对我来说其实是计划。或者说一个更简单的例子，我今天晚上计划做个番茄炒蛋，其实根据我们经验来说都知道是怎么做，计划都在我们脑海里面内，先买番茄和蛋，然后放一起炒，装碟，吃。

要不要做项目进度计划，PMP告诉我们是需要做的。因为这样我们可以更好的控制项目进度，以保证项目在规定时间与成本内完成。所以我们进去正题，到底要怎么制订项目进度计划。可以分为几步：规划项目进度管理--->定义活动--->排列活动顺序-->估算活动持续时间-->制订项目进度计划，这几步活动中工作可粗可细，毕竟PMP也说了需要根据项目情况进行剪裁。

规划项目进度管理

在这个过程中，最后需要输出一个文档【项目进度管理计划】的，这个文档可以指导我们后面怎么去完成项目进度计划与控制项目进度。那这个文档记录了我们所要用的进度模型，进度的计量单位如人/天，人/月。我们项目的发布计划、进度计划维护如：多久更新一次进度计划以及进度的报告格式。要知道，我们进度计划制定后并不是一成不变的，做过项目都知道。项目开发过程中总会遇到各种各样的奇葩问题，然后导致了无法按原来计划继续执行下去。但是有时候，我们就算是原来计划执行不了，也不会更新项目进度计划，因为觉得这是一件不好的事情。最后导致了项目的失真。其实我们做计划的原因就是为了应对变化的，当我们制订进度计划后，其实可以更好的控制项目的进度，可以更好更早的发现问题，从而提前制订应对计划。所以要明白进度计划不是一成不变的，需要定期的进行维护更新，以保证剩余计划的可控性。拥抱变化，积极应对。

定义活动

定义活动是什么意思？在这里之前，我们需要经过一个过程-范围管理。在范围管理的时候，我们是有了范围基准-也即是WBS（可交付成果），项目是由一个个的可交付成果组成，这里就不展开去谈了。在我们有了可交付成果后，定义活动就是完成这些可交付成果，我们所需要进行的一系列活动。例如：做番茄炒蛋，我们需要番茄，鸡蛋。番茄和鸡蛋是可交付成果，而我需要去菜市场某个档口里面购买番茄与鸡蛋是一系列活动。然后我们需要把这些活动用一个文件记录（活动清单）起来，这样做的好处是我们可以时刻知道，完成项目需要做哪些活动。除非范围基准变更了，要不除了这些活动以外的工作都不做，这样可以有效控制住我们是朝着正确的目标行动。当我们把所有活动都识别出来并记录，我们就可以把一些活动集合在一起，组成一个里程碑清单，里程碑清单相当于我们项目的控制节点，领导们也是看里程碑清单多一点。除了这两份文件以外，还需一个活动属性的文件来描述活动，对活动进行说明。

排列活动顺序

当我们手里有了三份文件：活动清单、活动属性、里程碑清单。就需要对活动开始先后进行排序了，要知道我们上面一步只是把需要做的工作识别出来了。但是要怎么做还没有定义的，我们总不能先把番茄炒熟了，再洗番茄吧。所以我们把需要做的工作识别出来后，还需排列一下顺序。知道要怎么做，哪个先做哪个后做。这里我给大家介绍活动之间的4种顺序关系：FS、SS、SF、FF。F代表Finish S代表Start，所以用中文说 FS:前一个活动结束后，后一个活动才能开始 SS:前一个活动开始后，后一个活动才能开始 SF：前一个活动开始后，后一个活动才能结束 FF:前一个活动结束后，后一个活动才能结束。用图表示的话，就是下面。

活动顺序排列完成后，我就知道完成项目要怎么做了。但是结合上面的信息，我们还可以绘制出一个进度网络图，进度网络图是一个好东西，它可以给团队成员清晰明确项目路径，相当于一个导航，也便于项目经理对进度的管理。就像下图这样

网络进度只有唯一一个开始和一个结束，不允许有多个开始或者结束。所以你们可以从上图的例子看出几点。第一活动之间的排列顺序可以直观看出，B、C、D活动都需要在A活动完成后才能开始。第二g以A活动为开始，G活动为结束。当然有些复杂的项目，可能会分为多个子项目，从而有多个进度网络图。

估算活动持续时间

在上一步工作中得出的进度网络图，只是一个初步的。细心的朋友可能会发现，在每个活动的上面和下面都有空的网格。这些空的网格就是用来填充我们估算出每个活动的持续时间，填充完成后才是一个完整的进度网络图。估算活动持续时间的方法几种，比如【类似估算】就是根据曾经做过类似的功能进行估算，说白了就是根据丰富的经验进行估算。【参数估算】是根据功能的各种参数，然后通过数学模型进行估算，这种估算比【类似估算】更准确。【自下而上估算】是从活动最底部开始估算，然后逐渐往上层汇总，最后得到一总的项目时间，这样的估算一般都是找最熟悉这项活动的同事进行估算，最好是以后就是该同事负责开发的，这样估算出来的时间是误差比较小的，也是我们使用的最多的估算方式。【三点估算】是根据活动的最乐观，最可能，最悲观三点的时间进行估算，例如：完成活动最乐观时间是8天，可能10天，悲观12天。然后用一个公式（乐观+可能*4+悲观）/6， (8+10*4+12)/6=10天，最期望能完成的工期就是10天。当我们把所以活动的持续时间都估算完成后，还需要考虑到一个活动需要多长时间完成，既取决于活动的性质，也取决于资源配置情况。最后编写的出【活动持续时间估算】文件还需根据【风险登记册】进行调整，估算持续时间还需考虑各种假设条件与制约因素并记录到【假设日志】上去。下图是我们最后完成的网络图