[Product] 关于产品需求文档PRD

博客首页 » Product 关于产品需求文档PRD

发布于 26 May 2015 07:57
标签 blog
产品的设计和产品经理很火,总结一下关于产品需求文档PRD的信息。

整理:产品文档规范——BRD、PRD和MRD

BRD和MRD,PRD一起被认为是从市场到产品需要建立的文档规范。

BRD

商业需求文档——BRD(Business Requirements Document)
商业需求文档重点放在定义产品的商业需求,要说明产品能够解决的、客户碰到的一个或多个商业问题,然后提出建议解决方案——通常是用新产品或者改进现有的产品来解决这些问题。
BRD也可能包括一个高级的商业案例,例如收益预测、 市场&竞争分析、 销售/市场策略。
BRD通常是由产品经理,产品市场经理、商业分析师编写。在小公司,可能由高级主管或者甚至创始人撰写。
BRD通常是一份 1~3页 Word 文档,或者是不超过 10页的 PowerPoint 文档。

PRD

产品需求文档(Product Requirement Document,PRD)的英文简称。是将商业需求文档(BRD)和市场需求文档(MRD)用更加专业的语言进行描述。

文档作用
该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档,其作用就是“对MRD中的内容进行指标化和技术化”,这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。

文档意义
该文档在产品项目中是一个“承上启下”的作用,“向上”是对MRD内容的继承和发展,“向下”是要把MRD中的内容技术化,向研发部门说明产品的功能和性能指标。

文档撰写
在该文档中,基点依然是MRD中的内容,只是把重心放在了“产品需求”上,而产品需求本身实在MRD中有所体现的,区别就是在于,PRD要把MRD中的“产品需求”的内容独立出来加以详细的说明。

文档核心:
该文档中,侧重的是对产品产品功能和性能(即“产品需求”)的说明,相对于MRD中的同样内容,要更加详细,并进行量化。
在一些国外的公司,是允许把MRD和PRD合并成一个文档的,通常叫做“Marketing & Product Requirements Document”。

错误认识
1)PRD无原始数据(MRD为体现载体)支持,只是个人经验、部门要求或者领导指示进行撰写。
2)在PRD中,只重视“产品功能”的描述,而缺乏对产品其它指标项的说明。在一个完整的PRD中,一共需要对产品的10个产品需求项指标进行说明,分别是“功能要求、开发要求、兼容性要求、性能要求、扩展要求、产品文档要求、产品外观要求、产品发布要求、产品支持和培训要求、产品其它要求”。
3)照搬国外的PRD模板,来源于何处,不知道,将去向何处,也不知道,无头无尾,一个被割裂的文档。

MRD

Market Requirements Document,简称市场需求文档。
市场需求文档的主要功能是描述什么样的功能和特点的产品(包含产品版本)可以在市场上取得成功。产品进入实施,需要先出MRD,具体来说要有更细致的市场与竞争对手分析,通过哪些功能来实现商业目的,功能/非功能需求分哪几块,功能的优先级等等。实际工作中,这个阶段PD可能的产出物有Mind Manager的思维图,Excel的Feature List等。
产品市场经理(PMM,Product Marketing Manager)负责分析市场变化,通过对市场的分析,MRD指出什么样的新产品、方案和服务可以更好的开拓市场。
通常情况下,产品经理或者技术产品经理会将在MRD的基础上完成PRD(Product Requiremnets Document),技术团队应用PRD开发产品

区别

下面回答整理自知乎,来源于百度李明远,这个人有兴趣的自己搜索下,29岁,最年轻的百度副总裁。

问题很宽泛。从不同级别的产品来说:

非常细节的、已知的、已有产品改善类的功能,提供PRD级别的即可;
一般产品的新系统、较综合的新功能实现,提供MRD;
全新的产品、较为重要和未来发展较为复杂的产品,提供BRD。

即,你考虑写的需求文档是给什么范围的人看的、所描述的需求是个什么范围和级别的。
BRD你要给产品、运营、研发、管理层等很多人看,要讲清楚为什么有这个需求,需求的边界和业务目标,所需资源等;
MRD给产品、运营、研发等业务线上的人看,主要是大家已经一致认可需求是成立的,只是我们如何来实现、什么时间实现需求,实现了需求会获得什么结果;
PRD是给单个职能单位看,沟通非常具体的实施方案。
所以,产品经理要能写好MRD和BRD,你带的人要能写非常成功的PRD。这是一个层次的问题,先有BRD,决策是否要开始一个产品;再有BRD,决策如何开始一个产品;最后有PRD,决定要开始的产品具体是什么样的。

互联网产品设计常用文档类型BRD、MRD、PRD、FSD

http://thomas0104.iteye.com/blog/1894757

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

商业需求文档重点放在定义项目的商业需求。BRD要能说出客户碰到的一个或多个商业问题,并且通过公司的产品能够解决这些问题。接着建议一个方案 —— 通常是新产品或者现有产品的改进来解决这些问题。BRD也可能包括一个高级的商业案例,例如收益预测,市场竞争分析和销售/营销策略。BRD通常是由拥有产品经理,产品营销经理或者行业分析师头衔的人撰写的。在小公司,可能由高级主管或者甚至创始人撰写。BRD通常是一份连续的1-3页Word文档,或者不超过10页的Powerpoint文档。

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

市场需求文档(MRD)重点放在为一个被提议的新产品或者现有产品的改进定义市场需求。与BRD指出商业问题和解决这些问题的解决方案不同,MRD更深入提议解决方案的细节。它包括一些或者所有这些细节:

a. 解决商业问题所需要的特色
b. 市场竞争分析
c. 功能和非功能需求
d. 特色/需求的优先级
e. 用例

MRD通常是由拥有产品经理,产品营销经理或者行业分析师头衔的人撰写的。MRD通常是一份连续的5-25页Word文档,或者正如之后描述那样在一些机构中甚至更长。

PRD
Product Requirements Document,产品需求文档。进步一细化,这部分是PD写得最多的内容,也就是传统意义上的需求分析,我们这里主要指UC(use case)文档。主要内容有,功能使用的具体描述(每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程,等几大块),Visio做的功能点业务流程,界面的说明,demo等。Demo方面,可能用dreamweaver、ps甚至画图板简单画一下,有时候也会有UI/UE支持,出高保真的demo,开发将来可以直接用的那种。

产品需求文档(PRD)重点放在为一个被提议的新产品或者现有产品的改进定义市场需求。与MRD侧重于从市场需要角度看需求的不同,PRD侧重于从产品本身角度看待需求。通常在特点和功能需求上更深入细节,并也可能包括屏幕截图和用户界面流程。在那些MRD不包括具体需求和用例的机构中,PRD就包含这些具体内容。PRD通常是由拥有产品经理,行业分析师或者产品分析师头衔的人撰写的。PRD通常是一份连续的20-50页Word文档,或者针对复杂产品甚至更长。

提醒:一些机构将这里描述的MRD和PRD合并成一个文档,并称最后的文档为MRD。在这种情况下,MRD包括本段描述的内容,也包括上一段描述PRD的内容,并且可能超过50页。

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

功能规格文档(FSD)把焦点集中在实现,定义产品功能需求的全部细节。FSD可能通过一张张的截屏和一条条功能点来定义产品规格。这是一份可以直接让工程师创建产品的文档。与MRD和PRD侧重于以市场需要和产品角度看需求不同,FSD把重点放在了以表格形式定义产品细节,再让工程师实现这些细节。FSD也可能包括完整的屏幕截图和UI设计细节。FSD通常是由拥有产品分析师,工程领导或者项目经理头衔的人撰写的

PSD   
Product Specifications Document,产品规格文档(PSD)是一个较不流行的缩写,但是在有这样一个文档的机构中,它大体和上面描述的功能规格文档(FSD)相同。

SRS   
Software Requirements Specification,软件需求文档,软件需求文档(SRS)是另一较不流行的缩写,在创建SRS的机构中,它在内容和细节上和上面描述的PRD或FSD有些想像。

ROI   
Return On Investment,投资回报。原本是会计学概念,早期用来判定投资工厂或购买铁路相关的成本是否合理,现被广泛使用在各个领域。ROI的结果通常用百分比来表示,即投入产出比,简单来说就是企业所投入资金的回报程度。ROI计算公式为:收益/投资×100%或者ROI=(成本降低+收入增长)/总成本。相关的术语:资金回收期,IRR(内部收益率)等等。
  投资报酬率,计算公式为:ROI = (1 + g) * n / PER。
  其中,g代表企业未来n 年平均获利成长率。PER表示本益比。若个别企业的ROI大于同业平均投资报酬率,则该企业值得投资。

CPA
   Cost Per Action,次行动的费用,即根据每个访问者对网络广告所采取的行动收费的定价模式。对于用户行动有特别的定义,包括形成一次交易、获得一个注册用户、或者对网络广告的一次点击等。

ASP   
Average Selling Price,公司某一类型产品或全部产品的平均销售价格(或称出厂价格)。公式为:销售额÷出货量。
  平均售价是分析预测制造业公司销售收入和毛利率的重要指标,是投资者需要密切跟踪和计算的经营数据。在销量不变的情况下,平均售价提高可以增加销售收入和毛利率,在销量下降的情况下,如果公司能提高平均售价可以降低销售收入和毛利率下滑的程度,当然,最好的情况是价升量增,销量和售价都出现增长。公司产品平均售价提升主要来自于产品结构的改善,如彩电生产企业近年来产品平均售价增长就是因为高价格的平板电视销售比重显著提升。所以,把握制造业公司业绩增长的两项最重要的因素就是产品销量和平均售价的变化。

PRD from 百度百科词条

http://baike.baidu.com/link?url=3XQWmbV6WUOJ8YoMuLGuuVoWtyaICL0WHr_w-Nd5Clm4NqSjlxGSGlby0j7Dv9t6nzd3DgrM3ylMC8WPGe0zC_

该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档,其作用就是“对MRD中的内容进行指标化和技术化”,这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。

  • 中文名 产品需求文档
  • 外文名 Product Requirement Document
  • 英文简称 PRD

应用商业需求文档市场需求文档

产品需求文档

产品需求文档(Product Requirement Document,PRD)的英文简称。是将商业需求文档(BRD)和市场需求文档(MRD)用更加专业的语言进行描述。

文档意义

该文档在产品项目中是一个“承上启下”的作用,“向上”是对MRD内容的继承和发展,“向下”是要把MRD中的内容技术化,向研发部门说明产品的功能和性能指标。

文档撰写

在该文档中,基点依然是MRD中的内容,只是把重心放在了“产品需求”上,而产品需求本身是在MRD中有所体现的,区别就是在于,PRD要把MRD中的“产品需求”的内容独立出来加以详细的说明。

这部分是PRD写得最多的内容,也就是传统意义上的需求分析,我们这里主要指UC(use case)文档。

主要内容有,

  • 功能使用的具体描述(每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程等几大块),
  • 功能点业务流程(Visio)
  • 界面的说明(Visio)
  • demo(Visio)
  • 等等。

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模板,来源于何处,不知道,将去向何处,也不知道,无头无尾,一个被割裂的文档。

如何写PRD

http://www.douban.com/group/topic/14113188/

PRD是每个产品人员最经常看到的文档,还是有很多产品的朋友问我PRD怎么写,如何才能表达清楚意思。其实PRD并没有规定的格式,每个公司都可以根据自己公司的实际需要来写适合自己产品团队的PRD。

PRD(Product Requirement Document,产品需求文档),这对于任何一个产品经理来说都不会陌生的一个文档,一个PRD是衡量一个产品经理整体思维的标准,一个PRD可以看出一个产品经理在某个领域的专业性,同时也可以反应出一个产品经理的整体产品思维。

