产品需求文档自查表：避免因为疏漏造成的各种问题

正因为有了这份自查表，帮我检查出PRD里不少错误或疏漏，从而尽可能确保把事情一次性做好，避免产品上线后因为疏漏造成的各种问题。

各位产品经理是否遇到过因为写PRD时考虑不周，导致产品上线后出各种问题的烦恼？

比如：

1. 个别关键操作点没有加数据埋点，导致无法统计到转化率数据。
2. 没有考虑到APP低版本的兼容性，导致新功能在低版本上无法正常运行。
3. 没有开发配套的后台功能，用户投诉时客服不能在后台查询相关信息，无法及时解决用户问题。

在现代社会，面对越来越复杂的工作，人们时常会因为疏忽而犯错，而有效解决这类问题的好方法就是建立一份工作内容检查清单。

上述观点出自图书《清单革命》，作者认为检查清单是你把事情做正确的必要条件。

以医学为例。1.3万个疾病诊断名称、6000余种药物、4000多种操作，再聪明的医生也难以记住全部。记不住的后果之一，便可能是犯错，而犯错的后果很可能会要人性命。据研究，在外科手术领域，由于人为不慎或错误所致的并发症达3%-17%。在分析这些案例后，研究者认为半数手术并发症可以被避免。

为保证躺在手术台上的病人安全，世界卫生组织制定过一项指南。而本书作者为此制定了一份“手术清单”，内含19条具体检查内容，目的正是减少外科医生的失误。后来作者的研究结果发表在著名的《新英格兰医学杂志》。通过组织全球不同地区、经济水平不一的8家医院，对近8000名成人患者进行研究发现，“手术清单”使手术死亡率由原来的1.5%降为0.8%，并发症发生率也降低了4个百分点。

上述数据表明检查清单的确是个好东西。目前，美国有10%的医院及其他国家和地区的2000家医院采用了类似的“手术清单”，减少甚至避免了部分手术死亡案例。

而在产品管理领域，检查清单也同样有效。之前我做项目或产品迭代时，不时会遇到由于产品设计时考虑不周，导致产品上线后出现各种问题的情况。记得有一次，由于没有考虑到新功能的客服系统配套改造，导致新功能上线后客服无法及时处理因新功能带来的产品咨询问题，从而被客服同学投诉，当时感觉很丢脸。

从此以后，为了避免这种不应有的疏漏，我再做每个项目后都会复盘，总结项目上线后遇到的问题及原因，并归纳成一份产品设计自查表及问题案例库（记录自己因为疏忽导致产品出问题的真实案例）。

现在我每次写完PRD后，都要对照自己总结的产品设计自查表把PRD再过一遍，检查PRD里是否存在疏漏之处。另外时不时翻看下案例库，提醒自己以后不要再犯同样的错误。

自查表的格式如下：

一、产品

• 流程是否存在断头路
• 文案是否易懂，是否存在歧义
• 是否存在APP高低版本兼容问题
• 新功能是否存在关联产品的改造
• 与其他系统的调用是否考虑到弱依赖处理
• 业务高峰的系统降级处理逻辑
• 后续新功能或关联产品如果下线的影响点

xxxx

二、运营

• 是否存在数据报表、埋点需求
• 是否存在客服查询需求
• 新功能的客户宣传策略
• 是否存在运营需求
• 运营内容与产品功能是否弱耦合

xxxx

三、风险

• 是否引发诸如骚扰、欺诈等安全隐患
• 是否存在负面舆情风险
• 是否存在法律及合规风险

xxxx

正因为有了这份自查表，帮我检查出PRD里不少错误或疏漏，从而尽可能确保把事情一次性做好，避免产品上线后因为疏漏造成的各种问题。

由于各种互联网产品的形态及发展阶段、侧重点不同，因此不强求大家的自查表内容一样，大家可以根据自己的工作情况总结出一份适用的自查表，相信可以帮大家在写PRD时少犯错，或是一样的错误不再犯。

延展思考，其他互联网工种如运营、UED、开发、测试同学也可以建立相关的工作自查表，从而避免运营活动、交互设计或是系统开发领域，由于疏忽所造成的各种问题。

作者：酷拉皮卡，支付宝产品经理