BRD、MRD 、PRD文档归纳比较

    BRD、MRD、PRD是从商业规划到市场运营,再到产品构思的过程中,需要建立的由宏观到具体逐渐成型的指导战略。在产品开发的过程中,BRD、MRD、PRD所面对的目标用户以及使用价值是不一样的,即便他们统一的功能都是为了将产品说清楚,但在实际应用中这三个文档所包含的内容以及撰写方式都有很大区别。

      BRD (商业需求文档) Business Requirement Document

      MRD (市场需求文档) Market Requirement Document

      PRD (产品需求文档) Product Requirement Document


BRD是针对谁看的呢?

        一般都是针对老板或CEO或者项目总负责人,那么他们需要了解的是什么呢?

1、要做什么样的产品;

        这就包含了项目定义,描述项目并且让老版感觉到产品的竞争优势;

2、需要什么样的资源

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

3、最终做成什么样

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

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


二、MRD是针对谁看的呢?

        一般都是商务、运营、市场人员,他们需要了解的是什么呢?整个文档对于他们的重要性?

1、我们要找什么样的客户,进行资源合作

        一般公司资源合作的都是商务和市场人员,或者加上运营人员,那么他们是资源拓展者,对于产品保驾护航,正如船要出海,就必须有在海里或者有水的地方,海的大小决定了船的大小,所以他们就是船的载体,不可能产品开发完介入吧?要是真是这样,那就当这里我没有说!

        商务、市场及运营人员在产品之前必须对于产品进行资源拓展,且快速评估产品的实现情况,MRD就是给他们一个清楚的方向,我该找什么样的客户,在这里或许有的朋友就问题了?你没有产品这些人员不可能空说吧,看到客户该怎们沟通,这一块就是项目与运营之间一种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:给单个职能单位看,沟通非常具体的实施方案。



来源:知乎

你可能感兴趣的:(BRD、MRD 、PRD文档归纳比较)