情景一：今天我们的团队终于完整了，接下来分配一下工作。A君和B君负责Search模块，C君和D君负责Document模块，E君和F君负责Configure模块，G君和H君负责Share模块。在接下来一个月的时间内，我们要完成整个系统框架的搭建以及界面的展示。现在大家一起来过一下需求，有什么问题就提出来。
情景二：本周要完成Document中的几个功能，X君你制定本周这几个功能的开发计划，然后发给我。我审核后，你要按照规划进行开发，周五下午3点进行工作验收。
情景三：Z君，我们从L部门借来一个员工M，在接下来的一周时间内，他会在我们项目上工作，但是他每天只有50%的时间在我们项目上。也就是说，他只有每天下午才会在我们项目上，你给他安排一下工作吧。
情景四：Q君，你负责的P模块现在Bug现在有50多个Bug，你需要抓紧时间修复了。现在我们一起看一下，你看看你今天能修复多少个模块，于是两人开始估算修复每个Bug的时间，并确定当天可修复的Bug数量。
根据项目的开发阶段、开发进度以及当前人力资源的状况，你可能需要为自己或他人估算他类似上面情景在一天、一周，一月，乃至几个月的工作。尽管随着估算周期的增长，估算的准确率越来越低，但是我们应该明白那句话：估算要准确，而不是精确。我们可以在估算工作时，提供缓冲时间，作为工作量结束的准确时间。
目前，有很多估算方法，我觉得比较好的两种，还是delphi估算法和功能点估算法。关于这两种方法的具体估算方式这里不再详述，只是以图表方式展示二者之间的区别，已经适用场景。
| Delphi估算法 | 功能点估算法 | |
| 对需求文档质量的要求 | 低 | 高 |
| 估算成本及工期 | 大，邀请专家的成本高 | 小，项目经理和技术经理在短时间内搞定 |
| 学习难度 | 小 | 大 |
| 估算准确性 | 主观 | 客观 |
| 估算结果 | 估算结果为产品规模 | 估算结果为项目规模 |
通过上图可以看出，Delphi估算法主要优势表现在需求文档不确定的情景，而功能点估算法的好处是估算成本低，而且估算结果比较客观。各项目经理需要根据自己的需求决定使用哪种估算方案。
在项目估算过程中，项目经理很容易碰到的问题就是如何处理项目的“缓冲时间”，在项目开发过程中，有的人过于乐观，有的人过于悲观，如果有这两种人在项目中同时进行项目估算，那么项目的缓冲时间跨度太大，就会严重影响项目的准确性。
处理缓冲时间最好的方法，就是在估算工作时，加入经验系数。在估算时分开考虑任务的大小与持续时间，并且把每个任务当做“小石子”（小石子指，把大任务分成小任务，每个小任务的持续时间不超过两天）去处理。但同时也要注意，不要在使用“小石子”时陷入微管理。
事实上，估算工作的知识有很多，远远不是一篇这样的综述性博文所能描述的详尽的。如果你想让自己的项目能够成功，想让自己的估算工作准确，不仅要了解常用的估算工作方法，更要熟知每种估算方法的特点、优点以及缺点，这样才是一个合格的项目管理者。
