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

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

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

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

01 需求輸出（PRD）自查

1.1 功能邏輯

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

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

一般公司内部都會有需求文檔規範，這個PRD規範就是一個非常基本的需求思考框架和信息傳遞框架，而且是在公司内部經過磨合以及實操驗證的。

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

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

正向過程是相對容易考慮全面，因此功能邏輯自查的重點是逆向過程，異常狀态。可以從以下幾方面着手：

1）業務異常

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

2）數據異常

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

3）網絡異常

4）服務器異常

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

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

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

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

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

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

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

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

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

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

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

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

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

1.3 視覺效果：UI稿

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

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

交給專業的設計同學

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

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

1.4 數據邏輯

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

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

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

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

産品為什麼要關注數據表結構？

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

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

從項目的完整生命周期來看，數據表結構是地基，決定了拓展性。上線後，前端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. 明确優先級：是否影響工期，是否本期一定要修改。小車，可以安排疊代更新‘’大車，緊急的話就得加班或者delay了。
3. 确定處理方案：處理人；處理方案
4. 事後總結：不是為了甩鍋，這個時候翻車就是産品的鍋，知道是哪個環節出的問題，以後才能避免。建議寫定期寫工作總結。沉澱下經驗教訓。

作者：石青；shiqingzixishi

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

題圖來自Unsplash，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部