PRD（Product Requirement Document）

1.做好准备工作：了解顾客、竞争对手、产品团队的实力和需要的技术。需要从顾客、客户、竞争对手、分析师、产品团队、销售队伍、市场、公司职员等收集他们能发现的问题和可能的解决办法。建立良好的交流。

2.确定产品的目的：任何好的产品都开始于一个需求，清楚地了解这个需求，你的产品如何达到这个需求。

产品经理提出一个清晰、简明的价值主张，让大家明白这个产品到底是什么意图。电梯间演讲、电梯行销,注意不要阐述太多的细节，从某些方面来说，一个有价值的观点应当是越简单越好。

3.确定用户原型、用户目标和用户任务

用户原型：此阶段PM与很多用户交流，花大量时间去观察讨论，现在我们需要对用户和顾客进行分类，决定哪一类是我们的首要客户。PM和PD首先确定类型很重要，尽量对这个用用户的特征进行详细的描述，以便使用这个模型去指导产品的涉及。这个模型通常称其为‘人物角色’

用户目标：清晰了解到底什么问题需要解决，每个用户模型可能有不同的目的，需要在用户原型涉及的方面中需找，有可能将来某个功能解决的问题并不是主要用户需要达到目的之一

用户任务：tasks

你用越少的功能，你的产品被发现得越来越强大，因为产品功能减少，你的用户就会发现并使用更多的功能，成功的使用越来越多的功能阿门就认为你的产品越强大

4.定义产品原则：现在需要开始把你的需求和用户体验定义成详细的要求

如:易趣   易于使用、安全、有趣

5.产品原型和检验   可行性测试（产品是否可以开发，你的工程师和设计师应当介入技术的可行性调查和探索可用办法）

可用性测试（产品设计师和你要紧密工作共同提出产品功能，让它适应不同的用户。）

概念测试（Product Concept Testing）良好的原型工具，有效模拟未来产品以达到必要的程度让实际用户进行测试。在实际去做产品前检验你的产品是非常重要的。一旦实际工程开始，作出重要的变动会变得非常困难，花费也会变得很高。

6.验证和质疑：当你认为你弄懂了你需要解决的问题，现在是时候开始验证和质疑假设、假设甚至当做不知道是很容易的，但切勿把不可知的结论当做指引，那会妨碍你获得成功。

7.写：当你把需要都写下来，大多数PRD是word文档，ppt，或白纸上。什么格式不是很重要，重要的是让团队成功轻松地看懂,记住对话是2个人之见，但PRD是沟通整个小组，记住获得产品的销售才是最重要的

PRD文档主要4个组成部分

产品用途：你的工作就是指出目标，团队需要知道他们的目的是什么，目标说明要尽可能的明确，请确保你的内容包括：那些问题你要解决，不是解决方案；谁是目标用户；细节很多，但是大图片必须清晰；情景描述；多开展集思广益的会议和临时口头的讨论，从而更好的写出来，更会让团队深入了解。

产品功能特性：产品需求文档最主要的当然是需求。具体的需求完全地将取决于您的领域，但是不管你是什么行业，您的产品团队将受益于陈述需求的清楚，毫不含糊的要求，而不是模糊的解决方案。描述每个功能的互动设计和使用案例。您必须非常清楚每个功能和用户体验，还需要给工程团队留下足够多的灵活自主空间。同样重要的是确定那些要求满足哪个目的。这里就需要提到“需求跟踪”，对于关键的产品这是一个重要的流程。每种产品规范可能受益于清楚确定那些要求满足哪个目的，如果某人决定削减要求，想要深入了解就会非常困难。 从要求到目的明确说明将会是文档更加清晰。

发布标准    发布标准经常是不断变化的，但是好的PRD应该考虑到为每种标准定一个最低要求。典型的如：性能，可测量性，可靠性，可用性，可控性。

时间进度    其中很困难的一个问题就是描述产品需要的时间进度表。随便列出一个时间是没用的，你需要描述环境、动机、预计目标。你需要整个团队都和你一样达到预计目标，最终完成一个成功的产品

8.优先级：除了明确的要求，对每一个您的要求给予优先和排列秩序是很重要的。分类很重要，不可以掉以轻心。产品经理对任何一个标记“必须拥有”都需要有高度的标准，如果还没找到必须拥有的功能意味着产品还不应该生产。这些“必须拥有”的功能直接反映出产品的核心价值。“重要”的分类页很重要，在产品销售前只要有机会就要满足这些功能

9.测试完整性：现在你有一个PRD的草稿，你需要测试它的完整性，工程师是否可以充分了解并达到目标？QA Team是否有足够的信息来作出测试计划，是否可以开始做案例？当投资人或相关人审核了PRD，确定了各个需要说明的方面，所有的问题得到解决，现在你就可以按PRD进行产品开发

10.管理产品

在产品实施期间，就算最好好的PRD，也有不计其数的问题被解决。解决所有PRD中存在的问题，如果不在PRD中就写进去，你的任务就是迅速解决问题并记录在PRD。如果你做了你的工作并准备记录在PRD，项目审查就会变得非常简单，因为任何一个部分都历历在目。

记住PRD是一个“活”的文件，在要跟踪记录在产品开发期间的所有功能过程。最后你会发现很多额外的东西，如果你认为是必要的就在PRD中写进。

需求种类（界面、功能、报表、性能、接口需求）

本文出自 “小恐龙” 博客，请务必保留此出处http://455215.blog.51cto.com/445215/1564623

PRD 如何编写好的需求文档