产品经理的整体思维体现在:
1、提炼核心需求
2、思考满足核心需求的方式
3、评估方式优劣选定方案
4、思考功能概要
5、思考支撑功能和关联功能
6、细化设计功能
7、子功能(功能间迭代)

PRD其实就是将以上的思维整体走向写出来,同时将产品的思想提炼出来,用文字表示给开发者,给UI、给视觉、给老板……PRD给的是一种思想,将产品的整体思想和核心需求灌输给产品的相关人员,都说PRD是个承上启下的功能,因为上接MRD,下对MRD进行技术性的描述。

网上已经有太多互联网公司的PRD文档,淘宝、百度、腾讯等这类大型互联网公司都有自己的PRD规范,适合企业的需要的PRD才是真正PRD。以淘宝的PRD为例,讲解一下PRD的主要内容。

1、文件命名(编号)
文件的编号很关键,因为产品迭代过程会有不同的文件版本,一般命名规则“公司名+产品名+PRD+D1.0”(以第一版为例),这样命名有利用版本号的迭代,如果是小的产品需求变动可以直接命名为“公司名-产品名-PRD-D1.01”,如果涉及到功能需求增加可以命名为“公司名-产品名-PRD-D1.1”,当出现产品第二版时,可以命名为“公司名-产品名-PRD-D2.0”。

2、修订控制页
一般有这么几项:编号、文档版本、修订章节、修订原因、修订日期、修改人。编号只是为了给个修改的顺序,文档版本显示的当前修改的内容是在哪个版本中出现,修订章节是具体到哪个章节哪个功能模块的修改,修订原因说明此功能修改的问题所在。修订日期以修改当日的日期为修订日期,修改人显示修改内容模块的人,可能是当前用户也可能是其它产品人员。

3、目录
不建议自己去添加一个新的目录,你可以去其它的文档中拷一个过来,不考虑目录的内容,等写完PRD可以再去更新。但建议用Mind manager来整理一下思路。

4、请与以下部门讨论PRD
PRD做为一个承接作用的“载体”,会与技术、运营、财务等人员的沟通,而与这些人员沟通的主题都将会出现在子功能或在细节细化的基本上,需要与相关人员确定“沟通内容”,这对于产品整体流程将是很重要的。同时对于产品核心功能的提取也是一个重要环节。产品经理很重要的一个职能就是沟通。例与客服中心:客服服务部,讨论的内容:预测客服成本、工作量;讨论客服如何支持;协助评估诈欺/数据窜改风险:欺诈/数据窜改风险、不正使用风险。这就是要写在与其它部门讨论PRD中的。一个产品经理需要考虑如何与其它部门之间的沟通合作,文档很大一部分的功能是提醒你要做的工作,同时不断补充将要面临的工作。

5、概述
概念就是总结,它包括的点有:名词说明、产品概述及目标、产品roadmap、产品风险。
名词说明:名称、说明。名称就是对文档中会出现的比较新的名称,说明则是对这些名称进行解释。
产品概述及目标:解释说明该产品是干什么的,为什么需要这样的产品。同时产品想要达到什么样的目标。产品概述及目标就是对产品核心功能讲解,同时希望可以达到的期望。
产品roadmap:产品分期目标,阶段描述,以及时间点的确定,产品是个不断演进的过程,很多时间一期产品只完成了产品70%的功能,二期才会继续去完善剩下的30%,同时有可能会推翻了重新推出第二版。产品roadmap并不及着全部规划好所有的阶段目标,而是更多的通过维护来保持产品的更新和迭代。
产品风险:描述产品可能存在的风险,比如商务谈判的风险,外部合作的风险,不当使用的风险等等。风险级别为高中低。

6、使用者需求
使用者需求一般只有个需求描述。需求描述有以下几项内容:目标客户、需求描述、场景描述、优先级。
目标客户即为产品的最终用户,确定产品的最终使用者。
需求描述是对目标客户的需求描述,表达用户最需要的是什么,找到用户的最根本需求。
场景描述,产品在哪种情况下会被用户使用,就是用户场景模拟。
优先级是指用户对于当前产品功能需求的优先级,哪些是用户最想要的功能优先级则排前。

7、可选方案
列出所有可以选择的达到该产品目标的方案要点(主要思路),给各方案适当的评价,并推荐最优方案。你在做这个产品规划时一定有很多的备选方案,别放弃这些方案,永远没有过时的idea,只有最适合时机的idea。所以可以写出几个可选方案,或许是你下期产品改版一个方向。

8、效益成本分析
产品经理是个全才,在这点上得到了体验。产品经理得知道财务知识。很大一部分是产品的环境搭建成本和支持人员的成本。一般的效益成本分析包括三个方面:效益预测、产品技术中心成本、非产品技术中心支持成本。
效益预测是指提供在各种产品环境中的效益预测,并标明主要的变量及假设,最好能包含现在和过去的效益数据。如网站的PV值,软件的使用数都是效益预测数据。
产品技术中心成本是指设计及部署此产品的产品技术中心所需的资源需求,包括人力成本,软硬件支出等。很大时候这份成本需要由项目经理来协助,需要有什么样的人才加入产品中需与人力协助。
非产品技术中心支持成本,产品不是只有产品组完成的,同样需要其它部门的配合与协助。比如:需要客服部投入多少的资源用于该产品的服务,需要运营部投入多少的资源运营该产品。

9、功能需求
功能需求一般是由四部分组成,功能总览、功能详情、整合需求、BETA测试需求。
功能总览一般包括二个部分,一个是流程图,一个是功能表。流程图是对产品的整体走向的流程的规划,流程图是用来对产品整体功能的梳理。所以在做产品前建议所有的产品经理先梳理一下产品流程。功能表是将流程图文字化,同时将列出产品的功能点。
功能详情,这是所有的产品功能的描述和规划。包括以下内容:
简要说明:告诉此功能主要干什么的。
业务规则:每上产品在使用时都有自己的规则,而产品的业务规则则是将产品的流程细化。个人建议将这个功能的业务规则,包括一些细节,如排版形式、日期显示方式全定好,这样方便其它人员的沟通和理解。
界面原型:产品经理在这时做的原型界面只是显示的框架,别细化,这样会给交互和UI造成错觉。只需做一个简单的界面即可,更多的时候只是个框架图。
执行者:产品使用者。
前置条件:具体的操作。
后置条件:操作后的展示。在UC(user case)中后置条件又是另一种情况,所以对于建议在PRD中的前置条件和后置条件结果合起来。
主流程:把主流放在最后是有道理的,结合上面所说的,做出主流程说明。将此功能的流程走向做个分点说明。

10、整合需求
产品经理很重要的一个能力就是体现在产品整合能力上,利用公司现有的资源或外部资源(合作公司等)实现产品功能需求的整合。实现功能贯穿的同时,更多的如何在新产品上实现功能的拓展来辅助核心功能。

11、BETA测试需求
很多产品都有BETA版本放出,为了就是收求意见和一些性能测试。这部份内容不是必须的,但现在很多产品已经开始先推出BETA版本再推出正式版,当然也可以通过升级来解决。所以BETA测试需求并不是一定需要的。如果有BETA测试需求,则需写出BETA版测试的要求和期望达到的目标要求。

12、非功能性需求
都说产品经理是全才,在这点上得到彻底的体现。很多产品经理在这点上忽视了,但很多方面是用到的,只是在产品过程中弱化了。

一般情况下非功能性需求包括以下几个部分:产品营销需求、规则变更需求、产品服务需求、法务需求、财务需求、帮助需求、安全性需求等。与其说是全方位的掌握技能,还不如说是沟通,如何与不同的部门人员之间的沟通,让更多的人协助产品的正常使用与上线。

13、上、下线需求
上线时限需求:此产品预定上线日期?上线日期有无任何特殊依据或规定?
下线需求(活动类需求必须明确下线时间):此产品预定下线日期?下线日期有无任何特殊依据或规定?

14、运营计划
说明产品的后续运营计划。包括与运营部的协作运营。更多的是给产品经理如何让更多的产品功能展示给用户,产品经理是核心需求的把握者,参与到产品整体运营计划显得特别的重要。

……

写PRD并不是产品经理的全部工作,但却是不可少的一部分,很大程度上反应了产品经理的思维和产品核心功能把握上,同时对产品经理沟通、协调、规划等都得到了一定的验证,但每个产品经理的第一职能是会写一份让其它人员看得懂的PRD。

商业需求文档(BRD)撰写体会(1)

http://blog.sina.com.cn/s/blog_3d302a9301012787.html

商业需求文档(BRD),是在用户需求调研完成后,就产品的定位、方向、功能进行基本概述,重点描述产品的市场需求状况、竞争者状况、商业机会以及财务预测,是作为公司对产品的决策依据。

百度百科中,对于商业需求文档的定义是:基于商业目标或价值所描述的产品需求内容文档,其核心的用途是用于产品在投入研发之前,由企业高层做决策评估的重要依据。

如果说,项目在投产前,一般会进行可行性研究并形成可行性报告,那么商业需求文档可以视作是产品的可行性研究报告。我的定义,简明扼要:商业需求文档,即是产品研发推广的可行性方案。

从定义可以看出,商业需求文档需要突出的是产品的“可行性”,而可行性的基础即是前一步的“用户需求调研”。用户需求调研的质量如何,直接决定着商业需求文档的可行性和可信性(PS:用户需求研究另作学习、实践和总结)。

在对用户需求进行调研之后,形成用户需求调研报告并得出结论,以此为基础,再进一步了解市场状况、分析竞争者。“用户+市场+竞争者”是前期研究和调研必须进行的对象。

在对用户、市场和竞争者调研并形成基本结论之后,结合公司自身的情况(可进行SWOT分析),提出新产品的设想,包括定位、功能,要对产品进行基本描述,解决用户的什么需求,与竞争者的差异化等。

在对产品做了描述后,就必须要点出商业价值在何处。任何的新产品研发必然是用户需求和商业价值的结合。描述产品的商业模式,可以在对市场和竞争者研究后,得出基本方向。

商业模式的描述并非是最终的结论,任何模式都需要通过实践来检验是否可行。那么,在此之前,公司做决策依据,商业需求文档中也需要涉及到一块财务的预测,投入成本与产出的预测。就目前来说,这一块,个人受经验和能力的限制,财务预测比较弱。有条件的,除自身加强学习之外,可以在研究阶段就把财务人士加入进团队中来,由他配合做财务预测,或许是一个办法。

有一点需要明确,商业需求文档的读者不是用户、不是外人,而是公司领导决策层,是公司决策层判断产品是否具备可开发的价值的依据。因此,如果想要促使公司决策层同意产品的研发投产,那么,至少在通过调研之后,其本身具有的商业价值首先能打动自己,否则,提也不要提。

以上流程下来,基本上就是商业需求文档(BRD)的主要内容版块。商业需求文档的撰写,有一些常用的模板,可以供参考。当然,具体的还是要看项目的不同,增减调整文档版块。以上只是本人的初浅了解,还有很多不足和不准确之处,还需要更多的实践。以上总结,仅作为个人学习体会。

用户需求调研体会(1)

http://blog.sina.com.cn/s/blog_3d302a9301011wqb.html

产品规划与设计之前,首要工作是对用户需求进行调研。用户需求调研是所有产品、营销的行动准则,用户需求指导一切。因此,在提出完整的产品规范方案之前,必须要做充分的用户需求调研,这是项目进行的源泉。

