项目评估与计划（五）- 计划如如何做出来的

计划是如何做出来的？

　　一、要站在战略的高度。

　　有时候我会问项目经理这样的问题：

　　1. 项目预算是多少？（注意前文提到的预算与估算的差别哦，预算是指公司打算花多少钱做这个项目。）

　　2.合同要求在什么时候验收？

　　3. 验收一次进行还是分初验、终验？

　　有些项目经理答不出了，他们没有去关注合同中的要点，也没有向高层取得项目的战略指示。

　　一般情况下，在项目初期，你应该搞清楚这些战略层面的内容：

　　1. 合同价钱是多少，公司打算赚多少钱？

　　2. 公司为什么要做这个项目？想赚钱？想维持客户关系？想积累业务和技术？本项目是公司战略的其中一步？

　　3. 项目的工期要求。

　　4. 项目的验收办法、验收标准。

　　5. 项目是如何收款的，客户每次的付款条件是什么？

　　你可以通过看合同，向公司高层请示，了解到这些关键信息。当然很多公司合同是保密的，你可能无法直接看到合同，但你可以直接问高层领导嘛，尽量获取上述关键信息。做项目就像打仗，秦国名将白起没有一次败仗，主要是因为他每次打仗之前，都会处在战略高度来审视国与国之间的大势。你要做好项目，先要把握项目的大势！

　　二、明确计划的“输入”。

　　要做好计划，你还需要了解清楚以下内容：

　　1. 系统的需求。通常需求是不明确的，能明确多少算多少，同时你需要有计划地去搞清楚。

　　2. 系统的设计。通常设计也是不明确的，你需要安排很多前期技术研究。

　　3. 项目组当前的能力情况。

　　4. 为成功完成项目，项目组还需提升哪些知识和技能。

　　以上这些内容，是项目计划的“输入”，良好的输入是优质计划的基本保证。

　　三、用估算来控制计划，由计划来调整估算。

　　估算如果做得好，其实计划就完成大部分了，你需要利用估算来指导计划。为了说明“估算指导计划”，下面我会虚拟一个例子。

　　某项目估计完工需要1000人日的工作量，其估算明细如下：

　　1. 项目管理150人日。

　　2. 需求150人日。

　　3. 设计150人日。

　　4. 编码250人日。

　　5. 测试100人日。

　　6. 实施200人日。

　　根据估算，你安排了详细的进度计划，进度计划中的各任务可以分为六类：项目管理、需求、设计、编码、测试、实施。请注意每一类工作量的总和，不能超过对应的估算，你需要用各子估算来控制这六类子任务。

　　不少项目在安排具体进度计划时，忘记做这个检查，有时候进度计划的总工时没有超出预算，但可能编码方面的任务已经超出了编码的预算了。

　　在具体计划时，往往会发现估算时遗漏考虑的内容，这时很有可能实际计划的总工时会超出估算，或者是某类别的工时超出相应的子估算。这是很正常的事情，项目组对项目的认识是逐步深入的，不太可能在估算时就100%考虑周到。遇到这样的情况，我们通常这样处理：如果仅是某类别工时超出相应的子估算，如果能从别的子估算挪一点过来“补数”，而总估算不受影响，则不需要申请估算调整；但如果总估算受到影响，则需要申请变更估算。

　　前文讲述估算时提到，会因为需求不能全部明确、设计也不能全部明确，估算往往不能一次完成，这时只需要估算能估算的部分就可以了。但我们需要随着项目的开展，认识的加深，持续更新估算。估算与计划的关系是：估算指导计划，计划反过来促进估算更新。

　　四、制定可执行可检查的进度计划。

　　具体工作任务的制定是很讲技巧的，如何做到“可执行可检查”是关键，下面是制定进度计划的一些技巧：

　　1. 每个任务的时长不要超过5天。

　　我们公司的项目，任务时长往往是在两三天内。

　　2. 任务只有完成与未完成两种状态。

　　所谓任务完成90%之类的说法是不靠谱，任务应该足够细分，不要安排周期长的任务，这样能更好控制项目进展。

　　3. 每个任务都有可供检查的工作产物。

　　不要笼统安排“研究什么什么技术点”之类的任务，必须明确工作产物，如：研究某某技术点，编写研究报告，提交演示程序。而任务完成标准就是：这些工作产物能达到期望的要求。

　　4. 一个任务一个人负责。

　　一般不要安排类似“小甲与小乙共同完成某设计文档”之类的工作，多人同时负责一个事情，效率会很低，效果也不太好。
尽管实际工作中有可能需要多人同时做一个事情，你可以：

　　1）再次将任务分解，落实到具体的人头上，如上述任务可以分解为两个任务：小甲完成设计文档的章节1、2、3，小乙完成章节4、5、6。

　　2）如果任务实在不好再分解，就只安排一个人去做。

　　在我们公司，一般只有评审任务是多人参与的，别的任务都会落实到具体的人头上。

　　五、细化近期计划，定下远期计划大节点。

　　我曾经负责一个房地产公司的成本管理系统，当时需求还没有全部明确、技术也很不成熟，就被要求做出该项目的全部详细计划。我当时很郁闷，一个月后某一天谁干什么的事情也要计划出来吗？我只能明确近期一两周的具体工作，而远期的工作我只能定出大概，以后的事情可变因素太多，现在写出所谓具体工作，其实是毫无价值的，浪费时间。

　　近期两周内的工作能明确的工作，必须按照上述第四点的要求制定详细的明确的可执行的可检查的任务，而对于将来的工作，则需要定出关键节点，如什么时候发布什么版本，什么时候验收。

　　六、让项目组各成员详细计划自己的工作。

　　在项目经理主持下，项目组全体共同来制定进度计划框架，明确任务的先后关系。而对于每个人的具体任务，则可以在项目经理的指导下，由每个人自己来确定。

　　项目组由项目管理、需求、设计、编码、测试、实施等各专业人才组成，每个人承担起自己专业方面的管理工作，项目管理其实是项目组成员每个人的事情，不是只由项目经理一个人来负责。

　　七、持续更新计划。

　　计划不是死的，是活的！项目计划不是一次成型就固定不变的，项目组需要持续更新计划细化计划，要随时保证近期的任务都已经明确，而远期的任务如果能明确也应当尽量明确。任何项目组成员都可以发起计划更新，项目经理要推动大家管理好自己工作，让大家主动更新计划。

　　这里要谈谈计划变更问题，谈到计划变更很多人会“闻虎色变”，我们先要看看看什么叫“计划变更”？

　　“计划变更”要与“计划调整和细化”区别开来，调整和细化是指根据实际情况，不断的适时地去修改计划。任务微调是很经常和很正常的时间，某某任务稍微延长一天，某某任务比计划提早一天完成，某项目组成员请假等影响因素，都需要我们去调整计划。与此同时，我们应当不让去细化中远期的任务，至少要一直保证近期的任务都是明细化的。

　　而计划变更是指，项目关键节点受到影响的重大变化，关键节点一般有：需求规格说明书通过评审的时间点、版本发布时间点、验收时间点等。这些关键节点的变化，会影响合同条款的履行，会影响公司的战略规划。通常是因为内因或外因导致计划变更，内因一般有：遗漏重要需求、软件设计出现重大失误、代码质量不过关；而外因一般有：客户的需求变更，客户未能做好项目上线准备，第三方未能及时完成相关工作（如：硬件提供商未能及时发货）。

　　在我们公司，计划调整和细化只需要项目组内达成一致便可，而计划变更则需要报高层审批。