Follow your heart(180)---tmd的 那些各种D文档

我4月去杭州,找好友谈一起做的事情,她推荐了一个人加入,然后要我写什么PRD,我才知道,那叫产品需求文档,可是,我有啊,只是我直接就加了很多设计进去, 不是完全把自己作为客户的,好友发了一个他们公司的PRD文档,那是一个非互联网产品的产品,是硬件产品,是家大网络公司,我看了觉得和我这个非常不符合.我不知道,为啥我要写成那样的.

后来,那人又要我写和竞争对手的比较什么的,问,我和他们比的优势在哪,能不能有把握一定战胜别人,我说,我都和你说了有哪些所谓的竞争网站,也列了单子了,也说了人家的优缺点,你问我,能不能战胜人家,我就不知道了,我说能,你也不一定信啊,而且,那个也没必要那么比啊...这个要你自己判断,后来,我知道,这个应该不是PRD,算是所谓的MRD.

我是自己做东西,为了要请人加入,不停地在写那些这个D,那个D的文档,反正到现在,做的其实都是这些事情.

今天看了一篇帖子,转来. 以后再谈谈我对这些tmd的D的看法.我现在真的太多感受了,我写了那么多.http://www.reirii.com/?p=376

MRD、BRD、PRD、FSD、PSD、SRS、ROI、CPA、ASP
经常听到有朋友在群里面问一些专有名词的缩写含义，恰巧在网上找资料看到这个帖子，故此转帖过来。希望对朋友们有所帮助。
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，公司某一类型产品或全部产品的平均销售价格（或称出厂价格）。公式为：销售额÷出货量。
　　平均售价是分析预测制造业公司销售收入和毛利率的重要指标，是投资者需要密切跟踪和计算的经营数据。在销量不变的情况下，平均售价提高可以增加销售收入和毛利率，在销量下降的情况下，如果公司能提高平均售价可以降低销售收入和毛利率下滑的程度，当然，最好的情况是价升量增，销量和售价都出现增长。公司产品平均售价提升主要来自于产品结构的改善，如彩电生产企业近年来产品平均售价增长就是因为高价格的平板电视销售比重显著提升。所以，把握制造业公司业绩增长的两项最重要的因素就是产品销量和平均售价的变化。

评论

2 楼 Jennycn 2011-12-12  

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

这篇讲用axure写PRD的

估计我以后就用这个了:)

本文想说的事情是，那个叫PRD文档的家伙只是个称呼而已，PRD的问题不在于如何写而在于如何被传递与执行。这里简单介绍一下我基于axure-rp的一种新的PRD写法。（友情提醒：从来不用axure，认为他笨重无比的人请路过。）

从半只脚迈入产品经理这个大门的那天起我就被2个文档的名称深深的纠缠着，他们是市场需求文档（MRD）、产品需求文档（PRD）。先不论你是什么方向的PM，这2个玩意一定会一直伴随你的Title跟着你。这2个文档在不同的团队中有不同的叫法和写法，我也见过有团队的MRD其实就是PRD，不沾半点商业市场分析的边的，当然，这些不是本文探讨的内容。

长久以来，有个很有趣的现象：“有没有PRD模板，PRD该咋写”这个问题已经成为新手入门经典必问题目之一；如果1年以后这个家伙还在这行里混，他一定会抱怨，娘滴，我们的QA压根就不看我的文档、我们的交互（如果有这个职位的话）还是会问我一些我写的很明白的问题、我们的测试拿着文档问我该咋测试、….

Web页面之间的关系是网状的，而Word文档只能树状的表述，这无疑是矛盾的；PRD文档无法做到实时更新发布，我回顾了我第一年写的PRD文档，很多下面的修改栏都是空的，惭愧之至….；所谓一图胜千言，万言刚够文档标准，每个PRD都是臭长臭长的，这样的东西别说交互设计师了，很多PM自己写完了都不想看。所以，我武断的认为，撰写某些PRD文档实在是一个既耽误时间又费劲且不敏捷的事情（很多PRD都是一夜情，写完了就不会修改更不会有人乐意看100P以上的文档），是在让产品经理实现慢性自杀！

个人认为，一个PRD文档需要包含以下的内容：

1、概述
1.1、名词说明：文档中涉及到的名词
1.2、产品概述及目标
1.3、产品风险预估
1.4、产品开发进度：产品开发阶段及责任人与时间节点
2、使用者需求
2.1、使用者需求描述：定义用户是谁
2.2、管理员需求描述：后台管理部分（很多人会忽略这个部分）
2.3、任务流程图：从业务逻辑流程到产品逻辑流程转化
3、功能需求
3.1、功能总览
3.2功能需求分解：界面分解及交互说明和用例
4、非功能需求：与该产品相关联的辅助产品等
5、上下线需求：产品的生命周期
6、运营计划：产品的上线后的反馈与改进

