MRD指Market Requirements Document，简称市场需求文档。
市场需求文档的主要功能是描述什么样的功能和特点的产品（包含产品版本）可以在市场上取得成功。
产品进入实施，需要先出MRD，具体来说要有更细致的市场与竞争对手分析，通过哪些功能来实现商业目的，功能/非功能需求分哪几块，功能的优先级等等。
产品市场经理（PMM，Product Marketing Manager）负责分析市场变化，通过对市场的分析，MRD指出什么样的新产品、方案和服务可以更好的开拓市场。
通常情况下，产品经理或者技术产品经理会将在MRD的基础上完成PRD（Product Requiremnets Document），技术团队应用PRD开发产品。
在百度的ECOM PM部门，MRD要分为给RD/QA看和给业务部门看的两种。
给工程、测试、设计看的MRD是他们的输入信息和测试对象。给业务部门看的MRD，最主要是因为MRD里面的功能实现后，会对客户产生影响，所以必须确认业务部门知晓。
MRD基本写法
一般来说，MRD包含“项目背景”“名词解释”“可行性分析”“综合描述”“功能详述”等部分。这里结合不同版本的MRD谈谈MRD的基本写法。
目前看到的几个MRD比较重视功能需求这块。功能需求主要包括功能点类型和优先级/流程图/页面布局/功能点描述等要素。其中优先级和功能描述比较重要，流程图常可省略。
要素1：项目背景要让RD理解。
“具体开发的背景是什么，解决什么问题得写清楚，否则开发人员在不清楚背景的情况下去做，很容易出问题，而且也缺乏参与感。”
事实证明，谁将买和使用户你的产品和与竞争对手的产品比你的产品定位怎么样的对工程师很有价值，许多工程师想知道为什么一个产品或特性要开发，谁将使用他们，什么是他们可以另外选择办法。这些信息帮助他们和产品组的其他成员想象最终用户并从而更好的为创造成功的产品工作。要尽可能的（在MRD中）包含这些信息。不一定要很详细，只要包含几个段落就足够了。
要素2：名词解释要确保RD看得明白。
在名词解释这块，“描述的准确性很重要，没有二意性，否则，等RD开发好了以后，才会发现和自己想要的不一样，追溯mrd才发现有歧义。”
要素3：要考虑系统的兼容性等不确定因素，把控风险。
我们应该提前把控风险，不确定性降到最低，并具有良好的沟通和通报意识。例如，当MRD要求的是原来系统的更新，而不是一个全新的，与其他系统没有关联的产品时，应考虑到更新的内容与原来的系统其他部件的接口，以及其他外部系统的兼容。eg：2006年8月3日MRD）
要素4：对于要实现的系统功能要详细分解。
每一步出现什么界面，进行什么操作，下一步又怎么进入什么界面，进行什么操作，都要介绍清楚，这样比较容易让RD明白，也易于实现。（eg：2006年9月4日MRD ）
要素5：在涉及数量关系时，要利用好公式。
要用公式明白地表明变量的关系。对公式里面变量的定义必须清晰无疑义。在列举公式时，需要穷尽所有可能的情况，此外，还需要列举注意事项，澄清可能存在的误区。在增加QA时，要把提问的问题写清楚。（eg：2006年8月3日写MRD）MRD里面的数据来源最好有附表，这样比较清楚明白。（eg：2006年9月4日MRD）
要素6：要区分功能需求的优先级。
通常来说，工程师团队不一定能全部实现MRD里包括的所有特性的没有删减的项目。当出现需要决定取舍的时候，应该提供一个办帮助让他们决定那些特性要实现那些可以推迟。最好的决定一个已经明确的需求的优先级方法这个需求实现后的好处-包括客户和公司。在实际实践中，最好是和其他多种因素一起综合决定。在学习材料里面的几个MRD里面一个突出的问题是优先级写的都是很高，没有根据第一等级，第二等级这样的区分。（eg：2006年9月4日MRD）
要素7：要积极参加评审鼓励修正。
要让产品经理伙伴和工程师团队评审MRD然后提出反馈意见。保持一个敞开的思想然后在评审反馈的基础上更新MRD。（eg：2006年9月4日MRD）
要素8: 要覆盖非功能性需求
要用功能性需求描述产品的功能，然后用非功能性需求描述系统特性，当写非功能性需求的时候，尽可能的是使他们可度量（可测试）。否则，QA不能测试它们，PM将没有办法知道完成的产品是否已经实现了这些非功能性需求。
要素9：要包含一个术语表
如果MRD使用了新术语或在非通用的地方是使用了常用术语-确保在MRD后面包含一 个术语表。术语表将确保所有读者（有些可能不是技术人员）理解PM的意思是什么 。
要素10：深入分析目标用户群需求，市场发展趋势，竞品，结合自身优势找出制胜点
在学习的历史MRD中，没有包含市场分析和定位，而针对市场做好分析其实是很重 要的一块，因为“写MRD一定就和画像一样，得现有轮廓，然后才有具体里面的眉毛、眼睛。”特别是对目标用户群需求，市场发展趋势，竞品等深入分析，然后结合公司自身优势找出制胜点。MRD必须在覆盖了市场目标（谁将买和使用户你的产品）和定位（与竞争对手的产品比你的产品定位怎么样的）的方面做好。
那么，如何分析好市场目标和定位？
首先，在写MRD之前，得有细致的研究和沟通阶段。其中比较重要的是要知道几个为什么：“用户需要的是什么？/ 我们为用户提供的是不是用户真正想要的？/ 凭什么能代表用户？”其他考虑的因素还有很多，例如人力，时间，成本，价值等。综合衡量很多因素，最后决定是否需要做这件事情。
在这方面，我们也可以通过以下方法去实现：
1、对于某产品可以进行调查问卷的形式发放出去（搞一些活动之类的）
2、对于有针对性的产品，可以去专访一些资深的用户去调查体验
3、找一些资源，设计一些脚本程序，用这个脚本程序，计算需要的数值，用数字说明用户想要。多个维度的思考会比较有力，所以最好综合参考几个维度。
撰写MRD的常见陷阱和对策
陷进1：如何不断提高可读性？
为了确保MRD可以执行，最重要的是提高MRD的可读性。其中可读性一般包含准确性和易读性两个方面。
不准确指表达模棱两可，容易让人误解；不易读指逻辑关系太复杂，表述太长，不容易理解。那么如何尽量避免这两个问题呢？
1 插入屏幕截图或者流程图，同时保持文本和图片描述一致。
一般来说，图片直观，容易理解。与此同时，因为MRD经常会改动很多次。当文字发生改动时，图片也应做相应的改动，以免带来不必要的混淆和误解。
Eg1: 图片中写了付款方式，但是文字中提到相应概念时，却说是“缴费方式”，那么就容易让人产生误解。
Eg2: 图片里面画了简略的图表，但是文字里面有了详细的分支的展开。那么读者在图表里面找不到文字里面描述的分支，就会产生困惑。
2 正文批注分开，省略功能实现等方面的细节
有时候MRD里面描述非常清楚，但是RD和QA希望提供更多的细节帮助理解。于是MRD越写越长，造成易读性变差，怎么办呢？
MRD里面应该省略细节，主要讲产品设计的思路。在排版时，应该把正文和批注分开。细节写在批注里面。这样一方面条理清楚，容易阅读。另一方面，讲清楚为什么这么设计的原因，而不穷举功能该如何实现，可以发挥RD的主观能动性，让他们更有参与感，从而主动去想如何做得更好。应该说明的是"是什么"和"为什么"，但不要"如何" 和“怎么样”。
3 通过版式来提高MRD易读性
MRD最好控制在5-6页之内。如果MRD比较长，最好使用1.5倍行间距，以便RD读起来比较舒服。如果使用模板，确信相关人员可以灵活的跳过模板某些部分和创建新的内容。
另外，应避免大段的文字。如果使用宋体5号字，文字超过两行半，就应该利用良好的逻辑结构来使文章易读，例如使用分段，序列符号，并列符号等等。
在语句组织上，应保持简短的语句，把长的语句分解成多个小的语句。或者把大块文本做成表格都是很好的办法。
4 通过详细解释项目背景和名词解释简化MRD
项目背景和名词解释对于某一个具体的MRD都是通用的知识。在项目背景和名词解释方面解释得越详细清楚，越有助于RD和QA理解下文中功能点设计和实施目标。预先的解释可以大量减少MRD后续解释的篇幅。
5 功能点和功能点之间合理分配篇幅并注意衔接
对于比较复杂需要长篇叙述的功能点应该进行进一步的细分。例如一个5页的MRD如果包含5个功能点，那么就不应该让一个独立的功能点占据2页的篇幅。
如果两个功能点A和B提到了同一个背景知识。为了节省篇幅，我们只需要在A展开背景知识，而在B的相应部分写上“相关介绍请见A”。
如果多个功能点共享同样的背景知识，造成嵌套的情况，容易让人对功能点之间的逻辑结构产生混淆。这时候应该画功能点逻辑图，以便于读者理解。
陷阱2：如何抓住关键，又不错过关键细节？
在MRD的纂写过程中，必须抓住关键，不能太纠缠于细节。与此同时，有些细节也是很关键的，需要辨别出来，那么，哪些是关键的细节呢？
1 当一个流程出现分支/异常的时候，临界的判断条件是关键细节
Eg 假设一个点击3毛钱，一个客户的广告该不该出现？那就需要考虑用户的预算/帐户余额等多种情况，然后确定广告是否出现，以及广告被点击后的后续操作
2 涉及用户体验的细节是关键细节
Eg 当客户点击一个操作按钮时，应该在新窗口打开，还是新标签页打开？
3 当一个过程操作结束后无法恢复时，处理方式是关键细节
Eg 当客户删除一个关键字时，操作是不可重复的，那么是不是应该有一个二次提醒的框？
陷阱3：多模块的合作模式下，MRD需要注意哪些方面？
有时候产品的更新不是一个独立进行的操作，而是涉及到多个模块的合作。应该注意推举一个总负责人，确保MRD与MRD之间，设计与设计之间不重合，也没有三不管地带。既减少别的产品更新给自己的产品变化带来不利影响，也认真考虑自己的MRD对别人的影响。
陷阱4：处于和RD/QA磨合期时，MRD需要注意哪些方面？
处于和RD/QA磨合期时，应该注意预判RD/QA可能出现的易错点和盲区，做好PPA/POA分析，及早预防可能存在的意外。尤其是当MRD推的产品非常重要时，需要特别注意这一方面。
另一方面，如果RD和QA在新人培训方面的确做得不到位，也应考虑暴露问题，推进问题的彻底解决。
关注公众号：diandipm 与朋友分享知识