如何写好MRD文档与相关注意事项.pdfVIP

如何写好MRD文档及相关注意事项 MRD定义与分类 MRD指Market Requirement s Document ，简称市场需求文档。 市场需求文档的主要功能是描述什 样的功能和特点的产品 （包含产品版本 ）可以在市场上取得 成功。 产品进入实施 ，需要先出MRD ，具体来说要有更细致的市场与竞争对手分析 ，通过哪些功能来实现 商业目的 ，功能/非功能需求分哪几块 ，功能的优先级等等。 产品市场经理 （PMM ，Product Market ing Manager ）负责分析市场变化 ，通过对市场的 分析 ，MRD指出什 样的新产品、方案和服务可以更好的开拓市场。 通常情况下 ，产品经理或者技术产品经理会将在MRD的基础上完成PRD （Product Requiremnet s Document ），技术团队应用PRD开发产品。 在百度的ECO M PM部门 ，MRD要分为给RD/QA看和给业务部门看的两种。 给工程、测试、设计看的MRD是他们的输入信息和测试对象。给业务部门看的MRD ，最主要是因 为MRD里面的功能实现后 ，会对客户产生影响 ，所以必须确认业务部门知晓。 MRD基本写法 一般来说 ，MRD包含“项目背景”“名词解释”“可行性分析”“综合描述”“功能详述”等部分。这里结合不同 版本的MRD谈谈MRD的基本写法。 目前看到的几个MRD比较重视功能需求这块。功能需求主要包括功能点类型和优先级/流程图/页面 布局/功能点描述等要素。其中优先级和功能描述比较重要 ，流程图常可省略。 要素1 ：项目背景要让RD理解。 “具体开发的背景是什 ，解决什 问题得写清楚 ，否则开发人员在不清楚背景的情况下去做 ，很容 易出问题 ，而且也缺乏参与感。” 事实证明 ，谁将买和使用户你的产品和与竞争对手的产品比你的产品定位怎 样的对工程师很有 价值 ，许多工程师想知道为什 一个产品或特性要开发 ，谁将使用他们 ，什 是他们可以另外选择 办法。这些信息帮助他们和产品组的其他成员想象最终用户并从而更好的为创造成功的产品工作。 要尽可能的 （在MRD中 ）包含这些信息。不一定要很详细 ，只要包含几个段落就足够了。 要素2 ：名词解释要确保RD看得明白。 在名词解释这块 ，“描述的准确性很重要 ，没有二意性 ，否则 ，等RD开发好了以后 ，才会发现和自 己想要的不一样 ，追溯mrd才发现有歧义。” 要素3 ：要考虑 统的兼容性等不确定因素 ，把控风险。 我们应该提前把控风险 ，不确定性降到最低 ，并具有良好的沟通和通报意识。例如 ，当MRD要求的 是原来系统的更新 ，而不是一个全新的 ，与其他系统没有关联的产品时 ，应考虑到更新的内容与原 来的系统其他部件的接口 ，以及其他外部系统的兼容。eg ：2 6年8月3 日MRD ） 要素4 ：对于要实现的 统功能要详细分解。 每一步出现什 界面 ，进行什 操作 ，下一步又怎 进入什 界面 ，进行什 操作 ，都要介绍清楚 ，这样比较容易让RD明白 ，也易于实现。 （eg ：2 6年9月4 日MRD ） 要素5 ：在涉及数量关 时 ，要利用好公式。 要用公式明白地表明变量的关系。对公式里面变量的定义必须清晰无疑义。在列举公式时 ，需要穷 尽所有可能的情况 ，此外 ，还需要列举注意事项 ，澄清可能存在的误区。在增加QA 时 ，要把提问的 问题写清楚。 （eg ：2 6年8月3 日写MRD ）MRD里面的数据来源最好有附表 ，这样比较清楚明白 。 （eg ：2 6年9月4 日MRD ） 要素6 ：要区分功能需求的优先级。 通常来说 ，工程师团队不一定能全部实现MRD里包括的所有特性的没有删减的项目。当出现需要决 定取舍的时候 ，应该提供一个办帮助让他们决定那些特性要实现那些可以推迟。最好的决定一个已 经明确的需求的优先级方法这个需求实现后的好处-包括客户和公司。在实际实践中 ，最好是和其他 多种因素一起综合决定。在学习材料里面的几个MRD里面一个突出的问题是优先级写的都是很高 ，没有根据第一等级 ，第二等级这样的区分。 （eg ：2 6年9月4 日MRD ） 要素7 ：要积极参加评审鼓励修正。 要让产品经理伙伴和工程师团队评审MRD然后提出反馈意见。保持一个敞开的思想然后在评审反馈 的基础上更新MRD。 （eg ：2 6年9月4 日MRD ） 要素8: 要覆盖非功能性需求 要用功能性需求描述产品的功能 ，然后用非功能性需求描述系统特性 ，当写非功能性