整个文档中，最大的部分其实是对功能需求的分解，但是最核心的部分是使用者需求与功能需求部分。使用Axure后，我发现Axure可以很好的承载我平常写的这个产品需求文档的全部内容，最主要的问题是，Axure是可以网状的展示的。下面是举个例子：



在Axure的站点导航中，默认的Home页面承担了PRD文档的第一部分内容；而使用者需求描述及任务流程图也可以由Axure自带的流程图功能完成；任务流页面的分解本来就是Axure中完成的；最后的非产品功能部分也可以由axure完成（文本块组件）

同时，Axure支持多种格式的输出，一般情况下我是发送给团队Html文件包，也可以是.chm格式的文件（团队协作目前还没有尝试）。该文件包打开后，左侧是整个系统的导航菜单，右侧是相应的说明。最主要在于，原型中的页面是可以相互跳转的（得益与axure的强大交互功能），同时页面有注释功能。所以，整个产品需求文档真正实现了基于产品的模拟，网状的传播，而不是Word式的树状阅读。

1）见过不少新手使用Axure生成的原型有页面是空白的，我问为什么，他说这个页面不知道放什么，但是又不能不命名，否则逻辑上有些不通。实际上，这个空白页面就可以用来放这个页面的流程图及整体的说明。

2）不建议做太复杂的Axure动作，比如使用多个层、动态面板等。因为在工程师等的眼里原型图是不可以点击的（基于viso等的惯性思维），所以，为了避免花很长时间去实现一个很炫的axure交互而最后被埋没，建议把任务分解来画。比如一个输入框，需要画：默认状态、获得焦点状态、输入字符判定状态、失去焦点状态等，按照逻辑分步来展示。（在我特别蛋疼的时候我会先分步展示，然后搞个比较炫的交互放在上面自己玩或者用于演示）

3）在每个页面的下方或者侧边（由页面大小来定）要放一个功能详解的文本块来对本页面的功能进行详细说明。也可以直接使用Axure自带的注释功能（组件注释、页面注释）为什么不推荐用Axure的组件注释功能？因为这个功能在生成的原型里是被隐藏的，有被人无视的可能。

4）使用axure的组件库功能（可自制）和模块功能既可以保证设计的统一性（设计规范），又可以提高原型制作的效率。图中我采用了注册模块。

下面，QA时间（这个QA是问答，文中的QA是技术，呃，注意区分）

Q：为什么我看到有的书上说要写N多文档，带RD的有：BRD、MRD、PRD、….
A：是的，有这样的定义。BRD（商业需求文档）、MRD（市场需求文档）、PRD（产品需求文档）。每个公司的风格不一样，我个人倾向于把BRD与MRD整合，PRD单独做。但是MRD与PRD中会有内容重合，就是会同时提到用户是谁？为什么要做？产品目标是什么？等几个问题

Q：Axure有个功能是可以导成Word格式，把做的原型导入后是归类好的，包含了用例文档，为什么不这么玩呢？
A:没人说不可以这么玩。还是那句话，个人习惯。

Q：除了页面原型之外你塞了这么多东西到Axure里，会不会导致源文件以及生成的文件体积巨大？
A：实际上塞进去的东西都是文本，使用axure的文本组件完成的，体积并不会大。同时，请不要在用axure做原型的时候使用过多的图片，尽量是用组件和模块完成。我目前位置做的最大的一个原型是4.7M，这是一个完整的系统原型。

Q：按照你的写法Axure好像是万能的了？
A：没有不好用的工具，只有用的不顺手的人。人是活的，工具是死的，且Axure目前在mac平台下功能并非很强大，也有很多人觉得axure很笨重，更加喜欢轻量级的原型功能。不过，这些都不是核心问题，核心问题是要让你的团队能够以最高的效率进行合作。使用Axure的人不必鄙视Viso，用excel的人也不必羡慕OmniGraffle，拿Word的人也不必留恋firework。

既然提到了MRD也顺便说下我写这个文档的习惯。一般情况下这个文档是给老板看的，主要是对市场的分析、同类产品的竞品分析、我们产品的盈利预测等等。所以，一般由PPT来完成。你的文档越长老板越反感，你的文档文字越多老板越没兴趣，所以，PPT是最好的方式。

文档这个东西跟流程有类似的地方，大公司会相当重视这个事情，因为要规避风险。流程与文档的核心点在于如何高效传递如何快速执行而不是他如何写以什么形式写。相对于小团队而言，流程之殇大可避免。当然，如果大公司能够以小团队的心态去做大产品的话，定会事半功倍！我更相信小团队大产品的力量，而不是大团队大产品的说法。

1 楼 Jennycn 2011-12-12  

nnd哦,我的PRD,fsd都很仔细了啊