BRD、MRD、PRD

=============================

看了一下回答，忍不住牢骚两句，我想楼主更纠结的，是BRD和MRD的区别，我分情景说明：
1.用于产品和技术的沟通时
这是最常见的情景，通常需要提供一份可以参考的PRD。当然
—默契度高的小团队，可以使用口头，wiki，N次贴等等记录，这种方式多见于小团队；
—偏向敏捷或增量式的团队，可以只使用Axure类的工具，在国内也不少见；
—按照职能划分组织结构的互联网公司，由于是跨部门沟通，需要要求详尽的PRD+Axure原型；
—跨部门协作默契度弱、项目外包、沟通严谨的企业文化中，这些需要不仅是详尽的文档和原型，还要求规格型号，甚至具体到了用例，当然，这种一般在系统集成或者软件开发领域，互联网应用不多。
2.用于跟领导汇报做什么和为什么时
BRD是很好的选择，通过BRD，需要解决战略层的问题：我们这个网站、产品的目标是什么？我们的用户有什么样的需求？以及扩展开来，结合SWOT，确认我们的竞争优势，并说明相应的预期收益和风险，让领导拍板。写BRD的人要么是产品总监、要么是产品线经理、最起码也要是能够对产品负责的“产品市场经理”，而不是只管设计的“产品经理”，因为那不是产品经理。
BRD需要符合公司的大战略，同时帮助领导顺利的作出决策，并能够指导运营、产品的规划。如果不能做到这几点，那BRD就是流于形式的东西， 没什么意义。
3.关于MRD
说实话，我不认为MRD能与BRD和PRD相提并论。或者说，就像苏杰提到的，这完全是可以和BRD合并的，辅助决策的东西。但是，跳出互联网，在传统行业中，产品的更新和革命没有互联网如此迅速，像可口可乐，卖了100年口味依旧，在比如保洁，化工用品说实话，功效与其他品牌不见得有多大差异。这些竞争更多的是市场的竞争。这些行业的市场经理具有极大的责任和权利，他们更关注区域市场的变化和用户消费行为的研究，而MRD正式基于这种对变化和趋势的理解，产出的“告诉领导我们应该如何改进产品和市场营销方式，才能够获取更多利润；以及告诉干事的人为什么我们要如此改进”。回到互联网行业，我们虽然也关注市场、关注用户的兴趣和行为，但是我们更关注创新、细分领域的机会、以及基于用户研究和数据挖掘的新的需求点，这些也正是BRD中需要告诉老板的。

欢迎与同行进一步交流： http://www.hanjunxing.com


=============================

BRD是想法，MRD是提案，PRD是实现，我也写过类似文章 http://www.54xiaomeng.com/?p=870

=============================

作者：张鹏涛TAO
链接：http://www.zhihu.com/question/19655491/answer/49122402
来源：知乎
著作权归作者所有，转载请联系作者获得授权。

BRD 商业需求文档 Business Requirement Document
MRD 市场需求文档 Market Requirement Document
PRD 产品需求文档 Product Requirement Document

好了，最好的记忆就一个单词 Business商业、Market市场、Product产品；那么这三个是什么关系呢？BRD是产品的head、MRD是产品的body、PRD是产品的Heart，有了Head、Body、Heart这就是一个完整的产品了！


一、BRD是针对谁看的呢？一般都是针对老版或CEO或者项目总负责人，那么他们需要了解的是什么呢？

1、要做什么样的产品；
这就包含了项目定义，描述项目并且让老版感觉到产品的竞争优势。

2、需要什么样的资源
要什么资源就必须知道产品的市场位置，通过多少人、多长时间、多少Money、多少关系等等能够实现这样的市场位置，并且还需要有利且有力的商业说明，需要有一定的高度！

3、最终做成什么样；
要怎么做或者说怎么安排，老板们很少关心，更多的是关心产品的结果展示及盈利，这个产品能带来什么样的收入情况；

最终BRD就浓缩为 商业模式、盈利模式、资源投入、市场优势等；哦！对了！还有重要的一点就是“战略壁垒”，为什么呢？这一点主要是针对被Copy和产品包括来做的，这一点或许决定着整个产品的成败，但是如果说有些公司有特殊的资源那就另一码事！


