互联网公司日常研发流程中，产品经理撰写好 （PRD, Product Requirements Document），需要进行需求评审，接下来最耗时的两个环节是：
如果PRD质量高，工程师与产品经理之间，以上两过程可以做到接近零沟通，参考PRD就可以完成研发和测试。相反，如果PRD质量不过关，需要来回沟通，降低合作效率。因此，PRD的最大作用是“提高团队协作效率”。
检验PRD是否合格，标准是什么？我的答案：研发过程是否接近零沟通。换个说法，拿PRD给外包公司，能否实现出你想要的产品。
如何写好PRD，网上很多文章道理都对，但执行有门槛。我总结写好PRD需要符合“三好原则”：
一、好结构
任何文档，都应该有合理的结构，就像一本书，得有个好目录。用下面的通用结构，不会有大问题：
二、好内容
好内容是指，让人看得懂，且各种疑问和细节都能从PRD找到答案。上述模板的“需求详述”部分，有特别多的细节需要描述，推荐图文并茂（一图胜千字），截一张图，再从上往下用文字描述。
文字需要描述关键细节，比如：这个按钮的文案是什么？繁体版文案又是什么？点击按钮后会发生什么交互？点击后的加载态是什么表现？点击失败交互会怎样？没有数据时会怎样？
一般要描述清楚这些信息：
很多的细节，你在PRD中不说清楚，研发工程师开发过程中就会来问你，给双方增加没必要的沟通，降低合作效率。一篇PRD是否合格，最主要就是看内容是否到位，此部分是关键。
三、好排版
好排版是指，让人更容易看懂你的文字，且让人看得舒服。这点主要考验同理心，站在研发同学和测试同学的角度，看一篇排版美观的PRD，会有种赏心悦目的感受，更愿意看，也更容易理解产品经理的想法。有些排版原则，简单说一下：
四、总结
话说回来，PRD文档很难做到“研发过程零沟通”（ryan也没把握每次自己的PRD都很完美），但我们作为产品经理，作为公司项目的发动机，我们应该尽量按这个标准去要求自己，提高PRD的质量，提升整个团队的协作效率。
