【产品工作流】需求评审篇
一、 先明确需求评审的目的
需求评审，是每个产品经理都必须经历的一个工作环节。在评审会议上，前端、后端、测试、UI、业务方、领导等不同角色都有可能会参与，每个角色对于需求的关注着重点都不同，如何高效完成需求评审，让大家都能理解你做的方案，是一个产品经理的基本素养，和赢得团队信任的基础。
（1）评估需求的价值：在会上传达准备要做的事情，这件事做成后对公司而言有哪些价值，值不值得做
（2）评估需求方案：业务方和开发设计人员，从不同的视角审视方案是否符合需求，查漏补缺，及早发现问题并完善。当然，在正式的需求评审之前，我一般会先与核心人员过一下需求方案，小范围内评审，先消灭大问题。
（3）初步评估技术可行性：需求在技术层面是否能实现，需要投入多少人力资源，方案上是否存在技术实现层面更经济的替代方案
（4）明确需求开发的事项：让所有人明确需求背景和目的，让参与研发人员知道工作的内容，评估产品的开发周期和交付时间
二、需求评审流程
2.1 首先是界定需求性质，需求本身可以大致分为：功能优化、功能拓展、新项目。
（1）功能优化定义：产品的功能模块已经能满足需求或者达到使用者的目的，但是当前方式并不友好，需要优化。重点在于讲清楚如何做
（2）功能拓展定义：产品的功能模块还不能满足需求或者达到使用者的目的，需要在原来的框架下新增子模块，重点在于讲清楚是什么，与原有功能的联系是什么
（3）新项目/新业务：要发展新业务，相对比较独立的模块或者新产品，重点在于讲清楚为什么要立这个项目，项目包括哪些模块，模块之间的联系是什么，每个模块间的功能及实现。
2.2 先介绍需求背景：上来就讲功能点绝对是莫名其妙的，可能讲完了在场各位连你到底要做什么都还不知道。对于不同性质的需求，背景描述也会有不同：
（1）功能优化类需求：当前需要优化的功能简要介绍，什么场景下，什么角色怎么使用这个功能，什么原因导致了使用过程中遇到了什么问题。
（2）功能拓展类需求：需要新增的模块是什么，与原有的功能的联系是什么，什么场景下，什么角色会使用到这个功能，预期的结果是什么
（3）新项目/业务类需求：将要做的业务是什么，需要哪些角色参与，为什么要做，市场经济效益如何
2.3 描述业务流程：此时千言万语都不如一张泳道图来的清晰。明确涉及的角色，梳理关键业务节点，目的是让大家都了解业务逻辑，以便去判断方案是否存在大方向的偏差。
2.4 描述需求目标：根据背景和业务流去明确此次的边界，要解决哪些问题，谁通过什么方式来解决
2.5 描述方案概述/功能架构：要达到这个目标，我需要做哪些功能点来支持，列举功能架构脑图，先大模块再延伸小功能点。
2.6 描述子流程图/功能逻辑图/页面流程：采用逻辑+模块的表达方式，业务流程上每个关键节点便是一个产品模块，先讲清楚每个链上的产品模块，再讲模块的功能。上帝视角与用户视角结合，既要说明逻辑、模块、功能等概念，也会从一个具体配置人员的角度讲一讲他们该如何使用这个系统。
2.7 细节需求描述：面向前端用户的交互细节，面向系统前后端之间的交互逻辑都要统一口径，让开发人员和测试人员知悉。
2.8 描述需求考核指标：此次需求设计的效果验证，最好能提供一些可量化的数据指标，即完成这个需求后能带来哪些数据的变动。
三、评审过程注意事项
3.1 不同需求，评审流程有差异。需求有复杂的也有简单一句话可以概括的，最终目的都是让大家都了解清晰，所以可根据实际情况以高效为前提描述需求。
3.2 描述需求要逻辑清晰。充足的准备能让你在会上从容不迫，有个大概的提纲第一点讲什么、第二点讲什么。
3.3 以故事形式讲述业务逻辑。比如某个用户在什么场景下有什么通点，我们这个功能可以以什么方式去解决这个问题。这样讲述功能，让功能点变得有趣。
3.4 切记无须太抓细节。例如按钮的位置摆放不合适，文案有歧义等，这些都是可以会后去完善，抓大放小，主要考虑大的问题。
3.5 会上要做记录。需求评审会上面对的是各种不同的角色，每种角色的关注点都不同，你也不可能在设计时就面面俱到，所以把问题点记录下来是很必要的。要记录的有：（1）会上有争论，但当时未解决的问题。（2）会上已解决需要完善需求文档的问题。（3）在评审过程中自己发现的问题。
四、评审会结束
4.1 同步会议记录。将会上待解决的问题列出来，与大家确认无遗漏。
4.2 整理问题，出解决方案。评审会很少有一次过的，对于第一评审后的问题要整理并出新的解决方案，小的问题发出确认即可，大的问题还要约第二次评审。
4.3 重新整理需求文档。对于要解决的问题需要在对应的文档进行更新，并通知相关人员。
4.4 版本排期。最后一次评审会确定就要排期，这个可以跟相关部门的负责人沟通，比如技术经理，需要多久时间什么时候可以上线。