本文从三个角度，分析了PRD这项基本功的培育方法~
曾有一个段子：
第一个问题：如果把你派到竞品公司捣乱，作为产品你会怎么做？产品经理答：每天疯狂提需求，不管是否有用。研发排期我不管。第二个问题：你现在做的主要工作是什么？产品经理：……
这篇文章，虽然不会让你瞬间越阶，但至少会让你对产品需求文档有个相对系统的认识，提升工作效率。只要你在做产品相关工作或是想往这方向就业做准备，都可以学习一下。
作为一只有梦想的产品狗，每天必备功课就是和各部门沟（si）通（bi）。
但你是否还能回忆起，被程序猿挑战逻辑漏洞的恐惧？还有被UI设计狮质疑需求价值的尴尬？
更有当你兴致勃勃准备验收需求，突然发现实现方案完全不是自己想要的，是不是只能无可奈何，忍气上线。
如果你经常遇到上面的情况，说明你的产品基本功：PRD需求文档撰写能力还不到家。
一份好的产品需求文档，可以减少开发人员与设计人员对需求的理解难度，避免产品经理陷入无休止的沟（si）通（bi）中….
今天就想和你聊聊这项基本功的培育方法~
01什么是PRD产品需求文档
传说中产品经理一生要面对三大文档：商业需求文档（BRD）、市场需求文档（MRD）、产品需求文档（PRD）。
其中产品需求文档PRD的撰写是很多产品新人首先要掌握的，因为它是在项目过程中给设计、开发、测试这样的实施人员看的，
它仔细描述了产品功能应该怎么做，是产品落地前的指南针、方向盘。也就是说，PRD的目的是给实施人员讲述产品最终要做成什么样。
较完整的PRD目录结构包括：概述、产品描述、功能需求、非功能需求、上下线需求、运营计划、附录。
如下图所示：
PRD的展现形式，行业内有2种：
一种是传统WORD，有清晰的目录结构，自顶向下阅读，以图文方式说明各个功能模块的设计思路，业务逻辑，如下图PRD目录：
WORD格式的PRD在大公司会比较常见，优点是结构完整，阅读顺畅，也不会有遗漏，适合成熟产品；
还有一种是把PRD和Axure交互原型混排在一起，如下图：
这种做法适合要求快速迭代的产品：
对产品人员：能够做到PRD快速产出；对开发人员：不必一页页的翻文档，可以直接可视化查看页面交互情况，对照页面标记去查看对应功能，所见即所得；对测试人员：则可以根据页面交互跳转去写测试用例，对后期测试可提供更加完整的测试思路。实际做的时候，可以二者结合，取最适合自己团队的方法。
02哪些人会