如何写好MRD文档及相关注意事项

MRD(Market Requirement Document),全称是市场需求文档,习惯上大家都喜欢叫需求文档或者需求设计文档,一般用于对产品的功能需求进行完整的描述,也是提交给开发和测试人员的正式文档。有的人会将其与PRD(Product Requirement Document)文档混淆,PRD是产品项目由概念化阶段进入到图纸化阶段的最主要的一个文档,其作用就是对MRD中的内容进行指标化和技术化,因此MRD和PRD文档的要求和侧重点并不一样。无论如何,做一个产品必须要有一份MRD文档,不过现在也有一些敏捷设计、敏捷开发的项目现在好像不太拘泥于这样的形式,直接是需求人员站在开发人员旁边讲解的。个人认为最好还是要有一份这样的文档,以系统的描述一个产品的功能需求。

那么如何才能写好MRD文档呢?比较好的MRD文档一般都遵循了多、快、好、省的特性,也即首先文档要完整,所有功能点都讲到了,没有任何确实和遗漏;其次是写文档要高效,在最快的时间内完成从方案确定到最终MRD文档定稿的整个过程;第三是要准确无误,结构合理,条理清晰,能够让这份文档的阅读人员没有困难的阅读和无歧义的理解;最后是要能节约沟通成本,对文档的讨论、评审和后期的改动都要十分的合理和顺畅。有了这些要求之后,写MRD的思路就比较清晰了,下面就要开始八股文式的说明了,其实八股文挺好的,让一篇文章的结构很清晰。

第一步是要搭建框架,或者叫做开篇构思,写论文都要先把框架搭好,确定论文的写作范围,写作提纲等等,写MRD也一样,也要将产品所有功能进行合理分解和排序,确定各小节的标题,并以此展开来写。这里有一些基本的书写规则,如果按页面布局来写的话一般是从上到下,从左往右;如果是按用户操作的步骤分解来写的话一般是从提交到展现,最后可能还有个展现后的编辑排版;如果是按产品系统来分的话一般是从前端展示页面到用户管理操作后台,再到系统管理操作后台;如果是功能的主次来分的话一般是从主要功能到次要功能,再到一些辅助性的功能。这里的区分方式可能在一份文档里面全都会用到,需要自己去把握如何恰当使用。

第二步是要梳理主要内容,按照已确定的章节顺序,用关键示例图+简要文字描述的方式对主要功能点进行说明。这里先只关注主要功能,不用过于详细的描述,也不用涉及各种特殊状态和细节的处理,尽可能的使产品所包含的主要功能在文档中有完整体现,并且在主要功能点的整理过程中,对文档的结构及时的进行合理调整。这个过程完成之后,可以邀请开发人员来对文档进行初步沟通,也就是第一道评审,看是否对产品的主要功能有遗漏的地方,要确保大方向没有错没有遗漏,后面就好办了,就不会出大的纰漏。

第三步就是对内容进行细化,查漏补缺。这里要对产品功能及其它相关需求进行完整的说明,包括所有操作流程、判断逻辑、权限区别、页面效果、特殊状态处理、错误提示、已有功能说明等。一般来说细节说明通常会占到整篇MRD文档篇幅的70%以上,占了绝大部分,一份细节清晰完整的MRD文档是项目顺利进行的有力保障,也是PM对产品理解和掌控程度的重要体现。这个过程完成之后就可以进行文档的第二轮评审了,一般来说也就是正式的文档评审,参与评审的人员会有很多。

这样三个步骤下来,一篇MRD文档就基本上完成了,很好不敢说,但一般不会差到哪里去,因为主体内容没有丢,至于好与不好的评判,还跟很多因素有关系,例如写文档人员的语言表达水平,逻辑思维能力等等。这里还有一些需要注意的问题,可以稍微参考一下:

一、任何页面或者界面都要说明是怎么展现的,最终会引导到什么地方,也即像写用例说明那样要说明这个用例的前置条件和后置条件,与这个类似。该页面的访问入口,页面title和布局方式,页面初始状态,页面展现和功能细节,各链接点击效果、指向地址、打开方式、刷新方式,浮动层具体策略以及是否自动关闭,右上角是否展示关闭按钮,点击效果如何,若在浮动层中可打开新页面,原浮动层是否关闭,关闭后是否刷新页面等等,需要考虑的细节很多。

二、不要只考虑普通用户。虽然大部分用户是这样的操作方式,但不是全部,既然这样就得考虑那一小部分用户的操作方式,所以若页面对不同权限用户有不同展示和功能,要完整的说明并提供准确示意图。

三、要有错误提示功能。这里说的错误提示一般包括输入为空,包括输入空格/空字符串;超过字数上限,前台以汉字数提示,技术上以字符数限制;是否包含特殊字符,可用字符集一般分常用字符(汉字、字母、数字、下划线)和GBK字符两种,由输入内容的应用范围而定;是否含过滤关键词,需明确过滤词表;输入无效的情况,有特殊格式要求、不能重复、有特定范围限制等;无提交权限或无权限访问,退出登录、被封禁、不符合权限要求等等。

四、要明确说明各个输入框的功能限制。是否可以为空;是否有初始内容,是否默认选中;大小写/全半角/繁简体是否转换;是否需要输入字数上限验证;是否有不允许的字符集;空格出现在首尾和中间部分,或者连续多个空格的各自处理方式;多行文本框的连续空行、不连续空行、空格、tab键、回车键等处理方式;是否允许快捷键控制等,这个一般没有办法面面俱到,尽量在前期的时候考虑的全面一些,后期的改动就会相对较少。

五、要说明各种非正常情况时的应对方法。事情的发展总可能脱离理想状态,对于满足一定条件才有效的功能,需要说明流程中遭遇各种非正常情况时的处理策略,虽然问题无法预估,但对于有限定条件的功能来说,不满足条件的时候就是其非正常情况。

六、尽量减少与外界的关联。少写一些与某某产品文档某某规范或者某某设计方法保持一致的说明,你自己是明白的,看的人不一定明白。

七、要制定统一出错页面的提示。初始无数据或搜索无结果;无论实际上限或理论上限,文档中最好给出各种边界值,并说明是否要求灵活可配置;除已说明的错误提示外,需要给出在其它情况下默认的统一出错页,如常见的404页面等。

八、有特殊要求的一定要说明清楚。例如对上线时间,范围等有特殊要求的,对功能开发的先后顺序有特殊要求的,还有一些是逻辑很复杂的但很重要的功能,如权限说明等,一定要在醒目的地方说明清楚。

九、按实际要求来图文结合的描述。页面截图和文字说明必须保持一致,前后文中的截图必须保持一致,截图必须与实际情况相符等。一个页面至少需要一个完整示例图,页面各模块至少需要各一个示例图,其它细节说明,在不影响理解的前提下,截图越局部越好,截图最好加边框以便和文字隔开。截图或者图表利用的好,可以省掉很多文字性的描述。

十、做好协调沟通,在文档中有影响别的产品或者系统的地方,一定要标明协调沟通的结果和处理方式。

基本上就是这些内容,如果评审后要需要修改的地方,一定要评审当场就与各方确认修改细节,修改完成后再知会给相关人员。个人觉得写MRD文档也是熟能生巧的,第一次写可能会觉得丢三落四的,写过几次之后就很顺手的,所以刚开始写文档的时候一定要自己一个人独立完成,这样能了解到整个文档的结构和内容,等熟悉了之后可以分工协作,毕竟有的产品文档实在是很长。



无觅相关文章插件,快速提升流量

评论已关闭!