言之无物

我说的一切都是错的

项目背锅侠之需求分析 - 优秀需求的要素

书接上文,今天先总结下优秀需求应该具备的几个要素,然后再介绍一种确定需求优先级的方法。
优秀的需求一般具有以下4个特征:
1. 完整性
需求的来源是用户,需求文档记录的是否完整,最后需要用户来验证。用户有自己的分析视角和业务语言,从用户的视角来组织、整理需求,用户才能“看懂”需求文档,从而保证需求的完整性。

2. 不失真
中文不是一门严谨的语言,同样一句话,可以有完全不同的理解。需求从业务人员传递到分析人员,“信息”已经损耗了很多,分析人员再转为为文字,因为理解和表达能力的不同,又会有一定的失真。开发/测试人员阅读文档,又会加入自己的视角和理解。所以,用户真正的需求,到了开发人员那里,也就剩20-30%左右。由于存在这种天然的损耗,需求分析人员需要考虑如何尽可能的减少失真。另外,光从文档来理解需求也是不充分的,还需要通过沟通、验证活动来缓解歧义。

3. 优先级
用户经常会说,所有的需求都是高优先级的,因为他担心一旦说优先级低,这功能就不会被团队重视。开发团队则会认为,客户既然提出了需求,那最终都是要做的,优先级没多大意义。 首先,从交付价值的角度看,如何在最短的时间内交付最大的价值?特别是在迭代式开发中,功能是逐步发布的,用户肯定希望价值高的功能优先发布。还有,到了项目后期如果不得不砍掉某些功能,依据什么判定呢?
有了优先级标准,上述的两个问题都很好解决,划分优先级的方法很多,有cost-value法,QFD法,PROMETHEE多属性决策法、SCRUM里常用的MoSCoW法等。本文后面会介绍一种基于cost-value的分析方法。

4. 技术早期介入
需求文档不仅仅是记录用户的需求,更要体现需求的可行性、可验证性。在需求分析阶段,得让技术/测试团队参与进来,因为无法实现的需求是无意义的。同时,技术/测试的前期参与,可以弥补文档本身的失真性,减少后期的需求沟通成本。

以上只是一份优秀需求的充分条件,并不能说满足了以上几点的需求就是优秀的需求了。个人认为,需求是连接开发和用户的桥梁,评判需求是否合格的标准就是一条:是否能有效的把信息从用户传递到开发/测试团队。

在查阅资料过程中,发现了一个优先级评定的方法,它在cost-value法的基础上扩展了一些指标,计算方法也比较简单,可以根据实际情况做调整。熟悉excel公式的同学可以做一个excel模板。
该方法通过四个指标来衡量功能的优先级:
Benifit:如果该功能实现了,给用户带来的好处。
Penalty:如果该功能没有实现,给用户带来的不良影响。
Cost:实现该功能所需的成本。
Risk:实现该功能潜在的风险。
每个指标都用1-9分来衡量,并且可以设置指标的权重,最后,通关以下公式算出每个功能的相对优先级。
所有功能的价值总和:TotalValue = SUM(Benifit*W1 + Penalty*W2);  (注:也有直接用Benifit*Penalty来计算价值的)

每个功能的价值占比:Value% = (Benifit*W1 + Penalty*W2)/ TotalValue

每个功能的相对优先级:Priority% = Value% / (cost%*W3 + risk%*w4) (注:cost%和risk%是单个功能的cost(risk)占比)

可以参照下图或我做的excel模板,这样比较好理解。

《项目背锅侠之需求分析 - 优秀需求的要素》

EXCEL模板下载

 

点赞

发表评论

电子邮件地址不会被公开。 必填项已用*标注