科技猎壹佰干货铺｜22篇实战干货，教你十步搞定PRD文档写作！（附模版）
欢迎客官来到又一期的壹佰干货铺~
你有没有这样的时候，在对产品经理一知半解的阶段，疯狂怒补网上的各种教程与干货？
到处寻找「模板」与「规范」，可能你不是想要把他看懂，只是想知道，那些玄乎其神的文档、原型究竟长什么样。
你是否曾在网上找过各种各样的PRD模板，感觉这货简直就是最神秘的东西，看到各种求职招聘信息都写，熟练撰写PRD文档？
因为，写PRD已然成为PM的基本技能了。
而作为一个产品新人，成功入职之后，首先就要开始撰写各种文档。而其中最重要的非产品需求文档（PRD）莫属。
而PRD也是令很多产品新人比较头疼的东西， 那么PRD到底该怎么写？
本期干货铺带来产品壹佰网站人气最高的22篇实战干货，教你十步搞定PRD文档写作！赶紧收藏起来~
本期干货铺内容大纲：
第一步：什么是产品需求文档（PRD）【干货 x1】
第二步：为什么需要写产品需求文档【干货 x1】
第三步：一份优秀的PRD应该包含的内容【干货 x1】
第四步：一个完整的PRD应该具备的要素【干货 x2】
第五步：一份完整的PRD的写作步骤【干货 x2】
第六步：0-1岁产品新人的产品需求文档写作方法【干货 x2】
第七步：怎样将你的PRD写得更好【干货 x2】
第八步：写PRD文档会遇到的问题和细节【干货 x3】
第九步：优雅地利用Axure进行PRD文档写作【干货 x2】
第十步：参考模版和案例【干货 x6】
学完后你将获得：
学习到更专业的PRD文档写作方法，对PRD文档写作有更清晰的思路。全面搞定PRD文档写作！
第一步：什么是产品需求文档（PRD）
PRD是英文“ProductRequirement Document”的缩写，翻译为中文就是“产品需求文档”，主要用于完整描述产品需求，向研发部门明确产品的功能和性能。
PRD的面向对象是研发部门，用于向他们说明需要开发的产品功能和这些功能的性能要求。PRD质量的好坏，在很大程度上不仅直接影响着研发部门是否可以明确产品的功能和性能，而且在很大程度上决定了产品的最终质量。
推荐干货>>> 产品经理小技巧——详解产品需求文档（PRD）
第二步：为什么需要写产品需求文档
在学习如何撰写PRD之前，我们先要明白写PRD的目的是什么：
①概念化”阶段进入到“图纸化”
我们之前在市场需求文档(MRD)中阐述到的功能，都是表达的一个意向，不考虑实现方法和细节。而PRD则是将概念图纸化，需要阐述详细的细节和实现模型。产品人员可以通过撰写PRD，梳理清楚方案实现过程中的各种问题和影响。
②向项目成员传达需求的意义和明细
PRD的主要面向对象是项目经理、开发、设计和测试。如何向这些不同的角色表达清楚需求明细，就需要一份规范的PRD文档来描述。项目经理通过文档可以迅速了解任务的规模和相关接口，而开发设计人员通过文档可以了解页面元素和用例规则，测试人员可以提前根据文档撰写测试用例。PRD文档在形式上是项目启动的必要元素之一。
③ 管理归档需求
大都数的新需求都需要迭代几个版本后才能走向成熟稳定的阶段，如果没有PRD文档，在大型项目中，需求的迭代变更将变的无据可循。PRD的文档修订编号和命名也是项目规范化管理的主要方法之一。
......
推荐干货>>> 干货 | 一篇文章搞懂移动应用prd怎么写
第三步：一份优秀的PRD应该包含的内容
PRD从整体上看可以划分为总体说明部分和UC部分，总体说明部分按照功能的不同又可划分为以下几个模块，分别为修订历史——用以交代每次修改的责任人和修改内容，项目概述——从业务背景和意义入手从整体上告诉读者为什么要做这个产品，功能范围——从全局视角交代产品的功能点，重点描述系统中角色的职责，优先级划分——对功能点进行优先级的排序，以便相关人员快速定位产品的核心功能和规划后续工作安排，非功能性需求——对如性能和埋点等非功能型需求做出相关要求和说明。
UC部分则是由多个用例组成，每个用例对应产品的一个或多个功能点，由用例名、设计图、流程图、用例图、状态图、序列图、用例说明、交换说明、边界条件等部分共同组成，这其中具体采用哪些类型的UML图需要根据产品的业务类型而定。举个栗子，偏向后台流程管理的产品应将重点放在流程图、时序图、类图等能表达清楚业务流程的UML图上，而手机APP类以页面交互为主的产品则应将重点放在用例图、状态图等能够表达页面之间交换和关联关系及用户操作顺序的UML图上。以上内容就是是PRD的核心部分。
......
推荐干货>>> 一份优秀的PRD应该包含哪些内容？
第四步：一个完整的PRD应该具备的要素
PRD的能力映射出的是一个产品经理的产品能力，这种能力分基础和高级两类，毋庸置疑，PRD应该是一种基础能力，产品经理必备的一种技能，PRD的能力反映的就是产品经理对用户需求的理解能力，这种能力其实是建立在对行业的专业知识（表现在对业务的理解力）基础上，再加之良好的沟通能力，一个优秀的产品经理写出的PRD必然是准确度高，开发出来的产品扩展性好，同时受用户欢迎。因此产品经理在日常必须深入学习行业知识，了解用户的操作规则，多与用户沟通，多倾听问题，从而发现问题，解决问题，随着对行业和用户的理解及把控的逐步深刻，PRD阐述的内容将越来越全面，越来越有深度，这份PRD将成为其他人的学习资料，会产生深远的影响。都说产品经理引领着产品的发展方向，是产品的“爸爸”或“妈妈”，衷心的希望每个产品经理都能做个称职的父母亲。
......
推荐干货>>> 如何写出好的产品需求文档（PRD）？
推荐干货>>> 产品经理该如何正确输出一份PRD文档
第五步：一份完整的PRD的写作步骤
做好产品需求文档的这十步，是经过长期的实践经验和反复验证而得到的。可能这里描述的不是很全面，但他已经足够让你做一个成功的产品需求文档。做好这几步花费的时间要以项目的大小、复杂程度、个体学识、基本技能熟练度而定。
第一步：做好准备工作
你要做的是一个让人无可争议的产品，为了做好他，你必须做好前期的准备工作。你需要去了解你的顾客、竞争对手、产品团队的实力和需要的技术。你需要从顾客、用户、竞争对手、分析师、产品团队、销售队伍、市场、公司职员等收集他们能发现的问题和可能的解决办法。这里有很多的工作需要你去完成,在“成功的产品背后”这篇文章中有详细的描述。
建立良好的交流也非常重要，它会影响着产品团队。如果你的准备工作做的够好，你也会变得越来越有信心和说服力。
第二步：确定产品的目的
任何一个好的产品都开始于一个需求。你必须清楚的了解这个需求，你的产品如何达到这个需求。
......
推荐干货>>> 产品需求文档的10步
推荐干货>>> 如何完整高效地制作一款APP产品需求文档
第六步：0-1岁产品新人的产品需求文档写作方法
作为一个产品新人，入职之后，首先就要开始撰写各种文档。而在我看来，其中最重要的非产品需求文档莫属。该文档是将一个产品由抽象到具体最重要的步骤之一，也是让技术人员详细了解一个产品的【三部曲】之一，其他两步分别是产品原型和语言沟通，会在接下来的两篇文章中细说。而PRD也是令很多产品新人比较头疼的东西，那么PRD到底该怎么写？
要明白写文档的直接目的！
一般PRD大约会给以下这三类人看：技术人员，公司BOSS以及客户，而本文以及接下来的两篇文章所说的内容目标用户均是【技术人员】。
即然目标人群已经明确，那么将PRD交给技术人员最直接的目的是什么?那就是让技术人员看完PRD之后，便会知道你的产品具体是一个什么样子。一个好的PRD会有什么样的效果?那就是技术人员只有你的PRD，没有原型，不经过语言沟通，他做出来的东西依然是你心中理想的样子。
......
推荐干货>>> 0岁产品经理：如何写需求文档
推荐干货>>> 从思考到撰写，产品新人如何写出自己风格的「需求文档」
第七步：怎样将你的PRD写得更好
Ruby语言的创始者松本行弘说过：“代码越少，有可能出现bug的机会也越少。”文档也是一样，越是简短，可能出现的错误也会越少，同时也更利于阅读、维护和更新，所以建议大家的PRD要写成“简单易懂”。
产品需求文档作为一种和开发人员沟通的重要工具，如果梳理得不好，会直接影响后续与开发人员的沟通质量，“简单易懂”显得十分重要。但很多刚做产品的同学不太了解其重要性，会走不少弯路，他们会发现：在开完需求会议后开发人员在开发的过程中很少去翻看需求文档，通常情况下都是口头询问，同学们就觉得很奇怪，他们写文档写得那么详细，为什么开发人员就不看文档呢？既然不看，就不用写了，直接用口头沟通不是更好吗？其实，能用口头阐述都小问题和小项目，如果是中、大型项目，参与人员比较多，文档是有助于减低沟通成本和提高共走效率；还有一点，很多时候开发不看文档，是嫌弃文档的内容太长了，他们只需要简单了解这个功能大概是做什么的，怎样去实现就可以了。反观很多同学在写的时候会进入一个误区，事无巨细地描述规则，总害怕开发同事看不懂，一个比较复杂的功能可能写个300字，结果人家直接不看了。
......
推荐干货>>> 升级版丨写PRD怎样思考的更加全面
推荐干货>>> 怎样才能写出简单易懂的需求文档？
第八步：写PRD文档会遇到的问题和细节
换位思考
写PRD一定要时刻想着换位思考，你得想着你的文档是给开发、设计、测试等看的，语言上尽量好理解，尽量不要用形容词，描述功能时，可以尝试用开发的逻辑去思考书写方式。
不要求大求全
这部分是我踩的一个深坑，我之前总想着把所有的逻辑都整理在一个流程图上，然而这在很多情况下是不可能的，除非你做的这个产品比较简单。即便你真能够将所有逻辑整理在一个流程图上，那么这个流程图也会很复杂，不容易让团队其他人看懂。功能最好分点说明，正常逻辑和异常逻辑分开说明。
所见即所得
这是一个读图的时代，图片展现是最清晰明白的。有的功能点，逻辑比较复杂，这时可以考虑用原型图展现，原型图可以做到所见即所得。
......
推荐干货>>> 编写需求文档常遇到的问题有哪些？
推荐干货>>> 产品需求文档中容易被忽视的10个细节
推荐干货>>> 产品经理写PRD文档时需要注意的事项有哪些？
第九步：优雅地利用Axure进行PRD文档写作
就我所见，行业大多产品经理都是用Word+Axure原型的方式组成产品需求文档。那这种方式，是否真的能方便地表达出产品需求？我问了很多程序猿，他们在开发时，一般都是看着效果图和原型图写代码，只有在遇到问题时，才会查看word文档。也就是说，开发需要一边写代码，一边看效果图，一边看原型，还要时不时查看文档。而且，大多数程序猿都不会逐字逐句去读产品经理的长篇大论。那产品经理写word真的合适吗？这样的用户体验真的好吗？花费大量时间写word真的有价值吗？在Axure画原型的同时，我们为什么不能直接在旁边标注呢？这样岂不是方便快捷很多吗？
其实，当下流行一种直接在原型图上标注的需求文档撰写方式。在新版的Axure8中，也已经推荐了原型加标注的需求文档样式。Axure8新增了一组部件—不干贴，就是方便产品设计人员进行功能标注。
......
推荐干货>>> 善用Axure写PRD，全局规范一个都不能少
推荐干货>>> Word产品需求文档，已经过时了
第十步：参考 模版和案例
记得自己在学习PRD文档撰写的时候，总希望能找到一份比较全面详细又易懂的模板。如果你也曾有相同的困恼或者尚未遇到满意的答案，或许本文可以提供不错的参考。
......
推荐模版>>> 这也许是最美的产品需求文档模板
推荐模版>>> 产品需求文档模板，不用找了（附“简”例）
推荐模版>>> 乔不死带你实战项目：PRD通用模板
推荐案例>>> 干货丨“密码管家”PRD需求文档诞生记（绝密产品原型文档）
推荐案例>>> PRD实用案例|「赶公交」App产品需求文档
推荐案例>>> 一个“广场舞APP”的PRD文档（含交互原型）
-完
-本期专题互动-
PRD写作这一项产品经理的基本功，你掌握了多少？
你在写PRD时，遇到过的最大的困难是什么？
把你的感想和大家分享一下吧~
「壹佰干货铺」——互联网产品、运营、设计、职场精品干货，应有尽有！
咱们下期再见~
P.S. 小预告一枚~本周四晚8点，壹佰讲堂大咖开讲：
1905电影网成都产品总监张崟 （声音超好听的大美女噢！）为大家分享：黄金5步打造优质团队，案例+实践为你全方面解析！
好学的小伙伴赶紧 戳这里 获取听课地址吧！
