一文掌握需求评审常见难题及改进策略【一杯咖啡谈项目】
在IT软件行业，软件需求是软件产品开发最重要的输入，需求风险也常常是软件开发过程中最大的一个风险。
降低需求风险的重要手段之一就是需求评审，但是需求评审是所有的管理评审活动中最难的，也是最容易被忽视的一个评审。
如下几个案例就是比较典型的情况。
案例1：不同的主持人评审效果不同
某业务专家对某企业的成本管理系统做用户需求报告的评审工作，在评审会开始后不久，就被在场的企业的一位副总打断，他认为业务专家提出的方案不适合本企业，在企业中无法实施。
该副总提完意见后，与会的用户方人员纷纷跟随他提出了反对意见，致使评审会无法继续进行下去，最终报告被用户否决。
一个月后，该企业重新召开了评审会议，用户需求报告没有做修改，而是换了一个会议主持人，结果报告顺利评审通过。
案例2：在某个具体问题上花费太多时间的评审会
某软件公司内部举行产品的需求评审会，主要是公司内部的业务专家参加。在评审会开始后不久，某业务专家就对需求报告中的某个具体问题提出了自己的不同意见。于是，与会人员纷纷就该问题发表自己的意见，大家争执不下。结果，致使会议出现了混乱状况,主持人无法控制局面,会议大大超出了计划时间。
案例3：枯燥的评审会
某软件公司为某公司A做业务流程管理系统的需求评审会。当项目组人员在会议上宣读多达上百页的需求报告时，用户明确提出听不懂，致使会议不得不改日进行。
案例4：没有实际效果的评审会
某软件公司召集了公司所有的中高层经理花费一个上午的时间,评审了一份230多页的需求文档，找到了20多个小缺陷,然后中午大家聚餐,庆祝需求评审顺利完成!
以上的现象在很多项目运作中都可以遇到。
概括起来，在需求评审中常见的问题有以下几种：
1）需求报告很长，短时间内评审者根本就不能把需求报告读懂，想清楚。
2）没有做好前期的准备工作，需求评审的效率很低。
3）需求评审的节奏无法控制。
4）找不到合适的评审员，与会的评审员无法提出深入的问题。
除了上面案例中提到的这些问题之外，在软件产品的需求评审工作中，我们还会遇到下面几种情况（可能还有其他问题，无法一一列举）：
5）需求评审人员对行业和业务深度了解不够。
6）需求评审人员对需求实现所需的技术架构不理解。
7）需求评审人员对需求的优先级了解的不清晰。
8）需求评审人员对需求的颗粒度的大小把握不好
9）需求评审人员不够客观评价，追求一团和气。
以上需求评审中常见的问题（其他行业的产品需求评审可能也有类似的问题），如何改进需求评审的工作质量？
基于笔者过往6年软件工程质量管理实践，并结合和同行交流所获得的体会，我提出如下改进框架（如下表1）。
表1 软件需求评审工作的质量改进策略
另外，从过程管理的视角看，需求评审是需要有始有终的，因此还需要做好需求评审后的相关跟踪工作，确保措施能够落地。
以上的策略还是比较笼统的，下面，我来详细说明下。
建议1：充分准备评审
评审质量的好坏在很大程度上取决于评审前的准备活动。
常见的问题是，需求文档在评审前没有提前发给参与评审的人员，没有留出充分的时间让参与评审的人员阅读需求文档。
更有甚者，没有执行需求评审的准入条件，在评审文档中存在大量的低级错误，或者没有在评审前进行沟通，文档中存在方向性的错误，从而导致评审的效率很低，质量很差。
对评审的准备工作也应当定义一个检查单，在评审之前对照检查单落实每项准备工作。
建议2：分层次评审
我们知道用户的需求是可以分层次的，一般而言，用户需求可以分成以下三种层次：
目标层需求:定义了整个系统需要达到的目标。
功能层需求:定义了整个系统必须完成的任务。
操作层需求:定义了完成每个任务的具体的人机交互。
目标层需求是高层管理人员所关注的，业务层需求是中层管理人员所关注的，操作层需求是具体操作人员所关注的。
不同层次的需求，其描述形式是有区别的，参与评审的人员也是不同的。如果让具体的操作人员去评审目标性需求，很容易导致“捡了芝麻，丢了西瓜”。
如果让高层管理人员去评审操作性需求，无疑是一种资源的浪费或者出现高层管理者拒绝参与的情形。
建议3：正式评审与非正式评审结合
正式评审是指通过召开评审会的形式，组织多个专家，将需求涉及的人员集合在一起,并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。
非正式评审不需要这种严格的组织形式，一般也不需要将人员集合在一起评审，而是通过电子邮件、文件汇签甚至是网络聊天等多种形式对需求进行评审。
两种形式各有利弊，但往往非正式评审比正式评审的效率更高，更容易发现问题。因此在评审时，应该灵活地利用这两种方式。
建议4：分阶段评审
应该在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。
分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风险，提高了评审的质量。
比如可以在形成目标性需求后进行一次评审，在形成系统的初次概要需求后再进行一次评审，当在概要需求细分形成几个部分后，对每个部分进行评审，最终对整体的需求进行评审。
建议5：建立标准的评审流程
对正规的需求评审会需要建立正规的需求评审流程，按照流程中定义的活动进行规范的评审过程。
比如在评审流程定义中可能规定了评审的进入条件、评审需要提交的资料、每次评审会议的人员职责分配、评审的具体步骤、评审通过的条件等。
建议6：精心挑选评审员
需求评审可能涉及的人员包括:
需求方的高层管理人员、中层管理人员、具体操作人员、IT主管;
供应方的业务专家、市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方的业务专家等。
这些人员由于所处的立场不同，对同一个问题的看法也是不相同的。有些观点是和系统的目标有关系，有些则关系不大，不同的观点可能形成互补的关系。为了保证评审的质量和效率，需要精心挑选评审员。
首先，要保证不同类型的人员都要参与进来，否则很可能会漏掉很重要的需求。其次，要在不同类型的人员中选择那些真正和系统相关的、对系统有足够了解的人员参与进来，否则很可能使评审的效率降低或者最终不切实际地修改了系统的范围。
建议7：对评审员进行培训
很多情况下，评审员是业务专家而不是评审活动的专家，他们没有掌握评审的方法、技巧、过程等，因此需要对评审员进行培训。
同样，对评审主持人也需要进行培训，以便参与评审的人员能够紧紧围绕评审的目标进行讨论，能够控制评审活动的节奏，提高评审效率。
对评审员的培训也可以区分为简单培训和详细培训两种。简单培训可能需要十几分钟或者几十分钟，需要对评审过程中需要把握的基本原则，需要注意的常见问题说清楚。
详细培训则可能要对评审的方法、技巧、过程进行正式的培训，需要花费较长的时间，是一个独立的活动。另外，需要注意的是,被评审人员也要被培训。
建议8：充分利用需求评审检查单
需求检查单是个很好的评审工具。
需求检查单可以分成两类:需求形式的检查单和需求内容的检查单。
需求形式的检查可以由QA人员负责，主要检查需求文档的格式是否符合质量标准。
需求内容的检查由评审专家用来检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等，这是需求评审的重点。
检查单可以帮助评审员全面、系统地发现需求中的问题，检查单也要是随着过程资产的积累逐渐丰富和优化。
建议9：做好评审后的跟踪工作
在需求评审后，需要根据评审人员提出的问题进行评价，以确定哪些问题是必须纠正的哪些可以不纠正，并给出充分客观的理由与证据。
当确定需要纠正的问题后，要修改需求文档并进行复审。切忌评审完毕后，没有对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流。
以上就是笔者针对软件需求评审工作中常见问题，提出的改进策略，包括9个建议，称之为“九大法则”。
这9条建议，归属在3个维度，分别是时间、能力和质量维度，其中时间维度（5条法则），这主要是指组织需强化需求评审工作的流程和计划职能，提高需求评审的效率，降低评审成本。
其次是能力维度（2条法则），组织需要重点赋能评审人员，评审人员在进行需求评审时需要保持专业性，这也是同行评审的应有之义。
质量维度也有2条法则，这主要是从检查和跟踪两个视角展开，确保相关措施的完整性和可落地性。九大法则和三大维度的映射关系，如下表2
表2 需求评审质量改进的“九大法则”和“三个维度”映射关系表
我相信，朋友们在实践中细心体会、实施上述的9条建议，定会受益匪浅。
Tip：
1、另附需求评审的项目和指标，供有需要的同学参考。
2、本文内容，部分参考了任甲林老师《术以载道：软件过程改进实践指南》中的评审方法，在此表示感谢！
一文掌握需求评审常见难题及改进策略【一杯咖啡谈项目】相关推荐
- 一文搞定JVM常见工具和优化策略
目录 1. 概述篇 1.1. 背景说明 1.3. 调优概述 1.4. 性能优化的步骤 2. JVM 监控及诊断工具-命令行篇 2.1. 概述 2.2. jps:查看正在运行的 Java 进程 2.3. ...
- 需求评审失败，常见的5大缺陷。
1.拒绝没有完整的需求文档 需要有完整的需求文档,首先需要包括关于文档的信息,我们将文档名称.文档版本.撰写人的信息.文档的修改记录以表格的形式,做简单的说明. 接下来是关于需求总览,即需求列表 ...
- 数据仓库应用篇（一）需求文档模板和需求评审
一.需求文档模板 1.产品需求文档:文档标识.产品概述.功能说明.全局说明.非功能性需求等 2.交互设计文档(DRD): 3.报表需求文档: 1)业务数据: 业务场景.指标名称.指标定义.维度.维度定 ...
- 干货！最全需求评审指南，让你不再怕被怼
本文由作者 冰冰酱 发布于社区 对于产品新人而言,日常最头疼的会议就是需求评审. 在做产品的这几年,笔者开过上百场需求评审会,曾经被研发在会上怼哭过一次,也遇到过研发和产品大吵半小时.最终有一方摔门而 ...
- 需求评审五个维度框架分析及其带来的启示-4-需求条目化管理
需求条目化管理是指需求的主体分条目管理,比如对于用例.用户故事.特征点的条目化列表管理,有些工具中条目称为工作项(work item).条目化管理的特征是1,状态流转实现工作流:2,条目属性字段可定制 ...
- 需求评审五个维度框架分析及其带来的启示-3-典型需求评审
典型情境是指软件开发的常见情境,本文选择如下来进行分析: 1. 传统瀑布模型开发下的需求评审 2. 使用IEEE Std. 1028的需求评审 3. 敏捷开发下的需求评审 传统瀑布模型下的需求评审 对 ...
- 需求评审五个维度框架分析及其带来的启示-2-框架原理
本文试图归纳分析近年来出现的需求评审方式方法,全面涵盖系统性评审和非系统性评审,提出五维需求评审框架. 首先确定对于需求评审的定义,结合传统需求阶段评审和敏捷迭代开发中相关需求实践,得如下定义. 定义 ...
- 07【需求评审】 UED
07[需求评审]& UED 1,什么是需求评审? 是产品设计完成之后,产品经理和研发团队进行细节确认的一个重要环节. 这里边包含3个比较重要的方面: 一,有谁参加? 产品经理 研发团队(前端, ...
- 项目开发 | 转载 | 需求评审与技术评审
转载自 知乎:项目经验 需求评审与技术评审 ,文字未改,格式有改动. 文章目录 0. 序 1. 需求评审 2. 技术评审 0. 序 做开发应该对需求评审,技术评审并不陌生. 但常有小伙伴抱怨,需求评审 ...
最新文章
- 寻找带环的链表的柄长
- Shell 正则表达式总结及其含义举例
- 怎么修照片多余的部分_PS教程旧照片翻新修复技巧
- php 导出word 高度,PHP导出word
- R语言中级--自定义方程
- 极乐技术周报(第十六期)
- javascript-自定义对象-数组形态对象-字典形态对象
- python基础for循环和while循环（十）
- 离散数学：构造性二难推理和破坏性二难定理的解释
- 21-python-time,random模块的应用
- 设计模式--策略模式（C++实现）
- 初级计算机课,教学ppt课件计算机初级培训.ppt
- 程序员试用期被裁，只给半个月赔偿
- Jacoco 实现 Android 端手工测试覆盖率统计
- 高频直流电源在整改、降压和作用方面解决方案
- ps—图层、（移动工具中）对齐
- android手机获取qq闪照的方法,QQ闪照怎么保存 闪照保存到手机的方法教程
- 银行测试（7）-支付测试
- 再不复工，公司就要发现没有我们也能正常运转了
- 帝国Cms7.5后台getshell | (CVE-2018-18086)漏洞复现