因为写的是针对产品经理入门的文章，在前面两篇中主要谈了作为产品经理两项底层的核心能力，从这篇文章开始，包括后面连续几篇，都可能都讲一些非常具体的，可拿来即用的技能。对于任何行业亟待入门的人来说，讲太多抽象的理论大家都是听不懂的，身不在其中、没有躬身实践过，对于那些被别人总结出来的头头道道一般是难以领会的，除非悟性极强。

这篇文章，主要讲作为一个入门的产品经理，怎么写好一篇合格的需求文档。

  01    什么是产品需求文档

产品需求文档，英文全称Product Requirement Document——简称PRD（以下简称PRD文档），其面对的核心用户是开发人员，也许你听人说过，产品需求文档市场人员也要看、老板也要看、xxx也要看——Bullshit!!!

简直鬼扯，我可以很负责任地说，看需求文档的只有开发人员，你只要服务好他们，你的工作就合格了，不用担心会有人对你地文档说三道四，包括你地老板，因为他们根本看不懂、也没时间去看、有时间也不会去看，可以说他根本不关心这些事情，要不要你干嘛，他们关系地只是一个结果，不必诧异，这对于产品经理来说是大有裨益。

PRD文档可以说就是开发人员开发产品的指导手册，如果说原型是图纸，那么PRD文档就是详细的指标说明书，有关产品的所有参数细节，都能够在这里找到记录与说明。文档还有另一个好处就是，便于下一个人接手你的工作时，他只需要看文档就可以了解有关产品所有的详细事项，这件事对于公司来说意义极大。

  02    PRD文档的组成

2.1文档说明

这个部分是文档的开头部分，主要说明当前文档所对于的产品名称、所属的产品线、所处部门等，如果开发工作面对的是多个部门，那么这部分的存在是很有必要的。

   产品名称   所属部门

   产品线   xxx   负责人   xxx

    产品编号    xxx   项目编号  xxx

2.2版本记录

这个部分是用于记录当前产品的版本号，一个产品做好之后，后期大迭代、小迭代肯定不断，这些琐碎的事项是需要进行记录的，便于以后回溯。

   版本号   修订内容   修订人  修订时间

   v1.0.0    1.xxxx

    2.xxxxx

   3.xxxxxx

   xxxx   xx-xx-xx

版本号：这里的版本号不是已发布的产品的产品版本号，只是当前文档的版本号，文档使用版本号好的原因是，迭代很多，而每次迭代的需求，不应该在原来的文档中进行修改，而是应该另起一个副本，在副本上进行增删改查，如果文档的管理没有版本号的概念，最后的结果就是之前做了哪些、后面做了哪些，再后面做了哪些，直接傻傻分不清，这时候便给了开发、测试复仇的机会，只能坐等挨批。

修订内容：这里记录当前版本相比于上一个版本，新增了哪些、修改了哪些、删除了哪些，切忌不要在此处长篇大论，做简明扼要，概括性的叙述即可。

修订人：当一个产品需要多个人进行协作时，增加修订人这一项是保险之举，其他人看文档如果有不明白之处可以直接找当事人，省去找人的麻烦。

修订时间：这个没什么可多说的，好不容易花了几天时间，整理出来的文档，盖上时间戳是一件利己利人的事情。

2.3全局说明

这一项并不是必须，但是如果你有一些通用的规则需要进行说明，那么，在全局说明里进行统一的描述是一个比较高效的选择，否则会像懒婆娘的裹脚布又臭又长，毕竟没有人喜欢在一个文档里看到许多重复的东西，再说后续修改的时候，那么多处，万一某个地方漏掉了可咋整，至于说这里要写什么，别人说了没用，只有你自己的总结的才是合理的、实用的。

2.4各模块需求说明

