实事求是的说，其实MRD这个文档不讲都没问题，因为对于大部分的朋友来说，即使前面的文档一个不写，这个文档也会去写的，毕竟名字叫市场需求文档，作为一个产品经理，管理并记录好市场需求就是自己的本分。
但是，我也见过一些朋友写的MRD，怎么说呢，很尽心，但是太混乱，主要表现在两方面：
1、缺乏MRD撰写的规范；
2、MRD和PRD混在了一起。
那么，在本节课中呢，我就重点讲一下如何避免出现这两个问题。
1、缺乏MRD的撰写规范
缺乏撰写规范不是指没有文档结构，其实MRD的文档结构很简单，大家看图1：
图1
MRD的第一章不用管，第二到第五章，是不是咱们前面已经完成的内容，直接摘抄过来就可以了。
那么，缺乏规范的主要是在第六章，也就是如何来记录和描述市场需求上。
首先，我们来看一下，MRD是如何定义第六章的，在撰写说明里写的很清楚，大家看图2：
图2
重点解释了两点：
1）第六章要记录的是“从市场问题中引出的市场需求”。
这说明什么呢？
其实说明的就是在产品管理中的需求管理的过程，这个过程是：
从问题到需求，从需求到概念，从概念到介质。
而MRD就要记录第一个过程得到的结果，从问题到需求。
这个过程咱们PMM的需求管理功能就可以实现，大家看图3：
图3
关于这个功能如何使用，在PMM的帮助文件中有详细介绍，大家可以和我索取帮助文件。
从问题到需求的结果有了，那么，我们如何规范的记录在MRD中呢？这就是我们要注意的第二点。
2）场需求是市场问题的反向呈现。在这个部分，避免定义一个产品以及设计细节和规格。如果缺乏目标或者针对某个特定的需求没有进行相关的讨论，那么，这个部分就必然会受到影响，要用"N/A"加以标注并进行简短解释。所有针对产品的市场需求的描述都来自于用户的观点和用户期望实现什么的有效描述。
在撰写的时候，需要把握三点：
（1）MRD中不会存在详细的需求设计说明；
（2）MRD第六章中涉及需求的十个撰写类别中，如果要撰写的话，都要进行必要的讨论，这十个撰写类别大家看图4：
图4
分别是：功能；开发；兼容性；性能；国际性；文档；外观；发布；支持和培训；其它。
关于每一项如何来写，都有撰写说明，我这里就不赘述了。
（3）所有的讨论都要基于用户角度，而不能是研发，营销的角度。
简单说，这三个要注意的点就是指MRD是根据用户需要和从用户的角度定义产品目标的文档，这是解决方案的用户视图。
那么，如何规范撰写呢？大家看图5：
图5
当然了，我也知道，只看这个撰写说明，很多朋友会有些晕，接下来，我就通过DD的例子来说明一下，大家看图6：
图6
一看例子就很清楚怎么写了吧，不过，有三个地方简单说一下。
（1）来源：我这里用的是公司自己市调的结果，如果是来自第三方的数据，那么，不用写这么多，直接扔一个数据来源的名称或链接就可以，当然，如果自己公司的市调报告管理规范的话，也可以直接写一个报告名称就行。
（2）约束条件：看到我这个案例就明白啥是约束条件了吧，比方说，DD要自动识别用户的高频词汇，那么，至少有两个条件会影响识别，一个就是当一个词条有多层含义的时候，例如，PM有项目经理的意思，也有产品经理的意思，在具体的翻译场景中，有时候需要翻译为项目经理，有时候需要翻译为产品经理，那么，DD就要能智能识别而不会出现混乱，另一个就是词条出现的次数，如何界定高频的标准，这个必须要考虑到，是规定一个具体的数值，还是根据用户在一个较长期的使用后进行测算，如果这两个条件达不到，那么，这个功能可能就实现的不好。
（3）用户原型和用户用例，原型是说明谁会用这个功能，用例是说明原型会怎么用，在用户用例文档的撰写中，我对这两个的解释很清楚，大家可以再去看看这节课。
当然，撰写的时候，不用写的很麻烦，因为咱们毕竟已经完成了用户用例，直接写一个用例名称就可以了，我这里用的是UC01，具体怎么命名，这个是在用户用例文档中定义的。
后面其它的撰写类别我就不介绍了，咱们的撰写说明里都有，并且也没有功能类别这么复杂，基本上都是用列表的形式说明用户在每个类别上的需求就可以了。
当然，前提还是前面提到的，一定要站在用户的角度说明他们想实现什么目标，而不是要站在我们的角度去设计如何解决，这不是MRD的作用。
关于MRD就讲这么多，有些朋友会问了，这么重要的一个文档，难道就讲这么点内容，怎么说呢，MRD是很重要，但是我说了，MRD只是记录我们从问题到需求这个过程结果的介质，既然PMM中已经提供了需求管理的功能，咱们就没必要再讲一遍了，我只讲一下怎么来规范记录就可以了。
这是原因之一。
第二个原因呢，就是本节课还没讲的撰写MRD时，经常会和PRD混在一起的问题，这个呢，我考虑放在下一节课，也就是如何撰写PRD中来讲，毕竟很多情况下，MRD和PRD是一组不可分离的文档。
好，本节课就到这里，最后呢，给大家一篇文章的链接，什么文章呢，《写好MRD的十个要，十个不要》。