从问题域和解决域看需求评审

　　什么是需求评审?

　　需求是用户在产品使用过程中，发现产品存在无法满足的业务场景或无法解决的业务问题，进而提出的诉求。

　　需求评审可以区分为两个维度，一个是评审需求的问题域，即该需求要解决的问题是否真实存在;另一个是评审需求的解决方案域，即解决问题的方案是否合理合适。

　　02为什么要做需求评审?

　　需求是连接用户和产品的重要桥梁，是业务价值的载体，持续的需求提出与交付是产品生命力的一种表现。通过评审需求的问题域，识别需求的产生原因与业务价值，确保做正确的事;通过评审需求的解决方案域，确保各方是正确地做事。

　　03需求评审怎么做?

　　需求的问题域评审

　　提问题比解决问题更重要，提问题相当于指出方向。问题的存在比问题的内容和形式更本质。相比较于提出问题，人们更擅长于给出答案。我们发现，很多需求的描述是“我要XXXX”，需求提出人往往给出的是答案，而不是问题。在评审需求的问题域时，需要警惕，避免陷入答案的讨论，只有发现核心问题、找出问题本质，才能判断答案是否正确。

　　有些公司会有专门的需求审批流程，例如业务人员提出需求、部门经理审核，通过后传递到研发团队，研发团队进行系统实现。这种场景下，需求问题域的评审是放在了业务部门、研发团队只是落地执行，本文所描述的需求问题域评审，指的是利益相关方和研发团队共同评审。

　　需求的问题域评审，常见的组织者是产品经理或需求分析师，参与人有需求提出人、利益相关方，通常以会议形式进行。为了提高需求评审的效率与质量，以下方式建议：

　　会前准备

　　用户的需求往往只是一句话，并且通常表达的是要什么而不是为什么。如果所有的需求澄清都在会议中进行，那么势必会导致会议的冗长和低效。因此，产品经理或需求分析师，需要在会议前进行一定的调研与分析，了解一句话需求背后的业务问题、核心诉求。常用的调研分析方法或工具，包括，5W1H、流程图、用户旅程地图、事件风暴等等。而这些方法的核心都是，从用户角度出发、围绕业务场景，只谈业务、不谈解决方案。

　　识别相关方：只有找对了人，才能事半功倍。基于需求调研，可以判断和邀请合适的利益相关方参与到评审会议中。

　　识别关键问题：基于调研信息，识别出已知的共识、影响决策与判断的关键问题。

　　提前通知与明确目标：可以整理一些文档或资料，让相关方在会前了解背景、要讨论的问题及要达成的目标。

　　会议中

　　明确会议目标：需求评审的目标是判断需求的合理性、排定需求优先级，聚焦的是需求问题域，各利益相关方在该会议上，探讨该需求所呈现的问题是否存在、是否是伪需求、对业务的影响和紧急度是怎么样的。而对于需求解决方案域，在这个会议中，聚焦的是问题解决后能带来什么，例如是工作效率的提升、业务操作错误率的降低，避免陷入解决方案的细节讨论中。

　　控制会议节奏：会议组织者可以通过约定会议时长、引导参会人员聚焦目标、及时对不相关问题讨论喊停等方式，把控会议节奏，始终围绕目标和具体问题进行讨论。

　　做好会议记录：对会议中的共识结论、待定问题，做好记录。

　　会议后

　　跟进待定问题，及时清理待定问题，避免问题遗留时间过长而不了了之。

　　需求的解决域评审

　　在充分理解和认识了需求后，提供的解决方案是否能高效合理地解决问题，最终交付的产品是否能实现业务价值，是需求解决域评审要回答的问题。

　　评审需求解决方案时通常要面向两类对象，目的和侧重点有所差异，具体如下：

　　需求的解决方案通常以PRD、产品原型为载体，为了提高评审效率，有以下几点参考：

　　会议前

　　可以根据评审侧重点发出对应资料，相关人员提前阅读和查看，并标记出重难点问题;同时，需求评审并不是一次会议就一蹴而就的，对于需求的实现重难点，在设计过程中，应该是在小范围进行了讨论和初步共识的。通过需求评审，一方面是传递需求，另一方面也可以借助不同角色的专业背景和知识，对需求设计本身进行查漏补缺。

　　会议中

　　控制会议节奏，尽量依据事实进行问题讨论，避免假设性的发散和主观判断的纠缠;对结论性的内容以及待定问题，进行归纳总结。

　　会议后

　　对待定问题，进行跟踪与反馈，根据实际情况，可以组织需求的二次评审。

　　为了确保需求从问题理解、方案设计、系统实现是一致的，避免理解偏差带来的返工浪费，除了上述两类需求评审之外，还建议在有条件的情况下进行需求串讲，即开发人员借助技术设计讲解其对需求的理解和设计、测试人员借助测试用例讲解其对需求的理解和测试，相信，经过这样的多轮需求对齐后，呈现给用户的产品一定是可用的。

　　04常用的工具介绍

　　需求管理是研发过程中的一个持续且重要的工作，合理使用工具能够提高研发管理效率。

　　猪齿鱼研发管理工具，提供了统一的需求收集渠道，连接用户与研发团队。同时，可以根据公司的管理规范，自定义需求提报后的审批流程，以方便各方及时获取和审核需求信息。需求池让需求回归业务本质、回归问题根本，解决了需求问题域的问题。

　　需求评审通过后，一方面可以快速转换为史诗、故事甚至是缺陷，以设计产品蓝图、规划产品路线，另一方面也可以快速转换为研发团队的工作任务，例如设计任务，以落地产品蓝图的执行。同时，支持以需求视角跟踪和查看从提出、审批、设计、执行、发布的全流程。完整管理需求的解决域，让提问人和答题人信息对称、进度可视、协作顺畅。

　　同时，借助需求的评论功能，可以建立需求提出人与研发团队的沟通渠道，对需求澄清过程中的重要信息实现线上记录。

　　需求是研发管理工作中的第一步，在了解了需求评审的问题域和解决域之后，怎样才能合理规划需求排期和研发节奏、为需求的落地保驾护航，我们将在下一期与您共同探讨，敬请期待!

　　资料来源于网络，详情请点击：软件研发管理系统（https://www.zknow.com/choerodon.html）