需求管理是產品工作中非常重要的一個環節。但很多人不知道怎么管理，或者就是憑借一些零散的方法論進行處理。這篇文章，作者以華為的IPD需求管理為例，通過Why、What、How三個角度和數個案例，教大家如何進行需求管理，希望有所幫助。

一、WHY：為何要引用IPD來搭建需求管理體系

筆者在多年產品工作生涯中，對需求管理有一定的理解和沉淀。也引入了很多任務協同軟件，可最終總難以達成預期的管理目標。直到深入研究IPD體系，才豁然開朗。需求管理軟件若脫離了卓越的產品管理思維，就如同臨摹畫作一般，形易而神難。

需求管理體系！簡言之、就是需求的全生命周期管理，從需求的洞察、規劃、設計、開發、測試、運營。

而為何我說現在的需求管理軟件脫離了卓越的產品管理思維呢？

我觀察主要突出有如下幾個問題：

1、問題1：只有工具思維、沒有管理思維

不少引入任務協同軟件的團隊，會粗暴的認為只要引入了軟件，就完成了需求管理。殊不知軟件只是一個沒有生命的工具，就比如一把刀、若落入正義之人手，則是守土安民的利器；若落入奸邪之人手，則是禍國殃民的幫兇。管理思維才可以給予工具以生命，需求管理體系需要自己去總結、比如產品成功管理、質量標準管理、需求方案管理、流程時效管理、人天投入管理、關鍵KCP管理、組織能力管理等等。

這些管理思維更需要團隊想清楚弄明白，并為了將團隊從“一次成功走向一直成功”，再將這些管理思維固化在流程上，而流程的承載載體就是軟件工具。

2、問題2：只有當下的流程交付思維、沒有長期的組織能力思維

還有不少團隊會將軟件協同工具在組織內走通流程之后，就萬事大吉了。然后流程可能幾年都不會有重新審視和價值評估。其實這個方法也不對的、當下的流程交付只是代表那一刻的管理思維已達到最優、可長期來看，業務和市場在變化、對組織的能力要求也在變化、組織能力需要新增更多的關鍵KCP、組織能力需要新增更多的質量標準。

所以、組織能力不僅僅是當下的管理行為、更應該是長期的管理策略。

王之渙《登鸛雀樓》：“白日依山盡，黃河入海流。欲窮千里目，更上一層樓”。

我們要做好需求管理、若思維停留在“任務協同、工具軟件”的樓層、必然打不成管理預期，我們應該要在更上一層樓，思維要拔高到“流程標準、組織能力”層面。

那么就需要引入IPD管理思想，將行業最佳實踐的集成產品開發管理模型嵌入到需求管理場景中，最終打造出真正具備價值的“需求管理平臺”。

二、WHAT：什么是IPD

2.1 IPD集成產品開發概念

IPD（Integrated Product Development，集成產品開發）體系是業界最佳的產品創新與研發管理體系，它將產品開發視為一項投資行為，通過業務戰略的制訂，洞察市場機會，確定產品和項目的價值最大化風險最小化的投資組合；通過基于應用場景的客戶需求挖掘，定義產品的價值主張和功能賣點；通過高質量的Charter開發（新產品立項分析），確保產品開發團隊是在做正確的事；通過產品和技術異步并行開發，跨部門的重量級業務團隊，以及結構化的研發流程，確保產品開發團隊正確地做事；通過技術貨架和產品平臺的共享，構建核心技術競爭力并讓產品開發過程像搭積木一樣快捷；通過增量績效管理及“以奮斗者為本”的研發人力資源管理，夯實產品持續成功的研發基礎

2.2 IPD流程框架

2.3 IPD管理體系價值

1、提升產品市場成功率：

加強市場研究和需求分析，做好業務策略及決策、產品規劃和定義，加快開發進度，保障開發質量，控制開發成本，強化產品上市，從而大大提升新產品開發的成功率和商業化成效，大大降低產品研發的浪費

2、提升產品質量競爭力：

通過能力復用降低開發成本、通過關鍵KCP加強產品質量保證和構建質量控制體系，過程質量保障結果質量、在過程中增加質量保證活動、來確保每一個交付件達成質量要求從而提升產品質量競爭力。

3、提升技術和平臺開發力：

強調技術開發與產品開發有效分離，在平臺/技術規劃的牽引下，加大技術開發和積累的力度，不斷提升技術實力，同時建立強大的產品平臺，發揮平臺的杠桿作用，實現公用技術模塊（CBB）重用率的不斷提升

4、提升產品的成功必然性：

通過明確的階段劃分和決策評審點，有相應的流程、工具和方法，把能力建在組織上，構建從營銷到產品開發的整個管理流程體系，確保把一個產品的成功能復制到其它產品

三、HOW：提升產品市場成功率和成功必然性（從一次成功走向一直成功）

需求管理也分為幾個階段，分別為“要不要做、怎么來做、做得如何”。這也對應價值管理的三個維度“價值創造、價值實現、價值經營”。需求管理首先要解決的就是“要不要做”。我們來看一下，當下的需求管理普遍存在的痛點情況。

首先、需求價值評估的標準不定，以領導的意志為轉移、以產品的感性喜好為依規、以獨立節點的局部最優為考量、以需求的先進先出為排序規則。整個需求評估都是感性的、沒有方法論的、根本無法量化市場成功概率。

其次、市場訊息萬變、組織爾虞我詐。需求代表的其實就是“野心”，產品人作為需求的解析者、評估者和經營者，需要對這些“野心”進行剖析、排序、經營，可產品人的個體力量是薄弱的、憑一己之力去抗衡整個漂浮多變的需求暴風驟雨。猶如一葉扁舟駛入魔鬼三角洲。

