关于需求评审的一些实践方法和思考

2018-01-08 08:53:00

开需求评审是产品经理的工作内容之一，那么如何做好这项工作呢？梳理自己在工作中的实践和感悟，希望能找到更适合的最佳实践方法。

需求评审的作用

向他人传达自己设计理念
如何在会议上讲解清楚自己的设计思路并得到大家认可，是需求评审前应准备和考虑的问题。
发现自己设计的不足，查漏补缺
一个人的思维毕竟是有限的，通过评审，让不同角色的人员站在不同的角度审视方案，是很好地补充自己思维不足和发现方案缺陷的方式。所以，没有评审，没有交流，没有讨论，是一件多么可怕的事情。
推动研发工作的重要节点
每次的需求评审都意味着产品研发进度又前进了一步，说明各项工作在慢慢不断完善和向前推进。
凝结团队成员的力量
通过开会交流、讨论，团队成员对自己的工作有更清晰的认知和责任感，也是无形中团结大家向同一目标努力的一股力量。
需求评审的流程
1、版本范围评审会
当一个版本开启时，需要先界定此次迭代的范围。产品经理先根据需求优先级，确定一些需要做的需求点，并对这些需求点的业务逻辑和功能设置可进行清晰地阐述。迭代需求点确认后，召集需求方（如tob系统的业务部门、运营部门等）、后端、前端、UI等干系人参加评审会议。此次会议更像是一个版本启动会（类似项目启动会），目的在于：

正式告知需求方，接下来我们打算做这些功能，若他们有更紧急的需求，可及时提出，保证每次迭代都在做最紧急重要的需求（当然，不同的部门会从自身角度出发提出要求，此时，需要产品经理进行综合考量）
使团队每个人对接下来将要做的事情有一个初步的概念和认知，使团队就此事达成共识；
使每个人对自己接下来的工作做到心里有数，接下来有这些活等着我；
技术人员（尤其是后端）评估功能实现的技术难点及可行性，避免原型、交互等前期工作做完后，交到技术人员手上才知道有技术瓶颈造成前期工作和资源的浪费。

此次评审需特别注意：需求点讲解的粒度不应过细，产品经理只要讲清楚，接下来我们将要做XXX这几条需求，每个需求大概实现的是一个什么功能即可，避免陷在业务细节中，偏离会议的主旨。

产品经理根据确定后的需求列表，初步完成设计原型方案后，召集业务或需求方（若无需求方，应在产品组内部进行评审）对功能设计进行评审确认。此次评审相当于方案确认会，目的在于：

此次评审，讲解的重点在于，每个需求点是如何转换为页面上的功能结构的？这样的功能结构是如何满足需求的？为什么是这样的结构，设计的思路是什么？有人说，产品经理最难的是，说服别人肯定自己的设计，此次会议要达到的就是这个目的。

方案经过评审后，完善修改问题，无误后，即可开启UI设计。此时，召集UI人员讲解和沟通需求。此次评审会的目的在于，让UI理解每个页面，为什么这个页面上有这些功能点？这些功能点之间的联系是什么？在讲解的过程中，应着重于页面交互和功能说明，避免过多的业务细节困扰UI。

待UI出具了交互和设计规范后，需想前端宣讲细节。此次会议主要由UI负责人讲解，产品经理辅助解释。以前端人员理解规范、交互和功能设计初衷为目的。当然在开会前，产品经理应该对交互设计稿先进行审核，发现与需求不满足的地方，并进行讨论修改。

业务细节规则、功能设计符合需要，需求方通过评审后，可交由后端技术设计数据表等准备工作。此时召集所有技术人员，一个个功能点进行详细的业务逻辑介绍，旨在帮助研发人员理解业务细节，帮助他们更好地进行架构规划和代码编写。

大致可以总结成下图，当然各项评审之间没有固定的前后顺序，不同职能间若不是强关联，往往是并期进行的：

（在新标签页中打开，即可查看大图）

除了细节功能的讲解，宏观大框架的交代也必不可少：

交代产品定位和目标：不要一开会就马上进入细节功能，balaba讲一通，别人还没反应过来，你给讲完了。应该先交代你要做的是个什么产品？PC端、移动端？APP、H5？为什们打算做这个产品？若是后期迭代，此处交代此次迭代的目标即可。
交代产品的面向用户：产品是做给谁用的呀？产品给这些人提供什么样的功能呀？此次迭代的功能主要是面向哪一些用户的呀？
交代产品的功能架构：这么多功能，他们之间的层级关系是什么样的？是用什么样的线索和结构组织起来的？
交代功能设计的思路：一个产品肯定有一套统一的设计思路，比如统一的信息展示、统一的页面流转路劲。

总结一下，大概下面这些内容是都应该讲解的：

诚然，不同的项目、产品、团队，实际的操作方式不同，但想要达到的效果一致，关键在于找到一个清晰的标准又灵活的适合自己的操作方式。

作者 @小麻雀。