4千字总结产品需求文档的形式、规范、自查

4千字，总结产品需求文档的形式、规范、自查编辑导读：产品需求说明文档（PRD）可以将产品设计思路清晰的展现给团队人员，便于他们快速理解产品。那么，产品需求说明文档该如何写呢？本文作者结合多年工作经历，分享了关于产品需求文档形式、规范、自查相关的非常有用的知识，供大家一同参考和学习。本文总结一个最基础的话题：PRD。目录：一、PRD的形式二、PRD的规范三、PRD的自查方法一、PRD的形式1.原型附带文字移动端产品当然是把产品DEMO展示出来为第一位。附带的文字，多是对原型的交互的说明、取值逻辑说明等。比如这样：文字较多的，可以把原型靠右的部分都分简单排版。比如这样：2.文字附带原型逻辑过重的后端需求，干脆就使用Word/Excel/TXT格式的PRD。好处是在行文的过程中，可以二次梳理思路，暴露问题。一般这样的需求文档都包括：版本说明(含变更日志)、背景、目标、需求范围、需求用例（正文，包含所有核心内容，如功能逻辑说明等）、参考资料等。（1）需求背景现状当前业务流程怎么了，当前功能是怎么样的，问题是什么，需要怎么办，以达到什么目标。用户故事也可以更简单的以“作为谁，希望通过什么，实现什么”这样的用户故事形式也可以。场景是需求的外在，拆解和穷尽需求场景，为穷尽功能和逻辑规则打基础。拆解需求场景的方法：按业务顺序，想象或模拟用户操作顺序；按目标生命周期，比如草稿、待审核、审核中；按正常、异常、正向、逆向，形成交叉矩阵。（2）需求目标用户角度的验收标准，即从效果的角度表达需求的预期（不表达如何实现）。例如：a、用户在点击页面之后3秒内必须加载完成。b、用户能看到自己买到的商品。c、用户可以删除自己的商品购买记录。（3）需求范围需求范围就是描述需求的目标项、边界、排除项，其作用是理清边界。目的是防止需求蔓延（参考PMBOK指南）。需求范围可以使用功能框架图。（4）需求用例需求用例是需求的正文部分。先将需求分成任务点，进行描述。描述的语句要严格按照文档语法原则进行（下文会继续聊到）。如下图：（5）参考资料参考资料部分，附上调研过程中查到的相关模板、数据表、脚本、接口地址、历史文档、原型链接等。二、PRD的规范这里主要以Word样式的PRD为对象。1.需求文档的语法（1）说明文一字千金需求文档就像是说明书一，去掉形容词、比喻句、副词等。能用一句话说明的就不要说第二句。（2）避免用词不当在文档或口头交流的时候，经常用到诸如“维度”、“颗粒度”、“参数”、“字段”、“项”、“列”、“表”等词汇。产品需求文档中，要做到用词严谨，避免词语歧义或失准。常见用法例如：以“订单号+产品编码”的[维度]进行唯一性判断；按照“订单”[颗粒度]进行汇总；以“时间”作为请求[参数]；数据库的[字段]为“number”；页面搜索栏的“姓名”搜索[项]；页面列表的“年龄”[列]。（3）按顺序描述开发和测试人员通常希望将一个模块的工作做完，再进行下一个，而不是来回跳。因此行文顺序上，按照先后、左右、大小等常规的顺序进行，一个模块写完再写下一个。前面写过的内容，后面不要再写了，避免歧义。比如：要在已有接口增加获取一个字段，并在页面展示，可以这样两步描述：在xx接口，增加xx字段，存入数据库xx表。接口逻辑调整为xx。旧数据初始化方案是xx。在xx页面列表中，新增一列“xx”，对应取值是数据库xx表中的字段xx。（5）以“在哪里，做什么”为主线文档以任务线为核心句式结构，即：“在哪里，做什么”。尽量用正向语序，不要倒叙，也不要用括号或破折号。比如避免前面描述完，后面又接着一个“即xxxxx”、“也就是说xxxxx”。（6）非本需求的功能，不要放在文档中产品经理是信息布道者，信息中枢。而开发和测试人员，是希望所见即所得的阅读方式。所以不必要的任务不要加入进来。比如不要使用“可能这次要做”、“注意，这个本次不做，只作为提前知悉”之类的内容。正文一定传达的是“做什么”。如果想补充，那么放在参考资料部分。（7）采用合适的行文结构1）如果需要在旧功能基础上做优化，可以用对比结构进行描述，比如：修改前：xxxx；修改后：xxxx；2）对于并列条件较多的，可以用平行列举的结构描述，比如：每天一次，定时监控【退款单】(表f_oms_refund)，若同时满足下列条件：同时满足上述条件，则进行数据抓取。数据更新时间为前两天；退款成功的（refund_status为：2、5、8、12、24任一个）；rma_sn不为空；order_sn已存在于【发票列表】中。注意：如果不熟悉数据库，建议不要写数据库，而是要写清楚页面取值位点并配以截图，避免弄巧成拙。3）如果需求点有多个，但属于同一个页面功能模块下的，那么可以放在一个用例中，分点描述，就像书本的目录一样进行编号。（8）穷尽原则“穷尽”是方案严谨的基础。穷尽包括穷尽需求的功能点，穷尽每个功能点的要素，穷尽每一个逻辑判断、性能要求、异常机制、用户权限等。比如：做一个新页面，就要从导航栏目、界面交互、搜索功能、网站介绍性文字、默认列表展示内容、列表数据统计等全部说清。同时对于后端产品而言，基本上每个需求都要说明性能要求、异常机制等。（9）最后，不要遗漏对性能的要求、对历史数据是否处理、以及权限要求性能的要求，如果不懂技术术语，则写出性能支持的数据或现象范围。比如：预计半年内数据量为100万/天，要求接口响应3s内。历史数据是否要初始化，及与发版的时间顺序。权限就是赋予页面数据、功能权限。2.通用项进行统一（1）命名统一页面一些常见的插件的命名可能有多个版本，产品经理需一开始就在需求文档中确定用哪一个。比如下面这几组意思相近的插件名称：表示删除或禁用的：删除、禁用、关闭、封存；表示启用的：开启、启用、生效；表示设置的：配置、设置；表示编辑的：编辑时间、修改时间、更新时间、操作时间。（2）数据库表中的通用字段命名统一（开发负责的）比如：每个开发习惯不同，所以要固定用哪一种，避免千人千面。是否已写入：用“is_use”、“is_used”还是“is_write”表示？已写入/未写入：用“1/0”，还是用“1/2”表示？笔者曾经遇到一个开发比葫芦画瓢，把“goods_sn”（商品编码），写成“good_sn”，这就闹笑话了。（3）页面展示统一比如：数据表为空字符串时，前端展示什么，是显示“/”，还是空白？（4）文档命名统一可以使用日期+模块名+需求名称+作者+版本号，例如：20180920_【个人资料】编辑个人资料优化_张三_V1.0。（5）术语名词定义统一比如跨境电商行业的“清关”、“保税”、“头程运费”、“尾程运费”、“大包”、“小包”等。三、PRD的自查PRD可形成一套自查规则。笔者抛砖引玉。1.按功能插件自查（1）输入框需限定输入的范围，做输入校验。示例：最多输入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）完整流程是否存在断头路。（2）逆向功能流程是否可逆，如果逆向操作，是否考虑对应的机制：比如退款、退货操作。（3）异常即异常机制。各个步骤都可能出现预期外的情况。（4）歧义需求文档的语法、功能文案、名词是否易懂，是否存在歧义。（5）兼容是否存在兼容问题：不同业务人员对功能都能接受吗？各个系统之间兼容吗？新旧功能的兼容吗（比如历史数据要不要初始化）？（6）备用是否有备用方案，次级选项。比如当正常流程无法传输的时候，是否可以用导入的机制救急。业务高峰的系统，是否有降级处理逻辑。（7）穷尽业务场景和可能原因是否穷举完毕。默认：是否给予了默认值。比如设置规则功能业务未设置怎么办？（8）脱敏是否存在敏感信息，是否有脱敏机制。4.其他自查的方式还有很多，比如也可以按照“增、查、改、删、显、传、