大约在我刚刚毕业参加工作那会儿，我们的小组就在推举需求评审这件时间，本人有幸跟着我们组那个时候充满男子气概的老大，整天沉迷于需求评审，怼天怼地怼需求怼开发。非常幸运的是当时的团队也非常的虚心抗怼，所以这件事情总体产生了一个比较正向的结果。
1、为什么要做需求评审？
最初在做需求评审的时候，我还没有了解到测试左移这个概念，只是那个时候作为一个测试执行角色， 被在后期才发现需求不明确的一些问题困扰着，并且往往会影响到版本的发布。随便回忆一下都可以列举一系列罪状：
--版本即将发布的时候才意识到我们所生产的产品与策划或者原始需求方产生了偏差，那么这个时候我们去修改的成本已经相当的大了。
--版本测试过程中发现多处需求不清晰，在了解了策划的意图以后程序又反馈目前的架构上不支持这样的做法。
--程序在开发的过程中意识到需求不明确私下和策划进行沟通却没有通知到其他干系人，导致大家的理解出现偏差。
。。。。诸如此类等等
需求作为整个产品版本的领头部分，哪怕出现一个细微的小问题在越往后期越会被无限的放大。
2、需求评审的成本与完成的质量。
能力成本:作为一个质量保证人员，我们要如何在前期去保证需求的质量呢，有些同学会说，我们如何在前期去预料到后期一系列的事情发生呢？这对相应人员的能力要求，会比较高，不同能力或者不同思维的人员来做需求评审所产生的结果与质量也是不同的。
时间成本：但是在推行需求评审的过程中其实也会存在许多的质疑，需求评审同样需要成本，需要评审人员在版本前期去花费较多的精力去理解需求、质疑需求，而且也不是在这样的时间段能够马上提出所有的疑问，随着案子的演进与更改也会带来和程序一样的小型质量演进。没有做好正确的管控可能无限拉长版本前期周期。
即便投入了这些成本，就能够产生好的效果吗？
所以如何更快更好的完成需求评审？这需要需求存在质量，保证质量的人员思维足够完善，完整的一套流程来共同努力。
3、把握需求评审质量。尽量让每一个需求评审员思维大方向不出现遗漏。
需求评审会
这个会议会邀请开发、策划、QA等干系人一起参加，大家在会议上各抒己见最后敲定需求。目前我参与过的比较多的项目中QA的存在感都很低，基本上一言不发听完全程。这样的会议对与QA来说不像是评审会倒像是知照会，甚至有些需求评审会会忘记去通知QA到场。为什么呢，因为QA在里面没有产出价值或者说目前暂时无法产出价值。针对这一点毫无疑问我们需要提升每一个需求评审员的评审技能。
控制需求评审环节的输入与输出。
一开始实行需求评审的时候，我们是采用一带一的模式，也就是开头说的由导师带领去参加需求评审会议，说实话这样比较靠经验也比较慢。毕竟每个需求案是不一样，而且我发现每次总会有一些我知道方向遗漏考虑了。于是我给自己列了一个需求检查表，并且在每次版本过程或者评审过程中去补充一些被遗漏考虑的方向。后来这张表同样也可以推广给一些需要去需求评审的人员手上，我通过各自的经验来共同分享与维护这张表。详细说明见需求评审检查表与报告。
有了这份检查表以后我们也慢慢意识到，在测试左移的过程中，仅仅增设某个环节是远远不够的，我们需要拥有一些看得见摸得着的检验标准与环节成果。
需求评审环节：
需求输入：策划案、需求评审会议
评审输出：策划案逻辑流程图，需求评审报告，更新的策划案。
需求评审报告：基本是基于检查表产出的一些成果。对于高职级的同学需要去审阅这样的报告快速了解当前案子需求质量情况。对于后续测试同学更需要去了解需求的一些约定与风险。
策划案逻辑流程图：本章不细节描述，详细见：让测试过程图表化
4、需求评审流程。
接收到案子--》组织需求评审会议--》输出需求评审报告--》策划更新案子同步各方--》对策划案质量进行打分--》QA组内评审。
前几个模块在前面都已经有所提及，这里不赘述了。主要提一下对策划质量进行打分这个环节。如果只是不断去做某个环节的检查和反馈问题，而对上游没有任何的改进和推进，是很被动的做法。在需求评审了一段时间发现策划案的质量永远存在很多问题的时候，我就萌生了能不能对策划案进行打分去反向促进的想法，这个想法当时也只是一闪而过没有去落地。一年多以后由另外一个组处发起了。打分表更加注重的是策划案的质量。后来在我们两个团队的融合下终于形成了现在一表在手，需求我有的一个局面。（这里纯属吹牛）
在需求评审的过程中，有一个不可忽视的问题，需求在不断地因为各种问题而迭代，这种迭代信息如何能够每次都快速的同步到各方干系人手里是一个值得思考的问题。
QA组内评审。这个环节可以根据情况进行，这个环节QA将自己作为介绍案子的角色，相互之间进行评审，同时也便于将一个大版本之前不同案子之间的联系关联起来。
5、需求评审检查表与报告。
检查元素：
需求角度
1、原始需求
结合原始需求评估该案子的可行性以及与原始需求是否符合。
真正的需求评审应该是QA也能够对产品的发展方向需求的合理有能力去评估。但是目前由于水平限制，我们把更多的重心放在了需求的检查上。
在真正的需求评审过程中，我们需要将策划案与原始需求的吻合度做个匹配。因为在项目中有出现过策划案与原始需求出现偏离的案例（捂脸）。
举个栗子：
之前在做一个项目的时候，原始需求方提出需要提供一款产品给学生作为考试工具，很粗略的体验了我们的产品后说认为现在产品的总体的功能就可以，那么策划方就提了一个很简单的策划案：现有的功能支持离线使用，并提高质量。
但是在实际开发的过程中，原始需求陆续提来要求，需要也支持在线模式给学生进行试用和适应，以及现在产品不支持xxx功能需要进行支持。而此时产品已经修复了某些bug进入了测试阶段，这个时候再来不断的增加需求，耗费了非常大的成本。
所以在这个环节我们需要注意的时候策划方有没有和原始需求方进行充分的沟通，原始需求方会在什么样的场景需求下使用我们的产品，是否有潜在需求被遗漏。
2、了解目标用户
辅助评估可能达到的用户量，分析用户行为。这一个环节给我们后续进行测试能够起到很大的指导作用
假设我们是要开发一个产品推向市场，根据现有的销售渠道目标支持用户是30w，再设计测试的时候就需要去考虑对应的性能测试。又或者我们的目标用户是某些年轻的群体，某些地区的群体，那么我们可以通过分析这些群体使用机型占比来考虑适配测试的优先级等等。
3、竞品分析
可以通过竞品分析了解细节，提出优化建议。
比如说我们在做一个链接收藏的功能的时候觉得现有的设计并不好用或者不好实现，例如如何爬取网络标题信息，如果没有标题信息怎么展示比较美观，如何管理大量的链接。由于我们不是专业的设计人员，我们可以去参考一些竞品，例如QQ来对比我们和对方方案的优劣。
4、情景分析
结合情景分析，覆盖用户场景用例，用户可能在什么场景下使用这些功能等等。
举个栗子：
还是上文的那个案例，我们的工具是提供给学生进行考试的，那么这个考试具备着特殊的地点、操作和持续时长，我们在设计测试场景的时候就会着重考虑系统的适配、特定的操作用例和稳定性测试
功能角度
1、运行环境的兼容。
考虑这个功能在各个平台的兼容差异，提醒策划做出需求方面的制定。
2、版本的向下兼容。
功能兼容：
1、新增功能在旧版本上是否会有展现与不兼容。
数据兼容：
2、新的数据类型在旧版本上是否能够展示。 例如我们新增了一种微博类型，发布后在旧版本上能否正确展示
3、旧版本的新/旧数据是否对新版本造成影响。 新版本出了一个被点赞三次即可获得奖励的功能，那么其他用户在旧版本上点赞是否可以触发相应的奖励给予。
兼容性的评估是我们在前期需求评审的时候就要去考虑的一个要素，如果新功能的推出势必会带来兼容问题，那么我们在版本发布是时候才发现久无法做好足够的应对。
3、版本的向后兼容
评估是否兼容未来的版本。这个部分我们需要去考虑未来产品的发展是否可能会对现在的功能产生兼容影响，这一点可能比较难理解，这里举个例子。
之前有设计了一个功能，通过配置cmp地址就可以跳转到指定的界面。那么这个时候需要去考虑我们未来增加了功能模块的cmp地址在现在的版本不存在需要如何响应。
4、功能完整性
哪里来？经过怎样的处理？到哪里去？这里可以通过梳理业务流程图来确认功能是否存在重大逻辑缺失。
例如这样一个需求案。
第一部分描述了用户上传资源
第二个部分描述了审核通过的资源展示在平台上
缺失了审核部分的需求描述。
5、功能交叉性
对已有功能的影响。评估新增功能是否改动到已有功能、评估可能影响的模块。具体可以考虑是否有重复的操作区域，是否有数据上的交互。
6、需求交叉性
新需求与新需求是否交叉，例如多个案子之间有协作依赖关系。
新需求与旧规则是否交叉，例如历史规则在这个版本得到变更。
QA角度评审
1、用户体验
交互是否符合用户操作习惯，是否简单好上手
是否对于错误或者异常有友好提示、操作保护、数据说明
是否有管理后台可操作配置
2、测试预期标准
服务端性能标准，安全标准，需要适配的设备，是否国际化
3、开发需求
设计方案在开发实现上的局限
例如策划希望可以达成某个效果，开发反馈在架构上不支持，需要巨大的开发量，性价比不高，这种时候也许我们需要考虑折中的方案。
4、前期风险评估
前期暴露出来的未来的测试风险、版本进度风险等等。
5、后期测试注意事项
需要把这个时期获得的一些信息与注意事项向后面的环节传递
打分元素
1、功能设计案的全面性
2、需求明确性、准确性
3、示意图的参考性是否准确
4、功能交叉性是否考虑完善
。。。。。。
由于这部分原创不是我所以只展示部分重要的点。
作者：鼓楼一枝花
链接：https://www.jianshu.com/p/8c1c13a9b221
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。
上周连续针对同一个版本进行了三次需求评审，第一次进行了全范围的评审，涉及到各方相关人员，包含：产品、设计、开发（客户端和服务端）、测试；第二次产品团队内部小范围的评审，主要是为了确定第一次评审中部分不太确定的/没考虑到实际可能遇到的问题的需求，涉及人员：产品（iOS端和Android端）和运营；第三次针对那些不太确定的/没考虑到实际可能遇到的问题的需求进行确认，涉及人员：开发和测试。等三场评审下来，就累成了狗。
一场需求评审会议变成了三场，这肯定是有问题的，是该好好检讨下了。
之前一直在创业公司，需求评审会基本很随意，叫上开发、设计和老板就可以直接开始了，评审会上也会遇到一些问题，但涉及的人比较少，且一个人从头到尾都只负责一个项目，事后基本上只要口头确认下评审时的问题就行了。但流程较复杂的公司情况就有些不一样了，需求评审会参会人数比较多，并且一个人可能会负责多个项目，需要重新调配资源，一旦评审中需求不确定/没考虑周全的问题，就会出现多次需求评审的情况，这就极大的降低了工作效率。
需求评审时常发生的情况：
1、与会人员对需求的目标不明确，易发散思维，最终偏离方向。
2、对某个需求点相持不下，认为该需求不合理/开发周期长不划算，从而导致场面混乱，长时间僵持下去。
3、对技术方案探讨不定，对问题点无限引申。
4、遗漏评审时的待改动的需求点，会后找相关人员再次确认。
基本上遇到上面情况中的任意一种，都会将需求评审时间拉长，导致效率低下，轻则需求产生变更，重则需求功能无法实现，产品人员在评审过程中也容易产生浑身燥热、体乏无力和头昏脑涨的感觉_|￣|○...
那如何进行有效的需求评审呢？
我结合我自己上周做的需求评审作了一些总结，天热了给自己拔拔罐，希望能做到更规范，减少评审时会出现的问题，少踩点坑。
将需求评审分为三阶段：
1、评审前
相关资料准备（确保人身安全）****
1）产品需求文档
我的需求文档里一般包含四块：项目背景、项目目标、需求概述和需求详细描述，必要的时候可以带上项目风险（说明此次版本可能带来的问题或考虑不够完善的地方）和业务流程图（对某些复杂功能/逻辑的分解）。
[图片上传失败...(image-52a805-1537845540344)]
产品需求文档主要是要把需求的逻辑表达清楚没歧义，对各个细节描述清晰，各输入输出项（涉及到表单/数据的输入输出）、业务流程（功能的交互步骤和数据的流转）、计算规则（某些特定须计算的规则）、判断逻辑 （业务流程中出现的一些判断逻辑及各种判断下的反馈情况，账号的权限范围也属于这种）和一些特殊情况（如是否支持横屏啊之类的）都要写清楚，如果实在记不住太多，每次写需求文档时都会这里漏个流程那里漏个判断的，可以整理一份适合自己的需求文档自查清单，每次写完后从头到尾对照一遍。当然不能事无巨细都通通一股脑写进去，不然开发和测试的朋友会看的很辛苦，小心被打...
举一个活生生的反例，上周写文档时有一个计算规则比较想当然了，要算“累计阅读时长”，阅读时长嘛就是阅读时长嘛，一句话就带过了，然后在需求评审时就比较惨了，该如何统计这个阅读时长？直接用定时器吗？还是使用本地时间？用定时器比用本地时间相比既复杂又低效，但如果用本地时间，那用户直接修改手机上的时间给不给累计阅读时长？还有用户如果一直停留在当前阅读页还给不给算阅读时长？...后面对这个功能的计算规则讨论了好久，最终评审会上也没确定下来。所以说，做好细节是多么的重要！/(ㄒoㄒ)/~~
产品需求文档的准确和详细可以有效减少需求评审时的花费的时间，也能让参会人员更清楚地了解需求。
2）线框图
带上线框图而不是比如这样或那样，配合线框图有利于对需求点的梳理。需求文档里可以简要配些线框图方便文字的理解，不过需求评审时还是另外打包一份线框图单独带着吧，可以详细点，把交互稿也带上。
第一次评审的时候，我忘了带，而需求文档里也刚好没放那个页面的线框图...于是我只能让大家跟着我一起在脑海中绘制一副图，能不能绘出来我就不清楚了Orz...反正不要学我！
3）相关数据
带上数据而不是我认为，一些需要数据支撑的需求点要带上相关的数据，用数据说话。
小范围的沟通（确认方案）****
产品需求文档写好了，这个时候就可以去找涉及到本次改版的同事们去聊聊了，不要有写好产品需求文档就万事大吉，接下来只要等需求评审会就可以了这样的想法。提前小范围沟通可以避免很多不必要的撕逼，将一些不确定的方案给确定下来，探讨方案实现的难易程度，确保某些需求的可行性，还可以发现可能与原有产品逻辑相冲突的地方等，把这些坑都填好，这样在需求评审的时候就可以快速走过了。
上周我连开了两个项目的需求评审会，一个是改版还有一个是新应用的上线，改版的需求评审总共开了三次，就是最开始说的那种情况，而新应用上线的评审只开了一次而且只用了不到半小时，需求评审前和开发沟通就基本上已经将我不太确定的方案给确定了下来，并且确保了部分不确定需求的可行性，在评审会上是一次就过。有对比才会有真相，多么痛的领悟，不要什么都等到需求评审会议上才去确认/解决，提前做好沟通工作，能大大提高需求评审的效率。但不是说提前把所有的需求都沟通一遍啦！大家都很忙，动好脑子带好方案再去沟通！
产品内部评审（确认需求）****
产品内部评审就是在产品团队内部进行小范围评审，确保需求逻辑的一致性。在确定好各种方案后，最好在产品内部先进行评审，特别是当有两个产品经理分别负责Android客户端和iOS客户端但是两种终端数据又是用的同一个接口数据的情况，说白点，就是Android客户端和iOS客户端要求在大体上保持一致的情况下，为了保证逻辑的一致性，最好先进行产品团队内部的小范围评审。
一次内部的小范围评审可以规避大部分需求不合理的地方，可以直接有效的提升需求评审的效率，同时也能增加其他团队对产品团队的信任感，以后办起事来就比较方便了你懂得(o)/。之前在创业公司就没有碰到过这种情况，因为Android端和iOS端都是我负责的，功能是一致的，所以就没这种情况，也就可以省去这一步产品内部评审了...如果功能逻辑涉及到多个产品负责人，这一步还是很有必要的！
提前把需求文档发出来（有备无患）****
根据以上步骤确认好需求后就可以把需求文档发出来了，以邮件/群聊的方式发出来，让与会者提前查看产品需求文档，不求他们能够把需求文档从头到尾看一遍，但求大家能知道下个版本要做的需求有哪些，这样前期的服务工作才算到位。
以上工作都做好了基本上就可以进行需求评审了，预约好会议室后通知相关参会人员参加。
2、评审中
正式需求评审时，带好必备品，就可以开始了，基本上只要前期准备工作做得好，需求评审时出现的幺蛾子就不会太多，稍微拍拍就能灭掉，所以评审时状况百出，多半是准备工作不到位。但除了前期的准备工作，在评审时还有几个需要注意的地方，能够帮助提升需求评审的效率。
产品经理应有的态度（兵来将挡水来土掩）****
1）有清晰的目标
相比其他参与者，产品经理要对此次需求评审更有方向性和目标性，这次改版所要解决的问题以及所要达成的目标都应铭记于心，只有产品经理自己有清晰的目标才能做到即使同时被多人撕也不发生动摇，才可能确保参会的其他团队能理解并认同该版本所要达成的目标以及要做的功能点。
即使有着明确的目标，也别想着要把自己的想法强加到别人的脑子里，很容易发生：目标很明确，所以大家要按我的想法走的这种情况。需求评审目标并不是为了要说服谁！召开评审会，就是为了让大家对你提出的方案进行批评指正或提出疑问点，从而能及时地解决并发现方案中的问题，保持各团队目标一致，将产品做好。
2）把控好时间
需求评审时很容易会对某个需求/方案僵持不下，常一讨论起来就是半个小时，多遇到这么几个僵持情况，一场需求评审下来就好几个小时，不仅会慢慢耗尽大家的精力，而且需求评审的效果也不好，得不偿失！所以产品经理要严格把控好时间，由于前期工作准备不充分而导致一些需求/方案模棱两可，且暂时无法立马提出解决方案的可以会后确认好后再沟通，必要时可以进行第二次评审。
3）认真倾听
可能别人一上来就开始对你的方案提出不认可，这个时候就得认真倾听；开发在探讨技术方案的时候你也要认真倾听；先在大脑梳理好他们在说什么，倾听后才能对症下药，而不是打断然后陈述自己的观点。
倾听后再陈述而不是直接打断，可以让人觉得你在认真思考后才说出这番陈述的，更有说服力，并且不跟其他团队硬碰硬，先了解他们的问题再提出解决方案，不是显得更理智么？
4）保持清醒的头脑
在需求评审会议中，很有可能会发生争论，产品经理一定要保持理性，切不可让怒气或胆怯冲昏了头脑，失去理智。对会议上提出的每一个问题都应该记录下来并作出解答，要冷静客观的把自己的观点给陈述出来。
小范围的讨论（见仁见智）****
在需求评审讲需求点时，开发会针对某个点进行技术方案探讨，这样有利于及早发现需求点与现有逻辑相冲突或由于硬件问题而导致需求变更或夭折的问题，避免到开发时才发现需求没法做...但也要控制好时间，引导大概讨论下技术实现方案，具体的细节之后再讨论。
除了开发团队内部小范围的讨论外，还有设计团队，不过设计一般不在需求评审会上讨论了，毕竟，设计基本上不会影响到产品需求的变更。
定下开发周期（诞辰）****
如果评审顺利的话，就可以直接定下开发周期了；如果不顺利，那就放在评审后吧~上周评审时就各种不顺利，三场评审后还加了一场开发周期的确定...祝愿以后一切顺利吧！
3、评审后
会后及时输出会议纪要，罗列出会议中有争议仍待解决的问题、改动的部分和结论，将完善后最终更新过的需求文档发送给参会人员，通知需求评审已完成。之后对问题进行跟踪，保证评审结果的落实。
总结
能否在产品需求评审会议中如鱼得水，提高需求评审的效率，我觉得前期的准备工作很关键！
作者：小圣
链接：https://www.jianshu.com/p/e5fc74a78ae5
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。
网友评论