MoDoFo.println(”

转自：http://bbs.bianews.com/thread-69395-1-1.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、小心的使用模板
  [...]

转自 http://bbs.bianews.com/thread-69395-1-1.html
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通常是由拥有产品分析师，工程领导或者项目经理头衔的人撰写的 – 作者通常属于工程部门。通常一个连续几十页的Word或类似文档。

原文地址
互联网公司的PM(产品经理)该如何写文档

作 为互联网公司的PM(产品经理)，我们需要面对众多部门，因为自己就是项链里的那根线。需要书写各种文档，最常见的就是PRD(产品需求文档)，当然根据 重量级和时间等多因素，可以提交不同类别的，例如DRD(设计需求文档)和ERD(工程需求文档)。嘿嘿，DRD和ERD是我自己发明的。更多小的ECR 级别项目中，文档大家写的都很自由。
　　今天晚上在跟工程师讨论中，得到了一些启发，摘录部分。
　　给工程师看的文档 　　1 工程师喜欢看结构化文档，不喜欢看描述性文档。 　　描述性文档也要给工程师看，并且最好亲口说，因为这对理解产品策略和发展方向有帮助，工程师可以帮助PM弥补没考虑到的地方
　　2 工程师喜欢流程图甚于Mockup，而Mockup是给领导给Marketing等成员看最合适； 　　并不绝对，初级工程师反倒喜欢mockup，而高级工程师经验多了两者没区别
　　3 Mockup是画大饼，产生食欲，争取资源和获得理解的方式。“有照片的菜单永远比只列菜名的菜单受欢迎”，这是马总说过的； 　　Mockup务必不要过于精细，否则累的是PM，领导和其他团队会一开始就进入细节盘问阶段，不利于表述产品目的和大的功能模块
　　4 工程师更喜欢菜谱，而且是西式菜谱。做一道菜需要几分钟，几滴色拉油，烤炉温度和时间，需要哪些工序，前后顺序和量化归纳。 　　这个并不绝对，聪明的工程师不喜欢菜谱，不喜欢纯粹编码。有些时候不妨像做中国菜一样，给对方发挥余地。只是碰上好搭档的概率不多，更多情况下菜谱更保险
　 　5 软件工程是西方的泊来物，标准化文档非常重要。很多老外PM希望达到一种境界，进行完详尽的分析和文档后，开发人员按部就班就行了。中国人做菜喜欢个性发 挥，油盐酱醋通常都需要自己拿捏，菜谱上多“少许、半勺、少量”等描述性词语。有时候PM也希望工程师这样做菜，我们想吃甜味，但放多少克糖是需要厨师自 己揣摩。
　　6 自己揣摩有利有弊，好处是PM省心，坏处是项目不可控。如果从风险角度考虑，软件工程中的过程改进及文档管理是受欢迎的。
　　给界面设计师看的文档
　　除了工程师，那么UI设计师的DRD(设计需求文档)又该怎样拿捏？
　　MS Office的Visio在PM中比较受欢迎，对于那种没有FW和PS操作经验的PM来说就更重要了。当然你也可以使用Word，但Word在画框图方面可视为不专业，对于入门级PM或者轻量级设计框图也适用。
　　对Word下了这么个定论，非常惭愧。工具是死的，人是活的，高级PM也能做到拈花折枝即可杀人的境界
　 　根据我的经验，如果项目一旦正式启动，PM最好不要采用Photoshop或者Fireworks等软件自己来做设计。那样会让自己陷入细节，总想着跟 UED去PK设计技巧，做了自己不该做的事。因为Visio已经将模块做成控件，所以自己不需要拉框线，做精细的按钮。
　　对于界面设计，除了正常的界面文案外，其他辅助性文字尽量使用一整块的灰块表示，PM不要陷入按钮和字体设计中。PM的眼睛应该像眺望远方一样，看到的只是起伏的群山轮廓，至于山上长的树是什么颜色，相信UED。
　 　倘若PM有空余时间，而且项目并非公司会投入UE资源去做的，还处于idea阶段。那么自己不妨用PS或FW做些精细设计。毕竟在立项前，PPT中配上 能看上的图，会增色很多，也更有说服力。让每个人头脑中不会出现1000个想象的产品，可以统一起来。至于精细到多细，要自己把握，这很花费时间的。一个 半成品的Demo专业UED也需要2－3个工作日，拿业余时间设计是不可能精细到那种地步。如果非要有个衡量标准，那就是图层尽量控制在100个以内，不 要使用需鼠标贝赛尔曲线效果，少用染色效果，不用滤镜。
　　给UED的设计稿，参考纸媒在版排前的草图，那种黑白框线，文字用灰色细条代替。有空我再思考总结如何具体把握。如下图：
名词解释： RD：Research and Development,在这里是指研发人员，就是公司的工程师 Mockup：图样，原型图，在这里的意思是初始设计图 UED：User Experience Designer ，用户体验设计。