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中需要告诉老板的。

欢迎与同行进一步交流:hanjunxing.com


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

BRD是想法,MRD是提案,PRD是实现,我也写过类似文章54xiaomeng.com/?

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

作者:张鹏涛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、业务逻辑的细节都要确定,细化文档并保持更新。相应的,有很多内容,比如表结构设计,要由架构师来编写了。

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




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



阅读更多
换一批

没有更多推荐了,返回首页