好的工作量评估，必须建立在对当前参与项目的实际情况有全面了解、有足够清晰的看法的基础之上。
一、怎样的工作量评估结果算是准确的、好的评估结果？
好的工作量评估，必须建立在对当前参与项目的实际情况有全面了解、有足够清晰的看法的基础之上。评估的结果必须成为整个项目可控的基础，可以给项目负责人（在我们公司通常是项目经理或者产品经理——我们的产品经理们通常一定程度上兼职了一些项目经理的职责）制定合理的计划提供可靠的依据。
参考一些统计数据来看，一个工作量评估良好的项目，某些单个的任务评估值难免会和最终执行结果产生偏差，但最终结果始终在评估范围左右，并且随着项目的进行，评估的范围是可以越来越小的。项目的进程是可以预测并且整体可控的。如下图：
△ 评估结果良好的项目过程的数据比较图
下图是一个评估结果较差并且有低估倾向的项目工作量评估过程的参考数据统计，这个项目一直处于工作量被低估的状态，并且评估的范围太窄以致于实际进度始终没有在评估的范围内。
△ 不好的工作量评估过程的数据比较图
不准确的工作量评估，往往直接导致依据其制定的项目计划失去实际意义，项目的实际进程总是偏离计划的轨道，项目进程经常处于难以预测、不可控的状态，这对项目管理者来说是非常糟糕的。
工作量评估的不准确而导致项目进度不可控，对于整个项目来说非常不利且不说，对于本人来说，你很可能成为众矢之的，经常被合作伙伴们催进度，责怪不给力的感觉肯定非常不好吧？如果你正有「为什么我工作量评估总是不太准？」这样的困扰，看看下面这些分析是不是会对你有所帮助。事实上我个人建议大家在工作量评估的时候，必须回避掉这些不合理的做法。
二、为什么我评估的工作量总是不太准确？
1. 工作量评估不准确的罪魁祸首：低估
罪魁祸首居然是低估？不是高估么？
大多数人都这样认为，如果你给一个开发者5天时间去做一件4天就能完成的工作，他必然会去寻找一些别的事情来把多出来的一天用掉；如果你给一个项目组6个月时间来完成4个月就能完成的项目，他们同样会找到办法来把多出来的2个月用掉；时间评估的多了，怎么样都有办法可以用掉（或者直白点：浪费掉）！老板们总是希望大家花越少的时间干越多的活，他们也深知大家的这点花花肠子，所以他们往往都希望通过挤压评估的时间来避免这个现象。
当然还有一些人认为如果给了太多的时间，开发人员往往会把任务放到后面来开展（每个人都有一点小小的拖延症），这样他们到最后还是匆匆忙忙的完成甚至无法按时完成任务。这些担忧都是正确的，而且也是客观事实，但是在开发过程中，工作量高估的代价却是线性的可控的，顶多就是浪费掉多估出来的那些时间。你可以回头看下上面的两张参考图，高估的结果起码实际进度会一直落在评估的范围之内，是可以预测、可控的。
反倒是工作量低估的坏处更加厉害。低估的代价是非线性的不可控的。工作量评估不准造成计划5%-10%的延迟还不算太大问题，但是大多数时候这样偏低的评估造成的可能是100%以上的偏差，基本上基于这样的评估结果来制定的计划就是在「我猜，我猜，我猜猜猜！」，已经失去实际意义。
大家都知道完整的项目工作是环环相扣的，你所在的项目环节往往还有上下游的环节，你依赖上游的进度，你的下游依赖你的进度。你把三天的工作量评估成两天，你的下游肯定是计划两天后就要介入的。结果你实际上必须得花三天才能完成！你下游的计划，乱了吧？你下游的下游的计划也跟着乱了吧？是不是差不多整个项目计划都可能跟着一起乱了？一群人可能就要指责你了，为什么延期！！其实并不是你实际工作不给力，只是因为你低估了工作量。
由于低估带来的计划延期等问题在管理规范的团队里面需要进行延期原因分析、影响评估、计划变更评审等等相关工作，这些工作所需要代价叠加起来往往是非线性增长的。
反过来想一下，如果你这三天的工作量，高估了一点估成了3.5天，即便是多费了半天时间，但是后续的计划基本上还是都可以跟上的。不是鼓励你高估工作量，只是你必须知道低估造成的危害往往更大！所以不要有目的的去低估，更不要盲目的乐观！低估的代价比高估的代价更高，我们的程序猿往往还是乐观主义者更多，往往给出的评估值就已经是较少的时间和成本了，如果再刻意压低评估值，一定适得其反。这一点，我觉得除了各位一线的开发人员必须知道之外，项目管理的负责人更必须知道，不要盲目的、刻意的要求开发哥哥压低他们合理的评估值！评估值低了，并不等于你的实际进度就真的可以更快了。
2. 工作量评估不准确主要原因之二：拍脑袋
拍脑袋，大家都懂什么意思了。评估工作量的过程中拍脑袋的表现就是即兴估算，根据个人记忆、印象，在未仔细考虑前就给出的看似思考分析过的评估结果。因为个人记忆常常出现错误，比如并不是记住项目的实际结果而是评估值或者是直觉，所以这种评估也常常出现错误。根据某位大牛实验收集的24组人员的即兴评估数据，并对即兴评估的平均误差和经过小组评审的评估结果的平均误差进行比较，见下图：
△ 即兴评估与评审过的评估的平均误差比较图
可见一般的即兴评估的平均相对误差量为67%，而一般评审过的估算的误差只有30%，只有前者的一半。所以不要拍脑袋，即使只用15分钟坐下来查查以前的记录的数据再进行估算也会更加准确些。
想一想，产品经理或者项目经理经常问：这个需求很简单的，一天就能搞完是不是？或者：这个需求很简单，你帮忙看下多久能搞完？你这个时候拍脑袋了吗？吞过拍脑袋造成的苦果吗？冷静一点，建议你不太能确定的情况下一定不要拍脑袋回答他，完全可以说：等我先仔细评估下，稍后答复你怎么样？
避免拍脑袋评估出不合理的工作时间，是对自己负责，更是对项目的实际进度和质量保证负责。
3. 工作量评估不准确主要原因之三：遗漏工作
看看下面张表，是不是有些工作（比如红线圈出的部分）你开始根本没想到要评估到你的工作量当中去？ 往往就是这些漏网之鱼造成你的评估值偏小，导致项目计划不合理而常常延期。
△ 正确的工作量分解示意图
想想你在评估工作量的时候，有没有直接只评估项目的主要任务分解出来的那部分？是不是没有考虑一些前期的准备工作、公共的工作，也没有包括后期的联调优化、产品体验、测试所需的时间？ 实际上这些前后期的工作都是必不可少的，往往还都是工作量的大头，评估的时候没考虑进去，得到的计划一定没个准。
一定程度上我们甚至可以说遗漏工作是导致工作量低估的罪魁祸首！也就是祸首中的祸首，很可怕。从这个角度来看认真、全面的了解需求和分解任务非常重要。
三、准确评估工作量的正确姿势
知道了评估工作量的三大误区之后，我们不难反推，正确的评估姿势就是：先做好充分的工作量分解，在不遗漏工作的前提下，对每个分解出来的子任务合理评估工作量。所谓的合理评估量就是不拍脑袋，不刻意低估也不刻意高估。
说起来容易，做起来难。难点有二：
- 首先是如何充分分解，不遗漏工作。
- 其次是如何合理评估，即不拍脑袋，也不低估、高估。
1. 先说怎样充分的工作分解
通常我们使用的方法叫 WBS，工作分解结构：
△ WBS工作结构
如下图示例：
△ 示例
但并不是到这一步就可以开始评估工作量了。严格意义上讲，我们这里分解出来的工作包应该是名词，不是动词。还需要识别和定义为实现工作包而进行的活动，如下：
△ 识别和定义为实现工作包而进行的活动
定义活动的过程，我们要生成一个活动清单，如下：
△ 活动清单
为了确保活动的定义也是正确、充分的，你可能还得先知道，活动其实有三种主要类型，除了独立型活动，往往还有许多相关的依赖型活动、支持型活动，千万不要忽略了，如下图：
△ 活动类型
2. 再说如何科学理性的评估工作量
活动清单制作完成后，就可以逐个活动来评估它的工作量了。既然不能拍脑袋，那肯定有一些比拍脑袋更可靠的方法要介绍给大家：
△ 评估工作量
其中几种方法分别简单介绍如下：
类比估算