上次写过一篇文章聊了聊我对 PRD 的看法，最近也有不少读者在后台留言关于 PRD 的问题，今天再补充几个观点。
最近这几年，时不时就会有读者问我要 PRD 模板，每次
遇到这样的诉求，我都微笑而不失礼貌地回绝了。
并不是我没有 PRD，而是有些内容涉及敏感信息，不能发。
要么就是我有的 PRD 跟他们想要的类型其实关联度很低。
这就引出一个问题，有标准化的 PRD 模板么？
我认为很难有。
因为不同行业、不同领域、不同产品之间的差异化还是挺大的，要解决的问题也不尽相同。
你要说类似项目背景、需求描述之类的文档框架，确实有，但我不认为这是 PRD 模板。
放眼看去各家互联网公司，你能找到两份一样的 PRD 么？或者你能找到模板一致的两家公司么？
基本没有。
有的用 Axure 配描述、有的用 PPT、有的用 Word，虽然形式和内容框架不一样，但也都不妨碍他们解决问题。
很多产品经理也都有一个共同的诉求，想知道别人家的 PRD 模板是什么样的。
同样，别人家的产品经理也是这么想的。
就像两个同类竞品互相抄袭，本来自己做得挺好，看到竞品改进，自己也跟上，结果还不如之前的方案好。
我们说，黑猫白猫，抓到老鼠的就是好猫。
实际情况是，很多人想要 PRD 模板，无非是以下这么几种情况。
第一，小白初来乍到，从没写过，对 PRD 是什么完全没概念。
第二，写过，但觉得写得不好，或是被喷过。
第三，领导安排让出个 PRD 模板给后来的人作为规范用。
以上三种情况中，属第一种和第二种的人比较多，尤其是第一种，因为这样方便他们快速上手。
结合我自己的经历，我一般不太喜欢套用各种模板，我写文档比较追求自由，不喜欢被条条框框约束。
基于问题写方案，把要做什么、为什么要做、做成什么样、怎么衡量结果写清楚就行。
实践来看，也挺香。
我上个月帮朋友的项目写过一份产品改版方案的 PRD，完全按照写文章的思路去写的，比较自由。
文档里，配了一个用例图、几个流程图以及一个信息架构图和一个功能结构图，补充必要的说明就完事了。
对方产品经历和技术读起来也毫无压力，但跟他们公司自己的 PRD 模板完全不一样。
教科书式的写法肯定会教你补充这、完善那。说实话，如果你做过技术，一定能理解程序员是怎么看 PRD 的。
很多时候，PRD 篇幅里至少 30% 以上的内容，技术基本不看，都会直接看你的流程、方案以及原型。
因为需求的类型和个性化程度比较高，有时无法完全按照模板去套用。
而且，为了把模板的内容填写完整，还需要现编很多东西，真心觉得有点浪费生产力。
评价一份 PRD 是否好，不在于写了多少字，也不在于有多精美，而重在能否高效解决问题。
PRD 不是论文，它是问题解决方案的可视化呈现，也是辅助沟通的工具。
千万别以为有了一份完整的 PRD 就可以省去沟通，某种程度上说，PRD 也是为沟通服务的。
明确了这个，就不会拘泥于形式了。
当然，模板和规范是两回事。
规范是从完整性和质量上提高 PRD 的品质，模板则是像八股文一样条条框框。
举个例子，有这么一份 PRD 模板，要求把业务背景、ROI 评估、产品方案、测试用例、相关人等各种信息全部写上。
而且，所有的需求都必须用这个模板进行提交，否则技术不接。
实际上，当需求只是改一个文案时，却要为了几个字的文案修改而写上百字的需求模板。
更傻逼的是，有些死板的团队还只认 PRD，说没有 PRD 就不评审，没看到 PRD 就不干活。
我见过一些 PRD，前面几页全是一些不疼不痒的内容，能看出来，产品经理是为了满足模板而写。
涉及到关键方案的部分，其实内容非常少。
这种三分之二篇幅是模板，三分之一内容是需求的做法，我反正是受不了。
有时候接到别人发来的 PRD，真的是得从文档中去找需求，就像到红烧牛肉味方便面里面去找牛肉一样。
很多人会把需求文档当成论文去写，其实真没必要。
因为就算写得再完美，在开发阶段，程序员也只会去看那些关键逻辑。
至于那些铺垫和说明，相信我，大部分人不会看。
反正我自己做技术写代码的时候，主要挑关键内容看，因为看半小时和看十分钟，得到的关键信息差不多。
当然，有的 PRD 是为了留档，为了给后面来填坑的人积点德。
如果是这样，就真的看产品经理的良心了。在有时间有精力的情况下，自然是越完善越好。
我曾经做过一个大需求，涉及上下游二十多个系统，总共有上百人参与。
为了把方案写清楚，也为了协作能顺利进行，我把 PRD 拆分成了几个部分，每部分都针对不同系统和团队的人。
这样的话，跟这个需求相关的人就只需要看跟他有关联的部分，而不用去管其他的系统。
相当于把复杂性隐藏在简单之下，效率其实是很高的。
而通常情况下，很多人可能会习惯于把所有需求写在一个大文档里，然后统一发给不同团队的或系统的人。
其实这只是从自我感觉良好的角度出发。
从 PRD 阅读者的角度看，他们需要从一个大文档里去找跟自己相关的部分，体验就不太好了。
如果只是其中一个环节有修改，还得把修改后的版本与其他不同团队全部同步一遍，效率不高。
另外就是这种大型需求的评审会，也不适合开大会，因为只要讲其中某一块，对于大部分人其实都没关系。
比较适合拆分成独立需求去开小会，把有关联的人叫到一起就行了，这种方式的效率要高很多。
与其沉迷于如何才能写出更好的 PRD，还不如多花点心思在产品和方案本身。
能用图表达的就尽量少用文字，能一百个字写明白的就不要用两百字。
PRD 本身无好坏，只要看的人觉得能解决问题就行。就算没有模板，也可以写出很漂亮的 PRD。
以上，希望对你有所参考。
··
···············END···············
··
写过代码、做过产品、出过一本书，在创业公司厮杀过，也在大厂服役过，如今是一个