这部分是整个文档的主体，是重头戏，在这里你需要根据产品的模块分别进行详细的注释说明，但表达格式应该统一，示例如下：

  数据名称  数据类型  交互说明  注释   备注

   xx  xxx   xxx   1.xxxx

 2.xxx

  xxx

2.4.1. 数据名称、数据类型：

这里的数据名称为所有文字能表达的东西，包括字段、以及各种组件，其类型包括：

文本、按钮、输入框、复选框、单选框、下拉框、时间、日期组件等等。

2.4.2 交互说明：

交互说明需要详细描述对于数据名称的所有动作，包括鼠标悬停、单击、双击、下拉、长按、三指、四指等等有什么效果，并把对应的效果进行详细的介绍。

2.4.3. 注释

这部分是对应数据名称需求的重点描述部分，需要在这里澄清当前需求所有的具体逻辑、规则、业务流程、影响等，如果比较复杂时，可以在这里对业务的背景、用户的使用场景也做简短的介绍。

2.4.4. 备注

在大多数文档、甚至产品中，备注就好像是万能药，也更像是保险丝，当无法预料用户的操作时，通常都用该功能来兜底，但在产品设计中切记保持克制，不可滥用。

以上便是一个份需求文档的基本框架。

   03      两种需求文档的表现形式

在这几年的职业经历，见证了这个职业井喷式发展的历程，有关产品的社区、协作平台也是这段时间突然兴起的，对此，我在前面的一篇文章中表达对于未能抓住这个机遇的遗憾。期间PRD文档对外的表现形式从纯word格式，衍生出完全用AXURE来进行表达，其实并无本质不同，只是把原型和文档结合来起来。

但是根据自己的实践经验，以及开发的反馈来讲，大多数情况下，后者可能会比较友好。

但是某些视觉设计本身较少的产品来说，使用纯文档能够更加专注地表达。所以具体使用哪种形式，需要根据具体情况来决定，但原则只有一个：哪种能更高效、更清晰地给开发人员传达需求就用哪种。

   04    泼一盆冷水

在我的职业经历中，大部分开发人员（尤其是前端）很少看需求文档，你不厌其烦地在需求评审会上给他们耳提面命地讲完需求后，他们会自以为是地都听懂了，然后就“扔掉书包、扔掉手表、扔掉外套”，倔强地开干，尽管UI设计稿已经精确到了像素级别，尽管他们犯的错误都是厘米的级别，测试、产品、UI都能看见，但他是就眼瞎看不到，有时甚至后端实在看不下去了，便会良心发现说几句。

情景虽然稍显夸张，但基本属实，所以为什么把产品经理称为母亲+保姆，需要全程陪护，因为出了任何问题，首先你需要站出来解释，解释不了就是你的锅，这点没有夸张。

相比于枯燥的文档，开发人员更倾向于看原型交互，这是人性使然，无可厚非，这也是为什么我建议大多数产品一定要学学AXURE，为什么是建议，因为，我碰到过不少产品经理，把画原型视为一件比较低级的工作，也许是因为他们公司有交互设计师、也许是因为自己手下带了几个小弟让手下的人画就可以了，但是殊不知，这是一种偏见，理论从实践来，没有实践，高谈理论不免沦为空谈，一个不会开车的人，他没大可能成为优秀的汽车修理师、或产品设计师。

不要说什么产品专家、产品总监人家从来不画原型，是啊，那你也得先成为那个层面的人，作为一个没有背景、没有关系的主儿，就老老实实从小做起，现在年轻人都是实用主义者，大话空话他们懂得比你多，只是人家嘴上不说而已。

不要放低了自己对于PRD文档的标准，罗曼罗兰说过：“真正的英雄是那些看清了生活真相，却依然热爱生活的人”。

你所用心走过的每一步都算数！

   未完待续   

由于这个主题比较大，一篇文章难以讲完，所以我会连续出一个系列进行翔实的讲述，还请同学们耐心期待，文中观点如有不妥之处请留言指正~

关注公号（lumyouth）看首发