likun.pm

上周，章婷评审了**需求，RD普遍反馈她的MRD要写的比我写的好很多。问了一下理由，阳阳说是看她的MRD，就可以直接设计出DB，化劲说是她的MRD里各种数据阈值都比较全面，杨老师说没有别的理由……因为她是一个妹子……囧

在大学时候跟永康做开发，从来没有什么产品需求文档，我都是直接出交互稿（其实就是高保真原型），然后永康哥哥直接就开干了。工作以后，用axure画出来的东西越来越丑，究其根本，还是自己思考的不够细致，需求描述不够翔实，经不起推敲。

今天，总结一下一份比较“好看”的MRD应该长什么样子，算是对自己做一个总结，也给后人留下参考。其实各个大公司都有自己的MRD模板，我今天以百度的模板为基础来说。

第一页：MRD封面，简单的说明几个问题：这是一个什么项目，优先级高不高，谁写的MRD，谁审核的，最后一次需求变更时间是什么时候。

第二页：MRD修改记录，记录每一次的变更历史，方便查阅。

第三页：目录

剩下的内容，我们都将基于目录来说。

从目录来看，一个完整的项目的MRD，主要包含三个部分，第一个部分是项目说明：包含项目的背景介绍，项目的预期收益或者想要达成的目标。第二部分是完整的需求描述，首先是最好有一个完整的流程图，让大家明白整个的项目逻辑与结构，然后是各个feature的介绍。最后一部分，是针对整个项目的统计需求，如何通过数据来监控项目的预期是否到达，即项目数据评价模型的建立。

从我自己做产品的经历来看，撰写一份MRD确实很不容易，容易出错的几个地方有：

1、在描述第一部分项目的目标或者收益时，往往容易描述为项目的结果，项目的结果是要去表达或者实现一个价值的，有最终的目的的，这个目的才是第一部分里要说明白的。

2、缺失整个项目的流程描述，缺少全局性的图示描述。在描述每一个feature时，描述不清楚。各种环境下的边界值情况没有考虑到，各种异常case会被忽略，与第三方有交互时，简单的只假定了第三方正常的情况等等。在描述文案时，语句不通顺，针对一个专有名词没有备注解释，针对某些业务名词每个地方都有不一样的称谓。

3、在撰写统计需求部分时候，经常数据模型建立不到位。统计数据埋点不及时，业务上线很久之后才明白真正的统计点没有埋。更有甚者，统计数据不对，也没有自己的预估，糊里糊涂的做统计。