前些日子，負責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 項目把控的一些基本原則

開發進行前，再小的項目，也要拉上所有的相關人員，明確需求，確認好明確排期，并周知所有人，誰 什么時候 要完成什么事情，讓所有人對項目都很明確而至于云里霧里；

項目進行中，每天跟進開發進度，并實時跟相關人員反饋；

項目結束后，及時發布上線通報，并跟進反饋效果評估。