根据停车信息服务项目的调研,我有如下体会并作相应总结:

一、事前制定详细的需求调研计划
针对用户的需求调研,首先需要制定详细的需求调研计划。
要明确调研目的,是为了什么而调研;
明确调研对象,针对谁进行调研;
确定调研方法,调研方法主要包括问卷法、座谈法、实地观察法等;
确定调研流程,一般包括四个阶段:前期准备,目标、人员、物料、计划的准备;调研执行,问卷、座谈、观察等调研工作执行;信息整理,收集整理前期调研资料;出具报告,撰写调研报告,撰写商业需求文档(BRD)。
明确调研计划安排,把工作内容、时间、责任人等都要明确,这是实际执行的工作排表;
另外,还需要准备相应的调查表,如《用户需求表》、《座谈会问题表》、实地观察表和调查问卷等。

用户需求表:
调研主题
调研对象
调研人
调研时间
调研描述

实地观察表:
调研主题
调研对象
调研人
调研时间
调研地点
调研描述

座谈会问题表:序号、问题

调研前讨论。这个很重要。在用户需求调研计划制定中,需要针对调研的问答问题进行小组讨论,是否能够反映出调研目的,不能的,就需要修改问题。

二、调研执行
调研执行,重在“执行”。在这个过程中,一定要明确责任、明确时间,调研领导人需要做到时间控制、调研效果控制,在调研完成当天,必须要求调研员第一时间出具调查简报,避免因拖延而造成遗忘,尤其是在通过观察法和座谈法进行调研时。
比较好的方式是,当天调研完成后,下班前进行汇总讨论,提交文档。
这里提一下实地观察法调研。个人认为,实地观察法调研有两点需要注意:一是调研地点的选择,首先要跟调研目的、调研对象相关,其次地点需要有代表性;二是实地观察绝不是漫无目的的去观察,在去之前,一定要确定去观察什么、到现场要询问什么,必须要用文档的方式确定下来,以确保现场观察有的放矢。

三、报告撰写
调研报告的撰写,个人也仍在摸索中,主要依靠以前积累的知识,按照以前撰写的方式。由于调研方式主要有问卷和实地观察两种方式,前者属于定量调研,后者属于定性调研,其撰写方式略有不同。前者,一般是按照每个问题进行统计,按照“图标+文字说明”的方式;后者,主要是通过总结性的标题文字进行撰写。当然,目前来说,个人所撰写的这两类调研报告仍显得有些粗糙,尚待改进。
根据用户需求调研报告,再撰写《商业需求文档》(BRD) 。BRD的撰写体会,将另辟一篇专门总结。

囿于个人能力和相关知识的欠缺,此次的用户需求调研还是存在一定的质量不足的问题。但目前能力上达不到,暂时没办法提升。因此,所形成的报告,只具参考意义。
总结一下,用户需求调研,至少应当做到以下几点:
1) 制定详细用户需求调研计划,明确目的、对象、方法、流程、计划以及各种表单、问题;
2) 调研过程中,做好严格的时间控制、调研效果控制,第一时间形成调研文档;
3) 撰写调研报告和商业需求文档。
四、用户需求调研的方法
实地观察法
在实地观察并记录用户的行为,工作流程和其他环境因素。
面谈法
又称座谈法。与调研对象面对面交谈。可在事先准备好问题,现场与对象进行交流。
问卷法
问卷法是最通行的一种方法,通过调查问卷的方式收集用户需求,一般耗时较长。
查阅资料法
收集整理一手或二手资料,获取用户需求。

教你如何写PRD(产品需求文档)

http://www.alibuybuy.com/posts/8699.html

如何写PRD(产品需求文档)

产品需求文档,也叫业务需求文档。一般写这样的文档用WORD+VISIO或AXURE,建议互联网产品经理都熟悉一下AXURE这个软件的使用,能直接生成PRD,但是生成的文档是英文的,听说只有腾讯有个汉化的版本。下次哪位老兄进了腾讯给俺捎一个,在这里谢谢了哈。

产品需求文档主要是描述产品功能,业务流程和LOFI。可以提供给UE,美工和项目经理执行的文档。

一般每个业务功能都按以下格式写:

1.1.1 (业务功能名称)
1.1.1.1 业务功能基本信息
1.1.1.2 业务功能
1.1.1.3 业务流程
1.1.1.4 业务规则
1.1.1.5 界面管理
1.1.1.6 数据要求
1.1.1.6.1 输入
1.1.1.6.2 输出
1.1.1.7 费用处理要求
1.1.1.8 打印单据/文件要求
1.1.1.9 参数要求
1.1.1.10 与其它界面的整合建议

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

文档分为两轮
  第一轮:
  1,文档使用方:UI设计师
  2、内容:
  .根据战略层定义出来产品功能范围,
  .说明此产品的目的,方便UI设计人员更好的理解产品
  .产品基本流程
  .详细的设计框架图,推荐用axure,简单效率高
  .详细文案
  3、格式:
  html,visio,或word,如果PS用的不熟练,不推荐使用,会影响工作效率。
  
  上面是要UI设计人员出来高保真原型图,
  
  第二轮:
  文档使用方:开发人员
  用高保真原型图来对开发人员写技术需求说明
  有了高保真原型图,开发人员看的最明白,我们只需要写好详细的逻辑功能结构和详细的流程图
  
  PS:个人认为在工作流程中,特别是面向UI和工程师,没有必要详细的写出来什么行业分析,开发背景之类的内容,因为UI和工程师是在干活,不去关心这些问题,但一定要写清楚功能范围和此产品的目的,这样有助于UI设计人员的理解。
  
  另外,上面说的是个人理想状态,可能每个公司有自己的现实情况而有不同的流程。关键是提高效率减少不必要的扯皮沟通。
2.2 产品定义 Product Definition

2.2.1 What 做什么产品定义,即定义产品到底要做成什么。一般来说,比较正规的做法是撰写一份称之为 PRD(Product Requirements Document)的文档,该文档一般可以包括以下内容:

该产品的远景目标(vision)
目标市场和客户(target market and customers)的描述
竞争对手分析(competitive summary)
对产品主要feature的比较详细的描述
这些feature的优先级
初步拟定的实现进度安排
用例(use cases),这可以是较粗略的大致描述,未必一定要UML Use Case图。
产品的软硬件需求
产品的性能要求
销售方式上的思路、需求(直销还是渠道?直销怎么做?渠道怎么做?)
技术支持方式上的思路、需求(提供什么样的技术服务?)
显然,PRD文档就是对产品的整体规划,应该比上述Market Research阶段的MRD文档要细化一些:

MRD文档主要侧重于市场机会的分析,得出结论“就当前市场情况而言,我们可以做什么”
PRD侧重于整个产品的规划,以及business方面的需求。
PRD不同于SRS(System Requirement Specification),SRS是系统需求分析说明书,是以相当技术化的语言撰写的,主要给研发人员看的。
2.2.2 Goal 目标是什么

产品定义是产品管理的核心工作。

通过产品定义:

使得公司内部所有与业务相关的部门(高层领导、研发、销售、支持等部门)都能基本清楚我们到底要做什么产品,从而统一大家的思想和行动。
产品定义的PRD文档,为研发部需求分析组接下来出SRS文档提供了基本依据。
2.2.3 How 怎么做

产品管理部门根据市场研究结果,和各个业务相关部门沟通,发挥自己的创造力来进行产品定义工作。

2.2.4 Who 谁来做

产品经理负责牵头,主要由产品管理部门进行具体工作实施。

2.2.5 Deliverable 有无输出

比较正规的做法是输出上述PRD文档。对小公司或者小团队而言,有时可以把MRD和PRD合并在一个文档里描述。

做好产品需求文档的10步

http://www.alibuybuy.com/posts/7946.html

做好产品需求文档的这十步,是经过长期的实践经验和反复验证而得到的。可能这里描述的不是很全面,但他已经足够让你做一个成功的产品需求文档。做好这几步花费的时间要以项目的大小、复杂程度、个体学识、基本技能熟练度而定。

第一步:做好准备工作

你要做的是一个让人无可争议的产品,为了做好他,你必须做好前期的准备工作。你需要去了解你的顾客、竞争对手、产品团队的实力和需要的技术。你需要从顾客、用户、竞争对手、分析师、产品团队、销售队伍、市场、公司职员等收集他们能发现的问题和可能的解决办法。这里有很多的工作需要你去完成,在“成功的产品背后”这篇文章中有详细的描述。

建立良好的交流也非常重要,它会影响着产品团队。如果你的准备工作做的够好,你也会变得越来越有信心和说服力。

第二步:确定产品的目的

任何一个好的产品都开始于一个需求。你必须清楚的了解这个需求,你的产品如何达到这个需求。

产品经理需要提出一个清晰、简明的价值主张,让它很容易被接受,要让产品团队、管理人员、用户、市场人员清楚的明白这个产品到底是什么意图。虽然这听起来很简单,但是也只有少数产品才有这样的价值主张。考虑“velevator pitch ”(电梯间演讲、电梯行销)测试。假设你在做电梯的时候遇到公司CEO,他问你产品的意图是什么,你能在电梯到达之前回答这个问题吗?如果不能,你就还有工作需要做。也许是你的说明没有针对性,他可能表现出来和其他产品做的没有什么明显区别;也许你提出的观点不能和你的用户产生共鸣;也许你解决的是一个非常规的问题,可能你想应用一种技术。这个价值主张可能需要满足公司的产品战略。注意你不需要阐述太多的细节,从某些方面来说,一个有价值的观点应当是越简越好。

产品需求需要确切的指出这个产品发布的目标,同样的这个目标也有优先之分。例如,你的目标可能是:1)易用,2)零售价不足$100,3)和前期产品很好的结合。然后你需要说明如何去测算。对于“易用”这类项目,你需要明确指出产品可用性达到某个水平。这是通常用目标用户来定义。可用性工程师能测算出你的产品对目标用户的可用性,也测算出可用性问题的严重程度,同样你可以说明没有重大的可用性问题。

这里的关键就是让每个人都知道产品成功的时候是什么样,还有给产品团队在设计和实施中遇到问题如何进行取舍的指导。

第三步:确定用户原型、用户目标和用户任务

现在你已经明白你想要解决什么问题,下接下来就要深入了解目标用户和顾客,在这步中,和你的PD(产品设计)紧密联系非常重要。

用户原型

在这个阶段,PM需要和很多用户交流,需要花费大量的时间去直接观察和讨论。现在我们需要对用户和顾客进行分类,然后决定那一类是我们的首要用户。

比如你正在做一个像eBay一样的互联网拍卖服务,你同时拥有买家和卖家,在这之中还有使用频率少的用户和经常使用的用户,不难想象还有个别特殊的用户,比如团体公司采购者。

PM(产品经理)和PD(产品设计)需要首先确定类型是最重要的,然后尽量对这个用户群的特征进行详细的描述,以便使用这个模型去指导产品的设计。这个模型通常称其为“人物角色”。 虽然是想像的,但是应该是典型的、可行的和真实的,让你能够使用。这个想法来自与一个能代表这类用户的本质的原型。

举个例子:

“里昂是一个超级卖家,46岁,男性,居住在Fresno,经营小型摩托车配件。虽然他开着一个小店,但是他的生意大部分来自Ebay,每个月平均有400多次交易。他出售的东西品种非常多,但是他最受欢迎的商品还是哈雷戴维森的负重袋。他自己拥有两个哈雷,还开着1993年的丰田皮卡。里昂已经结婚了还有两个小孩。