二、MRD是针对谁看的呢？一般都是商务、运营、市场人员，那么他们需要了解的是什么呢？整个文档对于他们的重要性？

1、我们要找什么样的客户，进行资源合作
一般公司资源合作的都是商务和市场人员，或者加上运营人员，那么他们是资源拓展者，对于产品保驾护航，正如船要出海，就必须有在海里或者有水的地方，海的大小决定了船的大小，所以他们就是船的载体，不可能产品开发完介入吧？要是真是这样，那就当这里我没有说！商务、市场及运营人员在产品之前必须对于产品进行资源拓展，且快速评估产品的实现情况，MRD就是给他们一个清楚的方向，我该找什么样的客户，在这里或许有的朋友就问题了?n你没有产品这些人员不可能空说吧，看到客户该怎们沟通，这一块就是项目与运营之间一种Demo沟通了，在这里暂时不说了！

2、找到客户后，我们该怎么和他们说
上面说了MRD指引着商务、市场和运营往前走，那么找到客户该怎么和他们说呢？除了文档描述一个清晰的蓝图，或者说从红海中挖出新的路子，这里边就是MRD中的业务模式了，通过业务模式，可以看到清晰的产品，且客户可以看到他们在中间的位置，甚至说他们怎么赢利；一般给客户看到的都是PPT+Demo的方式，这样对于客户更直观更易于理解，所以MRD的文档就是给团队和客户一个说明；

3、产品针对什么样的用户群体
商务是资源拓展的关键、市场是产品保障的关键、则运营就是产品的推手，那么市场和运营就需要了解产品是针对什么用户群体的，毕竟最终的是使用人群是用户，MRD基本需要明确产品的用户人群，这样市场才能更好的进行分析，通过分析这个人群，给运营提供很好的参考资料，这样运营在推广这部分人群的时候也能够制定出很好的方案，资源优化及减少资源消耗，这就是MRD对于商务、市场、运营的关键作用；

最终MRD就浓缩为产品模式、业务模式、运营模式、市场模式等，明确客户及市场方向！


三、PRD是针对谁看的呢？一般都是项目组、开发组、测试组、策划组、体验组人员；

1、产品具体是什么样的呢？
对于与产品相关的人员，就必须有一个清楚的产品概念，这个产品到底是干嘛的？插句话说，公司对于人员有一个硬管理文化，这就是公司的管理制度，而产品则是公司的软文化，让每一个参与产品的人都有一个“产品梦”，变成一群有产品信仰的人，无形中就会增加团队的战斗力。话扯回来了！要了解到底是什么产品，那就需要详细而简单的进行说明，但是这个只能是描述，还需要有与策划、开发、测试等另一种沟通语言，那就是UI、UE、原型图、流程图等，这样方便策划及开发人员的工作进展!

2、我们该怎么实现呢？
该怎么实现，那就是规划了，包括时间、人力、资源等，什么时间完成什么事了！在前进的路上设立一些里程碑！这就对于产品经理来说就是一个挑战了？为什么呢？因为产品经理与商务、市场、运营沟通的方式和开发人员方式不一样，有什么不一样呢？商务、市场、运营更多的是发散型思维，而开发则更多是紧密型思维，对于开发人员的沟通则不能用“基本”“差不多”“还好”等这样的词来进行沟通，否则开发人员会开始发散，如果发散的和你一致的话，你就烧高香吧，如果不一致，对于程序来说推导再来，就不是那么容易的了！甚至出现了大量的BUG，有时候过多的BUG会让一个产品死掉！
所以就需要有详细的功能说明，细化到什么程度了，用YN原则来说明，VISIO是甚好的工具，不能出现模凌两可的语句，甚至需要通过语句进行if else描述，对了还有default，这个很关键，当程序运行正确了那固然好，如果程序出现BUG，则你不能让程序没有出口吧，那就是default了，给程序的BUG找一个合理的理由！

