MRD、BRD、PRD、FSD、PSD、SRS、ROI、CPA.docx

通俗名解：MRD、BRD、PRD、FSD、PSD、SRS、ROI、CPA、(2009-11-24 14:59:19)转载标签： it 分类： 网站运营 经常听到有朋友在群里面问一些专有名词的缩写含义，恰巧在网上找资料看到这个帖子，故此转帖过来希望对朋友们有所帮助MRD　　Market Requirements Document，市场需求文档获得老大的认同后，产品进入实施，需要先出MRD，具体来说要有更细致的市场与竞争对手分析，通过哪些功能来实现商业目的，功能/非功能需求分哪几块，功能的优先级等等实际工作中，这个阶段PD可能的产出物有Mind Manager的思维图，Excel的Feature List等　　市场需求文档（MRD）重点放在为一个被提议的新产品或者现有产品的改进定义市场需求与BRD指出商业问题和解决这些问题的解决方案不同，MRD更深入提议解决方案的细节它包括一些或者所有这些细节： a. 解决商业问题所需要的特色 b. 市场竞争分析 c. 功能和非功能需求 d. 特色/需求的优先级 e. 用例　　MRD通常是由拥有产品经理，产品营销经理或者行业分析师头衔的人撰写的。

MRD通常是一份连续的5-25页Word文档，或者正如之后描述那样在一些机构中甚至更长 BRD　　Business Requirements Document，商业需求文档这是产品声明周期中最早的问的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，通常是和老大们过的ppt，所以也就比较短小精炼，没有产品细节　　商业需求文档重点放在定义项目的商业需求BRD要能说出客户碰到的一个或多个商业问题，并且通过公司的产品能够解决这些问题接着建议一个方案 —— 通常是新产品或者现有产品的改进来解决这些问题BRD也可能包括一个高级的商业案例，例如收益预测，市场竞争分析和销售/营销策略BRD通常是由拥有产品经理，产品营销经理或者行业分析师头衔的人撰写的在小公司，可能由高级主管或者甚至创始人撰写BRD通常是一份连续的1-3页Word文档，或者不超过10页的Powerpoint文档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通常是由拥有产品分析师，工程领导或者项目经理头衔的人撰写的 – 作者通常属于工程部门通常一个连续几十页的Word或类似文档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，公司某一类型产品或全部产品的平均销售价格（或称出厂价格）公式为：销售额出货量平均售价是分析预测制造业公司销售收入和毛利率的重要指标，是投资者需要密切跟踪和计算的经营数据在销量不变的情况下，平均售价提高可以增加销售收入和毛利率，在销量下降的情况下，如果公司能提高平均售价可以降低销售收入和毛利率下滑的程度，当然，最好的情况是价升量增，销量和售价都出现增长公司产品平均售价提升主要来自于产品结构的改善，如彩电生产企业近年来产品平均售价增长就是因为高价格的平板电视销售比重显著提升。

所以，把握制造业公司业绩增长的两项最重要的因素就是产品销量和平均售价的变化写好MRD的10种技巧MRD-“市场需求文档”，是产品经理或者产品市场经理编写的一个产品的说明需求的文档这些文档用于计划一个新产品或修正一个已有的产品，是被工程师团队开发产品时使用　　在硅谷的一些软件公司，MRD仅仅覆盖high-level的功能在这种情况下，产品经理通过创建了另一个文档-通常指的是PRD（产品需求文档）来定义更加详细的产品需求　　在本文中，我用术语“MRD”泛指所有那些由产品管理和/或产品市场团队创建的，为工程师团队传达产品需求为目的的文档　　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是第二高。