借鉴了网上的一些PRD入门教科书式回答，虽然有些枯燥，但是作为产品新人，觉得还是很受益，但是在实际操作中，我的同事还是提醒我切勿过多强调模板的使用，例如以下这幅图，内容很完整，但是在实际工作中，目前我只需要写清楚1,2,3,5，我的开发便能完成好工作，特别是对于已经有一定规模的互联网公司，很多步骤其实是可以省略的。因此，还是一切从实际出发，才是学习的真谛啊！

       以下是我认为最重要的点，不能再省了！很多也是借鉴网上的点，把好多点子连接到一起，去其糟粕，取其精华，因此算是非原创。

1、产品需求文档（PRD）是什么？

主要用于完整描述产品需求，向研发部门明确产品的功能和性能。

2、为什么要写产品需求文档（PRD）？

将概念图纸化，需要阐述详细的细节和实现模型。

传达需求的意义和明细

需求的迭代变更有迹可循

3、一份优秀的PRD应该包含的内容

总体说明部分:

修订历史——用以交代每次修改的责任人和修改内容

项目概述——从业务背景和意义入手从整体上告诉读者为什么要做这个产品

功能范围——从全局视角交代产品的功能点，重点描述系统中角色的职责

优先级划分——对功能点进行优先级的排序，以便相关人员快速定位产品的核心功能和规划后续工作安排

非功能性需求——对如性能和埋点等非功能型需求做出相关要求和说明

UC部分:

由用例名、设计图、流程图、用例图、状态图、序列图、用例说明、交换说明、边界条件等部分共同组成

4、一个完整的PRD应该具备的要素

PRD的能力反映的就是产品经理对用户需求的理解能力，这种能力其实是建立在对行业的专业知识（表现在对业务的理解力）基础上，再加之良好的沟通能力，一个优秀的产品经理写出的PRD必然是准确度高，开发出来的产品扩展性好，同时受用户欢迎。

5、一份完整的PRD的写作步骤

第一步：做好准备工作

你要做的是一个让人无可争议的产品，为了做好他，你必须做好前期的准备工作。你需要去了解你的顾客、竞争对手、产品团队的实力和需要的技术。你需要从顾客、用户、竞争对手、分析师、产品团队、销售队伍、市场、公司职员等收集他们能发现的问题和可能的解决办法。

第二步：确定产品的目的

指出这个产品发布的目标，同样的这个目标也有优先之分。

第三步：确定用户原型、用户目标和用户任务

用户原型：需要对用户和顾客进行分类，然后决定哪一类是我们的首要用户。

用户目标（用户意愿）：需要找出用户在使用产品中想要干什么，解开根本问题是非常具有挑战性的，特别当你周围的人告诉你你已经解决了他们想要的。

用户任务：设计任务来满足他们的目标意愿，这是产品制作进程中最核心的部分，也是创造力和创新力被激发的地方。通俗点讲，就是执行力 ，例如用户点击查询 ，下载按钮等链接。

第四步：定义产品原则

把你的需求和用户体验定义成详细的要求。每个成员都有做好产品的原则，但很少有两个人有同样的想法，这些差异都会导致不可思议的结果。尝试和制订一系列指导整个团队的产品原则是非常有价值的，这些原则需要具体到域名和项目。

第五步：产品原型和检验

可行性测试、可用性测试、概念测试（光是可用和可行是不足的。真正的问题是你的用户想要购买吗—你的用户有多喜欢-你做的有什么价值。这测试可能与可用性测试联系在一起。）

第六步：验证和质疑

当你认为你弄懂了你需要解决的问题，现在是时候开始验证和质疑假设。

第七步：写

大多数的PRD都是word文档，但也有一些是帮助文档，PowerPoint，或则写在白纸上。当然用什么格式不是很重要，重要的是让团队成功能轻松的看懂，不会遗漏，还有就是PRD可以随着项目开发而更新。PRD是要沟通整个小组。你也要记住获得产品的销售才是是重要的，所以不必担心要有什么漂亮的外观、PRD写的有多厚，只要它是可读的、可理解的、是需要的内容。

第八步 优先级

除了明确的要求，对每一个您的要求给予优先和排列秩序是很重要的。多数产品经理，如果他们给予优先级，一般都是表明要求是否是“必须有， “重要”或“希望拥有”(或其他一些分类系统)。

第九步 测试完整性

是否可以充分了解并达到目标？OA Team（质量管理团队）是否有足够的信息来做出测试计划，是否可以开始做案例？人审核了PRD，确定了各个需要说明的方面，所有的问题得到解决，现在你就可以按PRD进行产品开发。

第十步 管理产品

在产品实施期间，有不计其数的问题被解决。解决所有PRD中存在问题，如果不在PRD中就写进去，迅速解决问题并记录在PRD。如果你认为是必要的就在PRD中写进。

6、入门产品需求文档写作方法

要明白写文档的直接目的，让技术人员看完PRD之后，便会知道你的产品具体是一个什么样子。一个好的PRD会有什么样的效果?那就是技术人员只有你的PRD，没有原型，不经过语言沟通，他做出来的东西依然是你心中理想的样子。

该写些什么？例如：【项目概述】、【需求评估】和【阶段规划】，可能会有人说：为什么这么少?能问出这点的人们，首先你们需要先明确我们写文档的目的：只要能让技术人员完全了解一个产品的样子，哪怕是你只写一条也不会有人说你。【无关开发】的内容?我曾见过的有：市场调研、竞品分析、用户研究、产品价值观、以及上图的开发风险分析，以上内容基本都可以单独拿出来做为一个独立的文档去写，不要一厢情愿的认为技术人员会去看这些内容，我只想说：我!不!看!

该怎么写？先后顺序都是按轻重缓急去分的，需要给产品的功能加上需求等级，让技术人员清楚的知道开发的优先级。做完这步之后，你就需要详细的描述每一个功能。  落实到阶段规划，所谓的阶段规划就是：将一个产品的开发过程一步一步的分解开，详细的说明技术人员在接下来的这段时间具体要做些什么，如果用文字描述不清，那就借助工具：比如说大家用的最多的流程图，你需要在图中把你的产品逻辑顺序画清楚，既要简洁，又要全面，这并不矛盾。除了流程图，你也可以用N-S图，PAD图以及E-R图等。