产品需求文档自查表
共 4755字，需浏览 10分钟
·
2022-03-17 20:07
距离上次发文似乎已经是4个月前了，距离上次发产品经理的文似乎已经是十几个月前了吧，这期间发过HTTP协议讲解、物联网平台讲解、视频流讲解、带宽讲解、自动驾驶讲解...这些几乎都伴随着我的职业生涯的方向调整而变化，于是随着环境一路暴力前行，从产品、运营、项目、方案、供应链...（可以看得出来一路的波折了）...
但是人嘛，也要时常停下来好好反思，究竟什么是产品经理，什么是本心，经过一番思索，我还是决定彻头彻尾来一次空杯，从最基本的产品需求文档开始，一来为了整理一下过去的经验，二来为了重新思考一下产品经理是什么，逐步寻找一下最初的梦想和信仰。
1.目的
本文的目的，就在上边，写太多太矫情，写太少不深刻，总之就是一个字，空杯心态，从基础开始回归。
2.PRD自查表
大家都知道，产品经理是最细的男人，什么意思呢，就是说，产品经理的工作其实某种程度而言，需要极致的细致，才能打磨出极致的产品，就像乔布斯老爷子一样。
PM千万工作中，其中有一样最能体现细致，那就是PRD。随着工作的推进，你可能已经很久习惯了一句话需求，习惯了口口相传，随着工作内容和工作经验的提升，这固然是必然，但知道如何细而不做，和已经忘了什么是细，终归还是两码事。到这里，有的小朋友要说了，一个原型有啥可细致的，那么提问，我们经常用的淘宝，点击搜索，这里发生了什么交互？我们仔细想想，淘宝搜索框：
有默认推荐的商品：那推荐的规则是什么。
点击后：会跳转一个新的页面，为什么要跳转新的页面。
跳转之后：你的焦点还停留在搜索框，这时候默认推荐的商品消失了吗？
如果这时候输入了内容会怎么样，直接点击搜索会怎么样，点击返回之后页面跳转到哪里，跳转之后推荐的商品变了吗？他是怎么变的...
这么多细节，岂能是简单一句搜索讲清楚的，那么接下来，我们就，我们就不讲淘宝搜索，我们讲讲PRD自查表，从需求审查表的角度一起来梳理一下，做一个设计，写一份PRD需要从哪些角度来评判一份文档的“细”度，同样面对一份设计，可以从自查表的角度来确认自己的设计是否为完整细致的。
我们先来从整体角度明确一下PRD的内容：
| 阶段 | 目的 | Checklist |
| 需求分析 | 判断需求真伪 | 是否符合当前核心业务场景，是否符合用户画像和用户故事 |
| 是否存在类似竞品，是否完成竞品分析 | ||
| 当前方案是否是同类场景下共性需求 | ||
| 量化收益 | 对核心用户的影响程度，尽可能量化 | |
| 对核心业务的贡献程度，尽可能量化 | ||
| 整体开发难度，结合收益分析是否值得 | ||
| 整体维护难度，结合收益分析是否值得 | ||
| 判断可行性 | 当前技术是否可以支持 | |
| 当前业务是否可以支持 | ||
| 功能风险评估 | 存量功能变更：是否存在关联功能的改造点 | |
| 功能影响：是否完整梳理当前规划内容上线后的影响点 | ||
| 高并发处理措施：是否已经预估业务高并发时的处理措施 | ||
| 验证方法：是否已经计划好功能上线后的验证方法 | ||
| 外部风险评估 | 是否引发诸如骚扰、欺诈等安全隐患 | |
| 是否存在负面舆情 | ||
| 是否存在法律法规风险 | ||
| 优先级 | 用户覆盖度 | |
| 使用频率 | ||
| 核心场景影响 | ||
| 对核心用户的影响 | ||
| 对核心场景的影响 | ||
| 实际收益的高低 | ||
| 实现难度的高低 | ||
| 信息架构设计 | 信息架构设计 | 是否结合了用户画像、用户习惯、业务场景等因素 |
| 架构层次是否清晰，是否足够扁平，是否容易理解 | ||
| 所有信息均需要进行重要性评级 | ||
| 整个结构是否高内聚、低耦合 | ||
| 架构可拓展性是否足够强，对信息模块进行调整时是否容易实施 | ||
| 流程设计 | 产品流程设计 | 主干流程是否最简化，是否覆盖了足够多的场景 |
| 是否有特殊流程（例如逆向流程、分支流程等） | ||
| 是否有异常流程 | ||
| 操作节点、交互点 | 是否归纳了所有的操作节点、数据交互点 | |
| 操作点是否足够精简易理解 | ||
| 是否考虑了操作节点的容错性 | ||
| 数据交互点是否依赖其他系统 | ||
| 特殊、异常流程是否需要增加切换流程的引导 | ||
| 相关流程的用户体验路径是否一致 | ||
| 美观规范 | 图形形状、字号是否统一 | |
| 流程图均以开始框开始，以结束框结束，无虎头蛇尾 | ||
| 流程图遵从从左到右，从上到下排列 | ||
| 流程线无交叉 | ||
| 流程结束后是否进行了场景验证，是否符合用户预期 | ||
| 需求文档设计 | 业务流程 | 完整流程是否形成闭环 |
| 逆向功能 | 功能流程是否可逆，如果可逆，是否考虑对应的机制 | |
| 异常机制 | 各个步骤可能出现预期外的情况 | |
| 歧异文案 | 文档的语法、功能文案、名词等是否容易理解，是否存在争议 | |
| 兼容 | 不同干系人是否都能接受，各个系统之间是否兼容，新老业务或功能是否兼容 | |
| 备用 | 是否有备用方案，备用选项 | |
| 穷尽 | 业务场景和可能的原因是否已经穷举完毕 | |
| 脱敏 | 是否存在敏感信息，是否需要脱敏 | |
| 精确 | 文案描述要精确，不得出现可能、也许、大概之类的词语 | |
| 精练 | 需求文档要精练，非必要内容不用体现在文档内，避免给读者带来困扰 | |
| 版本发布自查 | / | 确认完需求后，是否已经告知相关干系人，是否已通知何时可以交付版本 |
| 是否已经落实应用商店图、欢迎页、新功能引导页等 | ||
| 确认埋点是否已经全部清除 | ||
| 确认新功能的数据统计功能是否明确 | ||
| 类型 | 子类型 | 内容 |
| 账号状态及用户权限自查 | 基本状态 | 不同账号状态说明：登录状态、非登录状态不同情况是否说明完整 |
| 不同用户等级和权限说明是否完整，例如非会员、会员、不同等级会员 | ||
| 不同账号状态切换是否有特殊提示 | ||
| 多账号切换时，本地缓存是否需要清空 | ||
| 老用户登录是否考虑数据同步 | ||
| 特殊和异常状态 | 是否允许多端登录同一账号，如果允许，如何应对操作同一数据时产生的冲突 | |
| 是否考虑多账号切换问题 | ||
| 是否支持第三方账号登录 | ||
| 网络状况 | 网络状况 | WIFI网络、移动网络 |
| 集团局域网、公共网络 | ||
| 连接超时，多久算为超时 | ||
| 是否给用户引导网络检查或重试的按钮 | ||
| 网络变化时候是否提醒，例如wifi变5g时 | ||
| 服务器问题 | 服务器问题 | 服务器问题返回数据失败时，是否给予用户提示或重试按钮 |
| 硬件权限 | 硬件权限 | 定位提示是否打开定位 |
| 相机提示是否打开相机 | ||
| 闪光灯是否提示调用闪光灯 | ||
| 蓝牙提示是否打卡蓝牙 | ||
| 设备数据是否需要调用，例如步数、心率等。 | ||
| 设备 | 横竖屏 | 是否支持横竖屏操作，是否需要锁定屏幕 |
| 分辨率 | 分辨率不同是否需要适配，如何适配 | |
| 系统性能 | 操作过程是否卡顿 | |
| 系统版本 | 系统版本不同是否支持 | |
| 存储 | 有SD卡或无SD卡、存储空间已满、存储位置等 | |
| 硬件按键 | 硬件不同造成物理按键不同衍生的操作 | |
| 特殊场景 | 无图模式 | 网络加载慢的情况下是否需要无图显示效果 |
| 夜间模式 | 是否需要考虑夜间模式下的展示效果 | |
| 编辑模式 | 是否需要无图模式、是否需要无痕模式模式 | |
| 意外中断 | 编辑模式下出现意外情况是否需要保存信息 | |
| 屏幕亮度 | 是否需要特殊情况下调高或调低屏幕亮度 | |
| 全局 | 页面 | 修改页面时，考虑在系统中其余地方是否有相同的业务，是否需要统一修改 |
| 控件 | 全局控件央视是否具有一致性 | |
| 交互 | 全局控件交互行为是否具有一致性 | |
| 操作反馈 | 是否周全考虑了所有操作成功的反馈 | |
| 是否周全考虑了所有操作失败的反馈 | ||
| 触发提示类型 | 控件触发的提示类型是否恰当 | |
| 按钮 | 按钮是些死还是服务端配置 | |
| 是否有默认的按钮文案 | ||
| 按钮文字超过按钮大小如何处理 | ||
| 按钮样式是否有特殊要求，例如带icon和不带icon的情况 | ||
| 考虑按钮点击之后的效果 | ||
| 点击按钮后出现的情况是否与页面其他元素有冲突，例如弹窗等。 | ||
| 内容型文案 | / | 内容是静态或静态 |
| 内容是否完整、顶部标题、按钮、输入提示、悬浮提示等 | ||
| 内容还在方式描述是否完整，如本地缓存或网络加载情况等 | ||
| 内容违禁如何处理 | ||
| 内容是否考虑换行，超度过长怎么处理 | ||
| 内容是否需要考虑单词换行（有时候一个单词会出现不换行的情况） | ||
| 内容长度如何限制 | ||
| 描述型文案 | / | 必填或非必填 |
| 若为非必填，界面样式如何 | ||
| 定义文案的行数或字数 | ||
| 文案的截断策略是否考虑，超行字数或行数如何展示或处理 | ||
| 出现同一场景时，提示文案是否保持一致 | ||
| 文案由服务端控制还是客户端控制 | ||
| 是否有默认文案 | ||
| 是否易理解、是否有错别字、是否有歧义 | ||
| 输入型文字 | / | 输入文字是否有默认值，是否有输入提示 |
| 输入框内容为空时如何显示 | ||
| 输入框获得焦点时，默认文字消失还是保留 | ||
| 输入框获得焦点时，默认弹出键盘的样式 | ||
| 输入焦点丢失和存在时是否有展示内容的差异 | ||
| 输入文字是否存在极限长度或最低长度 | ||
| 输入文字是否可存在特殊字符。若用户输入如何处理 | ||
| 输入文字是否存在对敏感词、违禁词的禁用或过滤 | ||
| 输入文字后是否需要一键清空操作 | ||
| 输入文字后是否显示辅助结果，如果需要，提供辅助词的搜索规则 | ||
| 输入文字后遇到流程打断的情况是否保留输入记录 | ||
| 是否说明了键盘唤醒后需要页面的滚动来避免输入框的遮挡。（移动端常见） | ||
| 输入型图片 | 上传前限制 | 是否强制要求上传图片的必须参数，例如尺寸、格式、大小等 |
| 是否设置了不符合尺寸的提示，图片过大或过小，格式错误等 | ||
| 上传后反馈 | 是否提供上传完成图片的预览 | |
| 是否提供了再次编辑操作，引导是否明显 | ||
| 上传失败的情况是否给予用户提示，引导再次上传 | ||
| 上传完成后遇到流程打断的情况是否保留已上传的记录（断网、退出、关闭浏览器等） | ||
| 页面跳转 | / | 页面跳转流程是否完整流畅，流程中间是否有页面缺失 |
| 页面跳转是否有提示和引导说明 | ||
| 页面跳转加载的loading展示是否友好 | ||
| 页面跳转动作是否有跳转特效 | ||
| 页面跳转的方式是什么，滑动等 | ||
| 页面加载不出来时展示什么内容 | ||
| 页面点击过程中是否包含权限限制，如果有如何提示 | ||
| 页面跳转尽量要减少跳转次数，缩短用户操作流程，尽可能在一个页面内完成 | ||
| 一个页面内是否有功能冗余的内容 | ||
| 页面跳转时是否需要进行辅助性说明 | ||
| 列表 | 排序 | 列表排序方式，时间正序或倒序或其他 |
| 元素定义 | 列表中的元素是否都定义清楚 | |
| 数据来源 | 列表中设计的数据来源定义 | |
| 空状态 | 列表数据为空时的展现形式 | |
| 后台配置 | 若部分元素为后台配置，则配置前后的情况定义 | |
| 加载方式 | 列表数据是否粉也展示还是一次性加载，单页加载数量是否有限制，下拉加载或其他 | |
| 数据 | 来源与加载 | 数据的来源，来源于具体后台的哪个地方 |
| 展示数据是否使用的是服务器数据，或使用的是本地缓存数据 | ||
| 展示数据是否是初次加载读取的静态数据，或实时，定时展示的动态数据 | ||
| 数据未加载出来前展示了什么 | ||
| 数据格式 | 是否规划数据为空时的展示效果 | |
| 数据的极值情况如何处理 | ||
| 数据长度是否有限制等 | ||
| 数据排序 | 若为多个数据，如何排序 | |
| 数据选取 | 是否选取全部数据或部分数据，数据根据什么搜索规则筛选出来 | |
| 其他 | 对过期的缓存数据是否需要告知用户刷新 | |
| 前置场景的不同是否对当前展示数据产生影响，不同场景是否需要展示不同数据 | ||
| 移动端从后台唤醒应用时，是否需要刷新当前页面数据 | ||
| 数据展示条件 | 数据在什么条件下进行展示 | |
| 数据是否分页展示 | ||
| 数据去重 | 数据去重策略 | |
| 数据请求 | 什么时候开始请求数据 | |
| 数据更新机制 | 什么情况下触发更新数据 | |
| 数据更新频次？是定时更新还是实时更新？ | ||
| 数据过滤 | 是否有部分数据需要过滤掉不展示？是否对特殊内容进行过滤、标记 | |
| 数据删除 | 数据被删除后，展示的状态如何 | |
| 数据缓存 | 过期的缓存数据如何处理，定时清理还是继续保存 | |
| 弹窗 | 触发条件 | 什么时候触发弹窗 |
| 关闭条件 | 什么时候弹窗消失 | |
| 元素定义 | 弹窗内的元素是否清楚 | |
| 次数 | 是否每次满足条件都出发弹窗还是只触发一次 | |
| 优先级 | 多个弹窗时弹窗触发的优先级 | |
| 轮播图 | 图片资源 | 图片数据为后台配置或客户端写死 |
| 图片排序 | 图片排序如何 | |
| 跳转 | 点击是否有跳转，跳转页面为内部链接或外部链接 | |
| 频次 | 轮播图轮播频次 | |
| 展示方式 | 轮播图切换时的展示形式 | |
| 异常 | 轮播图为空时如何展示 | |
| 等等 | ||