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