里昂买电脑仅仅是因为他需要使用Ebay,除了ebay和电子邮件很少再使用其他东西。里昂已经在Ebay上销售产品已经三年了,他学会了在ebay应该掌握的东西,他非常自豪的拥有超过5000的信用度。如果Ebay更改了网站,特别是销售的过程方面,对于他来说改变习惯、学习这些变更是非常困难的。 里昂已经形成了自己的习惯,星期一列出销售的商品,星期五拍卖结束,设法让在收到货款的几个小时内出货。”

但愿这样的描述能让你了解里昂和知道他是怎么来的。当我们考虑新功能时,我就要问问自己里昂会是什么发应,为了让他能顺利的使用这个功能我们需要做什么。

注意缩小范围,让他仅仅描绘必不可少的。满足所有人是徒劳的,通常最后没人会满意,所以尽量提出几个最重要的和最流行的角色描述是非常重要的。同样,如果你不去精确的定位你的目标用户,你就只会存在模糊的概念,你会发现理解你用户的反应非常困难。你要倾向于设想,让你能更像你的用户。

用户目标(用户意愿)

一旦我们确定并描绘了我们主要的用户类型,我们就需要找出用户在使用产品中的目标(想要干什么).这听起来很简单,但是解开根本问题是非常具有挑战性的,特别当你周围的人告诉你你已经解决了他们想要的。

从CEO、销售代表、工程师到客户,每个人都太兴奋而不能帮助你找到解决根本问题的办法,他们会告诉你在某个地方添加一个快捷按钮,或则添加一个功能仅仅是因为竞争对手有,或则是改变成他们喜欢的颜色。

最好的解决办法取决于清晰的了解到底什么问题需要解决,每个用户模型可能有不同的目的,需要在用户原型涉及的方面中进行寻找。有可能将来某个功能解决的问题并不是主要用户需要达到的目标之一。

用户任务(tasks,用户为达到目标使用产品而需要做的任务)

掌握了用户原型与他们的目标愿望,我们就开始着手设计任务来满足他们的目标意愿,这是产品制作进程中最核心的部分,也是创造力和创新力被激发的地方。

许多优秀的产品仅是用更好更新的办法解决一个已有的问题,有时候这种办法仅仅是应用一个种新技术,但是大部分是来自深刻的见解而使一种新方法的产生。例如TiVo(美国市场占有率第一的数字录像机)在电视节目录制的老问题上面想出一个全新的办法,让顾客更加容易地实现他们的目标并且建立了电子设备一个全新的类别。

注意我们虽然谈到了目标和任务但是还没有谈到具体的功能,这些功能都需要达到用户目标而必须的。你以后会发现许多功能都是低优先级或则是完全多余的。

以“必须功能”这个理由可以排除很多功能。讽刺的是,你用越少的功能,你的产品被发现得越来越强大。这是因为产品的功能越少,你的用户就会发现并使用更多的功能,成功的使用越来越多的功能他们就认为你的产品非常强大。这些理由都是违反我们直觉的,我们大多数人都不能和我们的用户一样,我们在自己的行业中愿意比用户花费更多的时间去探索功能和容忍复杂性。

第四步:定义产品原则

现在你需要开始把你的需求和用户体验定义成详细的要求。同时你仍然会面临着许多的决定和权衡,为你的产品标准作出最佳的决定是非常重要的。

在大多数的产品团队中,每个成员都有做好产品的原则,但很少有两个人有同样的想法,这些差异都会导致不可思议的结果。
尝试和制订一系列指导整个团队的产品原则是非常有价值的,这些原则需要具体到域名和项目。

用TiVo举例,在产品团队工作开始时,以下这些产品规范就被建立,并在团队里传达:

1.它是娱乐的
2.一个傻瓜式的电视
3.一个该死的视频设备
4.平滑柔顺的
5.没有模式和深层次
6.尊重观众的隐私权
7.像电视一样强大

这些规范很大的影响到产品的定义而且在很大程度上加大了难度,但是他们确实是成功产品的来源。比如易趣的口号就是:1、易于使用 2、安全 3、有趣

它将在该项目中,在面对众多问题而作出决定的时候进行指南.

第五步:产品原型和检验

这是一个拿出你想法的阶段,创造力和创新力拿出成就的地方.

很多人都容易犯一个常见的错误,他们对产品设计规范太有信心,结果一旦得到beta的测试他们就必须调整产品。但是肯定beta测试版并不是进行重大改变的时候,所以才会有许多首次发布的产品离目标太远。

对于许多产品来说,这个时候你可以用大量的原型做很多的实验。首先,下面的三个非常重要的测试你可能需要做

可行性测试
一个直接的问题就是产品是否可以开发,你的工程师和设计师应当介入技术的可行性调查和探索可用办法。有些办法是行不通的,但是有其他的办法可行是非常有希望的。
工程师会发现在产品的某个阶段不可能逾越,现在知道比以后知道要好。

可用性测试
产品设计师将要和你紧密工作共同提出产品功能,让它能适应不同的用户。可用性测试常常会找出遗漏的产品要求,同时确认产品最初的要求是否是必须的。在你拿出一个成功的用户体验之前需要多做一些测试工作。可用性的目的是在真正的用户身上测试,从产品目标用户得到质量反馈的测试是非常艺术和科学的。当然产品经理和产品设计将模仿使用,但是实际是没有人能取代真实的目标用户。

概念测试(Product Concept Testing)
光是可用和可行是不足的。真正的问题是你的用户想要购买吗—你的用户有多喜欢-你做的有什么价值。这测试可能与可用性测试联系在一起。

对于一部份小产品,您的想法写在纸就足够了,但是对于多数产品,为了预计产品是否达到目标,复杂用户互作用或新技术的使用、某种形式原型都是非常重要的。

原型也许是一个物理设备,或者它也许是软件产品的一个预览版本。关键是它需要足够现实,您能用原型在实际目标顾客身上测试,并且他们可以给您质量反馈。

以前做原型主要有两个障碍。第一是缺乏良好的原型工具,需要花费很多的时间制作原型;另一个是管理方不知道原型和真实产品的区别,在不可预计的情况下,按照最终产品来要求原型。

今天有优秀的原型设计工具可以让工程师或设计师快速的制作原型,可以有效的模拟未来的产品以达到必要的程度让实际用户进行测试。而且大多数管理者都知道模仿和实际的区别 — 就如同缩小比例的房子模型和真实的家一样。

在实际去做产品之前去检验你的产品是非常重要的。一旦实际的工程开始,作出重要的变动会变得非常困难,花费也会变得很高。

第六步:验证和质疑

当你认为你弄懂了你需要解决的问题,现在是时候开始验证和质疑假设。

假设甚至当作不知道是很容易的,但是切勿把不可知的结论当作指引,那会妨碍你获得成功。天文学最初定义是研究太阳和其他行星如何围绕自己转,本身的定义就是一个臆断,反而阻止人们获得真相。

第七步:写

当然你需要把这些都写下来,大多数的PRD都是word文档,但也有一些是帮助文档,PowerPoint,或则写在白纸上。当然用什么格式不是很重要,重要的是让团队成功能轻松的看懂,不会遗漏,还有就是PRD可以随着项目开发而更新。

记住对话是两个人之间的,但是PRD是要沟通整个小组。你也要记住获得产品的销售才是是重要的,所以不必担心要有什么漂亮的外观、PRD写的有多厚,只要它是可读的、可理解的、是需要的内容。

PRD文档主要有四个部份组成

产品用途
你的工作就是指出目标,团队需要知道他们的目的是什么,目标说明要尽可能的明确,请确保你的内容包括:
*那些问题你要解决,不是解决方案
*谁是目标用户
*细节很多,但是大图片必须清晰
*情景描述
多开展集思广益的会议和临时口头的讨论,从而更好的写出来,更会让团队深入了解。

产品功能特性
产品需求文档最主要的当然是需求。 具体的需求完全地将取决于您的领域,但是不管你是什么行业,您的产品团队将受益于陈述需求的清楚,毫不含糊的要求,而不是模糊的解决方案。
描述每个功能的互动设计和使用案例。您必须非常清楚每个功能和用户体验,还需要给工程团队留下足够多的灵活自主空间。
同样重要的是确定那些要求满足哪个目的。这里就需要提到“需求跟踪”,对于关键的产品这是一个重要的流程。每种产品规范可能受益于清楚确定那些要求满足哪个目的,如果某人决定削减要求,想要深入了解就会非常困难。 从要求到目的明确说明将会是文档更加清晰。

发布标准
发布标准经常是不断变化的,但是好的PRD应该考虑到为每种标准定一个最低要求。典型的如:性能,可测量性,可靠性,可用性,可控性。

时间进度
其中很困难的一个问题就是描述产品需要的时间进度表。随便列出一个时间是没用的,你需要描述环境、动机、预计目标。你需要整个团队都和你一样达到预计目标,最终完成一个成功的产品。

第八步 优先级

除了明确的要求,对每一个您的要求给予优先和排列秩序是很重要的。多数产品经理,如果他们给予优先级,一般都是表明要求是否是“必须有, “重要”或“希望拥有” (或其他一些分类系统)。分类是很重要的,不可掉以轻心。

产品经理对任何一个标记“必须拥有”都需要有高度的标准。如果还没有找到必须拥有的功能意味着产品还不应该产生。所以小心标注“必须拥有”,这些标注“必须拥有”的功能直接反应出产品的核心价值。
“重要”的分类也很重要,在产品销售前只要有机会就要满足这些功能。
“希望拥有”产品团队也应该注意到,即使大多数也都没有实现,在未来版本也适当的慢慢实现。

这些有时候是不够的,从1到n每一个分类优先排序都是很重要的。有几个原因:
首先,上市时间总是被关注,并且日程表经常下降,您说不定被迫使削减有些特点为了尽快进入市场。 你也不想产品团队先开发简单的功能而放松重要的功能,导致最后客户使用的关键功能还没完成。
其次,在产品设计和开发阶段,团队将会发现更多的问题产生并解决这些问题,所以很有可能有更多关键功能出现。优先顺序会可以帮助你如何平衡以容纳更多的功能。
这点就是说产品经理如何不给出优先级和重要等级,其他相关较少的因素也会跟着无法确定。

整个PRD是一个不断完善和思维提高的过程,明朗锐利就是可以成功的产品的,模糊就是失败的产品。在争论最激烈的时候也能容易做决定,并且帮助工程师做出计划。

第九步 测试完整性

现在你有一个PRD草稿,你需要测试它的完整性。工程师是否可以充分了解并达到目标?OA Team(质量管理团队)是否有足够的信息来做出测试计划,是否可以开始做案例?

当投资人或相关人审核了PRD,确定了各个需要说明的方面,所有的问题得到解决,现在你就可以按PRD进行产品开发。

第十步 管理产品

在产品实施期间,就算是最好PRD,也有不计其数的问题被解决。解决所有PRD中存在问题,如果不在PRD中就写进去。你的任务就是迅速解决问题并记录在PRD。

如果你做了你的工作并准备记录在PRD,项目审查就会变得非常简单,因为任何一个部份都历历在目。

记住PRD是一个“活”的文件,在要跟踪记录在产品开发期间的所有功能过程。最后你会发现很多额外的东西,如果你认为是必要的就在PRD中写进。

本文大体已经结束,全面的阐述一个PRD的产生和管理过程,感谢SVPG的分享。接下来有空闲时间我会整理上传一份互联网行业的产品需求文档模板在本页面,供大家下载。

产品商业需求文档(BRD)的设计

解说图
http://weili.ooopic.com/weili_12344642.html

