我不是在教你诈，而是传授做事的套路。
互联网公司的项目通常迭代周期短，导致需求评审成为频度极高的日常任务。但是许多测试同学和开发同学在参加需求评审时，由于各种原因，譬如时间少或者业务过于复杂，在短暂的会议时间里很难吃透需求，更难以发现其中的问题，于是需求评审就流于形式，变成了产品经理的独角戏。项目需求听得稀里糊涂，后期难免返工，增加了项目风险。但其实许多项目都有通用特性，本文以H5项目为例，抽丝剥茧后，将一些通用性问题整理成套路，在评审的时候直接拿出来即可使用，方便快捷，甚至达到事半功倍的效果。
从大的方向上，可以分为两方面考量，一是需求合理性，二是功能合理性。
需求评审开始时，产品经理会先大体介绍本次需求的目的和价值。所以，为了论证需求的合理性，评审时第一个问题必须是：产品或需求的价值是什么？通过这个问题我们可以了解到产品设计的目的，比如解决什么问题以及用什么样的功能实现来解决问题。这个问题背后所隐含的是产品经理在设计产品时，是否做了详尽的功课，是否对行业充分调研、是否对竞品进行分析、是否对用户人群进行了分析、如何对产品进行定位、是否对关键数据进行了分析等等。
为了保障需求的合理，还需要对需求是否合规进行论证，是否会有触犯法律法规的风险？合规风险的种类很多，如果现场不能确定，有必要暂停会议并咨询公司的法务同事，得到肯定的答复之后再继续进行。合规的风险除了考虑遵守国家的法律法规，还要关心投放平台本身的各项要求，比如微信要求不能有诱导分享、过度营销等等。
假设需求的合理性论述通过，产品经理主持人会推进评审进度，进入交互原型评审阶段。产品经理打磨交互原型本质仍然是寻求最终的解决方案。这个阶段有两个核心点，一个是“流程图”，一个是“功能点”，所以需要紧密围绕这两个点论证，下文我会重点对这两个点进行展开。
对于“流程图”来说，主要包含了业务流转以及状态变化。业务流转的节点有开始有结束，业务流向有正向有逆向，逆向流程是系统最容易出问题的地方，所以需要特别关注，例如订单中止，订单暂停，订单退订，客服退款等异常情况时，流程设计的是否完善，流程能否闭环？有些资深的产品经理还会绘制时序图、用例图等帮助与会人员加强理解，此时需要关注的是，是否有环节缺失？与主流程是否一致？
“功能点”就是指核心功能，通过讨论核心功能的可行性，产品的大致形态就能够确定了。仍然以H5项目为例，下面对最常见的核心功能进行提炼：
1、投放渠道是否有限制？直接访问url是否有拦截？
2、二次转发是否有控制，是否会有多重奖励？
3、兼容性方面主要是手机适配。主流手机机型+保有手机机型，设计测试覆盖矩阵，一般不需要笛卡尔积覆盖。
4、产品需要考虑用户登录态，是否需要登录状态，即用户注册前后页面是否不同。需要是怎么样的，不需要又是怎么样的。
5、如何收集打点，在哪里打点？产品经理需要认真考虑打点问题。
6、产品需要给出H5页面在手机首屏加载时间的期望值。一般来说，从用户的体验上讲，性能基线设置为安卓为1.5秒内首屏加载，ios 1秒内首屏加载。
7、需要考虑前端代码的健壮性。如果接口下发数据异常，页面如何处理，会不会crash，或者提示是否友好。
8、涉及数据报表类的页面，产品必须考虑到翻页的问题。一个页面展示多少条数据，翻页效果，页面刷新等等。
以上是八个核心功能的问题，一共涉及到了安全、功能、性能、兼容、打点、易用性等方面，对于一般的产品需求做到了基本覆盖。
结束语：古人有云，兵无常势，水无常形，产品需求形态各异，具体情况还要具体分析。学习套路，掌握套路，就能够兵来将挡，水来土掩，立于不败之地。
源自公众号 三国测