超全需求管理指南教你如何避免翻車

超全需求管理指南，教你如何避免翻車編輯導讀：需求管理對于項目來說很重要，甚至會影響到項目的成功與否。我們應該如何進行需求管理？本文作者將從實際的工作中體會，以實踐和理論相結合的角度對產(chǎn)品經(jīng)理日常中需求管理的流程方法進行了總結，與大家分享。需求管理不同于產(chǎn)品驗收：產(chǎn)品驗收，一般指的是產(chǎn)品同學在測試完成后，驗證產(chǎn)品交互物是否符合自己的產(chǎn)品設計預期。但產(chǎn)品的工作目標是順利產(chǎn)出，拒絕翻車。因此，需求評審完后，等到測試完成才驗收是不夠的，產(chǎn)品同學應該對整個產(chǎn)研過程進行過程管理，在各個節(jié)點進行階段性驗收，即需求管理。需求管理一條龍：全流程介紹：01需求輸出（PRD）自查1.1功能邏輯邏輯閉環(huán)，不遺漏判斷；描述清楚，無歧義。（1）PRD是否有按照需求文檔規(guī)范編寫？一般公司內(nèi)部都會有需求文檔規(guī)范，這個PRD規(guī)范就是一個非?；镜男枨笏伎伎蚣芎托畔鬟f框架，而且是在公司內(nèi)部經(jīng)過磨合以及實操驗證的。按規(guī)范來寫，至少需求的框架是成型的，在信息傳輸上需要達成共識的模塊也會考慮進去了。（如果小團隊沒有需求文檔規(guī)范，可以自己總結一份。）（2）是否有異常狀態(tài)的處理?正向過程是相對容易考慮全面，因此功能邏輯自查的重點是逆向過程，異常狀態(tài)。可以從以下幾方面著手：1）業(yè)務異常逆向流程：如訂單取消，退貨退款，優(yōu)惠券退回不可用：如賬號未注冊，賬號被凍結，校驗未通過超時效：如優(yōu)惠券過期無權限：常見2B產(chǎn)品，不同角色權限不同2）數(shù)據(jù)異常輸入異常：不符合輸入要求；輸入錯誤返回異常：無搜索結果顯示異常：空數(shù)據(jù)；加載異常；排序異常3）網(wǎng)絡異常無網(wǎng)絡：無網(wǎng)絡權限；沒有聯(lián)網(wǎng)網(wǎng)絡慢4）服務器異常接口調(diào)用超時收不到回調(diào)（3）與產(chǎn)品其他模塊是否有關聯(lián)影響？如涉及功能消息通知：短信/push/Email如需求涉及到的管理后臺系統(tǒng)改造1.2交互體驗：交互稿驗收/自查記住，用戶是很懶很懶很懶的。懶得想，懶得動，懶得等！用戶路徑是否清晰？用戶能很輕松知道當前自己在哪，從哪來，可以去哪，如何能完成目標?！叭吸c擊法則：如果用戶在3次單擊中未找到他們想要的信息或了解到該網(wǎng)站的功能，他們將離開。該法則強調(diào)了清晰導航，邏輯結構和易于理解的網(wǎng)站層次結構的重要性。”用戶路徑是否直接順暢？盡量少讓用戶選擇，已知用戶要做的選擇，提前幫他選好。但同時用戶可以隨時中止或退出。用戶操作是否簡單？業(yè)內(nèi)通用模塊的交互設計，已經(jīng)培育了一代用戶的操作習慣。如果沒特殊情況，新設計也沒有質(zhì)的飛躍，比如從文字交互到語音交這種變化，那就別標新立異，否則反而增加了用戶使用門檻。是否及時反饋？尤其是異常提示，錯誤提示，是否及時反饋給用戶，并告知下一步需要做哪些事情來結束當前的異常狀態(tài)。用戶等待時間是否再短一些？等待時間越短，用戶體驗就越好。能否通過業(yè)務流程優(yōu)化或者性能優(yōu)化減少用戶的等待時間，不能的話，那就需要考慮是否需要通過其他方式分散用戶注意力，拒絕產(chǎn)生“度秒如年”的感受。文案是否確認，文案風格是否友好？涉及到不同語言版本的，提前準備好翻譯。同樣的表述，不同語言的文字長度是有差別的，提前準備好，方便交互，設計根據(jù)文字長度進行設計。復雜/特殊的交互方案，是否描述清楚？一文字描述二口頭溝通三模擬效果展示復雜的交互方案，性價比高么？產(chǎn)品的核心工作是平衡需求和資源，做最優(yōu)決策。所以，開發(fā)資源不足的時候，非核心流程的交互，就不要死磕了。1.3視覺效果：UI稿頁面信息顯示優(yōu)先級明確產(chǎn)品/業(yè)務上需要強調(diào)的內(nèi)容，視覺上是否足夠強調(diào)彈窗等全局組件是否盡量統(tǒng)一？全局組件，通用組件盡量統(tǒng)一，一是風格統(tǒng)一好看，二是開發(fā)起來復用性好。審美交給專業(yè)的設計同學復雜/特殊的視覺是否描述清楚？一文字描述二口頭溝通三模擬效果展示復雜/特殊的視覺效果，性價比高么？同樣，開發(fā)資源不足的時候，非核心流程的視覺效果，勸一勸設計同學~1.4數(shù)據(jù)邏輯（1）數(shù)據(jù)存儲，數(shù)據(jù)處理這主要考量的就是數(shù)據(jù)表結構的設計。什么是數(shù)據(jù)表？什么是數(shù)據(jù)表結構？“數(shù)據(jù)表是由表名、表中的字段和表的記錄三個部分組成的。設計數(shù)據(jù)表結構就是定義數(shù)據(jù)表文件名，確定數(shù)據(jù)表包含哪些字段，各字段的字段名、字段類型、及寬度，并將這些數(shù)據(jù)輸入到計算機當中?！碑a(chǎn)品為什么要關注數(shù)據(jù)表結構？需求的確不一定都需要關注表結構才能完成，是可以完全交給開發(fā)設計。但是底層的數(shù)據(jù)邏輯思維，對于產(chǎn)品來說是很關鍵的?；ヂ?lián)網(wǎng)產(chǎn)品本質(zhì)結構都是數(shù)據(jù)，業(yè)務邏輯是否清晰就看數(shù)據(jù)邏輯是否清晰。數(shù)據(jù)從哪來，去哪，如何變化，都是在表里發(fā)生的。不過是多復雜的產(chǎn)品，實質(zhì)就是一堆數(shù)據(jù)在表里的流轉。數(shù)據(jù)邏輯清晰了，業(yè)務邏輯也就清晰了。從項目的完整生命周期來看，數(shù)據(jù)表結構是地基，決定了拓展性。上線后，前端UI展示等要優(yōu)化的話是很好改的，但如果涉及要改底層的數(shù)據(jù)表結構，那就是一個龐大的工程。所以，數(shù)據(jù)表結構，產(chǎn)品可以不參與設計，但是一定要和開發(fā)同學保持充分的溝通。因為，開發(fā)一般是基于當前的需求進行技術設計，這樣的情況下，架構很可能有局限性，無法適應日后的業(yè)務拓展。而上線后的重構是很痛苦的，成本也很高。因此，產(chǎn)品的介入，能幫助開發(fā)在架構設計時有更好業(yè)務前瞻性，也有助于產(chǎn)品自己對技術架構設計的了解。產(chǎn)品要關注哪些點？主要關注存儲的字段，和表關系。單張表：表中字段名稱，字段所屬對象，字段值類型，取值來源，最長長度，字段說明多張表之間的關系：一對一，一對多，多對多。關系盡量簡單。比如多對多的關系，可以增加一個第三方，改為兩個一對一的關系。（2）接口設計一般而言，內(nèi)部的接口無需額外關注，但平臺類產(chǎn)品，接口對第三方開放的，則需要從業(yè)務角度，思考如何設計接口，從而對第三方調(diào)用會更友好，有更好的兼容性。入?yún)?返參：產(chǎn)品不需要定義API所有的字段，但涉及到業(yè)務需求的字段，需要明確出入?yún)⒁?。接口性能要求：產(chǎn)品需要對業(yè)務充分評估，給出TPS/QPS限制，保證業(yè)務順暢運行的同時，也不浪費服務器資源。（3）數(shù)據(jù)指標體系明確業(yè)務目標，根據(jù)業(yè)務目標，用戶路徑確定數(shù)據(jù)指標：注意數(shù)據(jù)的準確性，可獲取性，時效性，統(tǒng)計口徑是否一致建立報表并搭建相應的監(jiān)控告警體系（4）埋點埋點定義：基于業(yè)務需求，為日后進行數(shù)據(jù)分析，提前在應用中特定流程植入代碼采集數(shù)據(jù)，從而達到追蹤用戶行為，輔助決策的目的。觸發(fā)事件分類：曝光：每被用戶看到一次，就是一個曝光事件。比如商品的曝光。點擊：用戶每進行一次點擊，就是一個點擊事件。比如按鈕的點擊。舉例：（不同公司，埋點規(guī)范不同，按公司要求來就好）1.5拓展性需求功能點是否考慮做成可配置需求功能點是否可做成通用模塊，提高復用性1.6監(jiān)控報警是否需要對關鍵數(shù)據(jù)指標進行監(jiān)控，并設置報警閾值。1.7部門協(xié)同需要協(xié)同的部門，是否都確認和周知？非常重要，不要閉門造車，然后辛辛苦苦開發(fā)完，結果安全/風控/合規(guī)部門一句sayno，上不了線…02了解技術實現(xiàn)方案開篇提到，產(chǎn)品不是寫完PRD，需求評審完就完事，一定要跟蹤產(chǎn)研整個過程。為啥不懂技術的產(chǎn)品要去了解技術實現(xiàn)方案呢？如”上文1.4數(shù)據(jù)邏輯”所述，開發(fā)一般是基于當前的需求進行技術設計，這樣的情況下，架構很可能有局限性，無法適應日后的業(yè)務拓展。產(chǎn)品的介入，能幫助開發(fā)在架構設計時有更好業(yè)務前瞻性，也有助于產(chǎn)品自己對技術架構設計的了解。以防自己留坑。產(chǎn)品的規(guī)則沒有細化并明確，開發(fā)按照自己的理解進行了功能設計，多溝通才能發(fā)現(xiàn)自己埋的坑。產(chǎn)品規(guī)則明確了，但開發(fā)有可能沒仔細看PRD，PRD寫得再好，也架不住開發(fā)不看。和團隊保持積極良好的雙向溝通是非常重要的。一個60分的產(chǎn)品，如何提高自己的需求質(zhì)量？很重要的一點就是溝通。開發(fā)/運營/測試提出問題，一定要重視，并且及時給到正向的反饋。否則，別人就算覺得需求有問題，也不愿意和你說，反正鍋不在他那。03UI驗收UI驗收，是由UI設計同學來驗證開發(fā)完的系統(tǒng)UI還原度，是否能夠達到預期的效果。這里產(chǎn)品同學要介入的是ui驗收報告，沒有報告的話，就保證和ui及時溝通，了解當前的問題。04測試這一步，產(chǎn)品主要關注的是測試用例。測試用例是否完善：流程：正向流程，逆向流程，異常流程是否全部涵蓋操作：執(zhí)行步驟，預置條件，預期結果數(shù)據(jù)：數(shù)據(jù)的記錄是否完整，流轉是否正確萬一翻車了，咋整？測試完成，產(chǎn)品在上線前進行最后的驗收，確認程序開發(fā)是否符合需求預期。萬一到