PRD（Product-Requirement-Document，产品需求文档），这对于任何一个产品经理来说都不会陌生的一个文档，在网上搜索也很容易找到关于PRD的干货，但会写还是不够，很多产品新人都问我为什么我的文档开发哥都不看？怎样才能写好PRD呢？

Ruby语言的创始者松本行弘说过：“代码越少，有可能出现bug的机会也越少。”文档也是一样，越是简短，可能出现的错误也会越少，同时也更利于阅读、维护和更新，所以建议大家的PRD要写成“简单易懂”。

产品需求文档作为一种和开发人员沟通的重要工具，如果梳理得不好，会直接影响后续与开发人员的沟通质量，“简单易懂”显得十分重要。但很多刚做产品的同学不太了解其重要性，会走不少弯路，他们会发现：在开完需求会议后开发人员在开发的过程中很少去翻看需求文档，通常情况下都是口头询问，同学们就觉得很奇怪，他们写文档写得那么详细，为什么开发人员就不看文档呢？既然不看，就不用写了，直接用口头沟通不是更好吗？其实，能用口头阐述都小问题和小项目，如果是中、大型项目，参与人员比较多，文档是有助于减低沟通成本和提高共走效率；还有一点，很多时候开发不看文档，是嫌弃文档的内容太长了，他们只需要简单了解这个功能大概是做什么的，怎样去实现就可以了。反观很多同学在写的时候会进入一个误区，事无巨细地描述规则，总害怕开发同事看不懂，一个比较复杂的功能可能写个300字，结果人家直接不看了。

怎样才能写出简单易懂的需求文档呢？

分析核心需求

明确开发需求实现哪些功能需求，PRD很多时候只是对原型上没有的说明进行补充，你总不能输入框限制多少个字符都写在原型上面，所以第一步需要看一下哪些是说明并没有在原型上面提现，然后在PRD上面进行补充。例如，原型上面更多的是交互说明与规则说明，但对字段的控制一般都很少去解释，还有时候原型上很难包含所有情况页面，所以PRD也有时候需要补充一下。

先填写躯干

为保持简短性，需求描述主要写成，提取关键词，关键词字数不要超过6个字，这样可以让开发哥最快的速度以内了解功能点；最好使用约定俗成的语言，因为产品与开发部在有些点上面的描述和说法是不一样的，如果使用大家能马上看得懂的言语就能提高效率，这个需要平时的积累和沟通的沉淀，最好每次项目结束总结范例，那下次开展项目可以更快更速度。

再增加枝叶

写完关键词后，围绕关键词展示具体内容，内容长度最好不要超过20个字，还把需要显示的具体内容放入了解释中，因为这些内容并不会影响开发，如果放在需求描述中，反而会降低阅读的速度和增加理解上的负担。

就前三点举个例子：我曾经做过一个功能消息待阅读，一级躯干为欠费提醒、账单提醒、生日提醒，二级枝叶为欠费提醒中对象、内容、时间等元素，最后对元素进行描述。

备注说明

在备注的加入需求来源、需求提出时间、需求提出人，避免出现产品开发完成后，由于开发周期太长，很多需求来源都淡忘了，无法得知为什么当初有这样的功能和需求，为什么增加这个字段，如果遇到项目需求确认人或者开发人员离开了，同时文档中没有留下任何确认过的需求来源记录，在产品上线验收的时候，需求出现了问题，那麻烦就大了，其实文档也是保护双方的一种手段。

时刻维护

文档还需要保持时刻更新，因为在产品开发阶段，会遇到零零散散的提升用户体现或者修改功能需求，如果是到了最后上线期间才去补很容易产生遗漏，这里也推荐避免3个遗漏的方法：

• 一定要及时把变更的需求写入需求文档中，不要拖到下次在写
• 用高亮的颜色标记出变更的细节，如需要显示的字段内容
• 对于做了删改的需求要标明原因以及时间
• 如果中途修改次数过多，建议专门做个文档来记录变动情况

项目总结

每经过一次项目，总结是必不可少的，在PRD方面也需要总结，在总结大会上需要收集开发对此项目PRD的意见和修改方向，如何才能更清晰简单地阐述我们的观点，“简单易懂”不单单是产品部为这个目标奋斗，开发的同事也应该参与其中，这个在下一个项目开发中才能取得更大的进步。

作者：毕振杰（微信公众号：毕生说产品），盖网产品经理。多年互联网产品设计经验，追求极致的用户体验。

本文由 @毕振杰 原创发布于人人都是产品经理 ，未经许可，禁止转载。