前些日子，负责app 站内自建头像昵称体系，以支持UGC内容产出。走过一些坑，与大家分享。

写MRD之前

1. 梳理大局

写MRD之前，往更大局宏观的方向思考。什么才是影响这个功能上线成功的主要因素，对于app 站内自建头像而言，功能使用细节其次，保证各个组件方头像统一或许更为重要。

所以要做的第一步：梳理各个页面有多少有头像的组件方，如果一期无法完全推动，挑大头分期推动，保证必须同步的大头组件方在一期同步上线，对于其他小的组件方，二期陆续推动。

需求评审时拉上所有相关组件方PM参加，避免通知不足，导致后续更大的问题。

2. 看看竞品

确定了这个大方向，并且确定要做之后，也不要急着写MRD文档。

看看竞品以及有相似功能的产品是如何解决这个问题的，包括所有前端细节交互是如何的。不然你的MRD，我相信会有不少漏洞。

MRD要详细明确，开发验收时才能避免纠结细节

对于基础底层功能的MRD，和策略型MRD还不太一样。它重交互，重产品细节，重极端情况。需要像QA（测试）一样去思考，才能保证最后实现不出问题。

以昵称为例：

昵称修改有两大页面：昵称入口页面（多是个人资料）、修改昵称页面；

1 昵称入口页面：

a. 昵称未设置时的展示样式？

b. 甚至需要考虑是账户名、账号名、帐号名、帐户名？哪一个？

2 修改昵称页面：

a. 考虑输入框的placehold默认占位信息是什么？（eg：“请输入您的昵称”）

b. 仅仅写明“点击修改昵称页面进行昵称修改”就行了？

有没有考虑过何时调起键盘呢？光标在哪里闪烁？是进入修改昵称页面，即调起键盘，光标在最后一个字符后闪烁？还是用户点击输入框之后调起键盘？

c. 空格的处理？空格是否算作字符？算作字符的话又是否展现？前面的字符是否展示？中间的呢？后面的呢？

d. 昵称为空时，是提交按钮置灰不可点击，还是提示“用户昵称不可为空哦”

e. 输入框不能折行==！

f. server端是否需要对特殊字符过滤，过滤的话，要过滤 @@#￥%…………&（ 中的哪些特殊字符呢？

g. 换行的处理？用户在另外个页面换行输入，复制到昵称修改页面？这种换行如何处理？

3 保存昵称：

a. 敏感词校验：黄反识别还是包括政治人物识别？还是怎样？需求是什么？

b. 保存成功后是否需要toast提示”昵称修改成功“？还是直接返回昵称入口页面，显示修改后的昵称？

c. 错误码情况，给出什么提示？以什么方式提示？是底部提示？还是toast提示？何时出现又何时消失？

eg. 头像、昵称可能的错误码：

若昵称重名；若昵称为空；昵称不符合规范；若昵称字数不足4个字符；若昵称字数超过20个字符；用户昵称进行敏感词校验，若命中反作弊策略；网络超时或者网络不可用；图片审核失败；图片提交失败；头像太大...这些都需要考虑不同的提示形式以及不同的提示语。

d. 机审，哪些头像可以展示，常见的有黄反识别；这个是否能满足需求？若不能，可以从哪里获取？

如果MRD不详细，至少会影响的一个点是，android 和 iOS不同的处理结果。因为RD的想象力是无穷的。

所以，产品设计能力，想清楚自己的产品所有细节，才是PM不败根本。才有底气跟RD撕，跟UE撕，跟运营撕。

统计埋点需求评审确认

提前跟RD统一 统计数据埋点的需求，可以避免后期很多问题。

P.S 项目把控的一些基本原则

开发进行前，再小的项目，也要拉上所有的相关人员，明确需求，确认好明确排期，并周知所有人，谁 什么时候 要完成什么事情，让所有人对项目都很明确而至于云里雾里；

项目进行中，每天跟进开发进度，并实时跟相关人员反馈；

项目结束后，及时发布上线通报，并跟进反馈效果评估。