3、什么样的产品才能投入到市场？
产品开发人员更多的是站在产品角度思考问题，以实现产品而完成产品，那么产品最终开发完后，是不是能够满足运营需求呢？这时候产品经理就需要进行产品审核！怎么审核呢？简单的依据于之前的详细功能说明来进行需求审核，但是需求审核只是测试走完了第一步，第二步就是黑盒、白盒、甚至灰盒测试，走完第二部还有第三步，那就是需求优化，怎么优化呢，依据于市场人员及运营人员提供的用户数据来进行，再让产品设计人员进行UI优化，立足站在用户的角度；第三步完成了，就是最终的步骤了，体验师就起了关键性的作用，AB原则就出来了，将产品上线，体验师们就开始采集用户信息进行分析了，这个阶段对于产品的整个战略规划很关键，因为用户对于产品的第一感觉非常重要，如果是互联网产品则你可以换个网站，反正用户没法删除你的网站，但是对于移动互联网的产品APP来说，就是一个挑战了，看着不顺眼就直接给删除了，你说你的产品还有第二次机会进入用户的手机吗？除非你搞特殊！

PRD最终浓缩下就是产品界面、产品流程、功能需求、测试需求、体验需求等，保证产品有效率有节奏的进行！关系到整个产品的发展方向！

=============================

BRD是在讨论现在做什么比较好，决定下来要不要做；
MRD是现在市场上很多人都做它，我们要做出什么不同；
PRD是既然决定做它了，应该做成什么样子。

=============================

1、我是谁（BRD），说清楚产品的战略层面；
2、我从哪里来（MRD），说清楚产品的市场情况，战术怎么打；
3、我到哪里去（PRD），细化产品应该怎么做。

=============================

brd［商业需求文档］是给老板看的，用在产品规划阶段，产物主要是一个ppt和一些草图或者线框图（不要求太详细）。主要是把自己的想法说给老板听（或者需求方）。

mrd［市场需求文档］是在产品评审前要做的工作，主要是在产品设计前，做好用于给开发，运营，测试等部门一起审核产品方案使用。这个产物包括组织信息图，产品结构图，原型，或文档本身。

prd［产品需求文档］这是用于存档，要求详细！是在设计的最后一个阶段做的，即你的组织信息图－》产品结构图—》原型都已经完备！在写，有时候也会整个项目完成以后在些，主要是存档！

ps：不要听人说产品需要文档写在原型里也可以之类的，文档内容是可以写在原型里，但那不是产品需求文档！文档必然是以文档格式为载体的！只是说为了高效率的工作，大家不写这个产品需求文档罢了！把产品需求文档的作用通过原型＋备注说明清楚，即ok！

=============================

产品设计体会（3009）PD的几种文档

今天看到一篇讲述产品设计中几种文档的文章（一个老外的blog，Michael on Product Management & Marketing），感觉很好，结合工作的实际整理一下。按照那篇文章的思路，从产品的抽象到具体主要产出的文档有BRD、MRD、PRD和FSD。

BRD：Business Requirements Document，商业需求文档。这是产品生命周期中最早的问的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，通常是和老大们过的ppt，所以也就比较短小精炼，没有产品细节。

MRD：Market Requirements Document，市场需求文档。获得老大的认同后，产品进入实施，需要先出MRD，具体来说要有更细致的市场与竞争对手分析，通过哪些功能来实现商业目的，功能/非功能需求分哪几块，功能的优先级等等。实际工作中，这个阶段PD可能的产出物有Mind Manager的思维图，Excel的Feature List等。

（iamsujie补：我们的模式下，上两种文档会合并成为BRD，参见“4004：资源战争与BRD”）

PRD：Product Requirements Document，产品需求文档。进步一细化，这部分是PD写得最多的内容，也就是传统意义上的需求分析，我们这里主要指UC（use case）文档。主要内容有，功能使用的具体描述（参见下一篇：UC写作），Visio做的功能点业务流程，界面的说明，demo等。Demo方面，可能用dreamweaver、ps甚至画图板简单画一下，有时候也会有UI/UE支持，出高保真的demo，开发将来可以直接用的那种。

FSD：Functional Specifications Document，功能详细说明。有一点像“概要设计”，这步就开始往开发衔接了，产品UI、业务逻辑的细节都要确定，细化文档并保持更新。相应的，有很多内容，比如表结构设计，要由架构师来编写了。

再往后，就到“详细设计”和编码了，就此打住。

=============================