1、网编教材 互联网产品经理必备文档介绍(转)互联网, 文档, 经理BRDBusiness Requirements Document，商业需求文档。这是产品声明周期中最早的问的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，通常是和老大们过的 ppt，所以也就比较短小精炼，没有产品细节。商业需求文档重点放在定义项目的商业需求。BRD 要能说出客户碰到的一个或多个商业问题，并且通过公司的产品能够解决这些问题。接着建议一个方案 通常是新产品或者现有产品的改进来解决这些问题。BRD 也可能包括一个高级的商业案例，例如收益预测，市场竞争分析和销售/营销策略。BRD通常是由拥有产
2、品经理，产品营销经理或者行业分析师头衔的人撰写的。在小公司，可能由高级主管或者甚至创始人撰写。BRD 通常是一份连续的 1-3页 Word文档，或者不超过 10页的 Powerpoint文档。MRDMarket Requirements Document，市场需求文档。获得老大的认同后，产品进入实施，需要先出MRD，具体来说要有更细致的市场与竞争对手分析，通过哪些功能来实现商业目的，功能/非功能需求分哪几块，功能的优先级等等。实际工作中，这个阶段 PD可能的产出物有 Mind Manager的思维图，Excel的 Feature List等。市场需求文档（MRD）重点放在为一个被提议的新产品或
3、者现有产品的改进定义市场需求。与 BRD指出商业问题和解决这些问题的解决方案不同，MRD 更深入提议解决方案的细节。它包括一些或者所有这些细节：a. 解决商业问题所需要的特色b. 市场竞争分析c. 功能和非功能需求d. 特色/需求的优先级e. 用例MRD 通常是由拥有产品经理，产品营销经理或者行业分析师头衔的人撰写的。MRD 通常是一份连续的 5-25页 Word文档，或者正如之后描述那样在一些机构中甚至更长。PRDProduct Requirements Document，产品需求文档。进步一细化，这部分是 PD写得最多的内容，也就是传统意义上的需求分析，我们这里主要指 UC（use cas
4、e）文档。主要内容有，功能使用的具体描述（每个 UC一般有用例简述、行为者、前置条件、后置条件、UI 描述、流程/子流程/分支流程，等几大块），Visio 做的功能点业务流程，界面的说明，demo 等。Demo 方面，可能用 dreamweaver、ps 甚至画图板简单画一下，有时候也会有 UI/UE支持，出高保真的 demo，开发将来可以直接用的那种。产品需求文档（PRD）重点放在为一个被提议的新产品或者现有产品的改进定义市场需求。与 MRD侧重于从市场需要角度看需求的不同，PRD 侧重于从产品本身角度看待需求。通常在特点和功能需求上更深入细节，并也可能包括屏幕截图和用户界面流程。在那些 M
5、RD不包括具体需求和用例的机构中，PRD就包含这些具体内容。PRD 通常是由拥有产品经理，行业分析师或者产品分析师头衔的人撰写的。PRD通常是一份连续的 20-50页 Word文档，或者针对复杂产品甚至更长。提醒：一些机构将这里描述的 MRD和 PRD合并成一个文档，并称最后的文档为 MRD。在这种情况下，MRD包括本段描述的内容，也包括上一段描述 PRD的内容，并且可能超过 50页。FSDFunctional Specifications Document，功能详细说明。有一点像“概要设计”，这步就开始往开发衔接了，产品 UI、业务逻辑的细节都要确定，细化文档并保持更新。相应的，有很多内容，
6、比如表结构设计，要由项目经理来编写了。功能规格文档（FSD）把焦点集中在实现，定义产品功能需求的全部细节。FSD 可能通过一张张的截屏和一条条功能点来定义产品规格。这是一份可以直接让工程师创建产品的文档。与 MRD和 PRD侧重于以市场需要和产品角度看需求不同，FSD 把重点放在了以表格形式定义产品细节，再让工程师实现这些细节。FSD 也可能包括完整的屏幕截图和 UI设计细节。FSD 通常是由拥有产品分析师，工程领导或者项目经理头衔的人撰写的 作者通常属于工程部门。通常一个连续几十页的 Word或类似文档。写好 MRD的 10种技巧2008-04-22 13:14MRD-“市场需求文档”，是产
7、品经理或者产品市场经理编写的一个产品的说明需求的文档。这些文档用于计划一个新产品或修正一个已有的产品，是被工程师团队开发产品时使用。 在硅谷的一些软件公司，MRD 仅仅覆盖 high-level的功能。在这种情况下，产品经理通过创建了另一个文档-通常指的是 PRD（产品需求文档）来定义更加详细的产品需求。在本文中，我用术语“MRD”泛指所有那些由产品管理和/或产品市场团队创建的，为工程师团队传达产品需求为目的的文档。写好 MRD的 10种技巧1、从用户角度的编写从用户角度编写需求内容。使用“用例(Use Case)”和“用户角色（User Personas）”来达到这个。考虑用以下两种方法来详
8、细说明你们公司正在开发的 SFA（sales force automation）软件的“Login”的功能性。方法 A：用户通过一个要求用户提供证书的登陆界面，然后软件允许用户带着特定的权限进入系统。软件鉴别这些证书，在鉴定通过的基础上允许用户访问那些他们有权限访问软件的功能部件。方法 B：Mike是一个销售经理，Cathy 是一个销售代表。当他们打开软件，他们看到登陆界面。他们通过用户名和密码进入系统。如果用户名和密码是正确的，他们能登进系统。一旦登陆进系统，Mike 能访问软件所有的功能部件。Cathy 只能访问那些对销售代表有有效的功能部件。哪个方法更加容易阅读和理解?就我的看法,毫无疑
9、问，“方法 B“。还有，它同时减少了令人烦恼的阅读！2、使用 Screen Shots使用 Screen Shots或者 mockup来你的想法。我们中很多人都听说过“一张图片好比一千个文字”。当提到写 MRD的时候，一个 screen shot好比一千个文字！举个例子,看看下面这个 screen shot，你需要多少字来描述？我想可能不只一千个字。3、用简单的语言编写在我超过 11年的行业中，我通常注意到的（更多是令我懊恼）一件事是用很做作的语言来写的 MRD。我想这个主要是因为 MRD听起来是正式的和专业的原因吧。相反，想象你写的 MRD是写给你的在工程师团队工作的朋友。你的目标是帮助他理
10、解你需要什么，以便于他能开发产品实现这些需要。这个将有助于你避开陷入那些令读者人厌烦（有时他们会把MRD撕碎然后再碎片喂给碎纸机）的用做作的语言的陷阱。还有：a)保持简短的语句，把长的语句分解成多个小的语句。b)避免大篇幅的连续文本，把他们分解成多个小的章节。c)把大块文本内容分解成，screen shots，表格、重点列表等等。4、小心的使用模板我发现 MRD模板非常有用。他们的几个好处包括：a) 模板提供了一个标准的格式，使那些不得不阅读大量 MRD的读者更加容易阅读。b) 模板让新的产品经理快速的写 MRD变得容易，因为公司与公司之间的 MRD内容是不同的。c) 模板确保你不会忘记所有需
11、要在 MRD中覆盖描述的部分；然而，一些公司过分的使用模板。一个硅谷最大的公司之一有一个所有部分被强制使用的近 60页的模板。我觉得这个让人觉得非常难以忍受并且有几个负面的作用：a) 产品经理害怕但又不得不写 MRD - 几乎和不得不和 Dick Cheney去南德克萨斯打猎一样（译者按：美国副总统 Dick Cheney在南德克萨斯打猎时意外的打伤了和自己一起去的打猎伙伴）。b) 工程师团队害怕但又不得不阅读 MRD。c) 写 MRD和读 MRD都需要花大量的时间。我推荐你使用 MRD模板，但确保他们不要过分的长。还有如果需要，确信产品经理可以灵活的跳过模板某些部分和创建新的内容。5、区分需
12、求的优先级在这些年里，我从来没有碰到一个工程师团队实现了 MRD里包括的所有特性的没有删减的项目-通常由于那些我们控制之外因素！这就是说作为 MRD作者的产品经理，当出现需要决定取舍的时候，应该提供一个办帮助让他们决定那些特性要实现那些可以推迟。区分需求的优先级是一个最好的能帮助完成这个事情的办法。我发现把需求分等级就像P1，P2，P3.这样工作的刚刚好。在这个分类中-P1 是最高优先级，P2 是第二高优先级等等。最好的决定一个已经明确的需求的优先级方法这个需求实现后的好处-包括你的客户和你的公司。在实际实践中，最好是和其他多种因素一起综合决定。我推荐你只要包括 P1，P2，P3 的需求在你的
13、 MRD中，在多数的项目中更低的优先级可能未必会实现。还有这样也让 MRD变得更加容易读。6、说明“是什么“和“为什么“，但不要“如何“产品经理为理解客户的需求负责，然后基于这些理解定义什么和为什么需要开发.有一件比任何事情让开发者发疯就像在几英里外都能听到的汽笛在他们耳边尖叫一样的是一个令人痛苦的详细描述了怎样实现每一个需求细节的 MRD。考虑你们公司正在开发的以下两种描述 CRM“Login”功能的方法。推荐-描述“是什么”Mike是一个销售经理，当他打开我们的 CRM软件，他会看到一个登陆界面.登陆界面建议提供“记住我”复选框。如果 Mike在点击登陆按钮之前选择了该复选框，我们的软件将
14、记住并且在他下次来到登陆界面时自动填写他的名字。不推荐-描述“怎么样”Mike是一个销售经理，当他打开我们的 CRM软件，他会看到一个登陆界面.登陆界面建议提供“记住我”复选框。如果 Mike在点击登陆按钮之前选择了该复选框-将通过 Javascript 保存他的名字以 cookie的方式写到他的硬盘。当 cookie写到硬盘后，用户名和密码将被发送到服务器。下一次 Mike来到登陆界面时，Javascript 将读取他的 cookie，成功读取后，Javascript 将是适当的 DOM命令填充登陆页面上的用户名。好的产品经理擅长理解用户的需求和描述什么需要实现，好的工程师擅长决定怎么样实现
15、它。好的工程师希望能自由的决定怎么样最好的实现用户希望得到的东西。我注意到有技术背景的产品经理尤其喜欢描述“如何实现”。如果这些描述的就是你，应该从现在开始不要再做这样的事了。工程师们将会感谢你。附：这里有一些例外的情况-当在描述“是什么”中描述“怎么样”是必要的，当描述“是什么”的最好的方式和/或唯一的方式就是描述“怎么样”的情况。7、覆盖非功能性需求尽管功能性需求描述产品的功能，非功能性需求描述系统特性，如：a)性能b)可伸缩性c)可用性d)国际化e)等等.我注意到因为许多产品经理和产品市场人员认为这些是“技术细节”，而在 MRD中被忽略。我发现这些是我的 MRD中非常重要的一部分，工程师
16、们会非常感激在 MRD中定义这些需求。要点：当写非功能性需求的时候，尽可能的是使他们可度量（可测试）。否则，QA 不能测试它们，你将没有办法知道完成的产品是否已经实现了这些非功能性需求。8、评审&修正我有一个朋友-我们叫他 Matt（他的真名叫 Steve）。Matt 在硅谷一家成功的公司做产品经理工作。最近我在午餐的时候碰到他是告诉我一个非常有趣的故事。他们雇用了一个有三年经验的产品经理。在他被雇用的几个月里，不知何故他让他的产品经理同事和工程师一样疏远他。他是罪犯？他基本上认为他的 MRD就像一个法令。他写了它，但不想和任何人评审或在反馈的基础上修改它。他仅仅想工程师团队没有问任何问题的拿
17、着它并实现它们！不要像 Matt的同事那样。确信做到和你的产品经理伙伴和工程师团队评审你的 MRD。保持一个敞开的思想然后在评审反馈的基础上更新 MRD。这将帮助你写出更好的 MRD，工程师将喜欢你（或者至少少恨你一些），你的团队也将创造更好的产品。9、定义市场目标和定位大部分我看到过 MRD在覆盖了市场目标（谁将买和使用户你的产品）和定位（与竞争对手的产品比你的产品定位怎么样的）的方面做的很好。我还看到过一些没有描述市场目标和定位的 MRD，他们通常会这样争辩：“为什么工程师们需要知道这些？拿到定义了什么是需要的还不够吗？”这些问题（谁将买和使用户你的产品和与竞争对手的产品比你的产品定位怎么
18、样的）的确有一些正面价值，我发现许多工程师想知道为什么一个产品或特性要开发，谁将使用他们，什么是他们可以另外选择办法。这些信息帮助他们和产品组的其他成员想象最终用户并从而更好的为创造成功的产品工作。我的建议的尽可能的（在 MRD中）包含这些信息。- 它们不一定要很详细，只要包含几个段落就足够了。10、包含一个术语表如果你的 MRD使用了新术语或在非通用的地方是使用了常用术语-确保在 MRD后面包含一个术语表。当你像这样说“我们的软件将提供 SME用户通过选择 WAP或 PSMS开 MRC帐单”时，术语表将确保你的所有读者（有些可能不是技术人员）理解你的意思是什么。trackback:http:
19、/ MRD2007-10-17 20:05:42联盟里有个朋友找 MRD的模板，我正好手头有一份，就回了个帖子，结果没想到，要这个模板的朋友还挺多，后来我想了想，模板这种东西其实就是个工具，本身没有什么价值，只不过是产品管理者想法的文字体现而已，与其只发给大家模板，不如介绍一下这个工具怎么来用，就算是好人做到底吧，呵呵！说到 MRD，就不得不说一下 PRD，也有朋友提到了这个问题，MRD 和 PRD有什么区别呢？如果大家看过联盟的第一期和第二期杂志，那么就应该知道 MRD和 PRD的区别和关系了，在这两期杂志的“PM 词典”栏目中，就对这两个工具进行了介绍，先来分别看一下。做个表格来说明一下两
20、者之间的关系：从这个表中可以看出，MRD 本身并没有什么特殊之处，按照产品管理者的工作内容来说，是必备的东西，但是，我们知道，现实的情况是，许多技术型的公司实际上对产品管理者的定位过于狭隘，非要生生地把产品管理者分为“技术型”、“市场型”，本来一个完整的产品管理过程和管理内容，就这样支离破碎了。关于这个问题抽时间，咱们再一块讨论，还是重点讲 MRD。正是因为这个原因，许多技术型企业的产品管理者很少或者几乎没有接触过 MRD，并不是说大家没有这个意识，其实，作为产品管理者，这些市场端的东西多少都会有了解的，但是，企业并没有把这个任务交给产品管理者来做，因此，就显的有些陌生了。在表格中，已经提到了
21、，MRD 起着一种“承上启下”的作用，“向上”是对不断积累的市场数据的一种整合和记录，“向下”是对后续工作的方向说明和工作指导。这个很容易理解的，那么，具体到这个文档中，都包括什么内容以及如何来完成好这些内容呢？接下来，我就自己的一些经验说说个人的想法，对不对的，大家见谅。刚才说到了，MRD 就是对产品所在市场数据的整合，说白了，就是对市场分析后的结论体现，那么，在这个文档中，需要体现哪些内容呢？在我看来，需要体现的主要内容包括：1、市场的问题和机会；2、市场特征；3、用户特征；4、使用者特征5、市场的需求。分别解释一下：1、市场的问题和机会。在这个主题中，主要是要求产品管理者说明自己负责的产
22、品现在所处的市场都有什么问题和机会、面对这个现实的市场，产品有什么问题和机会，以及产品所需技术面临的问题和机会。其实就是要求从市场层面、产品层面、技术层面来阐述问题和机会。2、市场特征。在这个主题中，主要是要求产品管理者说明目标市场的现状和趋势。应该包括的信息有：目标市场特征；目标市场趋势；目标市场细分；目标市场时间约束。3、用户特征。这里的用户是个广义的概念，它其实包括两个方面的信息：1、客户（customer）；2；购买者（buyer）。在这个主题中，主要是要说明这产品的目标用户的特征、细分、动机、影响因素以及用户期望（目标）。4、使用者（user）特征。之所以把这个主题独立出来，就是因为
23、，无论什么产品，最终是要由具体的人来介入的，这类人才是产品的最终享受者，具体到产品上，其实我们日常分析的产品需求和功能都是基于他们考虑的。在这个主题中，要说明这类用户的特征、现实需要和相关联系。这里插一句话，我看到国外的一些公司是采用了原型塑造法来完成这个主题的，关于这个方法，抽时间再说，呵呵。备注：关于客户（ customer）、购买者（ buyer）、使用者（ user）的区别和关系，如果有朋友还有不解的地方，可以一块来讨论，嘿嘿。5、市场的需求。这个就比较容易理解了，就是把市场需求按类别描述出来即可，具体的标准，大家应该很清楚的，就是“描述性的语言来说明用户的期望”，主要包括的内容有：功
24、能分类；开发环境说明；兼容性说明；性能说明；国际性说明；文档说明；外观说明；发布说明；支持和培训说明；其它说明；方案概述；技术概述。当然了，我是把可能出现的内容都列举出来了，在实际的情况中，肯定会根据行业和产品的不同有所删减，这个仅供参考哈。在这个主题的最后，我建议大家加一个表格，就是“需求概要表”，这个表格的作用就是用列举的形式来把所有市场需求记录下来，毕竟上面的内容都是描述性的，这个表格有助于快速浏览。这个表格应该包括的内容有但不仅限于：实现目标；约束条件；需求联系；原型；类型；优先级。简单介绍了一下 MRD中主要体现的主题，大家看一下，其实内容很简单的，但是，我在看了一些MRD后，才感觉
25、到，写好一份 MRD，那是相当的不易呀。首先，在 MRD中必须有许多的数据来支持你每个主题的结论描述，其次，在 MRD中，涉及到了一些具体的方法，例如刚才说到的原型法，三，MRD 是整个产品项目过程中非常重要的一份文档，或者说，这份文档奠定了接下来的一些列工作基础，MRD 做好了，其它的工作都没有问题，这个作不好，其它的都不可能让人满意的。因此，要写好 MRD，是不能脱离产品项目流程和思想的，这个说起来，就太大了，有时间咱们慢慢聊。大家在现实的工作中，偏重于 PRD的居多，大家可以想想，是不是通常把主要精力放在了产品功能上了，而忽视了对产品所在市场的关注和分析，尤其是在一些软件和互联网公司，非
26、常明显，有多少朋友做到了 MRD中要求的呢？说到最后，还是我始终坚持的一个观点，产品管理文档，本身没有任何价值，网上到处都可以找到，但是，如果不懂产品管理的思想，不明白产品管理到底是什么，不知道产品管理者到底应该做什么，即使给你非常好的文档模板，又有几个人能真正理解这份文档的作用，并把它写好呢？对了，最后提一点，有些公司，是把 MRD和 PRD合并来做的，或者说，即使可以舍弃 PRD，也不能舍弃 MRD，因为 PRD是由 MRD延展而来的，MRD 是根，PRD 正是枝叶而已。附一个 MRD目录吧，仅供参考，千万别照搬。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 业务决策购买者4.3.2 技术决策购买者5、使用者和用户原型5.1 本章摘要5.2 原型特征5.3 现实需要
