高手PRD自查：分支流程+元素备要+异常场景
问：
把大象放进冰箱需要几步？把长颈鹿放进冰箱需要几步？
答：
把大象放进冰箱共需要3步，把长颈鹿放进冰箱共需要4步。
把大象放进冰箱，第一步：打开冰箱门；第二步：把大象装进去；第三步：关好冰箱门。
把长颈鹿放进冰箱，第一步：打开冰箱门；第二步：把大象取出来；第三步：把长颈鹿装进去；第四步：关好冰箱门。
把这个顺序交给人去干，一般没问题。然而，把这个步骤直接描述给程序，一定出问题。
因为问题并没有想象的那么简单：
大象不肯进去怎么办？ 冰箱太小装不下怎么办？ 好不容易塞进去，冰箱门关不上怎么办……
于是交付给程序的实际流程图需要如下：
这就是在产品设计中常常会遇到的问题。
自信满满把PRD给到开发同学的时候，刚出去玩一会回头就发现满满的漏洞等着补。
只有手忙脚乱地，开始各种填坑……
这本质是马克思所说的事物矛盾的普遍性导致的。解决办法就是辩证看待，对立统一。
落地一点说，主要得兜住三个方面：分支流程穷尽+元素备要+异常情况穷尽。
下面正文，4.3千字，文末资料
本文目录：
1 分支流程
2 元素备要
3 异常情况
4 PRD自查
5 获取自查表（资料）
一、分支流程
当然我们做设计的时候，主要精力肯定是应该集中在主要任务和流程上，分支流程虽说是小概率事件，但是也要有所考虑，不然方案就会不完整。
解决这个问题，根本上是场景的穷尽。
需要注意：现实业务的场景枚举，与设计方案的枚举没有绝对对应性。也就是穷举场景可能是四个，但是实际上只需要三个方案就能覆盖。
但是场景枚举之间和分支方案之间存在MECE的属性。
案例：
OMS系统与亚马逊店铺对接的前提是：亚马逊店铺可用、对OMS系统已授权、OMS系统开启对接。
成功对接后，来自亚马逊的某些操作，会导致对接异常。此时通过接口返回错误提示，可以展示在OMS系统的店铺上，提醒商户处理。
那么这里有多少分支场景呢？
这个是第一性的，此后才能判断功能是否覆盖到上述场景。
针对场景到功能设计，本质是一种映射：y=f（X）
二、元素备要
如何一网打尽才是重要的。大多数是把每个流程都是按前、中、后进行要素的齐备。
1. 设计前
主要检查点：用户类型、帐号体系。
未登录：登录和未登录按钮权限差别，需要登录后才可操作的功能是否备注。
用户权限：需要读取权限吗？如何描述读取内容让用户读？不同权限管理。
2. 设计中
2.1 框架阶段
主要检查点：层级关系、信息区分、扩展性。
2.2 流程阶段
主要检查点：角色，入口，目的，操作，离开、中断。
「我是谁？从哪里来？要到哪里去？怎么去？还有谁？」。
要看流程有没有短路，如果过程中有中断，中断后要怎么提示，如果有不同的权限和角色，还得检查相互之间有没有相通和关联的地方，共同的关键节点。以及逆向操作。不同角色不同场景的任务流程一定要单独梳理。
2.2 内容显示
主要检查点：数据显示、缓存、内容、状态（特别是为空、初始）、显示（各种极限情况）。「为空、初始、极限情况」。
2.3 反馈通知
主要检查点：通知，提醒，界面反馈，用户反馈入口。
「操作的任何阶段（前、中、后被中断）都要防止用户发呆」。
2.4 文本控件
主要检查点：表意清晰、使用一致。「结合流程检查要符合操作的前后情景，符合用户的常规认知和习惯」。
三、异常情况
1、异常流程
退出、撤销、重置、返回、不通过、过期失效
返回：从哪里来是否可以回到那里去 保存：复杂任务流是否支持保存或自动保存；意外退出前保存提示 复杂状态之间的变化关系：子流程梳理辅助说明
2、刷新和加载
刷新：自动还是手动刷新？每次刷新加载多少条内容？刷新失败如何提示？ 无线刷新：顶部下拉、底部上拉，安卓有刷新按钮 加载：复杂页面是否有副列表加载？预览、保存、提交的完成时间若超过3S是否有加载的过渡状态？新加载内容是否有高亮底纹显示？
没有网络（无网）
网络超时（断网）
网络太慢（弱网）
网络环境变化：从WiFi到数据流量环境时是否需要切换视图
加载失败：是否自动重新加载？
4、操作异常
连续多次点击给予反馈、统一设备登录多个账号验证码、统一IP；连续破坏性操作n项内容时是否需要身份验证。 数据相关：进入页面后服务器获取不到数据；搜索无结果状态；数据加载时间较长时预设默认图片、状态、内容框架； 错误提示页：404页面、即将上线、页面失效、服务下线、系统繁忙，考虑出错页面内容情感化表达以减弱用户的受挫感。
需限定输入的范围，做输入校验。
示例：最多输入10个数值，输入不合规则的内容，则在输入框下方红色字体提示，比如：“请不要输人汉字！”。
（2）下拉框
下拉的同时是否支持输入搜索，是否支持多选。
（3）导入文档
表头校验、自校验、与系统校验、写入逻辑（全部不予导入或部分导入)、下载结果文档；
（4）已有功能的逻辑规则变更
则要考虑旧数据兼容或初始化。
（5）基础数据删除
则要考虑基础数据被调用的地方，删除和编辑怎么处理。
比如：
商品分类中维护的“商品类型”被删除，那么再编辑和删除该分类下的历史数据的时候就可能报错，所以基础数据维护时候要校验调用情况。
（6）设置规则
考虑规则去重、规则优先级。
一般情况下，没有优先级的话，规则的去重和命中次序校验起来比较麻烦。（在<后端产品经理宝典>一书中有专门介绍）。
（7）列表的数据的排序
一般按照修改时间的倒叙排列，也可以用数据库id代替序号。
用数据库id的好处是，方便用户和技术协作追溯数据。
（8）异常机制
每时每刻都要有逆向思维，告诉开发人员什么算异常？异常了怎么标示出来。
比如：
表1字段A，匹配表2字段B，将匹配成功的数据写入表3。就要考虑表1中字段A为空的情况该怎么办。
（9）页面长期不登录
则给自动退出。主要考虑到后端系统的保密性。
（10）凡是带操作的
一般都要设置页面权限。
最简单的方式是所有系统的权限都分三个等级：不能查看、只能查看、可以编辑。
（11）功能修订
比如规则变更，需要考虑旧数据是否要按照新规则进行初始化。
2、按需求类型自查
（1)功能需求
需要穷尽功能覆盖的使用场景，穷尽本功能相关联的各个系统模块，穷尽本功能的用户角色、权限。
（2)性能需求
数据量较大时的系统压力、反应速度；
批量上传、下载要考虑数量上限，考虑是否异步处理；
考虑浏览器兼容性；考虑调用接口超时的备用策略等。
（3）安全需求
敏感词屏蔽（同步过滤和异步召回）、防刷单机制、数据补推机制、风险预警等。
3、关键词提醒自查
笔者不完全罗列了几个关键词，可以作为自查的维度。
（1）完整
流程是否存在断头路。
比如当正常流程无法传输的时候，是否可以用导入的机制救急。业务高峰的系统，是否有降级处理逻辑。
默认：是否给予了默认值。
比如设置规则功能业务未设置怎么办？
4、其他
自查的方式还有很多，比如也可以按照“增、查、改、删、显、传、算”自查等。
-完-