引用链接及参考资料
http://wenku.baidu.com/link?url=INe1qO84S3p2RHrbDdpugoMvYVMCo1q-rWS0yusz06AsHZqEb6XiGlt2JLpFpMZfSee7hEz6GS8FuCxdRWW7ZotvTEG5tCnlJ5J8EHwI3wi

http://baike.baidu.com/archive/BRD/93652712

BRD为“商业需求描述”的英语缩写,全称为:Business Requirement Document。是基于商业目标或价值所描述的产品需求内容文档(报告)。其核心的用途就是用于产品在投入研发之前,由企业高层作为决策评估的重要依据。其内容涉及市场分析,销售策略,盈利预测等,通常是供决策层们讨论的演示文档,一般比较短小精炼,没有产品细节。

BRD与PRD的差异

BRD不同于常见的MRD(Market Requirement Document-市场需求文档)和PRD(Product Requirement Document-产品需求文档),既然是用于产品实施之前的决策评估依据,必然对其文档(报告)的内容和格式要求够直观、精炼,要点突出。作为报告的撰写者,你必须让高层明白,你的报告中将展现出怎样的商业价值,如何用有力的论据来说服企业对你这个项目的认可,并为之慷慨的投入研发资源及市场费用。如果说PRD的好坏,直接决定了项目的质量水平,那么BRD的作用,就是决定了你的项目的商业价值。优秀的BRD文档,可以让决策层充分被你的报告观点所吸引,或许财务主管会因为报告呈现的低投入高产出的经济效益预测而蠢蠢欲动;或许技术主管会因为项目的牵涉面广泛而头疼不已;又或许公司的VP之流因之报告而看到了未来一年业绩的飞速发展的广阔前景……

说白了,BRD需要产品经理(产品设计师)像对待PRD一样,充分应用市场调查、用户研究、需求分析等各种设计手段来充分阐述报告的内容。基于这样的状况,显然不是给大家一份完整的BRD标准格式规范,就能够搞定一切的!哈,也许有人会说这有点危言耸听,不过我一向赞成,面对一切“产品”,都应该用设计的眼光看待它。

首先,你应该把决策层当作你的产品——BRD的受众群体,一切从这里开始

BRD的受众群体

不同的企业,不同的时期以及不同的决策环境,使得BRD的决策层必然存在着较大的差异,很多人都会疑惑,究竟决策层都会有哪些人?为什么是这些人对BRD进行评审,而不是技术经理或项目经理之类?其实这都不是问题的关键,无论是企业的老板还是CEO、COO、CFO之类,又或者VP或各类部门主管,什么样的人参与BRD的评审都是可以的。

作为产品设计师,你对受众群体的分析,不是要关注他们是什么职业,又或是什么Title,是男又或女,你应该抓住这些受众群体的核心需求:“他们为什么要评估你的报告?评估后的决策,究竟决策什么?

再细致回顾一下,通常我们会在什么情况下撰写BRD报告?一般都是在年初大家做年度规划的时候,又或者是产品经理在日常产品管理过程中,通过一系列的市场分析或调查,掌握到了一个潜在的、未被满足的大量用户需求,而这些需求背后将映射着一个广阔的市场空间。产品经理因之而激动莫名,匆匆写了一个数十页的报告,找到上级领导,领导的领导,领导的领导的领导……

一番唾沫横飞的演讲后,也许就提出了以下这些要求:
这个项目很重要,希望领导支持我来做这个项目;
这个项目很有价值(社会价值——造福全人类?;
商业价值——未来的赢收主体?;
用户价值——引领用户潮流?

比如说Iphone;市场价值——也许明年我们的市场份额就会扩大一倍;投资价值——我们将全面进入一个新兴的领域),希望公司能重视这个项目,并纳入未来战略计划中; 这个项目很庞大,需要公司提供足够的研发资源和市场费用,希望公司能审批一笔预算并给我一个专属的项目团队,这样我才会最大限度确保项目成功;

BRD的决策参与模型

通过上述的分析,我们似乎找到了撰写BRD背后的目的:
我需要一笔费用;
我需要一些资源;
我希望公司高度重视;
我希望各级领导支持;

基于这些目的性,我们可以把决策参与人分成以下几类,先看看我整理出来的BRD的决策参与模型。
资本型:这类角色一般就是为我们提供足够的产品研发经费,自然以CFO(首席财务官)、财务总监之类为主;
市场型:这类角色一般就是为我们提供未来市场营销和商业运营方面的支持人员,通常以市场总监、运营总监之类为主;
研发型:这类角色一般就是为我们提供技术性支持的主管,比如技术总监或研发总监之类;
战略型:这类角色一般就是企业的老板(董事长)、CEO(首席执行官)、COO(首席运营官)或直属VP(副总裁),这类人,通常能够为你提供产品在企业内受到足够高度的重视,让你实施项目畅通无阻,而是否纳入1~3年的战略规划,也是这个层面的人说了算;

如果你充分掌握了以上这些信息,事实上你就已经为你的BRD获得审批通过成功了一半了,剩下的,就是看你对报告细节的把握能力了。确定报告的大纲,充分论述报告的各方面重点,利用你擅长的沟通表达能力,用最简洁的语言、条理清晰的思路来陈述你整个报告的核心部分!
接下来,我们进入BRD报告的核心环节——“设计”(抱歉,这里需要的是你的设计思维而非展现你深厚的文字功底)一份出色的分析报告!
上篇谈到BRD撰写之前的决策模型,其目的就是为了让大家明白一点,写BRD,不应该站在自已的角度来写这份报告,充分了解决策层,也就充分把握到了报告编写的要点。站在评审方的角度来写报告,你的报告成功的可能性就已经占了很大一部分了。

BRD报告要素

前篇中我们谈到决策的角色分类有资本型、市场型、研发型、战略型,我们现在就针对这几个角色,定义出BRD报告的要点。

资本型:假设你现在是一个财务管理人员,大家都知道,管钱的人对数字敏感,对“付出”抠门,因为对财务来说,付出都是负资产;对“进入”欢喜,最好的方式是只进不出,那样就是只有利润没有成本。哈,天下自然没有这么便宜的事,所以退一万步说,追求投入产出比是他们的首要关键,不在乎投入多少钱,而最在乎的是投入产出的比率,也就是追求利益的最大化。所以在BRD中,要专门针对这一方面,做一份详细的报告。而通常而言,做一个互联网项目,主要的投入在于“人力成本”“运营或营销成本”“时间成本”“软硬件成本”“环境成本”,如果单给出成本计划,财务肯定不乐意了。所以,一定要明确给出收益预测,而有时候项目不是关注短期效益,更多的项目在初期通常不大可能获得大的效益,这就需要报告中体现出长远的效益预测。设想一下,如果你跟管钱的人说:“做这个项目,我投入1万能赚1万……”,财务肯定拒绝投资,这种没有利润的买卖他们肯定不干(有一句话怎么说来着?资本家的本质就是追求利润的最大化!);但是如果换个说法“做这个项目,一个月内能赚到2000,二个月之后能赚到5000,三个月后能赚到一 万……”,同样是投入产出1比1,为什么财务会更倾向于投资后者?相信很多人想到了区别——增长率!前面我们说到了,管钱的都对数字敏感,他们专业内对增长率和趋势预测那是基础知识,前面一种说法表达的意思是增长率是零,后面一种说法则更具体,更有说服力,有高增长率,而且将来收益会越来越多。你现在投不投钱?所以说,这是一种报告的技巧,但注意:技巧不等于虚假,你要有严谨的数据或论据支撑你这
样的预测,别当别人是笨蛋!

市场型:假设你现在是营销总监。做市场,最关注几个方面:有没有成熟的推广渠道,有没有竞争对手,外部环境如何,有没有营销资源,市场占有情况,市场空间有多大等。我们仍然从营销总监的角度看这些问题:有成熟的渠道,我们营销工作就容易开展,如果没有,项目难度就会大增,有可能根本就无法落实。比如,一个项目要求快递公司要在保证全国二线城市1小时内配送到货,这很显然是不现实的,大家都知道目前的快递行业根本没有这么成熟的渠道,怎么可能做到这点?而有没有竞争对手,则要考虑我们是先发还是后发,做互联网产品,先发绝对具有优势,如果是后发,还要考虑竞争对手有多强大,它们有没有同类的产品?我们有没有跟它们在市场上直接竞争的实力?没有,那就免谈!外部环境,通常指行业环境和市场环境,政策环境,越成熟的市场环境,对新兴项目越不利,而越规范的政策环境,也对项目越不利。市场占有情况和市场空间的关注是相似的,就是要看我们有大的市场蛋糕可以吃。

战略型:你现在是VP或COO了。这个层次的领导,可能有些人接触不多,所以对这个角色的代入感比较弱,把握不到其关注的重点。其实,做到这一层面的领导通常眼界都会比较开阔,战略眼光高,看得远,想得透,抗风险性强!他们通常不会注重短期效益,而且也不仅仅只是关注单一的“钱”的效益,还包含关注是否是潜在市场或新兴市场,是否有长期投资的价值,未来的趋势是不是很好,风险是什么等等。举例来说,“做这个项目,对我们企业的好处是什么?”你不要光谈钱,前面说了,Boss级的人,好处不再仅仅是钱上面。假设你的项目是目前市场上的蓝海,恭喜你,你的报告已经成功了一半;假设你说“我们目前的客户只占了整个市场了50%,还有30%的潜在客户,通过这个项目能够挖掘到。”同样恭喜你!假设你预测到2010年微博将会大热,而你们公司的产品又是一个大的门户,你及时发现了这个商机,你认为未来5年将会是微博的天下,那就再恭喜你!这有长期投资的价值!风险是什么?风险就是你要告诉我,我们失败的原因,失败后的损失。有多少失败的原因是我们可控的?如果大多数都是不可控的,那这个项目的风险就太大了。失败后的损失是不是公司可以接受的?可以,那就值的做!

研发型:研发型专业性比较强,大多数人是不具备技术知识背景的,包括大部分的产品经理人员,所以,对于写报告的人来说,研发这块可尽量简化表达,目的就一个,让研发的Boss充分理解你想做的项目是什么样的,主要有什么功能模块(确定架构设计)是什么类型的网络功能(确定性能支撑),比如微博项目,最大的难度在于海量、碎片化的数据存储及应用问题;比如电子商务,最大的难度在于大的订单量以及订单背后复杂的商务逻辑造成的系统复杂度和压力。

BRD报告汇报过程

掌握了关注点,再预演一下BRD报告的过程:

会议开始,你总得先给与会的领导介绍一下你的产品要做什么吧?(解决什么问题或满足什么用户需要)
为什么要做?谈谈背后的原因(背景、市场空间、竞争对手、环境)
打算怎么做?(产品规划、模块规划、研发计划、运营计划)
需要多少资源?(人力成本、软硬件成本、运营成本)
最终能获得什么收益?(带来收入、带来用户、扩大市场、占有市场先机、满足未来三年战略规划等)
做这个有没有风险?(开发失败?失去市场机会?失去先机?竞争不过对手?没有带来收入?没有带来用户?与公司战略背道而驰?)
OK,一切都已经明朗,细节就不用再说了吧?最后给大家提供一个BRD的模板吧!

http://wenku.baidu.com/view/4ffb6434a32d7375a41780d8.html?re=view

BRD模版

