2023/02 作者：ihunter 0 次 0
01为什么要做估算
我们的业务方经常抱怨资源不足,团队需求的吞吐率太低,资源和需求量的不匹配是一个永恒的话题,解决方案应该不只是增加资源,增加了资源如果需求的输入量不能稳定保证,那资源就会处于持续浪费的状态当中。
1工作量透明出来
其实这个问题不一定是要从补充资源的角度来考虑,可以让我们的需求工作量透明出来,让我们的业务方知道团队的需求吞吐率,也可以辅助梳理优先级,合理安排资源。业务方对于一个需求需要的工作量其实是不清楚的,经常他们一个很简单的需求,其实实现起来是比较耗时的。
2促进深度思考
估算可以让团队对所做的事情有更加深入的思考,当我们要对外提供一个估算值的时候,团队会更加倾向于仔细考虑自己的工作。
当有一个需求需要你给出估算时,出于责任心的考虑,会让我进一步做出深入思考,这个过程也会促进了团队对需求的理解,及时识别依赖和风险,避免在后期出现“惊喜”。
3帮助确定优先级
如果一个需求完成的工作量需要5天,可能业务方会更加倾向于这个功能在下个迭代交付,但是如果这个工作量需要2个月,可能业务方会考虑这个需求的价值,是否值得团队去做,是否有其他更低成本的替代方案来实现,或者优先实现其他更优价值的工作。如果这个工作量需要耗费近半年的时间,可能业务方会考虑这个需求是否从需求列表中移除,因为实现这个需求的成本如此之大,或者对这个需求做进一步的拆分,采用分步验证的方式去实现。
4帮助了解团队速率
几个迭代下来,会发现团队能够完成的故事点数是比较恒定的,这也有助于我们的产品经理合理安排需求,对于一个高速发展期的业务,产品经理的待办列表中会有非常多的需求,但是接下来需要选取哪些需求进行细化,需要在当前迭代安排哪些需求的评审,如果没有估算,产品经理对自己需要梳理或者评审哪些需求其实是比较模糊的。
举个我们现实中遇到的问题:
产品经理在迭代开始前评审了需求,但是这些需求需要2个迭代甚至更久的时间才能完成。评审完成,一方面在下个迭代开始之前这些需求的优先级可能变化了,另一方面,评审了很长时间的需求,团队在开始做之前还需要进行重新熟悉和理解,这里就出现了重复的工作量。
有效避免这样的重复现象出现的方法,就是在迭代开始之前,由我们的SM及核心开发人员对需求进行估算,结合历史团队的交付速率,可以快速评估出接下来迭代可以交付需求的工作量,这样产品经理可以合理的安排需要评审的需求,帮助提升团队效率。
02估算的方法
作为项目经理,估算是一个基本功,不管在敏捷实践中,还是在传统方式的项目管理中。另外,估算也是计划的前提,只有对工作量做出合理的评估,才能给出一份可执行的计划。
那估算的方法有哪些呢?常见的有类比估算、三点估算、自下而上估算及专家估算法。
1类比估算
适用于:项目立项、项目计划阶段初估
通过和过去类似项目进行类比估算,如果这类项目过去已经做过,可以用这种方式快速的给出预估时间。对于项目型交付组织来说,如果过去做过类似项目,可以快速的评估出项目需要交付的周期。估算方法其实并不局限,这里也可以融入专家估算,如果有相关项目经验的专家,通过专家的经验,能够快速给出可靠的项目周期估算。
2三点估算
适用于:项目立项、项目计划阶段初估
在没有相关历史数据参考的情况下,可以相关专家(至少3人以上)参与估算,一般会有一个估算的最小值(最乐观的值),和估算一般值(一般的值),估算的最大值(最悲观的值)。
3自下而上估算
适用于:项目阶段性计划,迭代计划等
自下而上的估算,一般需要先进性WBS的拆分,拆分之后,由项目组成员对各自活动进行估算后求和,这种估算相对来说更加详细,相对耗时比较长,所以可以项目的阶段性计划中采用这种方式。
4Delphi专家估算
特点:匿名
Delphi估算需要一个专家组,是一个逐步达成共识的方法,每个专家通过匿名提交估算,并 对他们进行评审和讨论,如果不能达成共识需要重复该过程。
关于估算的方法就介绍到这里,估算的方法有很多,作为项目经理学习了这些方法之后需要进行灵活的应用。有些估算非常耗时,需要项目经理结合耗时和准确性进行取舍,选择合适的方式进行。
