如何避免“坑”的发生？
两个方面，第一个是产品规则里需要有哪些要素，第二个是自检文档里有没有纰漏；
规则
首先产品规则里需要有：
约束性描述-即这个东西只能怎么样，功能规则-这个功能该执行什么逻辑（这两个东西基本上都会有）
以下可能只会有些特定的需求才会有：
数据来源，显示的东西调用的是哪张表或者是哪个接口；
储存方式，缓存在本地还是保存到服务器上；
异常情况，如果发现异常或者错误，这个逻辑该怎么走；
极值，如果出现了XXXXXX条记录该如何处理；
操作提示，用户不知道这个功能是啥，改怎么提示用户，用户做了什么操作，该告诉用户什么；
防呆规则，这里的输入框是不是只能输入数字或者输入多少个数字；
显示内容及其格式，某块地方显示的是图片还是视频还是文字或者支持的是什么格式；
前后台逻辑关系，前端操作会对后台产生什么影响，后台的设置会让前端显示什么；
前置条件和后置条件，发生这个用例的前提条件，或者满足什么条件才能触发这个用例，发生这个用例之后的结果，会产生什么影响等。
一定要完整，明确并且清晰
自检
产品角度
从产品角度，需要注意以下要素：
流程是否形成有效的闭环（什么叫闭环，就是功能走着走着不能走不通了）；
文案是否易懂，是否存在歧义（提示或者描述是否表达清晰，无文法错误，slogan是否有情怀，吸引人）；
版本兼容问题（如固件/第三方插件/第三方接口/APP各版本之间是否有冲突，功能之间或者交互之间是否做好了兼容）；
与其他系统(后台系统/服务器)的调用是否能相互兼容跑通（这里会牵涉多方平台的处理方案）；
新功能是否存在其他关联功能点冲突（做一个新功能的时候一定要考虑到和其他有关联功能的相互影响）；
业务高峰的系统降级处理逻辑（如果你做的是重度业务APP，一定要考虑很多用户同时涌入的风险以及处理方案，比如某米的商品抢购）；
后续新功能或关联产品如果下线的影响点（当你要下架某个功能的时候，要考虑到下架以后的风险和对其他功能会产生什么影响，要写功能下架预案）；
运营角度
从运营角度，需要注意以下要素：
是否存在数据报表、埋点需求；
是否存在客服查询需求；新功能的客户宣传策略；
是否存在运营需求；数据指标和预期验证；
运营需求和产品功能是否相互影响；
风险评估角度
从风险评估角度，需要注意以下要素：
是否会因为功能设计而导致平台审核不通过（特别是苹果）；
是否引发诸如骚扰、欺诈等安全隐患；
是否存在用户资料泄露，财产，数据泄露安全隐患；
是否存在负面舆情风险；
是否存在法律及合规风险；
发布审核风险；版本撤回及异常评估（回滚策略）；
若有收获，就点个赞吧
0 人点赞