所以，需求管理要保障市場成功率、同時要保障成功必然性。就需要給單個產品人員配備一柄利劍、斬斷這剪不斷理還亂的思絮。

3.1 實踐案例一：KCP評分卡

如下筆者負責的需求管理體系，在整個需求評審環節，搭建了需求價值評估KCP的評分卡片、通過該評分卡體系化的管理產品市場成功率、定義了需求價值評估標準、需求的可行性和優先級不再以個體的意志為轉移。同時該體系以組織發文的形式下達到需求管理流程、從而保障了管理體系的公信力。

并且、該評分卡也輔助提供了很多實踐案例、這些實踐案例可快速的幫助產品人員提升能力，各個需求均必須填充該KCP評分卡，且在“8個KCP”中進行評審，若評審不通過的則會駁回重寫。

3.2 實踐案例二：8大KCP

以筆者經手的一款財經系統，該產品邏輯復雜，橫跨費用、應收、應付、資金、總賬、影像、數據等多個產品模塊；同時作為財經系統而言，專業性又特別強。往往一個需求牽一發而動全身。更為關鍵的是該產品覆蓋集團95%以上的產業，而集團又是一家多元化經營的企業，各產業需求的差異性極強，有時候需求還會出現相互矛盾之處。

為了將KCP可持續的在組織中運作，筆者團隊還搭建了一套需求質量管理系統。將KCP嵌入到流程之中。

下圖為8大KCP的管控要點：

下圖為8大KCP的流程圖：

3.3 實踐案例三：KCP嵌入到系統流程中

四、HOW：搭建技術開發平臺、提升產品質量競爭力（能力落在組織上）

產品質量競爭力的指標是“效率、穩定、成本”。通俗而言、即用最少的錢造出更多的好產品（多快好?。?！效率=多/快、穩定=好、成本=多/?。?，這必然立于商業不敗之地?？蓪嶋H情況是團隊開發耗時不透明、耗時合理性無法評估；產品質量輸出不穩定、質量標準無法有效執行；企業重復造輪子的事情時有發生、技術中臺穩定性不足。

產品質量競爭力的工作主題就是三個“質量標準落實在流程上（KCP）、公用技術模塊（CBB）、最小化經營單位（阿米巴）”（如下圖所示）。通過這三個主題承載產品競爭力指標，最終實現多快好省的可持續的提升產品質量競爭力。

4.1 質量標準落實在流程上（KCP）

所有的管理動作若需要通過會議、郵件、培訓來監督，則該管理目標一定難以持續。管理要有效、一定要擺脫人的因素干擾。人有惰性、人有私心、人有失誤。通過“人來管人”或“人來自管”都是不可持續的。

所以、管理動作要做成漏斗模式、流程要經過必須經過這個漏斗篩查一遍，一些大顆粒的不良問題通過漏斗這個質量標準做了排查。換言之、質量標準要落實在流程上，并嵌入到關鍵評審點上（KCP），通過KCP起到漏斗的過濾效果。

4.2 公用技術模塊（CBB）

軍事理論：存地失人、人地皆失；存人失地、人地皆存。

軍事中何為組織競爭力？是一座城池、還是一支軍隊。上面的理論再明白不過~~城池誠然可以獲得補給、可并不能根本性的奠定軍事格局的戰略主動權。只有“消滅更多的敵方有生力量、擴大更多的自我軍隊力量”才是真正的戰略主動權，而且占據更多的城池，則意味著要分兵把守，無形中也削弱了軍隊的靈活機動性。

同理，開發團隊的組織競爭力，也不是不知疲倦的攻克一個個項目、更是擁有更多的“自我開發力量”。除了一些高精尖的產品強依賴某一位科學家式的英雄，其實大部分的IT產品都依賴團隊的快速交付。而其中若團隊擁有更多的組件框架、擁有更多的公共技術模塊，則可大幅度的提升開發團隊組織競爭力，從而真正的實現能力落在組織上。

公用技術模塊封裝了很多技術框架，一個初出茅廬的開發工程師調用這些框架即可快速交付產品。同時這些公用技術模塊還可以讓系統耦合性更低、讓系統穩定性更強、同時也可提升團隊的凝聚力。

4.3 最小化經營單位（阿米巴）

《稻盛和夫 | 阿米巴經營》：阿米巴經營就是通過小集體的獨立核算，實現全體參與經營，凝聚全體員工力量的經營管理系統。首先就是要有能使全體員工毫無疑義地全力埋頭工作的經營理念和經營哲學

曾記起《韓非子·內儲說上》中有一個“濫竽充數”的寓言故事。齊宣王的吹竽團隊就如同一條需求的各個參與者、有用研、產品、設計、交互、開發、測試、運營。南郭處士可能就隱藏其中。若需求不量化各個節點的耗時，那就如同300人同時吹竽，分不清優劣、看不清誰在裸泳。

組織效率肯定不是一鍋粥和稀泥，得分清楚子丑寅卯、需理得出魚目混珠。所以就需要在組織中做“最小化經營單位（阿米巴）”。將需求的各個參與者單獨拎出來量化人天。這和阿米巴經營一樣、小集體的獨立核算，從而實現全員參與經營的目標

4.4 實踐案例一：需求管理流程的阿米巴

下表是整個需求質量管理流，在整個管理流中共細分為12個節點、每個節點對應著不同的團隊角色。當然很多節點在一些企業內并不是必須，筆者分這么細目標在于量化人天，也是根據本身的產品特點而定。

五、總結

無論是購買還是自建IT軟件，首先要解決的不是軟件工具選型問題，而是管理思維再造問題。換言之、軟件供應商銷售的也并非冷冰冰的軟件工具，而是顧問式的管理最佳實踐。