作為一名產品經理，會在日常工作中接收到各種需求，而解決需求要提供對應的解決方案。本篇文章以華為的 IPD 需求管理流程為例，探討其需求管理思路，幫助產品崗位的你快速做好需求管理并解決方案。

說到這個話題，我們先來理一下關鍵詞【需求】到底指的是什么？

一般來說，需求是一個想法，指的是誰想通過什么來解決什么樣的問題。

(相關資料圖)

在互聯網產品孵化以及商業化的各個階段，我們會接收到無數問題或者建議，像業務需求、系統需求、用戶需求、包括其他各式各樣的建議類需求（技術、市場、測試、缺陷等）。

我們可以把它們叫做需求，但這些都不屬于產品需求，那什么是產品需求呢？

華為提了一個思路，那就是：

產品需求 = 場景問題 + 解決方案

因此，很明顯，產品需求提供的是針對問題的解決方案。

有了產品需求，產品經理就可以進行產品功能設計搭建，進而完成后續開發實現、測試上線、周期迭代的過程。

而產品需求，則需要有一個標準化的管理模式。

沒有標準化的管理思維，就會產生如下問題：

產品需求混亂，頻繁變更，研發周期成本加大，代碼結構混亂無法維護。

采用技術導向開發產品，想要通過技術優勢讓客戶買單，但并沒有。

一味抄襲模仿，產品并沒有形成市場競爭優勢，最后全程了代碼廢墟。

產品交付質量差，客戶現場成了產品實驗局。

未提前識別需求風險，研發預算失控，項目虧錢。

需求做一次完一次，公司像外包，沒有核心產品，無法應對市場變化。

…

諸如此類，太多太多。

為了解決上面這些問題，我們來看一下標桿企業華為是怎么做的？

二、華為 IPD 需求管理流程

小拓展：IPD 即集成產品開發體系，最早來源于美國，后被華為引進，改良為更適合國內企業的研發管理體系，被廣泛使用。是一套端到端的方法論，需求管理只是其中的一環。

首先，需求管理 = 全生命周期的管理。

在華為 IPD 里分為幾個階段：需求收集、需求分析、需求分發、需求實現、需求驗證。

如下圖：

當然這個是華為內部的一個管理，使用的時候具體情況具體看待。

我們分別對每一個階段，來進行一個思路延展，看看在互聯網產品里，它是如何適用的。

1. 需求收集

關注問題：需求從哪來？如何收集？

這一階段，我們首先確定對內和對外需求來源。

1）對內

領導、產品研發組、行研組、市場、研發、測試等。

從需求收集的出發點來說，需要改變以往的串行體系，優化為各部門協作的并行體系（專指與客戶、行業接觸最緊密的部門）。即大家圍繞產品坐在一起討論應該是什么樣。

因為需求是分布在各個部門的（比如市場更熟悉行業、客戶；開發更熟悉技術需求、運維采購知道如何實現成本最低等等），這就是華為 IPD 變革帶來的創新。在這個對內的需求收集階段，一般產品研發團隊負責收集和歸檔。

2）對外

客戶、使用方、行業、友商、媒體、數據分析等。

對外的需求來源階段，我們重點關注幾個點：

行業內上下游產業鏈中，top 友商企業的競品分析。

行業研究分析。通過產品市場反饋數據進行分析收集等。

常用的華為需求收集方式：問卷調查、焦點小組、面對面訪談、第三方調研、客戶滿意度調查、β 測試、概念原型驗證評審、高層拜訪…

分享一個常用的需求采集卡、或者方便可以做成在線文檔表格進行收集歸檔：

在收集這些潛在的功能需求時，我們不要忘記收集 DFX 需求，因為產品需求 = 功能需求 +DFX 需求。

成熟的企業，是會把這些都落實到產品開發里的，而很多現實情況里，卻都容易忽視 DFX。

2. 需求分析

通過審視收集上來的需求（一般包括 bug、新需求、優化需求），進行需求過濾、需求重構、優先級排序。

初步篩選：通過對需求描述的檢視過濾掉無價值、不可行的需求；再進行優先級排序。

