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 case）文
4、档。主要内容有， 功能使用的具体描述（每个 UC 一般有用例简述、行为者、前置条件、后置条件、UI 描述、流程/子流程/ 分支流程，等几大块） ，Visio 做的功能点业务流程，界面的说明，demo 等 。Demo 方面，可能用dreamweaver、ps 甚至画图板简单画一下，有时候也会有 UI/UE 支持，出高保真的 demo，开发将来可以直接用的那种。产品需求文档（PRD）重点放在为一个被提议的新产品或者现有产品的改进定义市场需求。与 MRD 侧重于从市场需要角度看需求的不同， PRD 侧重于从产品本身角度看待需求。通常在特点和功能需求上更深入细节，并也可能包括屏幕截图和界面流程。在那些
5、 MRD 不包括具体需求和用例的机构中， 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 种技巧MRD-“市场需求文档”
7、 ，是产品经理或者产品市场经理编写的一个产品的说明需求的文档。这些文档用于计划一个新产品或修正一个已有的产品，是被工程师团队开发产品时使用。在硅谷的一些公司，MRD 仅仅覆盖 high-level 的功能。在这种情况下，产品经理通过创建了另一个文档-通常指的是 PRD（产品需求文档）来定义更加详细的产品需求。在本文中，我用术语“MRD”泛指所有那些由产品管理和 /或产品市场团队创建的，为工程师团队传达产品需求为目的的文档。写好 MRD 的 10 种技巧1、从用户角度的编写从用户角度编写需求内容。使用“用例(Use Case)”和“用户角色（User Personas） ”来达到这个。考虑用以下
8、两种方法来详细说明你们公司正在开发的SFA（sales force auation）软件的“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 内容是不
11、同的。c) 模板确保你不会忘记所有需要在 MRD 中覆盖描述的部分；然而，一些公司过分的使用模板。一个硅谷最大的公司之一有一个所有部分被强制使用的近 60 页的模板。我觉得这个让人觉得非常难以忍受并且有几个负面的作用：a) 产品经理害怕但又不得不写 MRD - 几乎和不得不和 Dick Cheney 去南德克萨斯打猎一样（译者按：副总统 Dick Cheney 在南德克萨斯打猎时意外的打伤了和自己一起去的打猎伙伴） 。b) 工程师团队害怕但又不得不阅读 MRD。c) 写 MRD 和读 MRD 都需要花大量的时间。我你使用 MRD 模板，但确保他们不要过分的长。还有如果需要，确信产品经理可以灵活
12、的跳过模板某些部分和创建新的内容。5、区分需求的优先级在这些年里，我从来没有碰到一个工程师团队实现了 MRD 里包括的所有特性的没有删减的项目-通常由于那些我们控制之外因素！这就是说作为 MRD 作者的产品经理，当出现需要决定取舍的时候，应该提供一个办帮助让他们决定那些特性要实现那些可以推迟。区分需求的优先级是一个最好的能帮助完成这个事情的办法。我发现把需求分等级就像 P1，P2，P3.这样工作的刚刚好。在这个分类中-P1 是最高优先级，P2 是第二高优先级等等。最好的决定一个已经明确的需求的优先级方法这个需求实现后的好处-包括你的客户和你的公司。在实际实践中，最好是和其他多种因素一起综合决定
13、。我推荐你只要包括 P1，P2，P3 的需求在你的 MRD 中，在多数的项目中更低的优先级可能未必会实现。还有这样也让 MRD 变得更加容易读。6、说明“是什么“和“ 为什么“ ，但不要“如何“产品经理为理解客户的需求负责，然后基于这些理解定义什么和为什么需要开发.有一件比任何事情让开发者发疯就像在几英里外都能听到的汽笛在他们耳边尖叫一样的是一个令人痛苦的详细描述了怎样实现每一个需求细节的 MRD。考虑你们公司正在开发的以下两种描述 CRM“Login”功能的方法。推荐-描述“是什么 ”Mike 是一个销售经理，当他打开我们的 CRM 软件，他会看到一个登陆界面. 登陆界面建议提供“记住我”复
14、选框。如果 Mike 在点击登陆按钮之前选择了该复选框，我们的软件将记住并且在他下次来到登陆界面时自动填写他的名字。不推荐-描述“ 怎么样”Mike 是一个销售经理，当他打开我们的 CRM 软件，他会看到一个登陆界面. 登陆界面建议提供“记住我”复选框。如果 Mike 在点击登陆按钮之前选择了该复选框-将通过 Javascript 保存他的名字以 cookie 的方式写到他的硬盘。当cookie 写到硬盘后，用户名和密码将被发送到服务器。下一次 Mike 来到登陆界面时，Javascript 将读取他的 cookie，成功读取后，Javascript 将是适当的 DOM命令填充登陆页面上的用户
15、名。好的产品经理擅长理解用户的需求和描述什么需要实现，好的工程师擅长决定怎么样实现它。好的工程师希望能自由的决定怎么样最好的实现用户希望得到的东西。我注意到有背景的产品经理尤其喜欢描述“如何实现” 。如果这些描述的就是你，应该从现在开始不要再做这样的事了。工程师们将会感谢你。附：这里有一些例外的情况-当在描述“是什么”中描述“怎么样”是必要的，当描述“是什么”的最好的方式和/或唯一的方式就是描述“怎么样”的情况。7、覆盖非功能性需求尽管功能性需求描述产品的功能，非功能性需求描述系统特性，如：a)性能b)可伸缩性c)可用性d)国际化e)等等.我注意到因为许多产品经理和产品市场人员认为这些是“技术
16、细节” ，而在MRD 中被忽略。我发现这些是我的 MRD 中非常重要的一部分，工程师们会非常感激在 MRD 中定义这些需求。要点：当写非功能性需求的时候，尽可能的是使他们可度量（可测试） 。否则，QA 不能测试它们，你将没有办法知道完成的产品是否已经实现了这些非功能性需求。8、评审& 修正我有一个朋友-我们叫他 Matt（他的真名叫 Steve） 。Matt 在硅谷一家成功的公司做产品经理工作。最近我在午餐的时候碰到他是告诉我一个非常有趣的故事。他们雇用了一个有三年的产品经理。在他被雇用的几个月里，不知何故他让他的产品经理同事和工程师一样疏远他。他是罪犯？他基本上认为他的 MRD 就像一个法令
17、。他写了它，但不想和任何人评审或在反馈的基础上修改它。他仅仅想工程师团队没有问任何问题的拿着它并实现它们！不要像 Matt 的同事那样。确信做到和你的产品经理伙伴和工程师团队评审你的 MRD。保持一个敞开的思想然后在评审反馈的基础上更新 MRD。这将帮助你写出更好的 MRD，工程师将喜欢你（或者至少少恨你一些） ，你的团队也将创造更好的产品。9、定义市场目标和定位大部分我看到过 MRD 在覆盖了市场目标（谁将买和使用户你的产品）和定位（与竞争对手的产品比你的产品定位怎么样的）的方面做的很好。我还看到过一些没有描述市场目标和定位的 MRD，他们通常会这样争辩：“为什么工程师们需要知道这些？拿到定
18、义了什么是需要的还不够吗？”这些问题（谁将买和使用户你的产品和与竞争对手的产品比你的产品定位怎么样的）的确有一些正面价值，我发现许多工程师想知道为什么一个产品或特性要开发，谁将使用他们，什么是他们可以另外选择办法。这些信息帮助他们和产品组的其他成员想象最终用户并从而更好的为创造成功的产品工作。我的建议的尽可能的（在 MRD 中）包含这些信息。- 它们不一定要很详细，只要包含几个段落就足够了。10、包含一个术语表如果你的 MRD 使用了新术语或在非通用的地方是使用了常用术语-确保在MRD 后面包含一个术语表。当你像这样说“我们的软件将提供 SME 用户通过选择 WAP 或 PSMS 开MRC 帐单”时，术语表将确保你的所有读者（有些可能不是技术人员）理解你的意思是什么。
