如何写好软件项目的工作计划-项目假设（三）

      确定了项目目标，下面就是要把项目的实施策略、人力资源、进度和成本有个大致的估计，当然这是一个很粗略的估计，不是太精确，但是这不是什么大的问题。但是你一定要做这一步，否则项目到了中后期你就会惴惴不安起来。

       项目的估算主要是软件的规模、工作量、工期、成本、人力资源数量及资源日历（资源占用的起止时间）需要好好进行分析和估计。

     CMMI里面会有很多需要你去度量的产品数据、项目过程数据，但是这些数据对你来说是否真的有用，其实那是另外一个事情了。但是对于一个成熟的组织，能够收集这些数据以供分析项目和软件的健康状况也是有益的，或者用来将来项目的参考也是有指导意义的。但是让你在项目早期逼着开发人员估计他要开发多少行代码好像意义并不充分，而且还会受到嫌弃。你完全可以在软件发布前对实际撰写的代码行使用工具统计出来，这些数据是比较容易收集的。

    对于软件规模的度量很多公司更加倾向于去使用功能点估算，或者在敏捷方法里面对故事点的估计。如果对软件的需求确实能够写到需求规格说明书的要求，把输入和输出都讲清楚，那么确实可以估计出功能点，然后再去推算工作量，但是往往估算工作会占用很多工作量，这不是一个投入和产出成正比的工作。那么实际上，很多人怎么做的呢？

       工作量=任务人数*工期

     好像工作量的问题确实是解决了，把所有能够列举的任务（来自于WBS）的工作量全部累加起来就能够将项目完成软件或者系统集成的工作量推算出来，这种自下而上的估算方法不仅仅精度提高了，而且项目管理的精细程度增加了。但实际情况又是怎么样的呢？

   第一，你没有办法通过历史项目的数据穷尽你现在项目的所有数据，哪怕这两个项目非常类似。

   第二，不同的人工作效率是不一样的，新人不一定都是你可以认为的战力，也许你会自嘲认为那算半个人吧。

   第三，可能有未知的项目风险会占用更多的工作量和人力资源。

   第四，最让人头疼的情况，客户或者你的供应商他们的拖延症犯了，这个时候，哪怕你不停的催促，但你依旧没有办法控制你的工作量。或者你以为是客户应该做的事情，他会告诉你他不是很懂，希望你去完成。

   试着回答下面几个问题：

  1. 写一份项目计划，为啥你用1天就写好了，但是如果我来写就要3天时间，难道是我的工作效率比你低吗?

  2.做一份需求规格说明书，甲调研了10个部们花了10天，撰写文档花了5天，乙调研了5个部门，撰写文档花了5天。甲写的文档比乙写的文档，调研的详细程度更高吗？撰写的文字更加详细吗？

 3.1个高级工程师撰写概要设计说明书和2个中级工程师撰写同样的文档，同样都用了3天，你认为两组人谁写的更好呢？

 4.小A1个小时500个字可以把事情写清楚，小B1个小时1000个字还没有把事情说明白，你认为你应该怎么估算这样的工作量？

      如果你把这些问题想清楚了，那么你会发现你所有的工作量估算都是基于你自己各种的假设，这种假设是主观的，但是你又不会把这些假设写到计划中，让所有人都看到。

      当你限定了人数和工期的时候，你把这样的计划发出去，实际上更多的是你把你自己个人的进度期望强加给了执行这个任务的人，希望他们在规定的时间内完成，不管他们是否要加班应对。好的情况是，当你把这个计划给你的团队成员看的时候，他会告诉你完成不了，好吧，你又要修改工期，不好的情况是有人选择沉默，也许是他不知道你的计划会发生什么，更糟糕的情况是他心里清楚完成不了，但是看到别人没有发声，所以就不讲话了。当完成不了的时候，你会生气的跟他说，为什么你觉得完成不了，当时评审的时候不说出来，为什么你已经发现完成不了没有反馈给我？

      实际的情况要比你想的更糟，如果这是一个在关键路径上的任务，你不得不要考虑修改你的进度计划，或者发现项目延期时，你的项目成本可能就要超支了，你唯一能够做的，就是让大家不停的加班。一个蝴蝶效应即将在你的项目发生。推倒这个多米诺骨牌的人不是你的成员，而是你自己。从一开始你就把编制进度计划推导出的工作量，等同于了完成产品的工作量。

       项目的需求是客观的，因为你必须完成那么多的事情，但是假设却是主观的，工作量的推导如果是基于需求的规模，那么有可能比你用假设的人数*工期来的更加有说服力和指导性。如果 你的需求还没有梳理的如此清楚，OK，你需要的是一份能够把需求调研清楚的短期行动计划。

       如果你不要求你写的总体计划准确性那么高的情况下，你可以基于一些假设来完成它，但是你要清楚这个如果作为你项目绩效的基准和你的钱挂钩了，那就真的要仔细考虑一下。