目 录
0. 文档介绍
0.1 文档目的
0.2 文档范围
0.3 读者对象
0.4 参考文献
0.5 术语与缩写解释
1. 公司目的
1.1 用一句话描述公司的业务
2. 问题
2.1 描述客户的“切肤之痛”
2.2 简介目前客户是如何应对这些问题的
3. 解决方案
3.1阐述公司的产品/服务的价值定位如何解决客户的难题
3.2说明公司的产品/服务具体在何处得到实现
3.2提供一些产品/服务使用的具体例子
4. 时机:为何是现在?
4.1 回顾公司产品/服务所应用的领域的历史演变
4.2 说明哪些近期的趋势使得公司的产品/服务之优越性得到可能
5. 市场规模
5.1 定义你的目标客户并描绘他们的特性
5.2 用不同的方法测算市场规模
6. 竞争格局
6.1 列出现有的和潜在的竞争对手
6.2 分析各自的竞争优势
7. 产品/服务
7.1 产品/服务描述:外形,功能,性能,结构,知识产权等等
7.2 产品/服务的开发计划
8. 商业模式
8.1 收入模式
8.2 定价
8.3 从每个客户上可获得的平均收入或其终身价值
8.4 销售和渠道
8.5 现有客户和正在开发的客户清单
9. 团队描述
9.1 创始人和核心管理层
9.2 董事会成员和顾问委员会成员 10. 财务资料
10.1 利润表
10.2 资产负债表
10.3 现金流量表
10.4 股本结构
10.5 融资计划

BRD模版2

目录 
 
1、文档介绍
1.1 文档目的
1.2 内容概要
2、市场问题和机会
2.1 本章摘要 
2.2 市场问题
2.3 市场机会
2.4 产品问题和机会
2.5 技术问题和机会
3、市场概述
3.1 本章摘要
3.2 目标市场描述 
3.2.1 目标市场特征 
3.2.2 目标市场趋势 
3.2.3 目标市场细分 
3.2.4 目标市场时间约束 
4、客户和购买者 
4.1 本章摘要 
4.2 目标客户描述 
4.2.1 目标客户细分 
4.2.2 客户动机 
4.2.3 影响因素 
4.2.4 客户目标 
4.3 目标购买者描述 
4.3.1 业务决策购买者(BDM)
4.3.2 技术决策购买者(TDM) 
5、使用者和用户原型 
5.1 本章摘要 
5.2 原型特征 
5.3 现实需要 
5.4 原型联系 
6、市场需求
6.1 本章摘要 
6.2开发环境说明 
6.3兼容性说明 
6.4性能说明 
6.5国际性说明 
6.6文档说明 
6.7外观说明 
6.8发布说明 
6.9支持和培训说明
6.10其它说明
6.11 方案概述
6.12 技术概述
6.13 市场需求概要表 (实现目标、约束条件、需求联系、原型、类型、优先级)
7、支持信息
7.1 本章摘要 
7.2 文档假设 
7.3 参考资料 
7.4 产品体系

BRD样例3

http://www.docin.com/p-512392176.html
老年人代步车项目 商业需求文档

  • 项目背景
    • 提案原因
      • 调研报告
        • 细分市场
        • 竞争格局
    • 商业价值
      • 价值链 设计、制造、渠道、销售方式、服务及定价
      • 价值网络中的位置及竞争战略
  • 项目规划
    • 核心产品需求
  • 收益、成本及风险
    • 收益=对象群体*顾客消费
    • 成本
    • 风险
      • 技术
      • 销售链条
MRD市场需求文档模板(一)作者:老坛

http://blog.sina.com.cn/s/blog_486d34590101b8fu.html
http://blog.sina.com.cn/s/blog_5f4b06430100clme.html

说到市场需求文档,可能很多刚开始做产品经理的朋友,都不太清楚。今天我就转载一篇有关市场需求文档/MRD,与大家一起分享!

从这个表中可以看出,MRD本身并没有什么特殊之处,按照产品管理者的工作内容来说,是必备的东西,但是,我们知道,现实的情况是,许多技术型的公司实际上对产品管理者的定位过于狭隘,非要生生地把产品管理者分为“技术型”、“市场型”,本来一个完整的产品管理过程和管理内容,就这样支离破碎了。
关于这个问题抽时间,咱们再一块讨论,还是重点讲MRD。
正是因为这个原因,许多技术型企业的产品管理者很少或者几乎没有接触过MRD,并不是说大家没有这个意识,其实,作为产品管理者,这些市场端的东西多少都会有了解的,但是,企业并没有把这个任务交给产品管理者来做,因此,就显的有些陌生了。
在表格中,已经提到了,MRD起着一种“承上启下”的作用,“向上”是对不断积累的市场数据的一种整合和记录,“向下”是对后续工作的方向说明和工作指导。
这个很容易理解的,那么,具体到这个文档中,都包括什么内容以及如何来完成好这些内容呢?
接下来,我就自己的一些经验说说个人的想法,对不对的,大家见谅。
刚才说到了,MRD就是对产品所在市场数据的整合,说白了,就是对市场分析后的结论体现,那么,在这个文档中,需要体现哪些内容呢?
在我看来,需要体现的主要内容包括:
1、市场的问题和机会;
2、市场特征;
3、用户特征;
4、使用者特征
5、市场的需求。

分别解释一下:

1、市场的问题和机会。
在这个主题中,主要是要求产品管理者说明自己负责的产品现在所处的市场都有什么问题和机会、面对这个现实的市场,产品有什么问题和机会,以及产品所需技术面临的问题和机会。
其实就是要求从市场层面、产品层面、技术层面来阐述问题和机会。

2、市场特征。
在这个主题中,主要是要求产品管理者说明目标市场的现状和趋势。应该包括的信息有:
目标市场特征;目标市场趋势;目标市场细分;目标市场时间约束。

3、用户特征。
这里的用户是个广义的概念,它其实包括两个方面的信息:1、客户(customer);2;购买者(buyer)。
在这个主题中,主要是要说明这产品的目标用户的特征、细分、动机、影响因素以及用户期望(目标)。

4、使用者(user)特征。
之所以把这个主题独立出来,就是因为,无论什么产品,最终是要由具体的人来介入的,这类人才是产品的最终享受者,具体到产品上,其实我们日常分析的产品需求和功能都是基于他们考虑的。
在这个主题中,要说明这类用户的特征、现实需要和相关联系。
这里插一句话,我看到国外的一些公司是采用了原型塑造法来完成这个主题的,关于这个方法,抽时间再说,呵呵。

备注:关于客户(customer)、购买者(buyer)、使用者(user)的区别和关系,如果有朋友还有不解的地方,可以一块来讨论。

5、市场的需求。
这个就比较容易理解了,就是把市场需求按类别描述出来即可,具体的标准,大家应该很清楚的,就是“描述性的语言来说明用户的期望”,主要包括的内容有:
功能分类;开发环境说明;兼容性说明;性能说明;国际性说明;文档说明;外观说明;发布说明;支持和培训说明;其它说明;方案概述;技术概述。
当然了,我是把可能出现的内容都列举出来了,在实际的情况中,肯定会根据行业和产品的不同有所删减,这个仅供参考哈。
在这个主题的最后,我建议大家加一个表格,就是“需求概要表”,这个表格的作用就是用列举的形式来把所有市场需求记录下来,毕竟上面的内容都是描述性的,这个表格有助于快速浏览。
 

MRD市场需求文档模板(二)作者:老坛

http://blog.sina.com.cn/s/blog_3d302a9301012787.html

这个表格应该包括的内容有但不仅限于:
实现目标;约束条件;需求联系;原型;类型;优先级。

简单介绍了一下MRD中主要体现的主题,大家看一下,其实内容很简单的,但是,我在看了一些MRD后,才感觉到,写好一份MRD,那是相当的不易呀。
首先,在MRD中必须有许多的数据来支持你每个主题的结论描述,其次,在MRD中,涉及到了一些具体的方法,例如刚才说到的原型法,三,MRD是整个产品项目过程中非常重要的一份文档,或者说,这份文档奠定了接下来的一些列工作基础,MRD做好了,其它的工作都没有问题,这个作不好,其它的都不可能让人满意的。
因此,要写好MRD,是不能脱离产品项目流程和思想的,这个说起来,就太大了,有时间咱们慢慢聊。
大家在现实的工作中,偏重于PRD的居多,大家可以想想,是不是通常把主要精力放在了产品功能上了,而忽视了对产品所在市场的关注和分析,尤其是在一些软件和互联网公司,非常明显,有多少朋友做到了MRD中要求的呢?
说到最后,还是我始终坚持的一个观点,产品管理文档,本身没有任何价值,网上到处都可以找到,但是,如果不懂产品管理的思想,不明白产品管理到底是什么,不知道产品管理者到底应该做什么,即使给你非常好的文档模板,又有几个人能真正理解这份文档的作用,并把它写好呢?
对了,最后提一点,有些公司,是把MRD和PRD合并来做的,或者说,即使可以舍弃PRD,也不能舍弃MRD,因为PRD是由MRD延展而来的,MRD是根,PRD正是枝叶而已。

写好MRD的10种技巧-第一部分

http://www.yeeyan.org/articles/view/14480/6689/
http://www.alibuybuy.com/posts/1997.html

MRD-“市场需求文档”,是产品经理或者产品市场经理编写的一个产品的说明需求的文档。这些文档用于计划一个新产品或修正一个已有的产品,是被工程师团队开发产品时使用。

在硅谷的一些软件公司,MRD仅仅覆盖high-level的功能。在这种情况下,产品经理通过创建了另一个文档-通常指的是PRD(产品需求文档)来定义更加详细的产品需求。
在本文中,我用术语“MRD”泛指所有那些由产品管理和/或产品市场团队创建的,为工程师团队传达产品需求为目的的文档。
写好MRD的10种技巧(第一部分)
1、从用户角度的编写
从用户角度编写需求内容。使用“用例(Use Case)”和“用户角色(User Personas)”来达到这个。考虑用以下两种方法来详细说明你们公司正在开发的SFA(sales force automation)软件的“Login”的功能性。
方法A:
用户通过一个要求用户提供证书的登陆界面,然后软件允许用户带着特定的权限进入系统。软件鉴别这些证书,在鉴定通过的基础上允许用户访问那些他们有权限访问软件的功能部件。
方法B:
Mike是一个销售经理,Cathy是一个销售代表。当他们打开软件,他们看到登陆界面。他们通过用户名和密码进入系统。如果用户名和密码是正确的,他们能登进系统。一旦登陆进系统,Mike能访问软件所有的功能部件。Cathy只能访问那些对销售代表有有效的功能部件。
哪个方法更加容易阅读和理解?就我的看法,毫无疑问,"方法B"。还有,它同时减少了令人烦恼的阅读!""

2、使用Screen Shots
使用Screen Shots或者mockup来你的想法。我们中很多人都听说过“一张图片好比一千个文字”。当提到写MRD的时候,一个screen shot好比一千个文字!
举个例子,看看下面这个screen shot,你需要多少字来描述?我想可能不只一千个字。

3、用简单的语言编写
在我超过11年的行业中,我通常注意到的(更多是令我懊恼)一件事是用很做作的语言来写的MRD。我想这个主要是因为MRD听起来是正式的和专业的原因吧。
相反,想象你写的MRD是写给你的在工程师团队工作的朋友。你的目标是帮助他理解你需要什么,以便于他能开发产品实现这些需要。这个将有助于你避开陷入那些令读者人厌烦(有时他们会把MRD撕碎然后再碎片喂给碎纸机)的用做作的语言的陷阱。""
还有:
a)保持简短的语句,把长的语句分解成多个小的语句。
b)避免大篇幅的连续文本,把他们分解成多个小的章节。
c)把大块文本内容分解成,screen shots,表格、重点列表等等。

