編輯導讀：需求管理對于項目來說很重要，甚至會影響到項目的成功與否。我們應該如何進行需求管理？本文作者將從實際的工作中體會，以實踐和理論相結合的角度對產品經理日常中需求管理的流程方法進行了總結，與大家分享。

需求管理不同于產品驗收：產品驗收，一般指的是產品同學在測試完成后，驗證產品交互物是否符合自己的產品設計預期。但產品的工作目標是順利產出，拒絕翻車。

因此，需求評審完后，等到測試完成才驗收是不夠的，產品同學應該對整個產研過程進行過程管理，在各個節點進行階段性驗收，即需求管理。

需求管理一條龍，全流程介紹：

01 需求輸出（PRD）自查

1.1 功能邏輯

邏輯閉環，不遺漏判斷；描述清楚，無歧義。

（1）PRD是否有按照需求文檔規范編寫？

一般公司內部都會有需求文檔規范，這個PRD規范就是一個非?；镜男枨笏伎伎蚣芎托畔鬟f框架，而且是在公司內部經過磨合以及實操驗證的。

按規范來寫，至少需求的框架是成型的，在信息傳輸上需要達成共識的模塊也會考慮進去了。（如果小團隊沒有需求文檔規范，可以自己總結一份。）

（2）是否有異常狀態的處理?

正向過程是相對容易考慮全面，因此功能邏輯自查的重點是逆向過程，異常狀態?？梢詮囊韵聨追矫嬷郑?/p>

1）業務異常

• 逆向流程：如訂單取消，退貨退款，優惠券退回
• 不可用：如賬號未注冊，賬號被凍結，校驗未通過
• 超時效：如優惠券過期
• 無權限：常見2B產品，不同角色權限不同

2）數據異常

• 輸入異常：不符合輸入要求；輸入錯誤
• 返回異常：無搜索結果
• 顯示異常：空數據；加載異常；排序異常

3）網絡異常

• 無網絡：無網絡權限；沒有聯網
• 網絡慢

4）服務器異常

• 接口調用超時
• 收不到回調

（3）與產品其他模塊是否有關聯影響？

• 如涉及功能消息通知：短信/push/Email
• 如需求涉及到的管理后臺系統改造

1.2 交互體驗：交互稿驗收/自查

記住，用戶是很懶很懶很懶的。懶得想，懶得動，懶得等！

• 用戶路徑是否清晰？

用戶能很輕松知道當前自己在哪，從哪來，可以去哪，如何能完成目標。

“三次點擊法則：如果用戶在3次單擊中未找到他們想要的信息或了解到該網站的功能，他們將離開。該法則強調了清晰導航，邏輯結構和易于理解的網站層次結構的重要性?！?/p>

• 用戶路徑是否直接順暢？

盡量少讓用戶選擇，已知用戶要做的選擇，提前幫他選好。但同時用戶可以隨時中止或退出。

• 用戶操作是否簡單？

業內通用模塊的交互設計，已經培育了一代用戶的操作習慣。如果沒特殊情況，新設計也沒有質的飛躍，比如從文字交互到語音交這種變化，那就別標新立異，否則反而增加了用戶使用門檻。

• 是否及時反饋？

尤其是異常提示，錯誤提示，是否及時反饋給用戶，并告知下一步需要做哪些事情來結束當前的異常狀態。

• 用戶等待時間是否再短一些？

等待時間越短，用戶體驗就越好。能否通過業務流程優化或者性能優化減少用戶的等待時間，不能的話，那就需要考慮是否需要通過其他方式分散用戶注意力，拒絕產生“度秒如年”的感受。

• 文案是否確認，文案風格是否友好？

涉及到不同語言版本的，提前準備好翻譯。同樣的表述，不同語言的文字長度是有差別的，提前準備好，方便交互，設計根據文字長度進行設計。

• 復雜/特殊的交互方案，是否描述清楚？

一文字描述 二口頭溝通 三模擬效果展示

• 復雜的交互方案，性價比高么？

產品的核心工作是平衡需求和資源，做最優決策。所以，開發資源不足的時候，非核心流程的交互，就不要死磕了。

1.3 視覺效果：UI稿

• 頁面信息顯示優先級明確

產品/業務上需要強調的內容，視覺上是否足夠強調

• 彈窗等全局組件是否盡量統一？

全局組件，通用組件盡量統一，一是風格統一好看，二是開發起來復用性好。

• 審美

交給專業的設計同學

• 復雜/特殊的視覺是否描述清楚？

一文字描述 二口頭溝通 三模擬效果展示

• 復雜/特殊的視覺效果，性價比高么？

同樣，開發資源不足的時候，非核心流程的視覺效果，勸一勸設計同學~

1.4 數據邏輯

（1）數據存儲，數據處理

這主要考量的就是數據表結構的設計。

什么是數據表？什么是數據表結構？

“數據表是由表名、表中的字段和表的記錄三個部分組成的。設計數據表結構就是定義數據表文件名，確定數據表包含哪些字段，各字段的字段名、字段類型、及寬度，并將這些數據輸入到計算機當中?！?/p>

產品為什么要關注數據表結構？

需求的確不一定都需要關注表結構才能完成，是可以完全交給開發設計。但是底層的數據邏輯思維，對于產品來說是很關鍵的。

