产品经理三大文档

商业需求文档

Business Requirement Document
BRD和MRDPRD一起被认为是从市场到产品需要建立的文档规范。
产品生命周期中最早的文档,再早就应该是脑中的构思了,其内容涉及市场分析,销售策略,盈利预测等,通常是供决策层们讨论的演示文档,一般比较短小精炼,没有产品细节。是基于商业目标或价值所描述的产品需求内容文档(报告),其核心的用途就是用于产品在投入研发之前,由企业高层作为决策评估的重要依据。
BRD与PRD的差异
BRD不同于常见的MRD和PRD,既然是用于产品实施之前的决策评估依据,必然对其文档(报告)的内容和格式要求够直观、精炼,要点突出。作为报告的撰写者,你必须让高层明白,你的报告中将展现出怎样的商业价值,如何用有力的论据来说服企业对你这个项目的认可,并为之慷慨的投入研发资源及市场费用。如果说PRD的好坏,直接决定了项目的质量水平,那么BRD的作用,就是决定了你的项目的商业价值。优秀的BRD文档,可以让决策层充分被你的报告观点所吸引,或许财务主管会因为报告呈现的低投入高产出的经济效益预测而蠢蠢欲动;或许技术主管会因为项目的牵涉面广泛而头疼不已;又或许公司的VP之流因之报告而看到了未来一年业绩的飞速发展的广阔前景……
说白了,BRD需要产品经理产品设计师)像对待PRD一样,充分应用市场调查、用户研究、需求分析等各种设计手段来充分阐述报告的内容。基于这样的状况,显然不是给大家一份完整的BRD标准格式规范,就能够搞定一切的!哈,也许有人会说这有点危言耸听,不过我一向赞成,面对一切“产品”,都应该用设计的眼光看待它。

市场需求文档

Market Requirement Document
该文档在产品项目过程中属于“过程性”文档。

1文档作用

该文档是产品项目由“准备”阶段进入到“实施”阶段的第一文档,其作用就是“对年度产品中规划的某个产品进行市场层面的说明”,这个文档的质量好坏直接影响到产品项目的开展,并直接影响到公司产品战略意图的实现。

2文档意义

该文档在产品项目中是一个“承上启下”的作用,“向上”是对不断积累的市场数据的一种整合和记录,“向下”是对后续工作的方向说明和工作指导。

3文档撰写

撰写MRD,大致下几个方面(按先后顺序)着手:
1、项目背景;
2、名词解释;
3、可行性分析(前期调研信息和数据+项目预期目标);
4、综合描述(功能概述+对其他产品的影响);
5、功能详述(功能需求+功能点);
6、其他问题描述。

4文档核心

该文档中,侧重的是对产品所在市场、客户(client)、购买者(buyer)、用户(user)以及市场需求进行定义,并通过原型的形式加以形象化

5错误认识

1)根本没有MRD的思想,许多企业把产品经理归为技术端,因此,在现实中,许多产品经理的产品文档只是侧重于功能描述,而对基础性的市场缺乏足够认识和记录;
2)把MRD和PRD混为一谈,MRD是PRD的基础,PRD是MRD在产品功能上的具体化。
3)照搬国外的MRD模板,来源于何处,不知道,将去向何处,也不知道,无头无尾,一个被割裂的文档。

产品需求文档

产品需求文档(Product Requirement Document,PRD)的英文简称。
是将商业需求文档(BRD)和市场需求文档MRD)用更加专业的语言进行描述。
 
文档意义
该文档在产品项目中是一个“承上启下”的作用,“向上”是对MRD内容的继承和发展,“向下”是要把MRD中的内容技术化,向研发部门说明产品的功能和性能指标。

文档撰写

在该文档中,基点依然是MRD中的内容,只是把重心放在了“产品需求”上,而产品需求本身是在MRD中有所体现的,区别就是在于,PRD要把MRD中的“产品需求”的内容独立出来加以详细的说明。
这部分是PRD写得最多的内容,也就是传统意义上的需求分析,我们这里主要指UC(use case)文档。主要内容有,功能使用的具体描述(每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程等几大块),Visio做的功能点业务流程,界面的说明,demo等。Demo方面,可能用dreamweaver、ps甚至画图板简单画一下,有时候也会有UI/UE支持,出高保真的demo,开发将来可以直接用的那种。
文档核心:
该文档中,侧重的是对产品产品功能和性能(即“产品需求”)的说明,相对于MRD中的同样内容,要更加详细,并进行量化。
在一些国外的公司,是允许把MRD和PRD合并成一个文档的,通常叫做“Marketing & Product Requirements Document”。
该文档一般可以包括以下内容:
该产品的远景目标(vision)
目标市场和客户(target market and customers)的描述
竞争对手分析(competitive summary)
对产品主要feature的比较详细的描述
这些feature的优先级
初步拟定的实现进度安排。
用例(use cases),这可以是较粗略的大致描述,未必一定要UML Use Case图。
产品的软硬件需求
产品的性能要求
销售方式上的思路、需求(直销还是渠道?直销怎么做?渠道怎么做?)
技术支持方式上的思路、需求(提供什么样的技术服务?)
开发工具推荐 :
Rational Rose★★★★--熟悉项目发生的相关业务行为。
visio 2007★★★★--将业务,从产品层面肢解开来,做到抽丝剥茧部分与整体统一
mind manager★★★--把项目条目化,条理化,目录结构具体规定好。
Axure★★★--前台结构布局,合理规范的将系统脱去朦胧的华纱。
Word★★★★★--穿针织网,把需求综合起来,整理成最终的产品需求文档。

错误认识

1)PRD无原始数据(MRD为体现载体)支持,只是个人经验、部门要求或者领导指示进行撰写。
2)在PRD中,只重视“产品功能”的描述,而缺乏对产品其它指标项的说明。在一个完整的PRD中,一共需要对产品的10个产品需求项指标进行说明,分别是“功能要求、开发要求、兼容性要求、性能要求、扩展要求、产品文档要求、产品外观要求、产品发布要求、产品支持和培训要求、产品其它要求”。
3)照搬国外的PRD模板,来源于何处,不知道,将去向何处,也不知道,无头无尾,一个被割裂的文档。
更多内容关注微信公众号:
--------------------------------------------------------------------------------------------------------------------------------------------------------
原文地址:https://www.cnblogs.com/helloy-Net/p/9284256.html