4、小心的使用模板
我发现MRD模板非常有用。他们的几个好处包括:
a) 模板提供了一个标准的格式,使那些不得不阅读大量MRD的读者更加容易阅读。
b) 模板让新的产品经理快速的写MRD变得容易,因为公司与公司之间的MRD内容是不同的。
c) 模板确保你不会忘记所有需要在MRD中覆盖描述的部分;

然而,一些公司过分的使用模板。一个硅谷最大的公司之一有一个所有部分被强制使用的近60页的模板。我觉得这个让人觉得非常难以忍受并且有几个负面的作用:
a) 产品经理害怕但又不得不写MRD - 几乎和不得不和Dick Cheney去南德克萨斯打猎一样(译者按:美国副总统Dick Cheney在南德克萨斯打猎时意外的打伤了和自己一起去的打猎伙伴)。""
b) 工程师团队害怕但又不得不阅读MRD。
c) 写MRD和读MRD都需要花大量的时间。

我推荐你使用MRD模板,但确保他们不要过分的长。还有如果需要,确信产品经理可以灵活的跳过模板某些部分和创建新的内容。

5、区分需求的优先级
在这些年里,我从来没有碰到一个工程师团队实现了MRD里包括的所有特性的没有删减的项目-通常由于那些我们控制之外因素!
这就是说作为MRD作者的产品经理,当出现需要决定取舍的时候,应该提供一个办帮助让他们决定那些特性要实现那些可以推迟。
区分需求的优先级是一个最好的能帮助完成这个事情的办法。我发现把需求分等级就像P1,P2,P3…这样工作的刚刚好。在这个分类中-P1是最高优先级,P2是第二高优先级等等。
最好的决定一个已经明确的需求的优先级方法这个需求实现后的好处-包括你的客户和你的公司。在实际实践中,最好是和其他多种因素一起综合决定。
我推荐你只要包括P1,P2,P3的需求在你的MRD中,在多数的项目中更低的优先级可能未必会实现。还有这样也让MRD变得更加容易读。

在我前面名为“写好MRD的10种技巧-第一部分”Blog文章中,我描述了写好MRD的5种技巧。我知道你一定迫切的想看到其他5种技巧,不用再等了,下面我就描述它们!

在本文中,我用术语“MRD”泛指所有那些由产品管理和/或产品市场团队创建的,为工程师团队传达产品需求为目的的文档。如果你还没有阅读前面的5个技巧,请先阅读它们,我会等在这里,好了,你准备好了吗?

以下是写好MRD的10种技巧-第二部分(6-10)

6、说明”是什么”和”为什么”,但不要”如何”

产品经理为理解客户的需求负责,然后基于这些理解定义什么和为什么需要开发.
有一件比任何事情让开发者发疯就像在几英里外都能听到的汽笛在他们耳边尖叫一样的是一个令人痛苦的详细描述了怎样实现每一个需求细节的MRD。

考虑你们公司正在开发的以下两种描述CRM“Login”功能的方法。

推荐-描述“是什么”
Mike是一个销售经理,当他打开我们的CRM软件,他会看到一个登陆界面…登陆界面建议提供“记住我”复选框。如果Mike在点击登陆按钮之前选择了该复选框,我们的软件将记住并且在他下次来到登陆界面时自动填写他的名字。

不推荐-描述“怎么样”
Mike是一个销售经理,当他打开我们的CRM软件,他会看到一个登陆界面…登陆界面建议提供“记住我”复选框。如果Mike在点击登陆按钮之前选择了该复选框-将通过Javascript 保存他的名字以cookie的方式写到他的硬盘。当cookie写到硬盘后,用户名和密码将被发送到服务器。下一次Mike来到登陆界面时,Javascript 将读取他的cookie,成功读取后,Javascript 将是适当的DOM命令填充登陆页面上的用户名。好的产品经理擅长理解用户的需求和描述什么需要实现,好的工程师擅长决定怎么样实现它。好的工程师希望能自由的决定怎么样最好的实现用户希望得到的东西。

我注意到有技术背景的产品经理尤其喜欢描述“如何实现”。如果这些描述的就是你,应该从现在开始不要再做这样的事了。工程师们将会感谢你。

附:这里有一些例外的情况-当在描述“是什么”中描述“怎么样”是必要的,当描述“是什么”的最好的方式和/或唯一的方式就是描述“怎么样”的情况。

7、覆盖非功能性需求

尽管功能性需求描述产品的功能,非功能性需求描述系统特性,如:
a)性能
b)可伸缩性
c)可用性
d)国际化
e)等等…

我注意到因为许多产品经理和产品市场人员认为这些是“技术细节”,而在MRD中被忽略。我发现这些是我的MRD中非常重要的一部分,工程师们会非常感激在MRD中定义这些需求。

要点:当写非功能性需求的时候,尽可能的是使他们可度量(可测试)。否则,QA不能测试它们,你将没有办法知道完成的产品是否已经实现了这些非功能性需求。

8、评审&修正

我有一个朋友-我们叫他Matt(他的真名叫Steve)。Matt在硅谷一家成功的公司做产品经理工作。最近我在午餐的时候碰到他是告诉我一个非常有趣的故事。

他们雇用了一个有三年经验的产品经理。在他被雇用的几个月里,不知何故他让他的产品经理同事和工程师一样疏远他。
他是罪犯?他基本上认为他的MRD就像一个法令。他写了它,但不想和任何人评审或在反馈的基础上修改它。他仅仅想工程师团队没有问任何问题的拿着它并实现它们!

不要像Matt的同事那样。确信做到和你的产品经理伙伴和工程师团队评审你的MRD。保持一个敞开的思想然后在评审反馈的基础上更新MRD。这将帮助你写出更好的MRD,工程师将喜欢你(或者至少少恨你一些),你的团队也将创造更好的产品。

9、定义市场目标和定位

大部分我看到过MRD在覆盖了市场目标(谁将买和使用户你的产品)和定位(与竞争对手的产品比你的产品定位怎么样的)的方面做的很好。

我还看到过一些没有描述市场目标和定位的MRD,他们通常会这样争辩:“为什么工程师们需要知道这些?拿到定义了什么是需要的还不够吗?”

这些问题(谁将买和使用户你的产品和与竞争对手的产品比你的产品定位怎么样的)的确有一些正面价值,我发现许多工程师想知道为什么一个产品或特性要开发,谁将使用他们,什么是他们可以另外选择办法。

这些信息帮助他们和产品组的其他成员想象最终用户并从而更好的为创造成功的产品工作。我的建议的尽可能的(在MRD中)包含这些信息。- 它们不一定要很详细,只要包含几个段落就足够了。

10、包含一个术语表

如果你的MRD使用了新术语或在非通用的地方是使用了常用术语-确保在MRD后面包含一个术语表。

当你像这样说“我们的软件将提供SME用户通过选择WAP或PSMS开MRC帐单”时,术语表将确保你的所有读者(有些可能不是技术人员)理解你的意思是什么。

产品需求文档PRD模版 from 人人都是产品经理

http://www.woshipm.com/xiazai/3680.html

该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档,其作用就是“对MRD中的内容进行指标化和技术化”,这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。

产品需求文档(Product Requirement Document,PRD)的英文简称。是将商业需求文档(BRD)和市场需求文档(MRD)用更加专业的语言进行描述。

文档意义

该文档在产品项目中是一个“承上启下”的作用,“向上”是对MRD内容的继承和发展,“向下”是要把MRD中的内容技术化,向研发部门说明产品的功能和性能指标。

文档撰写

在该文档中,基点依然是MRD中的内容,只是把重心放在了“产品需求”上,而产品需求本身是在MRD中有所体现的,区别就是在于,PRD要把MRD中的“产品需求”的内容独立出来加以详细的说明。

这部分是PD写得最多的内容,也就是传统意义上的需求分析,我们这里主要指UC(use case)文档。主要内容有,功能使用的具体描述(每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程,等几大块),Visio做的功能点业务流程,界面的说明,demo等。Demo方面,可能用dreamweaver、ps甚至画图板简单画一下,有时候也会有UI/UE支持,出高保真的demo,开发将来可以直接用的那种。

文档核心

该文档中,侧重的是对产品产品功能和性能(即“产品需求”)的说明,相对于MRD中的同样内容,要更加详细,并进行量化。

在一些国外的公司,是允许把MRD和PRD合并成一个文档的,通常叫做“Marketing & Product Requirements Document”。

产品需求文档模板下载地址: http://pan.baidu.com/s/1gdwyTcZ

附上海某知名互联网公司产品需求文档案例一份,woshipm.com版权所有,转载请注明来源,请勿用于商用,否则追究法律责任,谢谢。

下载地址: http://vdisk.weibo.com/s/aoFZDu6DkG5Mi

产品经理的5种能力 (2009-03-30 10:44:42)转载▼