互聯網產品本質結構都是數據，業務邏輯是否清晰就看數據邏輯是否清晰。數據從哪來，去哪，如何變化，都是在表里發生的。不過是多復雜的產品，實質就是一堆數據在表里的流轉。數據邏輯清晰了，業務邏輯也就清晰了。

從項目的完整生命周期來看，數據表結構是地基，決定了拓展性。上線后，前端UI展示等要優化的話是很好改的，但如果涉及要改底層的數據表結構，那就是一個龐大的工程。

所以，數據表結構，產品可以不參與設計，但是一定要和開發同學保持充分的溝通。因為，開發一般是基于當前的需求進行技術設計，這樣的情況下，架構很可能有局限性，無法適應日后的業務拓展。而上線后的重構是很痛苦的，成本也很高。因此，產品的介入，能幫助開發在架構設計時有更好業務前瞻性，也有助于產品自己對技術架構設計的了解。

產品要關注哪些點？

主要關注存儲的字段，和表關系。

單張表：表中字段名稱，字段所屬對象，字段值類型，取值來源，最長長度，字段說明

多張表之間的關系：一對一，一對多，多對多。關系盡量簡單。比如多對多的關系，可以增加一個第三方，改為兩個一對一的關系。

（2）接口設計

一般而言，內部的接口無需額外關注，但平臺類產品，接口對第三方開放的，則需要從業務角度，思考如何設計接口，從而對第三方調用會更友好，有更好的兼容性。

入參/返參：產品不需要定義API所有的字段，但涉及到業務需求的字段，需要明確出入參要求。

接口性能要求：產品需要對業務充分評估，給出TPS/QPS限制，保證業務順暢運行的同時，也不浪費服務器資源。

（3）數據指標體系

明確業務目標，根據業務目標，用戶路徑確定數據指標：

• 注意數據的準確性，可獲取性，時效性，統計口徑是否一致
• 建立報表并搭建相應的監控告警體系

（4）埋點

埋點定義：基于業務需求，為日后進行數據分析，提前在應用中特定流程植入代碼采集數據，從而達到追蹤用戶行為，輔助決策的目的。

觸發事件分類：

1. 曝光：每被用戶看到一次，就是一個曝光事件。比如商品的曝光。
2. 點擊：用戶每進行一次點擊，就是一個點擊事件。比如按鈕的點擊。

舉例：

（不同公司，埋點規范不同，按公司要求來就好）

1.5 拓展性

需求功能點是否考慮做成可配置

需求功能點是否可做成通用模塊，提高復用性

1.6 監控報警

是否需要對關鍵數據指標進行監控，并設置報警閾值。

1.7 部門協同

需要協同的部門，是否都確認和周知？

非常重要，不要閉門造車，然后辛辛苦苦開發完，結果安全/風控/合規部門一句say no，上不了線…

02 了解技術實現方案

開篇提到，產品不是寫完PRD，需求評審完就完事，一定要跟蹤產研整個過程。

為啥不懂技術的產品要去了解技術實現方案呢？

• 如”上文1.4數據邏輯”所述，開發一般是基于當前的需求進行技術設計，這樣的情況下，架構很可能有局限性，無法適應日后的業務拓展。產品的介入，能幫助開發在架構設計時有更好業務前瞻性，也有助于產品自己對技術架構設計的了解。
• 以防自己留坑。產品的規則沒有細化并明確，開發按照自己的理解進行了功能設計，多溝通才能發現自己埋的坑。
• 產品規則明確了，但開發有可能沒仔細看PRD，PRD寫得再好，也架不住開發不看。

和團隊保持積極良好的雙向溝通是非常重要的。一個60分的產品，如何提高自己的需求質量？很重要的一點就是溝通。開發/運營/測試提出問題，一定要重視，并且及時給到正向的反饋。否則，別人就算覺得需求有問題，也不愿意和你說，反正鍋不在他那。

03 UI驗收

UI驗收，是由UI設計同學來驗證開發完的系統UI還原度，是否能夠達到預期的效果。這里產品同學要介入的是ui驗收報告，沒有報告的話，就保證和ui及時溝通，了解當前的問題。

04 測試

這一步，產品主要關注的是測試用例。

測試用例是否完善：

• 流程：正向流程，逆向流程，異常流程是否全部涵蓋
• 操作：執行步驟，預置條件，預期結果
• 數據：數據的記錄是否完整，流轉是否正確

萬一翻車了，咋整？

測試完成，產品在上線前進行最后的驗收，確認程序開發是否符合需求預期。

萬一到這步還有遺留問題，四步解決：

1. 定位問題：發現問題的時間；所屬模塊；具體問題描述（附上截圖）
2. 明確優先級：是否影響工期，是否本期一定要修改。小bug，可以安排迭代更新，大bug，涉及核心流程或者緊急的話就得加班或者delay了。
3. 確定處理方案及處理人
4. 事后總結：不是為了甩鍋，這個時候翻車就是產品的鍋，知道是哪個環節出的問題，以后才能避免。建議寫定期寫工作總結。沉淀下經驗教訓。

作者：石青；微信公眾號：shiqingzixishi

本文由 @石青 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議