需求優先級方法：KANO 模型、四象限法則、投入產出比優先、二八法則 ( 挖掘使用高頻的 20% 需求）、風險成本、技術限制等進行劃分。

3. 需求分發

需求分析結束，就到了需求分發階段，在華為的理念原則是：需求分發的目的是將分析后的需求分配到最佳的組織和流程中去拆解完善和處理。

我們可以看到、不同的需求包有各自對應的流程機制來進行處理，分別為：

長期需求（未來 3-5 年需求）：產品演進長期需求進入市場 / 戰略管理類團隊進行分析歸檔。

中期需求（未來 1-3 年需求）：形成產品路標、指導產品階段迭代體系。

短期需求（1 年內）：需要盡快立項，通過 charter 評審，進入產品開發流程處理。

緊急需求（需盡快實現）：來源與領導或者高價值客戶或者產品 bug、優化需求，都需要通過變更評審納入開發項目處理（盡量降低此類需求占比、因為只能說明產品前期規劃能力較差）。

到此，我們得出了待進入開發流程的產品需求池，產品經理需要形成一個需求池表格進行動態管理（需描述清楚需求的基本信息、狀態、優先級、工作量等，內容要求視各公司情況而定）。

4. 需求實現

需求實現是需求進入開發階段，跟蹤管理、指導發布測試的過程。

從需求的立項、產品架構、產品演進圖路標的導入，到需求包的發布、評審；到產品經理的原型設計、文檔輸出；和研發中需求變更的控制，直至產品上線、進入驗證階段。都是產品經理需要參與或者管理的實現環節。

這一過程，考驗產品經理的需求溝通能力、解決阻塞問題、需求邊界管理、產品迭代版本管理、項目進度管理、產品質量（體驗及功能設計）等多項能力，更重要的是極強的思辨能力。

甚至在這個過程當中，若出現重大研發失誤，產品將推翻重來。

需求實現的過程當中，產品經理要重點跟進變更的需求，以及在開發中的需求阻塞問題，確保需求可正常進行。

有重大外部資源阻塞的需求，如果剛開始沒有識別出來，在這一階段做不了要全部納入需求池記錄。

5. 需求驗證

需求驗證環節，一般整個過程要經過模塊需求驗證（單元測試）、子系統需求驗證（子系統集成測試，即是否滿足概要設計的要求）、確認測試（即是否滿足需求特性規格的要求）系統需求驗證（系統測試 , 即非功能需求特性的符合度）、特性驗證（α 測試）、客戶驗證（β 測試）等測試驗證活動。

最終滿足驗證需求，形成可實施交付 / 發版上線的高質量產品。

雖然主要工作都在測試團隊，但必要時，在這個環節，建議產品經理也參與進來，進行產品交叉驗證。便于了解研發實現結果與預估的匹配度和存在的問題，并記錄下來，歸類留檔，便于后續產品管理體系的完善。

你會發現：什么叫各有所想。

三、總結

綜上，其實我們通過華為 IPD 的需求管理思路呢，能感受到華為以 " 客戶需求為中心 " 的理念，也感受到沒有流程化支撐的策略其實都是在紙上談兵，不切實際。

有時候管理思維適用于企業，更適用于我們產品經理個人的日常工作，回歸到本質。

我們常說：產品經理非經理，而是產品的經理，要為產品負責。

如果在產品管理當中你運用了較好的流程化思維，把控好每一個需求節點，這樣的產品它對企業、客戶甚至自己就是有價值的。

一些延伸

IT 需求管理工具

推薦一些提高效率的 IT 需求管理工具：其實大部分情況是跟隨開發計劃一起協作的 PingCode、Worktile、ONES、禪道、JIRA、TAPD、數知鳥、Polarion 等。

以上這些工具，都擁有各自特點，可以根據項目、團隊的規模、領域和特點，來選擇最適合自己的需求管理工具。

一些書籍推薦

《IPD 華為研發之道》

《華為能，你也能：IPD 產品管理實踐》

本文由 @凱拉 Kella 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議。