如何写好产品需求文档PRD.docx
《如何写好产品需求文档PRD.docx》由会员分享，可在线阅读，更多相关《如何写好产品需求文档PRD.docx（17页珍藏版）》请在冰豆网上搜索。
如何写好产品需求文档PRD
如何写好产品需求文档PRD
十步做好产品需求文档
做好产品需求文档的这十步，是经过长期的实践经验和反复验证而得到的。
可能这里描述的不是很全面，但他已经足够让你做一个成功的产品需求文档。
做好这几步花费的时间要以项目的大小、复杂程度、个体学识、基本技能熟练度而定。
第一步：
做好准备工作
你要做的是一个让人无可争议的产品，为了做好他，你必须做好前期的准备工作。
你需要去了解你的顾客、竞争对手、产品团队的实力和需要的技术。
你需要从顾客、用户、竞争对手、分析师、产品团队、销售队伍、市场、公司职员等收集他们能发现的问题和可能的解决办法。
这里有很多的工作需要你去完成,在“成功的产品背后”这篇文章中有详细的描述。
建立良好的交流也非常重要，它会影响着产品团队。
如果你的准备工作做的够好，你也会变得越来越有信心和说服力。
第二步：
确定产品的目的
任何一个好的产品都开始于一个需求。
你必须清楚的了解这个需求，你的产品如何达到这个需求。
产品经理需要提出一个清晰、简明的价值主张，让它很容易被接受，要让产品团队、管理人员、用户、市场人员清楚的明白这个产品到底是什么意图。
虽然这听起来很简单，但是也只有少数产品才有这样的价值主张。
考虑“velevatorpitch”（电梯间演讲、电梯行销）测试。
假设你在做电梯的时候遇到公司CEO，他问你产品的意图是什么，你能在电梯到达之前回答这个问题吗？
如果不能，你就还有工作需要做。
也许是你的说明没有针对性，他可能表现出来和其他产品做的没有什么明显区别；也许你提出的观点不能和你的用户产生共鸣；也许你解决的是一个非常规的问题，可能你想应用一种技术。
这个价值主张可能需要满足公司的产品战略。
注意你不需要阐述太多的细节，从某些方面来说，一个有价值的观点应当是越简越好。
产品需求需要确切的指出这个产品发布的目标，同样的这个目标也有优先之分。
例如，你的目标可能是：
1）易用，2）零售价不足$100，3）和前期产品很好的结合。
然后你需要说明如何去测算。
对于“易用”这类项目，你需要明确指出产品可用性达到某个水平。
这是通常用目标用户来定义。
可用性工程师能测算出你的产品对目标用户的可用性，也测算出可用性问题的严重程度，同样你可以说明没有重大的可用性问题。
这里的关键就是让每个人都知道产品成功的时候是什么样，还有给产品团队在设计和实施中遇到问题如何进行取舍的指导。
第三步：
确定用户原型、用户目标和用户任务
现在你已经明白你想要解决什么问题，下接下来就要深入了解目标用户和顾客，在这步中，和你的PD（产品设计）紧密联系非常重要。
用户原型
在这个阶段，PM需要和很多用户交流，需要花费大量的时间去直接观察和讨论。
现在我们需要对用户和顾客进行分类，然后决定那一类是我们的首要用户。
比如你正在做一个像eBay一样的互联网拍卖服务，你同时拥有买家和卖家，在这之中还有使用频率少的用户和经常使用的用户，不难想象还有个别特殊的用户，比如团体公司采购者。
PM（产品经理）和PD（产品设计）需要首先确定类型是最重要的，然后尽量对这个用户群的特征进行详细的描述，以便使用这个模型去指导产品的设计。
这个模型通常称其为“人物角色”。
虽然是想像的，但是应该是典型的、可行的和真实的，让你能够使用。
这个想法来自与一个能代表这类用户的本质的原型。
举个例子：
“里昂是一个超级卖家，46岁，男性，居住在Fresno，经营小型摩托车配件。
虽然他开着一个小店，但是他的生意大部分来自Ebay,每个月平均有400多次交易。
他出售的东西品种非常多，但是他最受欢迎的商品还是哈雷戴维森的负重袋。
他自己拥有两个哈雷，还开着1993年的丰田皮卡。
里昂已经结婚了还有两个小孩。
里昂买电脑仅仅是因为他需要使用Ebay,除了ebay和电子邮件很少再使用其他东西。
里昂已经在Ebay上销售产品已经三年了，他学会了在ebay应该掌握的东西，他非常自豪的拥有超过5000的信用度。
如果Ebay更改了网站，特别是销售的过程方面，对于他来说改变习惯、学习这些变更是非常困难的。
里昂已经形成了自己的习惯，星期一列出销售的商品，星期五拍卖结束，设法让在收到货款的几个小时内出货。
”
但愿这样的描述能让你了解里昂和知道他是怎么来的。
当我们考虑新功能时，我就要问问自己里昂会是什么发应，为了让他能顺利的使用这个功能我们需要做什么。
注意缩小范围，让他仅仅描绘必不可少的。
满足所有人是徒劳的，通常最后没人会满意，所以尽量提出几个最重要的和最流行的角色描述是非常重要的。
同样，如果你不去精确的定位你的目标用户，你就只会存在模糊的概念，你会发现理解你用户的反应非常困难。
你要倾向于设想，让你能更像你的用户。
用户目标（用户意愿）
一旦我们确定并描绘了我们主要的用户类型，我们就需要找出用户在使用产品中的目标（想要干什么）.这听起来很简单，但是解开根本问题是非常具有挑战性的，特别当你周围的人告诉你你已经解决了他们想要的。
从CEO、销售代表、工程师到客户，每个人都太兴奋而不能帮助你找到解决根本问题的办法，他们会告诉你在某个地方添加一个快捷按钮，或则添加一个功能仅仅是因为竞争对手有，或则是改变成他们喜欢的颜色。
最好的解决办法取决于清晰的了解到底什么问题需要解决，每个用户模型可能有不同的目的，需要在用户原型涉及的方面中进行寻找。
有可能将来某个功能解决的问题并不是主要用户需要达到的目标之一。
用户任务（tasks，用户为达到目标使用产品而需要做的任务）
掌握了用户原型与他们的目标愿望，我们就开始着手设计任务来满足他们的目标意愿，这是产品制作进程中最核心的部分，也是创造力和创新力被激发的地方。
许多优秀的产品仅是用更好更新的办法解决一个已有的问题，有时候这种办法仅仅是应用一个种新技术，但是大部分是来自深刻的见解而使一种新方法的产生。
例如TiVo（美国市场占有率第一的数字录像机）在电视节目录制的老问题上面想出一个全新的办法，让顾客更加容易地实现他们的目标并且建立了电子设备一个全新的类别。
注意我们虽然谈到了目标和任务但是还没有谈到具体的功能，这些功能都需要达到用户目标而必须的。
你以后会发现许多功能都是低优先级或则是完全多余的。
以“必须功能”这个理由可以排除很多功能。
讽刺的是，你用越少的功能，你的产品被发现得越来越强大。
这是因为产品的功能越少，你的用户就会发现并使用更多的功能，成功的使用越来越多的功能他们就认为你的产品非常强大。
这些理由都是违反我们直觉的，我们大多数人都不能和我们的用户一样，我们在自己的行业中愿意比用户花费更多的时间去探索功能和容忍复杂性。
第四步：
定义产品原则
现在你需要开始把你的需求和用户体验定义成详细的要求。
同时你仍然会面临着许多的决定和权衡，为你的产品标准作出最佳的决定是非常重要的。
在大多数的产品团队中，每个成员都有做好产品的原则，但很少有两个人有同样的想法，这些差异都会导致不可思议的结果。
尝试和制订一系列指导整个团队的产品原则是非常有价值的，这些原则需要具体到域名和项目。
用TiVo举例，在产品团队工作开始时，以下这些产品规范就被建立，并在团队里传达：
1.它是娱乐的
2.一个傻瓜式的电视
3.一个该死的视频设备
4.平滑柔顺的
5.没有模式和深层次
6.尊重观众的隐私权
7.像电视一样强大
这些规范很大的影响到产品的定义而且在很大程度上加大了难度，但是他们确实是成功产品的来源。
比如易趣的口号就是：
1、易于使用2、安全3、有趣
它将在该项目中，在面对众多问题而作出决定的时候进行指南.
第五步：
产品原型和检验
这是一个拿出你想法的阶段，创造力和创新力拿出成就的地方.
很多人都容易犯一个常见的错误，他们对产品设计规范太有信心，结果一旦得到beta的测试他们就必须调整产品。
但是肯定beta测试版并不是进行重大改变的时候，所以才会有许多首次发布的产品离目标太远。
对于许多产品来说，这个时候你可以用大量的原型做很多的实验。
首先，下面的三个非常重要的测试你可能需要做
可行性测试
一个直接的问题就是产品是否可以开发，你的工程师和设计师应当介入技术的可行性调查和探索可用办法。
有些办法是行不通的，但是有其他的办法可行是非常有希望的。
工程师会发现在产品的某个阶段不可能逾越，现在知道比以后知道要好。
可用性测试
产品设计师将要和你紧密工作共同提出产品功能，让它能适应不同的用户。
可用性测试常常会找出遗漏的产品要求，同时确认产品最初的要求是否是必须的。
在你拿出一个成功的用户体验之前需要多做一些测试工作。
可用性的目的是在真正的用户身上测试，从产品目标用户得到质量反馈的测试是非常艺术和科学的。
当然产品经理和产品设计将模仿使用，但是实际是没有人能取代真实的目标用户。
概念测试（ProductConceptTesting）
光是可用和可行是不足的。
真正的问题是你的用户想要购买吗—你的用户有多喜欢-你做的有什么价值。
这测试可能与可用性测试联系在一起。
对于一部份小产品，您的想法写在纸就足够了，但是对于多数产品，为了预计产品是否达到目标，复杂用户互作用或新技术的使用、某种形式原型都是非常重要的。
原型也许是一个物理设备，或者它也许是软件产品的一个预览版本。
关键是它需要足够现实，您能用原型在实际目标顾客身上测试，并且他们可以给您质量反馈。
以前做原型主要有两个障碍。
第一是缺乏良好的原型工具，需要花费很多的时间制作原型；另一个是管理方不知道原型和真实产品的区别，在不可预计的情况下，按照最终产品来要求原型。
今天有优秀的原型设计工具可以让工程师或设计师快速的制作原型，可以有效的模拟未来的产品以达到必要的程度让实际用户进行测试。
而且大多数管理者都知道模仿和实际的区别—就如同缩小比例的房子模型和真实的家一样。
在实际去做产品之前去检验你的产品是非常重要的。
一旦实际的工程开始，作出重要的变动会变得非常困难，花费也会变得很高。
第六步：
验证和质疑
当你认为你弄懂了你需要解决的问题，现在是时候开始验证和质疑假设。
假设甚至当作不知道是很容易的，但是切勿把不可知的结论当作指引，那会妨碍你获得成功。
天文学最初定义是研究太阳和其他行星如何围绕自己转，本身的定义就是一个臆断，反而阻止人们获得真相。
第七步：
写
当然你需要把这些都写下来，大多数的PRD都是word文档，但也有一些是帮助文档，PowerPoint，或则写在白纸上。
当然用什么格式不是很重要，重要的是让团队成功能轻松的看懂，不会遗漏，还有就是PRD可以随着项目开发而更新。
记住对话是两个人之间的，但是PRD是要沟通整个小组。
你也要记住获得产品的销售才是是重要的，所以不必担心要有什么漂亮的外观、PRD写的有多厚，只要它是可读的、可理解的、是需要的内容。
PRD文档主要有四个部份组成
产品用途
你的工作就是指出目标，团队需要知道他们的目的是什么，目标说明要尽可能的明确，请确保你的内容包括：
*那些问题你要解决，不是解决方案
*谁是目标用户
*细节很多，但是大图片必须清晰
*情景描述
多开展集思广益的会议和临时口头的讨论，从而更好的写出来，更会让团队深入了解。
产品功能特性
产品需求文档最主要的当然是需求。
具体的需求完全地将取决于您的领域，但是不管你是什么行业，您的产品团队将受益于陈述需求的清楚，毫不含糊的要求，而不是模糊的解决方案。
描述每个功能的互动设计和使用案例。
您必须非常清楚每个功能和用户体验，还需要给工程团队留下足够多的灵活自主空间。
同样重要的是确定那些要求满足哪个目的。
这里就需要提到“需求跟踪”，对于关键的产品这是一个重要的流程。
每种产品规范可能受益于清楚确定那些要求满足哪个目的，如果某人决定削减要求，想要深入了解就会非常困难。
从要求到目的明确说明将会是文档更加清晰。
发布标准
发布标准经常是不断变化的，但是好的PRD应该考虑到为每种标准定一个最低要求。
典型的如：
性能，可测量性，可靠性，可用性，可控性。
时间进度
其中很困难的一个问题就是描述产品需要的时间进度表。
随便列出一个时间是没用的，你需要描述环境、动机、预计目标。
你需要整个团队都和你一样达到预计目标，最终完成一个成功的产品。
第八步优先级
除了明确的要求，对每一个您的要求给予优先和排列秩序是很重要的。
多数产品经理，如果他们给予优先级，一般都是表明要求是否是“必须有，“重要”或“希望拥有”（或其他一些分类系统）。
分类是很重要的，不可掉以轻心。
产品经理对任何一个标记“必须拥有”都需要有高度的标准。
如果还没有找到必须拥有的功能意味着产品还不应该产生。
所以小心标注“必须拥有”，这些标注“必须拥有”的功能直接反应出产品的核心价值。
“重要”的分类也很重要，在产品销售前只要有机会就要满足这些功能。
“希望拥有”产品团队也应该注意到，即使大多数也都没有实现，在未来版本也适当的慢慢实现。
这些有时候是不够的，从1到n每一个分类优先排序都是很重要的。
有几个原因：
首先，上市时间总是被关注，并且日程表经常下降，您说不定被迫使削减有些特点为了尽快进入市场。
你也不想产品团队先开发简单的功能而放松重要的功能，导致最后客户使用的关键功能还没完成。
其次，在产品设计和开发阶段，团队将会发现更多的问题产生并解决这些问题，所以很有可能有更多关键功能出现。
优先顺序会可以帮助你如何平衡以容纳更多的功能。
这点就是说产品经理如何不给出优先级和重要等级，其他相关较少的因素也会跟着无法确定。
整个PRD是一个不断完善和思维提高的过程，明朗锐利就是可以成功的产品的，模糊就是失败的产品。
在争论最激烈的时候也能容易做决定，并且帮助工程师做出计划。
第九步测试完整性
现在你有一个PRD草稿，你需要测试它的完整性。
工程师是否可以充分了解并达到目标？
OATeam（质量管理团队）是否有足够的信息来做出测试计划，是否可以开始做案例？
当投资人或相关人审核了PRD，确定了各个需要说明的方面，所有的问题得到解决，现在你就可以按PRD进行产品开发。
第十步管理产品
在产品实施期间，就算是最好PRD，也有不计其数的问题被解决。
解决所有PRD中存在问题，如果不在PRD中就写进去。
你的任务就是迅速解决问题并记录在PRD。
如果你做了你的工作并准备记录在PRD，项目审查就会变得非常简单，因为任何一个部份都历历在目。
记住PRD是一个“活”的文件，在要跟踪记录在产品开发期间的所有功能过程。
最后你会发现很多额外的东西，如果你认为是必要的就在PRD中写进。
网站的MRD和PRD
说到MRD，就不得不说一下PRD，也有朋友提到了这个问题，MRD和PRD有什么区别呢？
如果大家看过中国产品经理联盟的第一期和第二期杂志，那么就应该知道MRD和PRD的区别和关系了，在这两期杂志的“PM词典”栏目中，就对这两个工具进行了介绍，先来分别看一下。
做个表格来说明一下两者之间的关系：
从这个表中可以看出，MRD本身并没有什么特殊之处，按照产品管理者的工作内容来说，是必备的东西，但是，我们知道，现实的情况是，许多技术型的公司实际上对产品管理者的定位过于狭隘，非要生生地把产品管理者分为“技术型”、“市场型”，本来一个完整的产品管理过程和管理内容，就这样支离破碎了。
正是因为这个原因，许多技术型企业的产品管理者很少或者几乎没有接触过MRD，并不是说大家没有这个意识，其实，作为产品管理者，这些市场端的东西多少都会有了解的，但是，企业并没有把这个任务交给产品管理者来做，因此，就显的有些陌生了。
在表格中，已经提到了，MRD起着一种“承上启下”的作用，“向上”是对不断积累的市场数据的一种整合和记录，“向下”是对后续工作的方向说明和工作指导。
这个很容易理解的，那么，具体到这个文档中，都包括什么内容以及如何来完成好这些内容呢？
接下来，我就自己的一些经验说说个人的想法，对不对的，大家见谅。
刚才说到了，MRD就是对产品所在市场数据的整合，说白了，就是对市场分析后的结论体现，那么，在这个文档中，需要体现哪些内容呢？
在我看来，需要体现的主要内容包括：
1、市场的问题和机会
2、市场特征
3、用户特征
4、使用者特征
5、市场的需求
分别解释一下：
1、市场的问题和机会
在这个主题中，主要是要求产品管理者说明自己负责的产品现在所处的市场都有什么问题和机会、面对这个现实的市场，产品有什么问题和机会，以及产品所需技术面临的问题和机会。
其实就是要求从市场层面、产品层面、技术层面来阐述问题和机会。
2、市场特征
在这个主题中，主要是要求产品管理者说明目标市场的现状和趋势。
应该包括的信息有：
目标市场特征、目标市场趋势、目标市场细分、目标市场时间约束。
3、用户特征
这里的用户是个广义的概念，它其实包括两个方面的信息：
1、客户（customer）；2；购买者（buyer）。
在这个主题中，主要是要说明这产品的目标用户的特征、细分、动机、影响因素以及用户期望（目标）。
4、使用者（user）特征
之所以把这个主题独立出来，就是因为，无论什么产品，最终是要由具体的人来介入的，这类人才是产品的最终享受者，具体到产品上，其实我们日常分析的产品需求和功能都是基于他们考虑的。
在这个主题中，要说明这类用户的特征、现实需要和相关联系。
这里插一句话，我看到国外的一些公司是采用了原型塑造法来完成这个主题的，关于这个方法，抽时间再说，呵呵。
备注：
关于客户（customer）、购买者（buyer）、使用者（user）的区别和关系，如果有朋友还有不解的地方，可以一块来讨论，嘿嘿。
5、市场的需求
这个就比较容易理解了，就是把市场需求按类别描述出来即可，具体的标准，大家应该很清楚的，就是“描述性的语言来说明用户的期望”，主要包括的内容有：
功能分类、开发环境说明、兼容性说明、性能说明、国际性说明、文档说明、外观说明、发布说明、支持和培训说明、其它说明、方案概述、技术概述。
当然了，我是把可能出现的内容都列举出来了，在实际的情况中，肯定会根据行业和产品的不同有所删减，这个仅供参考哈。
在这个主题的最后，我建议大家加一个表格，就是“需求概要表”，这个表格的作用就是用列举的形式来把所有市场需求记录下来，毕竟上面的内容都是描述性的，这个表格有助于快速浏览。
这个表格应该包括的内容有但不仅限于：
实现目标、约束条件、需求联系、原型、类型、优先级。
简单介绍了一下MRD中主要体现的主题，大家看一下，其实内容很简单的，但是，我在看了一些MRD后，才感觉到，写好一份MRD，那是相当的不易呀。
首先，在MRD中必须有许多的数据来支持你每个主题的结论描述，其次，在MRD中，涉及到了一些具体的方法，例如刚才说到的原型法，三，MRD是整个产品项目过程中非常重要的一份文档，或者说，这份文档奠定了接下来的一些列工作基础，MRD做好了，其它的工作都没有问题，这个作不好，其它的都不可能让人满意的。
因此，要写好MRD，是不能脱离产品项目流程和思想的，这个说起来，就太大了，有时间咱们慢慢聊。
大家在现实的工作中，偏重于PRD的居多，大家可以想想，是不是通常把主要精力放在了产品功能上了，而忽视了对产品所在市场的关注和分析，尤其是在一些软件和互联网公司，非常明显，有多少朋友做到了MRD中要求的呢？
说到最后，还是我始终坚持的一个观点，产品管理文档，本身没有任何价值，网上到处都可以找到，但是，如果不懂产品管理的思想，不明白产品管理到底是什么，不知道产品管理者到底应该做什么，即使给你非常好的文档模板，又有几个人能真正理解这份文档的作用，并把它写好呢？
对了，最后提一点，有些公司，是把MRD和PRD合并来做的，或者说，即使可以舍弃PRD，也不能舍弃MRD，因为PRD是由MRD延展而来的，MRD是根，PRD正是枝叶而已。
附一个MRD目录吧，仅供参考，千万别照搬。
1、文档介绍
1.1文档目的
1.2内容概要
2、市场问题和机会
2.1本章摘要
2.2市场问题
2.3市场机会
2.4产品问题和机会
2.5技术问题和机会
3、市场概述
3.1本章摘要
3.2目标市场描述
3.2.1目标市场特征
3.2.2目标市场趋势
3.2.3目标市场细分
3.2.4目标市场时间约束
4、客户和购买者
4.1本章摘要
4.2目标客户描述
4.2.1目标客户细分
4.2.2客户动机
4.2.3影响因素
4.2.4客户目标
4.3目标购买者描述
4.3.1业务决策购买者
4.3.2技术决策购买者
5、使用者和用户原型
5.1本章摘要
5.2原型特征
5.3现实需要
5.4原型联系
6、市场需求
6.1本章摘要
6.2功能分类
6.3开发环境说明
6.4兼容性说明
6.5性能说明
6.6国际性说明
6.7文档说明
6.8外观说明
6.9发布说明
6.10支持和培训说明
6.11其它说明
6.12方案概述
6.13技术概述
6.14市场需求概要表
7、支持信息
7.1本章摘要
7.2文档假设
7.3参考资料
7.4产品体系
MRD-“市场需求文档”，是产品经理或者产品市场经理编写的一个产品的说明需求的文档。
这些文档用于计划一个新产品或修正一个已有的产品，是被工程师团队开发产品时使用。
在硅谷的一些软件公司，MRD仅仅覆盖high-level的功能。
在这种情况下，产品经理通过创建了另一个文档-通常指的是PRD（产品需求文档）来定义更加详细的产品需求。
在本文中，我用术语“MRD”泛指所有那些由产品管理和/或产品市场团队创建的，为工程师团队传达产品需求为目的的文档。
写好MRD的10种技巧（第一部分）
1、从用户角度的编写
从用户角度编写需求内容。
使用“用例（UseCase）”和“用户角色（UserPersonas）”来达到这个。
考虑用以下两种方法来详细说明你们公司正在开发的SFA（salesforceautomation）软件的“Login”的功能性。
方法A：
用户通过一个要求用户提供证书的登陆界面，
升级会员 