项目管理之漫谈如何开展有效的需求评审
发布网友
发布时间：2024-09-03 10:29
共1个回答
热心网友
时间：2024-10-16 20:31
一、什么是需求评审？
在百度百科的定义为：
需求评审：通过将需求规约文档发布给利益相关者进行检查，发现需求规约中存在缺陷（如错误、不完整性、二义性等）的过程。
而我的理解为：
需求评审：将需求文档发布给权利相关的人员进行查阅检查，发现需求文档中存在的缺陷（如错误、不完整性、二义性等）并完善，然后聚集相关人员召开相关会议进行需求解析与确认，最终达到明确确认好需求的过程。
附录：
需求的定义：人们在某一特定的时期内在各种可能的价格下愿意并且能够购买某个具体商品的需要。
延伸需求的定义：人们在某一特定时期内购买某个具体的产品所需具备的特征。
二、为什么要进行需求评审？
需求评审，特别是在软件项目中的需求评审是非常重要的一项项目任务。因为这项任务一是可以尽早发现需求中的问题，减少后期修改缺陷的成本；二是和相关干系人明确了需求范围和明确了需求的理解保持一致，避免后期的互相推卸问题；三是明确了需求的可行性及实现方式；四是有助于相关人员了解用户业务需求和产品设计的由来。
古语有云：当局者迷，旁观者清；智者千虑，必有一失等。所以即使是经验再丰富的需求分析人员或是产品经理也是有可能犯错或是考虑不周的时候。同时考虑到，每个人的理解能力和表达能力等不同，所以也可能存在需求在传递的过程中发生了很大的偏差......由以上的种种因素的影响，如果没有进行需求的评审工作，那么得出的需求说明可能存在和实际的业务需求千差万别，从而存在后期推翻重做的风险，甚者整个项目失败告终的重大风险情况。
因此，为了使得需求文档的正确性得到彻底的验证以及权利相关人员需求理解达成一致，并明确好需求的范围，降低后期的需求风险问题，需求评审是一个行之有效的方法。
虽然，很多人都明知道需求评审的重要性和有效性，但实际上，很多企业公司，特别是一些中小微的软件企业公司，他们在需求调研阶段，做法往往是需求分析人员（可能是产品经理、项目经理、需求分析师等人，这个根据不同的公司的岗位设置而定）大致找用户沟通下，然后就开始编写项目需求规格说明书，写完后再跟用户简单沟通一下，就直接进入设计开发阶段了，压根没有进行需求评审。也有不少的企业公司虽然也有进行“需求评审”的项目任务，但更多不过是“走过场”的情况，出现“走过场”的情况大多数的原因是其他的人员根本不关心需求的情况，认为需求就是需求分析人员或是产品经理的事情，他们怎么写那么他就怎么做就可以了，所以在要求提需求异常时要么回复说无意见或是简单找几个错别字提一下应付了事，没有提出有效的需求异常。也有不少的企业公司，在进行需求评审过程中，逐渐将关注点在不知不觉中转向了技术，结果需求评审会议就变成了技术讨论会，使得大家想得最多的是需求如何实现，而不是需求文档本身是否存在问题，再有就是所谓的需求评审都是临时临急的召开，没有做好前期的准备和熟悉，使得大家都不知道开什么会，糊里糊涂的来参加个会议，从而导致效率低，结果可想而知了，肯定是不了了之......
以上的这些情况，在很多的中小微的软件企业公司多多少少的都有存在，出现这些现象的项目的结果一般都是可预想到的，要么的项目草草了事，然后后面就再弄个二期、三期、四期的继续忽悠下去，要么就不了了之，实在有责任的话，让项目经理这个背锅侠去“背锅”了事，要么就是项目失败告终了。
题外话：既然需求评审那么重要和有用，那么是不是所有的需求都需要进行需求评审呢？其实不然，如果是一些比较小的需求或是非常明确的，不会产生歧义或是理解不一的需求，其实不是非要进行需求评审的。
说了那么多需求评审的必要性了，那么下面我们开始进行本次的正题，如何进行有效的需求评审。
一份好的需求规格说明书（最好是有相关的模板，这样可以统一风格以及提高效率），是进行有效评审的必要条件。
因为需求规格说明书，不仅是代表用户的期望意愿，更是需求分析师（或产品经理/项目经理）对用户需求的总结和分析，同时也是需求评审的必须材料。
一份好的需求规格说明书，必须包含用户的每一项需求，做到不漏不差，同时分析人员也需要对需求进行必要性的梳理和分析：判断好哪些是合理的，哪些的不合理的，哪些是用户的潜在但用户没有想到的。一般情况，最好能根据业务场景来进行需求的描述，主分为：主业务流程场景和扩展流程场景两大类。主业务流程场景是比较容易理解的，因为是用户一直以来赖以生存的标准化操作流程，一般比较耗时的是扩展流程场景，所以扩展流程写得越完善，说明需求人员考虑得越周全，后期需要优化或是改善的地方越少。
2. 充足的会议前准备时间
在开始进行评审会议前，一定要给相关人员充足的会前查阅时间，不要出现相关人员参会前都不清楚所参与的会议主题以及内容。所以在召开评审会议前（最少提前1天及以上，如果条件允许，提前一周左右，但也需要控制不要提前太多时间，因为每个人都有每个人的工作内容，提前太多的话，会容易出现忘记，开会前一天应做好相关提醒工作），一定将相关的资料提前发布给项目相关的人员熟悉，如果条件允许，在正式评审前，也可进行一些必要的沟通和讨论，完善需求文档【完善后的文档需及时反馈给项目相关人员，并告知更新内容和缘由】。同时也做好提前订好会议室和准备会议通知。
3. 分层次评审
一般情况下，需求是由不同层次组成的，例如领导层、业务层、以及操作层，所以按照这样的结构可分为如下三种层次的需求来进行：
（1）目标性需求（领导层关心）:定义整个系统需要达到的目标；
（2）功能性需求（业务层关心）:定义了整个系统必须完成的任务；
（3）操作性需求（操作层关心）:定义了完成每个任务的具体的人机交互。
对不同层次的需求，其描述方式还是应有所区别的，同时参与评审的项目人员也相应不同的。假如让具体的操作人员去评审目标性需求，可能出现“我不清楚这个，我要的不是这个”的“推脱”现象，如果让高层的管理人员也去评审那些操作性需求，无疑是一种资源的浪费。
分层次评审，可以让不同类型的参与人分别评审他们关注的内容，从不同的角度找到需求的异常，提高评审效率。
4. 分阶段进行评审
一般情况下，一个会议就那么一两个小时左右，那么短的时间内，不可能将每一个细节都涉及到，再加上评审员也有一个理解需求（自己理解和评审讲解员的理解是否一致性的理解）的过程，同时在短短的会议中不可能发现太多问题。所以需求的评审应该在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。可以根据需求人员进行需求分析的进度，将一个整体的需求分为不同的阶段，组织小规模的评审。在形成目标性需求后进行一次评审，在形成系统的初次概要需求后进行一次评审，然后可对概要需求按功能细分成几个部分，对每个部分进行各个评审，最终再对整体的需求进行评审。这样降低了需求返工的风险，提高了评审的质量。
5.把握需求评审的关键点
（1）对需求的正确性进行评审
① 是否有需求与其他需求相互冲突或者重复？
② 是否清晰、简洁、无二义地表达了每个需求？
③ 是否每个需求都在项目的范围内？
④ 在现有的资源内，是否能实现所有的需求？
（2）对需求的完整性进行评审
① 编写的所有需求，其详细程度是否一致和合适？
② 需求是否能为设计提供足够的基础？
③ 所有对其他需求的内部引用是否正确？
④ 是否包含了每个需求的实现优先级？
⑤ 是否定义了功能说明的内在算法？
⑥ 是否包含了所有已知的用户需求？
⑦ 是否遗漏了必要的信息？
⑧ 是否对所有预期的错误条件所产生的行为都编制进文档？
（3）对需求方案的可行性（包括技术可行性和经济可行性）和成本预算进行评审
（4）对需求的质量要求进行评审
6.评审后的记录和跟踪
需求评审不是开完会后就完结了，需要做好评审会议纪要和问题跟踪，记录好每一次评审会的情况，总结评审结论，同时也是作为是否进行第二轮、第三轮评审的依据，会上所提出的问题，需要跟踪记录，保证每个问题会后有人负责和处理。
以上就是我个人对有效的需求评审的理解！
