技能 | 产品经理文档那些事

    产品设计从抽象到具体的过程中主要产出的几个核心文档分别为：BRD、MRD、PRD和FSD。

    BRD : Business Requirements Document，商业需求文档。产品生命周期中最早的文档，其内容涉及市场分析、销售策略、盈利预测等，通常是给大老板们演示的PPT，比较短小精炼，没有产品细节，主要是为了获得认可，争取资源。

    MRD：Market Requirements Document，市场需求文档。获得老板们的支持后，产品进入实施阶段，需要写出MRD，要有更细致的市场和竞争对手分析，包括可通过哪些功能来实现商业目的，功能、非功能需求需要分哪几块，功能的优先级，等等。实际工作中，PD在这个阶段常见的产出物有产品的feature list（功能列表），业务逻辑图等，这是从商业目标到技术实现的关键转化文档。

---

    上述两份文档都是给老板看的，更多偏商业，很多公司实际工作中并不会写这么多文档，一般的BRD实际就包含了上述两个文档的核心内容，主要包含：

    项目背景：为什么要做这个项目，解决什么问题，可以列出一些数据说明项目的重要性。

    商业价值：这是老板们感兴趣的关键重点。要提出这个产品的商业目标，做了这个项目后有什么价值，也就是我们要通过这个产品得到什么？可以给用户提供什么价值，又能给公司提供什么帮助。

    功能需求描述：我们要通过做哪些事情来达到目标，描述打包好的需求，列出功能列表，最好可以画出业务逻辑图。PS：对于需求而言，应按种类以及优先级进行划分，这里有几种不同的划分维度可供参考。因为对需求的划分并不绝对，常常会随着商业目的或执行阶段的变化而变化。

图源《人人都是产品经理》

    这里的需求层次分级方法来源于东京理工大学教授狩野纪昭(Noriaki Kano)提出的kano模型，常用于产品需求分析中作为评定产品优先级的标准。

    基础需求：用户认为该产品理所应当应该具备的功能，当产品缺乏该功能或该功能的体验差强人意时，用户会有不满意感。例如（假设）：微博没有评论功能。

    扩展（期望）需求：这类需求在产品中没有体现，用户不会觉得不满意，但是如果这类需求越多，越好，用户的满意度就越高。也即为我们所说的用户痒点，这类需求在用户调研中出现最多。例如（假设）：微博中的拉黑功能。

    增值（兴奋）需求：这类需求提供给顾客一些完全出乎意料的产品属性，使顾客产生惊喜。兴奋点常常是一些未被用户了解的需求，用户在看到这些功能之前并不知道自己需要它们。但当产品提供了这类需求中的服务时，顾客就会对产品非常满意，从而提高忠诚度。例如（假设）：微博中的一键拉黑某一评论的评论用户及点赞用户。

非功能需求描述：比如性能、可培训、可维护、可扩展等等，有很多需求不是为终端用户做的，而是为销售、服务、测试做的。

    资源评估：项目需要的资源预估，如人力与时间。一般跟技术人员一起探讨确定。

    风险与对策：有的项目会有一些潜在风险，此时不妨给老板看一下并给出自己的对策。由于信息和资源的不对称，有时你认为的麻烦可能老板一句话就能搞定，而且也可将一些我们认为可能会与公司战略相冲突的功能点提出来与老板一起探讨。

---

    PRD：Product Requirements Document，产品需求文档。PRD是对产品功能的进一步细化，属于需求开发过程，是PD新人写得最多的文档。文档主要包含整体说明、用例文档、产品Demo等，会对产品功能做具体描述。

    FSD：Functional Specifications Document，功能详细说明。经常包含在PRD中，从这步开始会出现一些技术内容，产品界面、业务逻辑的细节都要确定，有一点像软件工程中的概要设计。与此同时，例如硬件系统的设计、数据库设计、表结构设计等详细设计工作，也会开始由架构师、系统分析师们编写。

     这两份文档主要是给技术人员看的，实际工作中很多公司的PRD就包含了上述两文档的核心内容。也就是整体说明+用例文档+原型。关键要记住无论用什么方法，都要做好迭代记录，把逻辑说清楚。

图源《人人都是产品经理》

    不同公司或工作情况中有时候叫法相同内容不同，或叫法不同内容相同，关键是我们要知道写这些文档的目的，说清楚哪些事就可以了。

---

主要参考书目：苏杰，《人人都是产品经理》

本文主要用于个人学习记录，非作商用，不妥侵删