标签: it 分类: 产品管理
产品经理的角色到底是什么?他们要想方设法得到企业高层的信赖与支持,他们要推动产品开发的进度,他们要用各种关系和资源推广自己的产品,他们甚至于要去完成很多细节的设计工作。
忽然之间市场对产品经理的需求有了如此之大的跨越?就像在前不久CSDN主办的软件开发2.0大会上,CSDN掌门人蒋涛所提到的:Business of Software已经成为我们不得不重视的一项工作,这也是我们为什么要从《程序员》的角度来看产品经理的原因。
产品的价值
任何一项单独的技术,在它没有被产品化之前,其应用价值都可以被看成是0。这绝非危言耸听!在技术社区,我们常常可以看到很多对纯技术顶礼膜拜的开发者。这其中不少圣徒对于如何做软件、如何做市场、如何销售技术的工作视而不见,这也是不少技术创业失败的根本原因。
下面我们作一个假设:如果一项好的技术其应用价值为1,那么基于这项技术所开发出的软件产品应用价值可以达到10;当然,软件市场上产品很多,但好的产品在其中的比例不会超过10%,由于产品并不仅仅包含技术,那么我们可以认为一个做得好的产品的应用价值超过100;即使你完成了一个很好的软件产品,如果没有有效的途径销售,或者获取其他资源,那么它并不能成为一个商品,而成为商品之后的产品影响力再大一个数量级是可以预计的,这样一个商品所带来的应用价值也许就是1000了;更进一步,市场上流行的商品或者是领域内领先的商品,其价值再乘以十倍,其应用价值则达到10000!或许有些人会认为这种计算方法有失偏颇,但相信大多数人此刻都已经明白,软件产品的价值其实并不仅仅只取决于技术。
我试图去说明的是软件产品的价值点,它不仅仅在于技术,但技术在软件产品中同样非常重要。倘若没有最初的1,那么也绝不会有后来的10000。
当然,上面这个笼统的假设并不能全面概括技术、产品设计、产品开发以及推广等相关工作的真正价值。不同的产品,对应的不同市场,是应该有不同价值点的。以现在很多互联网产品为例,推广的模式和资源成为了限制互联网产品发展的一个重要瓶颈。
更重要的是,作为产品所在的组织,其组织架构以及工作流程等方面也面临着重要的挑战。仅在软件开发阶段,需求工程、项目管理、开发方法、质量监督等多方面环节都可以说具备非常重要的价值,这也是完整产品不可或缺的重要组成部分。所有的这些工作汇总起来之后,产品的开发便成了一件极为琐碎的工作。协调和平衡各种各样的关系、充分调配资源、准确的把握产品发展策略等工作,在原有的组织结构里越来越难以开展。
正因如此,产品经理的职位才显得格外重要。这也是为什么我们看到最近一两年,寻求软件产品经理人才的企业越来越多的原因。若是按照前面假设的价值分布,他们正肩负着将技术价值从1放大到10000的压力,而他们所带来的价值,也是前所未有的。
产品经理改变世界
如果要给产品经理做一个严格的定义,相信每一个企业所给出的答案都是截然不同的。但毋庸置疑的是,几乎每一个成功的产品背后都有一个,或者一群人在担任产品经理职责。他们承担着产品成败的责任,有时甚至关系到这个企业的生存,这对于唯技术论者无疑是一个极大的讽刺。如果你看过市场上一些并没有太多技术含量的产品,就可以很容易地理解这一点。
那么对一个成功的产品,甚至是商品,哪些环节才是最重要的?在商品社会,生产和制造仅仅只是整个价值链当中的一小部分。经济学家郎咸平对于产业价值链环节的定义有个非常著名的6+1理论,其中的6包括:产品设计、原料采购、物流运输、订单处理、批发经营、终端零售,而那个1才是加工制造。
如果把软件产品当成市场上其他实体商品的话,那么6+1的理论同样适用于软件市场。技术所解决的问题,在很大程度上解决的是加工制造的问题,而真正在价值链上游的那个6,才是真正能够创造财富的环节。产品经理所做的工作,就是解决这个6的问题。
对微软创始人比尔?盖茨的评价很多,但是如果要我们选择比尔?盖茨众多丰功伟绩中最重要的一个时,那么多数人都会认为将软件商品化是他对数字时代最大的贡献。不管你是桌面电脑终端的用户,还是一个大型软件公司的总裁,如果没有软件的商品化,没有软件授权的协议以及这种模式的广泛流行,也许今天我们生活的时代还很保守。不管自由软件、开源软件如何攻歼微软的产品授权体系,但你不得不承认的是这套体系主宰了我们20多年来的整个软件商品市场。而微软,借助整个价值体系的6,成就了伟大的软件霸业。
毫不夸张地说,作为产品经理的比尔?盖茨改变了这个世界。然而,像他这样的产品经理,毕竟在人类历史上也寥寥可数;对于一般开发人员来说,除了踏踏实实做好软件,认认真真写好代码之外,产品经理这一职业发展通道还需要我们具备更多能力与基本素质。
成为产品经理
通过对超过20名各种软件产品经理的沟通,我们对产品经理的基本素质进行了简单的总结,多数人赞同产品经理需要具备下面的5项基本能力:
● 规划力
● 设计力
● 沟通力
● 执行力
● 推广力
当然,这并非意味着所有的产品经理都需要在上述5项能力上都达到满分的程度,甚至说某些人即使具备了上述5项能力当中的全部,也未必能够将产品做好。在采访著名的软件大师Martin Fowler时,当他谈及缘何能够成为软件大师,并成功推广“敏捷”这一产品的时候,他的回答是:“Luck, luck and luck!”由此可见,运气在打造一个成功产品的要素中扮演了很重要的角色。我们能做的,是在好运到来时能够把握住机会。
下面,让我们分别看看这五项基本能力所覆盖的范围以及它们在做产品当中的价值。
规划力
这是一个产品经理较高层面上的能力,而具备这种能力的产品经理,通常会具备很多思想家的特质。从产品外部体系上,规划力代表了产品经理对整个价值市场的认同,对企业产品线的布局,对自身产品的定位以及对每一款产品的发展思路。而在企业内部看来,它所代表的含义还不止这些,它包括对产品研发体系的设计,对资源协调制度的制定,对各种突发事件的把控等。在规划力上具备很强意识的产品经理,通常是产品的灵魂,也是技术团队崇拜的偶像,在一个软件企业或组织中,总裁、CEO等职位最容易成为这样的产品经理。
如果我们看一看今天软件市场上的很多产品就会发现,事实上,很多企业最大的产品经理是这个公司的实际决策人。很难想象一个产品在企业中得不到资源,将会如何发展下去,而事实上也只有整个公司的决策者们了解哪些产品对于他们的公司来说是最重要的。如果一个企业的生存状况,是通过其核心产品的市场状况来反映的话,那么这个产品一定要有比企业内部其他产品更具优势的资源。这一点对大公司来说尤其是这样,数量众多的部门,如何去做有效的权衡与取舍,是大产品经理的必修课。
今天,我们看到众多软件公司高喊的各种口号,其实就是产品经理们为争取更多市场资源的有效印证。SOA、SaaS、S+S、Web 2.0这些概念,无一不是为产品服务的。而为了达到这一目标,还要求企业有节奏、有步骤的一步一步迈向这些概念所提倡的目标。更有不少产品经理,为了达成既定目标,制定出种种制度,比如微软的里程碑制度,就是在这种强大规划力下的产物,从而进一步确保产品的研发和市场投放有序进行。
设计力
事实上,并不是每个软件企业的总裁或者CEO都是产品经理,有不少企业都有一个首席设计师或者首席架构师的职位。他们的工作目标是研究用户,通过各种手段将用户放在第一位,他们是用户的心理学家,他们知道用户最想要的是什么。
有个朋友在做互联网创业,他所在的团队对设计有很深刻的认识。因为用户看到页面的第一眼,就必须要知道他/她能做什么,这件事需要付出多大的代价。作为一个以评测为入门基础的互联网应用,如果无法得到用户的数据,其存在的价值就会大打折扣。通常这个时候,产品经理要紧盯用户的每一个行为,确保他们有耐心完成我们所期待的每一个动作。
耐心和细致在这项能力当中占据了极为重要的地位。今天我们看到很多软件产品界面上的元素,甚至经历过数百次不断的调整和修改,如果没有这些耐心细致的反复打磨,也许今天我们还停留在命令行软件的时代。无疑,软件世界中美好的一切,都不能不归功于产品经理。
沟通力
在不少企业里,新产品替代旧产品,逐渐成为企业核心竞争力的案例也常常见到。最初,这些产品经理没有多少骄人的权力,但他们却需要承担产品成败的责任,这种产品经理有些像外交家,他们能够通过各种方式有效地取得产品发展所需要的各种资源。
无论是组织内部还是组织外部,沟通都是很多技术人员并不擅长的一件事。这一点在需求工程的过程中显得尤其明显。例如与客户的沟通,软件工程的专家们发明了用例、用户故事等方法,来试图强化产品开发与用户之间的关系。这些方法和工具,今天已经成为大多数产品经理用来沟通的工具了。当然,没有什么比产品经理本身就是业务专家来得更直接的沟通方式,这无疑对产品经理提出了一个巨大的挑战。
此外,组织内部的沟通同样重要。跨部门的协调工作往往是产品经理最常见的工作之一。每天埋头在会议中的产品经理并不罕见,足以说明强大的沟通能力,将会是程序员迈向产品经理职业生涯的重要门槛。也许在一个企业里,公关经理也会成为产品经理,这丝毫不会让我们觉得奇怪。
执行力
建立敏捷企业今天似乎已经成为很多经理人的口号。当然,之所以称之为口号,是因为人们并没有完全实现它。真正敏捷的企业,像训练有素的军队那样行动,臂如指使。这必须建立在有效的执行以及快速的行动上。
市场的博弈,从某种程度上说对企业的挑战就是这一点。在面对强手如林的竞争环境下,很多企业甚至将执行力列在核心竞争力上。很多人批评今天的企业家用近乎军事化的管理来管理企业,然而很多成功的企业确实在用这样的体制开发产品。对应在软件企业当中,尤其以开发部门为要。产品能否按时交付,很大程度上反映了产品开发团队的战斗力,也很大程度上反映了产品经理的执行力与决断力。
正因为有太多臃肿缓慢的团队,限制了软件产品的发展,才导致很多天才般的技术最终被打败。因此,不少企业的产品经理,直接就是开发项目的项目经理,尤其是那些本身就充满了创意的产品,以最快的速度交付它,是实现竞争力的关键。
推广力
互联网的出现,彻底改变了软件的传播方式。当零售商店与盗版小贩不再成为软件传播的唯一途径时,软件产品的推广上升到了另外一种境界。即使开发一个普普通通的软件产品,也不愁没有第一批敢于吃螃蟹的用户,但要成就一个伟大的产品,却不能不对软件的推广有更清晰的思路。
如果我们回过头来看看历史,就会发现,软件产品的推广,其核心在于维持企业与用户之间的一种关系。这并非用一句简单的“以用户为中心”可以表达,而是要创造一种供需双方都无法退出的局面。如果今天微软说它即将倒闭,数十亿的用户都不会同意,因为架构在微软技术和平台上的产品将失去最后一层的保护,不会再有任何人为它们负责;同样,如果IBM今天宣布倒闭,全世界的银行和制造业等企业都会伸出援手,因为他们深刻地明白,双方都无法从这种局面里退出了。
在互联网时代,你会如何推广你的产品?互联网也好,销售渠道也罢,这些都是那些产品市场经理运作的手段,真正要将产品推向更广阔的市场,不仅要具备对市场的敏感、独到的眼光,更需要有产品的大局观。
其实,一个产品的生命周期是可以预期的。它基本上被分成三个部分,即策划、实施和营销。如何有效把握这三个阶段当中的每一个部分,会根据不同的产品策略以及不同的企业行为来决定。但通过访谈,我们却了解到了另外一个被普遍认同的共识:心态问题。
产品经理应该具备什么心态?如果说积极向上是一种心态,那么未免显得有点敷衍。然而,这并非本文的讨论范围,希望那些有志于成为产品经理的技术人员在掌握了强大的技能之后,能够更好的把握心态,做出震惊世界的产品。

本文转自:http://docs.chinapm.com.cn/2059.shtml

FRD

阿里交互设计
http://wenku.baidu.com/view/2076cd3a580216fc700afdfd.html

其他参考资料
魔方商业需求文档(BRD)实例
http://wenku.baidu.com/view/8abbdb00de80d4d8d15a4fe8.html?re=view
产品经理深入浅出第9课-市场需求文档(MRD)写作方法与技巧(上)
http://wenku.baidu.com/view/fbdeabb4f121dd36a22d8200.html?re=view
http://wenku.baidu.com/view/03d8cb064a7302768e99393f.html?re=view
19楼
http://wenku.baidu.com/view/79faf8eb81c758f5f61f6734.html
腾讯需求文档
http://wenku.it168.com/d_000248702.shtml

集萃
http://wenku.it168.com/tag/52890_0_1.shtml

http://wenku.it168.com/d_001418638.shtml
http://wenku.it168.com/d_001418635.shtml

唐杰
http://tangjie.me/tag/prd

互联网一些事
http://www.yixieshi.com/ucd/

有一个PRD模版,有功能列表的例子
http://download.csdn.net/detail/adengliang/3924249

淘宝的PRD
http://www.doc88.com/p-409278823857.html

6 非功能需求空缺
产品营销需求
规则变更需求
产品服务需求
法务需求
财务需求
帮助需求
安全性需求
7 上线需求
7.1 上线时限需求

再一个
http://wenku.baidu.com/link?url=LV_fUezf22KYxpYjQiD8E6tnPQC6hKTHk4dhtUTi23aes2fEgqnKX1ENyHkdgNjyWnNPJsc6t03zRpS4URjqtQr-brolR9QvqLb_Z4Nctau

还有一个
http://www.docin.com/p-231092823.html


本页面的文字允许在知识共享 署名-相同方式共享 3.0协议和GNU自由文档许可证下修改和再使用,仅有一个特殊要求,请用链接方式注明文章引用出处及作者。请协助维护作者合法权益。


系列文章

文章列表

  • Product 关于产品需求文档PRD

这篇文章对你有帮助吗,投个票吧?

rating: 0+x

留下你的评论

Add a New Comment