因此，需求评审完后，等到测试完成才验收是不够的，产品同学应该对整个产研过程进行过程管理，在各个节点进行阶段性验收，即需求管理。
01 需求输出（PRD）自查
1.1 功能逻辑
逻辑闭环，不遗漏判断；描述清楚，无歧义。
（1）PRD是否有按照需求文档规范编写？
一般公司内部都会有需求文档规范，这个PRD规范就是一个非常基本的需求思考框架和信息传递框架，而且是在公司内部经过磨合以及实操验证的。
按规范来写，至少需求的框架是成型的，在信息传输上需要达成共识的模块也会考虑进去了。（如果小团队没有需求文档规范，可以自己总结一份。）
（2）是否有异常状态的处理?
正向过程是相对容易考虑全面，因此功能逻辑自查的重点是逆向过程，异常状态。可以从以下几方面着手：
1）业务异常
· 逆向流程：如订单取消，退货退款，优惠券退回
· 不可用：如账号未注册，账号被冻结，校验未通过
· 超时效：如优惠券过期
· 无权限：常见2B产品，不同角色权限不同
2）数据异常
· 输入异常：不符合输入要求；输入错误
· 返回异常：无搜索结果
· 显示异常：空数据；加载异常；排序异常
3）网络异常
4）服务器异常
（3）与产品其他模块是否有关联影响？
· 如涉及功能消息通知：短信/push/Email
· 如需求涉及到的管理后台系统改造
1.2 交互体验：交互稿验收/自查
记住，用户是很懒很懒很懒的。懒得想，懒得动，懒得等！
用户能很轻松知道当前自己在哪，从哪来，可以去哪，如何能完成目标。
“三次点击法则：如果用户在3次单击中未找到他们想要的信息或了解到该网站的功能，他们将离开。该法则强调了清晰导航，逻辑结构和易于理解的网站层次结构的重要性。”
尽量少让用户选择，已知用户要做的选择，提前帮他选好。但同时用户可以随时中止或退出。
业内通用模块的交互设计，已经培育了一代用户的操作习惯。如果没特殊情况，新设计也没有质的飞跃，比如从文字交互到语音交这种变化，那就别标新立异，否则反而增加了用户使用门槛。
尤其是异常提示，错误提示，是否及时反馈给用户，并告知下一步需要做哪些事情来结束当前的异常状态。
等待时间越短，用户体验就越好。能否通过业务流程优化或者性能优化减少用户的等待时间，不能的话，那就需要考虑是否需要通过其他方式分散用户注意力，拒绝产生“度秒如年”的感受。
涉及到不同语言版本的，提前准备好翻译。同样的表述，不同语言的文字长度是有差别的，提前准备好，方便交互，设计根据文字长度进行设计。
产品的核心工作是平衡需求和资源，做最优决策。所以，开发资源不足的时候，非核心流程的交互，就不要死磕了。
1.3 视觉效果：UI稿
产品/业务上需要强调的内容，视觉上是否足够强调
全局组件，通用组件尽量统一，一是风格统一好看，二是开发起来复用性好。
交给专业的设计同学
一文字描述 二口头沟通 三模拟效果展示
同样，开发资源不足的时候，非核心流程的视觉效果，劝一劝设计同学~
1.4 数据逻辑
（1）数据存储，数据处理
这主要考量的就是数据表结构的设计。
什么是数据表？什么是数据表结构？
“数据表是由表名、表中的字段和表的记录三个部分组成的。设计数据表结构就是定义数据表文件名，确定数据表包含哪些字段，各字段的字段名、字段类型、及宽度，并将这些数据输入到计算机当中。”
产品为什么要关注数据表结构？
需求的确不一定都需要关注表结构才能完成，是可以完全交给开发设计。但是底层的数据逻辑思维，对于产品来说是很关键的。
互联网产品本质结构都是数据，业务逻辑是否清晰就看数据逻辑是否清晰。数据从哪来，去哪，如何变化，都是在表里发生的。不过是多复杂的产品，实质就是一堆数据在表里的流转。数据逻辑清晰了，业务逻辑也就清晰了。
从项目的完整生命周期来看，数据表结构是地基，决定了拓展性。上线后，前端UI展示等要优化的话是很好改的，但如果涉及要改底层的数据表结构，那就是一个庞大的工程。
所以，数据表结构，产品可以不参与设计，但是一定要和开发同学保持充分的沟通。因为，开发一般是基于当前的需求进行技术设计，这样的情况下，架构很可能有局限性，无法适应日后的业务拓展。而上线后的重构是很痛苦的，成本也很高。因此，产品的介入，能帮助开发在架构设计时有更好业务前瞻性，也有助于产品自己对技术架构设计的了解。
产品要关注哪些点？
主要关注存储的字段，和表关系。
单张表：表中字段名称，字段所属对象，字段值类型，取值来源，最长长度，字段说明
多张表之间的关系：一对一，一对多，多对多。关系尽量简单。比如多对多的关系，可以增加一个第三方，改为两个一对一的关系。
（2）接口设计
一般而言，内部的接口无需额外关注，但平台类产品，接口对第三方开放的，则需要从业务角度，思考如何设计接口，从而对第三方调用会更友好，有更好的兼容性。
入参/返参：产品不需要定义API所有的字段，但涉及到业务需求的字段，需要明确出入参要求。
接口性能要求：产品需要对业务充分评估，给出TPS/QPS限制，保证业务顺畅运行的同时，也不浪费服务器资源。
（3）数据指标体系
明确业务目标，根据业务目标，用户路径确定数据指标：
· 注意数据的准确性，可获取性，时效性，统计口径是否一致
· 建立报表并搭建相应的监控告警体系
（4）埋点
埋点定义：基于业务需求，为日后进行数据分析，提前在应用中特定流程植入代码采集数据，从而达到追踪用户行为，辅助决策的目的。
触发事件分类：
曝光：每被用户看到一次，就是一个曝光事件。比如商品的曝光。
点击：用户每进行一次点击，就是一个点击事件。比如按钮的点击。
举例：
（不同公司，埋点规范不同，按公司要求来就好）
1.5 拓展性
需求功能点是否考虑做成可配置。
需求功能点是否可做成通用模块，提高复用性。
1.6 监控报警
是否需要对关键数据指标进行监控，并设置报警阈值。
1.7 部门协同
需要协同的部门，是否都确认和周知？
非常重要，不要闭门造车，然后辛辛苦苦开发完，结果安全/风控/合规部门一句say no，上不了线…
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
