<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>后时代&#187; MRD</title>
	<atom:link href="http://www.houshidai.com/tag/mrd/feed" rel="self" type="application/rss+xml" />
	<link>http://www.houshidai.com</link>
	<description></description>
	<lastBuildDate>Fri, 11 Oct 2019 03:37:37 +0000</lastBuildDate>
	<language>zh-CN</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.4.1</generator>
		<item>
		<title>产品经理文档必修课</title>
		<link>http://www.houshidai.com/product/pm-requirement-document.html</link>
		<comments>http://www.houshidai.com/product/pm-requirement-document.html#comments</comments>
		<pubDate>Wed, 09 Jan 2013 14:00:14 +0000</pubDate>
		<dc:creator>RUI</dc:creator>
				<category><![CDATA[产品]]></category>
		<category><![CDATA[BRD]]></category>
		<category><![CDATA[MRD]]></category>
		<category><![CDATA[PRD]]></category>
		<category><![CDATA[产品经理]]></category>
		<category><![CDATA[市场]]></category>
		<category><![CDATA[需求文档]]></category>

		<guid isPermaLink="false">http://houshidai.com/?p=6840</guid>
		<description><![CDATA[BRD和MRD，PRD一起被认为是从市场到产品需要建立的文档规范。 BRD：Business Requirem [...]]]></description>
			<content:encoded><![CDATA[<p><span class='wp_keywordlink_affiliate'><a href="http://www.houshidai.com/tag/brd" title="查看 BRD 中的全部文章" target="_blank">BRD</a></span>和<span class='wp_keywordlink_affiliate'><a href="http://www.houshidai.com/tag/mrd" title="查看 MRD 中的全部文章" target="_blank">MRD</a></span>，<span class='wp_keywordlink_affiliate'><a href="http://www.houshidai.com/tag/prd" title="查看 PRD 中的全部文章" target="_blank">PRD</a></span>一起被认为是从<span class='wp_keywordlink_affiliate'><a href="http://www.houshidai.com/tag/agora" title="查看 市场 中的全部文章" target="_blank">市场</a></span>到<span class='wp_keywordlink_affiliate'><a href="http://www.houshidai.com/tag/produce" title="查看 产品 中的全部文章" target="_blank">产品</a></span>需要建立的文档规范。</p>
<p><img class="alignnone size-full wp-image-6841" title="PM-document" src="http://www.houshidai.com/wp-content/uploads/2013/01/PM-document.jpg" alt="" width="600" height="220" /></p>
<p><span id="more-6840"></span></p>
<p><span class='wp_keywordlink_affiliate'><a href="http://www.houshidai.com/tag/brd" title="查看 BRD 中的全部文章" target="_blank">BRD</a></span>：Business Requirements Document，商业<span class='wp_keywordlink_affiliate'><a href="http://www.houshidai.com/tag/requirement-document" title="查看 需求文档 中的全部文章" target="_blank">需求文档</a></span>。</p>
<p><span class='wp_keywordlink_affiliate'><a href="http://www.houshidai.com/tag/brd" title="查看 BRD 中的全部文章" target="_blank">BRD</a></span>指的就是基于商业目标或价值所描述的<span class='wp_keywordlink_affiliate'><a href="http://www.houshidai.com/tag/produce" title="查看 产品 中的全部文章" target="_blank">产品</a></span>需求内容文档（报告），其核心的用途就是用于产品在投入研发之前，由企业高层作为决策评估的重要依据。BRD是产品生命周期中最早的文档，再早就应该是脑中的构思了，其内容涉及<span class='wp_keywordlink_affiliate'><a href="http://www.houshidai.com/tag/agora" title="查看 市场 中的全部文章" target="_blank">市场</a></span>分析，销售策略，盈利预测等，通常是供决策层们讨论的演示文档，一般比较短小精炼，没有产品细节。</p>
<p>好的BRD应有的特点：商业价值、资源评估、风险和对策三大块是一个BRD最重要的三部分。好的BRD应当有煽动性、导向性。在写BRD时应当充分考虑阅读人（通常是老板）的出身背景、知识结构及思考问题的一般方法，考虑到他在看了BRD后会有什么反应，他是怎样考虑的，而不是仅仅是将要表达的结果做一个简单的信息传递，应当做到未雨绸缪。通常要做到这种程度，需要很深刻的了解公司的高端愿望，在企业里做到信息对称，高端愿望解码正确。当然，如果写BRD的人在公司对老板的影响力非常大，也会对BRD增色不少。</p>
<p>BRD文档通常包括：项目背景、商业价值、功能需求描述、非功能需求描述、资源评估、风险和对策。</p>
<p>项目背景：我们在哪里？为什么要做这个项目？解决什么问题？可以列出一些数据说明项目的必要性。<br />
商业价值：我们去哪里？最关键的重点！做了这个项目以后有什么价值？一般我们还会预测一下相关数字的变化，提出这个项目的商业目标。<br />
功能需求描述：我们怎么去？通过做哪些事情来达到目标，把打包好的需求描述一下，可以用功能列表的形式表达，但最好能画出业务逻辑关系。当然我们也经常会高点技巧性的东西，比如要砍掉的需求，俗称李代桃僵。<br />
非功能需求描述：提一下重要的非功能需求。<br />
资源评估：达成项目的目标需要多大的花费。<br />
风险和对策：项目中可能存在的风险及应对策略。</p>
<p>BRD技巧：通过一系列的市场分析或调查，掌握到了一个潜在的、未被满足的大量用户需求，而这些需求背后将映射着一个广阔的市场空间。说明这个项目很有价值（社会价值——造福全人类？；商业价值——未来的赢收主体？；用户价值——引领用户潮流？比如说Iphone；市场价值——也许明年我们的市场份额就会扩大一倍；投资价值——我们将全面进入一个新兴的领域）。写BRD，不应该站在自已的角度来写这份报告，充分了解决策层，也就充分把握到了报告编写的要点。站在评审方的角度来写报告，你的报告成功的可能性就已经占了很大一部分了。</p>
<p>BRD实例：</p>
<p>让我们假设你的公司正在开发一个用户关系管理系统（CRM）。这个系统是协助其他公司的销售经理如何跟进产品销售过程，并分析得出关于销售的靠谱的预期的。那在这种情况下我们的BRD应该怎写呢：</p>
<p>A. 谁会面对这些问题？——世界五百强的销售经理。</p>
<p>B. 他们面对的时什么问题？——1.无法实时的查看交易进行状态；2.无法分析出一个可信赖的销售预期。</p>
<p>C. 建议的解决方案是什么？——创建一个基于页面的系统，能够查看实时交易进行状态，并分析出一个可信赖的销售预期。</p>
<p>BRD与<span class='wp_keywordlink_affiliate'><a href="http://www.houshidai.com/tag/prd" title="查看 PRD 中的全部文章" target="_blank">PRD</a></span>的差异</p>
<p>BRD不同于常见的<span class='wp_keywordlink_affiliate'><a href="http://www.houshidai.com/tag/mrd" title="查看 MRD 中的全部文章" target="_blank">MRD</a></span>（Market Requirement Document-市场<span class='wp_keywordlink_affiliate'><a href="http://www.houshidai.com/tag/requirement-document" title="查看 需求文档 中的全部文章" target="_blank">需求文档</a></span>）和PRD（Product Requirement Document-产品需求文档），既然是用于产品实施之前的决策评估依据，必然对其文档（报告）的内容和格式要求够直观、精炼，要点突出。作为报告的撰写者，你必须让高层明白，你的报告中将展现出怎样的商业价值，如何用有力的论据来说服企业对你这个项目的认可，并为之慷慨的投入研发资源及市场费用。如果说PRD的好坏，直接决定了项目的质量水平，那么BRD的作用，就是决定了你的项目的商业价值。优秀的BRD文档，可以让决策层充分被你的报告观点所吸引，或许财务主管会因为报告呈现的低投入高产出的经济效益预测而蠢蠢欲动；或许技术主管会因为项目的牵涉面广泛而头疼不已；又或许公司的VP之流因之报告而看到了未来一年业绩的飞速发展的广阔前景。</p>
<p>说白了，BRD需要<span class='wp_keywordlink_affiliate'><a href="http://www.houshidai.com/tag/pm" title="查看 产品经理 中的全部文章" target="_blank">产品经理</a></span>（产品设计师）像对待PRD一样，充分应用市场调查、用户研究、需求分析等各种设计手段来充分阐述报告的内容。基于这样的状况，显然不是给大家一份完整的BRD标准格式规范，就能够搞定一切的！哈，也许有人会说这有点危言耸听，不过我一向赞成，面对一切“产品”，都应该用设计的眼光看待它。你应该把决策层当作你的产品——BRD的受众群体，一切从这里开始。</p>
<p><span class='wp_keywordlink_affiliate'><a href="http://www.houshidai.com/tag/mrd" title="查看 MRD 中的全部文章" target="_blank">MRD</a></span>：Market Requirements Document，市场需求文档。该文档在产品项目过程中属于“过程性”文档。</p>
<p>该文档是产品项目由“准备”阶段进入到“实施”阶段的第一文档，其作用就是“对产品进行市场层面的说明”，这个文档的质量好坏直接影响到产品项目的开展，并直接影响到公司产品战略意图的实现。该文档在产品项目中是一个“承上启下”的作用，“向上”是对不断积累的市场数据的一种整合和记录，“向下”是对后续工作的方向说明和工作指导。</p>
<p>MRD要有更细致的市场与竞争对手分析，通过哪些功能来实现商业目的，功能/非功能需求分哪几块，功能的优先级等等。实际工作中，这个阶段PD可能的产出物有Mind Manager的思维图，Excel的Feature List等。</p>
<p>MRD就是对产品所在市场数据的整合，说白了，就是对市场分析后的结论体现，在这个文档中，需要体现的主要内容包括：</p>
<p>1、市场的问题和机会</p>
<p>在这个主题中，主要是要求产品管理者说明自己负责的产品现在所处的市场都有什么问题和机会、面对这个现实的市场，产品有什么问题和机会，以及产品所需技术面临的问题和机会。其实就是要求从市场层面、产品层面、技术层面来阐述问题和机会。</p>
<p>2、市场特征</p>
<p>在这个主题中，主要是要求产品管理者说明目标市场的现状和趋势。应该包括的信息有：目标市场特征、目标市场趋势、目标市场细分、目标市场时间约束。</p>
<p>3、用户特征</p>
<p>这里的用户是个广义的概念，它其实包括两个方面的信息：1、客户（customer）；2；购买者（buyer）。在这个主题中，主要是要说明这产品的目标用户的特征、细分、动机、影响因素以及用户期望（目标）。</p>
<p>4、使用者特征</p>
<p>之所以把这个主题独立出来，就是因为，无论什么产品，最终是要由具体的人来介入的，这类人才是产品的最终享受者，具体到产品上，其实我们日常分析的产品需求和功能都是基于他们考虑的。在这个主题中，要说明这类用户的特征、现实需要和相关联系。</p>
<p>5、市场的需求</p>
<p>就是把市场需求按类别描述出来即可，具体的标准，大家应该很清楚的，就是“描述性的语言来说明用户的期望”，主要包括的内容有：功能分类、开发环境说明、兼容性说明、性能说明、国际性说明、文档说明、外观说明、发布说明、支持和培训说明、其它说明、方案概述、技术概述。建议大家加一个表格，就是“需求概要表”，这个表格的作用就是用列举的形式来把所有市场需求记录下来，毕竟上面的内容都是描述性的，这个表格有助于快速浏览。这个表格应该包括的内容有但不仅限于：实现目标、约束条件、需求联系、原型、类型、优先级。</p>
<p>MRD主要用处是定义市场需求，可能是针对一个新产品也可能是旧有产品的一个增强型的功能，BRD是对于商业问题和解决问题的方法的简要定义，而MRD则更加的细节，他可能包括以下几点：</p>
<p>a. 解决这个商业问题的功能需求；<br />
b. 市场和竞争对手分析；<br />
c. 功能与非功能需求；（所谓非功能需求包括性能要求等）<br />
d. 功能需求的优先级；<br />
e. 需求用例。</p>
<p>MRD实例：</p>
<p>紧接着上面那个CRM的例子继续，MRD会定义需求，对需求进行优先级排序，同时描述需求用例。需求主要包括功能需求和非功能需求两种：</p>
<p>A. 功能需求：</p>
<p>必须能够在IE（6.0版本以上）和FireFox（1.5版本以上）上工作；<br />
必须使用SSL协议保证通信能够被加密；<br />
用户能通过交互界面输入以下字段的内容：用户名称、公司名称、联系方式、机会说明、销售额度等等。<br />
…</p>
<p>B.非功能需求：</p>
<p>能够承担十万同时在线用户；<br />
系统稳定性达到99.9%；<br />
拥有英、德、日三种语言的用户使用说明。<br />
…</p>
<p>PRD：Product Requirements Document，产品需求文档。</p>
<p>PRD是将商业需求文档（BRD）和市场需求文档（MRD）用更加专业的语言进行描述。该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就是“对MRD中的内容进行指标化和技术化”，这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。该文档在产品项目中是一个“承上启下”的作用，“向上”是对MRD内容的继承和发展，“向下”是要把MRD中的内容技术化，向研发部门说明产品的功能和性能指标。</p>
<p>PRD文档，基点依然是MRD中的内容，只是把重心放在了“产品需求”上，而产品需求本身是在MRD中有所体现的，区别就是在于，PRD要把MRD中的“产品需求”的内容独立出来加以详细的说明。该文档中，侧重的是对产品产品功能和性能（即“产品需求”）的说明，相对于MRD中的同样内容，要更加详细，并进行量化。在一些国外的公司，是允许把MRD和PRD合并成一个文档的，通常叫做“Marketing &amp; Product Requirements Document”。</p>
<p>产品需求文档侧重于产品需求的具体阐述，是BRD的延伸。如果说BRD可以决定要不要做以及做什么的话，那么PRD就解决怎么做的问题。商业需求文档侧重性价比的描述，产品需求文档侧重产品功能规划及实施，即想方设法实现BRD中提到的价值并使之最大化。该文档的内容主要包括产品定位、目标人群界定、用于满足用户哪些核心需求或解决哪些问题、同行竞品分析、差异化竞争优势、推广运营策略、盈利模式分析以及详细的产品功能规划（如业务逻辑、权限分配、功能模块设置、参数规格等）、产品实施路线图、非功能性需求（如界面UI风格、安全性、易用性、兼容性、性能等需求）。通过该文档，读者对整个产品有个全面清晰的了解。</p>
<p>产品需求文档和产品战略文档（Product Strategy）、产品发展路线文档（Roadmap）的区别：产品战略描绘出2-5年产品的发展方向和蓝图而产品发展路线文档描绘出不同的阶段到达这个目标；产品需求文档则是在这个蓝图中某一个阶段的详细需求产品。</p>
<p>PRD写得最多的内容，也就是传统意义上的需求分析，我们这里主要指UC（use case）文档。主要内容有，功能使用的具体描述（每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程，等几大块），Visio做的功能点业务流程，界面的说明，demo等。Demo方面，可能用dreamweaver、ps甚至画图板简单画一下，有时候也会有UI/UE支持，出高保真的demo，开发将来可以直接用的那种。</p>
<p>PRD文档一般可以包括以下内容：</p>
<p>该产品的远景目标（vision）<br />
目标市场和客户（target market and customers）的描述<br />
竞争对手分析（competitive summary）<br />
对产品主要feature的比较详细的描述<br />
这些feature的优先级<br />
初步拟定的实现进度安排<br />
用例（use cases），这可以是较粗略的大致描述，未必一定要UML Use Case图。<br />
产品的软硬件需求<br />
产品的性能要求<br />
销售方式上的思路、需求（直销还是渠道？直销怎么做？渠道怎么做？）<br />
技术支持方式上的思路、需求（提供什么样的技术服务？）</p>
<p>在一个完整的PRD中，最好对产品的10个产品需求项指标进行说明，分别是“功能要求、开发要求、兼容性要求、性能要求、扩展要求、产品文档要求、产品外观要求、产品发布要求、产品支持和培训要求、产品其它要求”。</p>
<p>MRD往往从市场需求角度描述产品的需求，而PRD更加关注产品本身的需求，会详细描述各种特性与功能的细节，PRD中还常常包括用户界面和用户流程。如果一家公司的MRD不包括各种特性与功能的细节需求和用户需求用例的话，这些内容就会由PRD来描述。</p>
<p>PRD实例：</p>
<p>继续上面的CRM项目，在这个项目中PRD文档应该包括的内容是：</p>
<p>登录界面应包括用户名、密码字段，还应该有“忘记密码？”提示文字链；<br />
“联系我们”界面应该让用户可以输入姓名、电话、Email…<br />
“销售预测”界面在生成年度预测报告前，应该有5个步骤，每个步骤用户都会输入一些限定条件，每个步骤的详细说明如下：<br />
…</p>
<p>PRD文档除了上面描述的这些功能逻辑外，还应该包括一些详细的需求用例。</p>
<p>FSD：Functional Specifications Document，功能详细说明文档。</p>
<p>FSD这步就开始往开发衔接了，产品UI、业务逻辑的细节都要确定，细化文档并保持更新。功能详细说明文档从具体执行的角度定义产品的功能需求，FSD会对每一个界面和功能做出非常细节的定义说明，并能够直接交付技术人员进行开发。我们再来对比一下MRD、PRD还有FSD的不同，MRD是关注于市场需求的需求定义，PRD是关注于产品本身的需求定义，而FSD是关注于定义功能的细节设计，这个设计会以技术人员熟悉的格式撰写，并直接交付技术人员进行开发，FSD还包括确定的UI设计，界面各个部分细节都已经被确定。这篇文档通常由产品分析师、技术负责人或者项目经理来撰写，总之这个文档的作者一般都隶属于技术团队。这篇文档一般是无数页的word或者其他的文本文件格式文档。相应的，有很多内容，比如表结构设计，要由项目经理来编写了。</p>
<p><img class="alignnone size-full wp-image-6842" title="Requirement_Document" src="http://www.houshidai.com/wp-content/uploads/2013/01/Requirement_Document.gif" alt="" width="400" height="200" /></p>
]]></content:encoded>
			<wfw:commentRss>http://www.houshidai.com/product/pm-requirement-document.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
