come on，被技術(shù)懟是日常了好嗎，有什么可寫的...
關(guān)鍵是被懟總是因為那些細(xì)節(jié)，是不是該長長記性了!
下文就說說開發(fā)過程中產(chǎn)品提需求應(yīng)該注意的幾個點~
應(yīng)對網(wǎng)絡(luò)環(huán)境異常的需求
記得百度有產(chǎn)品經(jīng)理的12條軍規(guī)，其中有一項是“PM首先是用戶”。PM應(yīng)該是疑難雜癥較真強迫癥用戶的結(jié)合體吧，因為總有難搞定的用戶會在使用產(chǎn)品時遇到各種各樣的問題，需要PM先想到并設(shè)立預(yù)案。其中以網(wǎng)絡(luò)環(huán)境異常為最典型的使用場景，也是入門級PM在寫PRD時最容易忽視的問題，比如我，圍笑??
網(wǎng)絡(luò)異常以?弱網(wǎng)?和?無網(wǎng)?兩種情況為主，兩者都會導(dǎo)致無法及時拉取數(shù)據(jù)/數(shù)據(jù)返回，造成請求超時，體驗中斷。
弱網(wǎng)的常見場景為通勤時地鐵內(nèi)網(wǎng)絡(luò)由4G切換成2G網(wǎng)絡(luò)（玩兒農(nóng)藥的同學(xué)請舉手??），或者封閉空間內(nèi)（電梯間、地下室）網(wǎng)絡(luò)信號弱。移動端針對這種情況通常的處理方式是做系統(tǒng)提示或toast類彈窗提示，提示用戶當(dāng)前為弱網(wǎng)環(huán)境，請重新刷新/下拉數(shù)據(jù)或檢查網(wǎng)絡(luò)等，且將未加載的模塊使用灰度展位圖代替。無網(wǎng)是弱網(wǎng)的極端情況，出現(xiàn)場景可能是網(wǎng)絡(luò)中斷、用戶接聽電話等，常見的處理方式除同上外，應(yīng)增加的是重新加載網(wǎng)絡(luò)功能，界面設(shè)置熱區(qū)點擊能二次連接網(wǎng)絡(luò)。比較特殊的情況是iOS10更新后出現(xiàn)的APP首次啟動需允許訪問數(shù)據(jù)網(wǎng)絡(luò)，iOS的這個特性處理方式同流量下斷網(wǎng)，一定要設(shè)置可再次彈出權(quán)限，不然太坑（不懂蘋果的邏輯，攤手）
在實際開發(fā)中，還要求產(chǎn)品經(jīng)理要根據(jù)不同產(chǎn)品功能提出每個使用節(jié)點上的網(wǎng)絡(luò)異常應(yīng)對措施。網(wǎng)絡(luò)環(huán)境異常是產(chǎn)品經(jīng)理必須應(yīng)對到的經(jīng)典場景，特別在手游、出行導(dǎo)航、新聞資訊類應(yīng)用中出現(xiàn)頻率較高。曾經(jīng)腦洞過一個功能覺得會有意思，是在斷網(wǎng)時彈出浮層，提示用戶進(jìn)入another space ，類似于樹洞的功能可以寫點什么給未來的自己，存在device里，當(dāng)下次遇到斷網(wǎng)時再以圖文的形式展示給用戶，輸出所謂的“情懷”，至少讓用戶感到這是個有溫度的APP。
對關(guān)鍵數(shù)據(jù)的需求
實踐證明，躲過網(wǎng)絡(luò)異常的坑，還不能避免自己在技術(shù)前長跪不起...
PM還需要在開發(fā)過程中對提出相對完善的關(guān)鍵數(shù)據(jù)需求，過于簡單或含糊不清都會提高溝通成本，造成技術(shù)返工，不利于項目的推進(jìn)。對數(shù)據(jù)的需求主要提給后端開發(fā)，在實際開發(fā)中我發(fā)現(xiàn)掌握以下四點可以減少溝通成本、提高后端開發(fā)對數(shù)據(jù)需求的理解：
1.數(shù)據(jù)粒度 2.數(shù)據(jù)應(yīng)用周期 3.數(shù)據(jù)需求冗余 4.數(shù)據(jù)權(quán)限
產(chǎn)品需要APP內(nèi)所產(chǎn)生的數(shù)據(jù)，但你不能跟技術(shù)說：“嘿，給我有關(guān)XX的所有數(shù)據(jù)！”。PM需要先明確哪些數(shù)據(jù)是你需要的，再給出明確需求，以新聞資訊APP的評論功能為例，需要的關(guān)鍵數(shù)據(jù)有一級評論（父級評論）、二級評論（子集評論）、對二級評論的回復(fù)評論、對回復(fù)評論的追加評論，每級評論在時間維度上又分為升序、降序、一天內(nèi)、一周內(nèi)、一個月內(nèi)等。在提出這些關(guān)鍵數(shù)據(jù)需求或提取數(shù)據(jù)時要和技術(shù)明確數(shù)據(jù)的粒度和定義，避免數(shù)據(jù)范疇寬泛和定義不明造成的需求不明確。
還以新聞APP的評論功能為例，在后端開發(fā)時常遇見的問題就是哪些數(shù)據(jù)要永久保存？其他數(shù)據(jù)的存儲周期是多久？所以要求PM在明確數(shù)據(jù)粒度和定義后，將關(guān)鍵數(shù)據(jù)的應(yīng)有周期設(shè)置好。比如為保證前端顯示內(nèi)容豐滿度，要求一級評論的保留周期為6個月或12個月，評論通知的有效期在3個月或6個月；為保證后端存儲空間可能會對最早的評論信息動態(tài)刪減，這些出于技術(shù)方面要考慮的需求需要PM提前和技術(shù)對接好
在敏捷開發(fā)中設(shè)計評論功能時，通常迭代規(guī)律是：實現(xiàn)文字一級評論 → 實現(xiàn)文字二級評論及回復(fù) → 實現(xiàn)評論回復(fù)的通知 → 實現(xiàn)圖片/GIF的一級評論 → 實現(xiàn)圖片/GIF的二級評論及回復(fù)。這其中設(shè)計到評論、通知、文本信息三個模塊的開發(fā)，所以要求PM不能將需求局限于一次迭代版本中，要將最終版本的需求通盤考慮后拆分給技術(shù)，告知其每個版本開發(fā)時要考慮之后功能的冗余，也就是我們經(jīng)常說的?留個口兒！
最后一點其實是PM在后臺取數(shù)時最常碰到的問題，涉及到一些敏感數(shù)據(jù)時一定要提醒技術(shù)哪些數(shù)據(jù)需要哪些權(quán)限才可查看，涉及到CMS這種后端平臺的更需要明確哪些ID可以增刪改查；前端呢，數(shù)據(jù)隱私性其實也是PM需要注意的：用戶的手機號、微信號、住址這類隱私信息一定要做馬賽克處理。鵝曾經(jīng)在做積分排行榜時疏漏了手機登錄用戶昵稱默認(rèn)使用手機號這一點，幸好超nice的技術(shù)大神自己做了星星，不然我會被打得滿頭星星的，比心?！
改需求的正確姿勢
都說改需求是PM的大忌，但其實在實際開發(fā)中，很多因素導(dǎo)致PM要在開發(fā)周期內(nèi)改PRD。（很多因素里有老板、老板、老板、老板、客戶吧）
既然胳膊扭不過大腿，那就拿出正確的該需求姿勢，將技術(shù)懟你的怒火降至冰點。
其實無非就是將改動的點想清楚后再提需求，以點為軸，輻射出需要聯(lián)動的功能或模塊。最怕的就是還沒有想好改動一點會對全局有什么影響就急忙找技術(shù)對接，不僅會造成對現(xiàn)有功能的推動重建，甚至?xí)同F(xiàn)有的功能和架構(gòu)產(chǎn)生矛盾，牽一發(fā)而動全身。最好的方法是自己先畫roadmap，或在腦圖上把和需要修改的有關(guān)功能都列出來，再找到技術(shù)master私底下討論下修改的可行性，商量出最少代碼改動的可行性方案，最后再組織需求變動評審。
純銀說過看到自己一個下午想出的idea，技術(shù)要加班加點做一兩周，就明白做PM要耐操，要對自己的需求慎之又慎，對產(chǎn)品負(fù)責(zé)。出需求前認(rèn)真復(fù)盤自己的方案、和技術(shù)/測試多一些溝通，是減少你被懟的好選擇。要想不被懟，鵝有個秘籍，記得給技術(shù)買一個月的早餐和夜宵哦~??
最近在找新坑，更新的少了，感謝大家的關(guān)注~
“好希望我的產(chǎn)品能和用戶心智相通，成為人生追求的一部分”
---鵝哥 ?
