项目初期如何确定项目的进度计划和资源需求？

凡事预则立，不预则废，IT 项目实施，更是如此。在项目的实施初始，进度计划是否完整、可行，资源是否估算准确，是项目顺利实施的关键。
一、首先，让我们回顾下理论知识，制定进度计划 7 个步骤：
1）规划进度管理
2）定义活
3）排列活动顺序
4）估算活动资源
5）估算活动持续时间
6）制定进度计划
7）控制进度
       其中 4、估算活动资源，5、估算活动持续时间这两步是制定进度计划的关键步骤，如何能够准确的估算项目需要资源，估算出单个活动所需要的时间，是该项目制定进度计划的关键。理论是指导方向，需根据项目实际情况，选择项目实际需要的步骤。在实际项目中，当你中标后，根据招标文件，项目的整体计划是确定的。比如，招标文件里会写明该项目的进度计划，是多少天，30 天，45 天，等等，你在偏离表中，还必须应对，无偏离，同意此时间，虽然这个时间根本无法完成，但是为了拿标，只能…（忍了、认了、怂了、背了……）
       中标后，项目开始启动，那么合同的进度就是你实施项目的参考，当然不能超太多，客户方会说不过去。根据这个时间，制定一个粗略的进度计划，可以按软件工程理论，设立几个里程碑，初步完成一个进度计划报给客户方。
     当然这个计划是倒推法，根据客户要求的时间进行倒推，完成初步计划。紧接着根据这个初步的计划，项目经理开始带领团队核心骨干或专家一块，细化该进度计划，估算所需各类资源。
     项目初期，项目建设书一般都很粗范，只是明确的大块内容，主要模块的内容，一般会细化到系统平台的二级节点。
     具体的内容可根据你投标文件，应对的内容来估算资源，你应对的文件是客户方认可的内容，是要写到合同中，这块其实很重要，这个项目你能做到什么程度，你就写明，中标后这就你可以按这个内容提交成果。
     如果你应对文件准备的够详细，很熟悉，甚至这个招标建议书都是你写的，那么你的计划制定起来就比较容易，同时你估算资源也就比较准确了。
在制定进度计划过程中，我重点要求项目经理和组长重点关注这几个进度管理过程：
 1、定义活动；
2、估算活动资源；
3、估算活动持续时间。
要求项目经理和组长重点确认这几个关注点： 
1、工作内容不能缺失，要完成的全部工作；
2、工作分解后是否明确责任人；
3、估算人员的时候是否考虑专家备份，替补；
4、是否涉及第三方厂家配合；
5、涉及的硬件具体到货日期；
6、是否预留任务的缓冲时间以及项目整体缓冲时间等等。

二、那么，我们应该如何做呢？

      在制定进度计划和估算资源的工作中，先明确项目范围，做工作内容估算，wbs 专家明确技术难点，类比估算时间。
      参考同类型项目的人员配备和其他资源配备，一般项目都会配置一个经验丰富的人，根据以前的经验可以按这种人员资源模式评估时间，估算出来的肯定是一个成本，资源，时间的区间。
      再利用历史数据或组织过程资产，或者向项目管理办公室寻求类似项目的相关信息作为参考，制定项目管理计划，因为好多信息不明确，风险管理计划要充分做好，尤其是风险应对措施。
      比如在一个大数据项目中，项目经理和核心骨干、组长全员参与，参考公司事业部大数据中心的提供的各类材料，根据以往的项目实施经验，通过 project 工具进行 wbs 分解，对资源、成本、工时，进行估算。
     采用从下到上，估算每个活动的资源和时长，在往上汇总，整理出整个模块的估算数据，比方这个项目要建立一个数据模型，还需要进行前台的展现，那么这个工作就要进行分解，
     1 个 java 开发人员，2 个 oracle 开发人员，1 个模型开发专家。这个专家必须的预约时间，只能在本地工作 3 天，对于这种情况，就要需要预留任务的缓冲时间，3-4 天。如果这个专家来不来，还要提前准备替补专家，项目的风险也要考虑在内，作为估算的一部分，才能有可能保证该模型正常实施。

三、最后，项目开始实施了

       那么我们可以采用每周写周报、开周例会、每月写月报、阶段工作成果评审、风险和问题跟踪表等方式监控项目进度，及时纠偏，了解团队整体开发进度。

     1 个月后，如果实际执行情况与计划有较大偏差，则需要根据团队实际能力重新估算工时、调整人力资源计划、调整进度计划；同时每个月监控费用成本并及时纠偏；定期召开进度会议和回顾会；时刻关注关键路径和里程碑事件，必要时动用应急储备快速跟进。这样遵循渐进，来回往复，就相对容易管控好进度了。

02

一、敏捷的估算扑克是什么
     我估计针对这个问题，大家都是有证的人，技术上肯定没啥问题，方法特别多。关键就在于如何做到准确灵活，有同学说，按时间点倒推，或者里程碑控制。也没什么错，关键在于倒推的这些内容都是什么，在过程内容中对管理上其他的参与要素怎么管理。
     比如说在很多年以前，我们估算的时候，要对周期和工作量提倡做 buffer。或者我们用滚动式规划的方式做持续估算，都是一种合理且已被证明了有效的管理方法。
我简单说说敏捷的估算扑克。
     通常我们的估算，不管是不是敏捷，都需要在需求范围没有歧义的前提下，至少需要在团队内部达成一致。我们会拿到一副牌，通常是长这样的，这是现在改进的版本。



     这些数，首先，绝对不是工时。在敏捷的估算里我们一般会做相对估算，传统的敏捷意义中，这些数字的意义是故事点。我们再看这些数，这是斐波那契数列。这个数列的其中一个特点是，数列位数越大，相邻项的间隔就越大。那我们再回到扑克，0.5、1、2、3……40，这些数字，表示的不是绝对值。有 0 的情况，0 的情况的意思就是，可以忽略不计。
     举例说明：我认为这个功能的故事点我估算出牌是 5，那我觉得应该在 3-8 之间的某一个正态分布的值上可以完成。3-8，老板肯定认为是 3，程序员肯定觉得是 8。那到底是几呢？
这就说到了敏捷团队的一个文化，叫自组织的高度透明团队。意思就是大家商量，商量出来个几就是几。关键在于，需要参与估算的这一些人达成一个共识。
    还有几张牌，一个是问号，一个是无穷，其实还有一个上面画的是一杯咖啡。问号的意思是，你说的这些东西我没听懂，那就需要在讲讲，或者参与探讨；无穷的意思是，这个东西我没有办法估计，希望能够通过拆分或者转化进行估算；咖啡的意思是，我累了需要歇歇。

二、估算的过程：
1、找个舒适的环境，准备好零食；
2、主持人宣读规则，大家签字达成一致；
3、PO 对需求进行讲解，大家同时估算，如果未能达成一致，请有分歧的人说说为什
么，重复这个过程；
4、如果 3 次未能有结果，建议休会或暂时跳过；
5、最后会有一个统计结果，根据团队速率和 PB 优先级，决定迭代做哪些；
6、将结果公示到信息源，以保证团队承诺。

 

作者：张勇强

2 年 erp 行业 IT 建设管理经验

11 年电信项目支撑项目管理经验

作者：大懒

从业 12 年

程序员转项目经理、pmo 经理