先思考一個問題，中大型技術團隊的研發效能提升，哪個環節最重要？
下圖是敏捷方法專家ScottW.Ambler，關於“反饋與耗費成本比較”的圖，表達的思想是：需求反饋越晚，浪費的成本越高。
比方說，業務方跟你提了一個需求，你開發完並且發佈之後，業務方纔反饋這不是他想要的，所耗費的成本，是需求討論階段就反饋的50倍以上。
研發效能提升最關鍵部分就是需求治理。產品需求代表着一列火車的車頭，開發和測試好比引擎動力。車頭方向不對，引擎動力越足，就越跑偏。下面繼續來聊，需求治理的具體實施方法。
01
需求缺乏治理，40%以上的開發資源被浪費
技術領導力社區，對10多家互聯公司需求價值達成情況做了調研，在所有已上線的需求當中，有將近45%需求是沒有達到預期的，其中23%的需求，上線後根本就沒有使用過，這直接導致了開發資源被浪費，而這種浪費，通常在需求評審階段可以避免的。
通過建立起需求治理機制，可以減少“低價值”需求對開發資源的浪費，意味着公司戰略更聚焦，跑得比別的競爭對手快，就有更大的概率在競爭中勝出。
02
以價值爲導向的需求治理機制
把有限的開發資源，投入到更有價值的項目上
以價值爲導向的需求治理機制，其目的是把有限的開發資源，投入到更有價值的項目上，該機制分成幾個部分：
建立需求管理閉環。以價值爲導向的需求治理機制，是在需求提報環節，提出該需求的價值預估，即這個需求將給業務帶來什麼樣的價值，這些價值要能夠量化、能夠追蹤。比如，一個結算系統需求，價值是：提升客戶對賬效率20%，上線後會來驗證效果，看看是否達到預期。
整個閉環，分成：提交需求、排期開發、上線運營、需求調整，4個環節。
在提交需求環節，需求提報方要給出可量化的價值預估。
在排期開發環節，開發團隊將需求池裏的需求按價值大小進行PK，價值高的需求會排在前面，優先安排開發資源 。
上線運營環節，對該需求的價值進行驗證，驗證的結果將影響需求提出方的信用等級，信用等級將用於需求PK階段，作爲加減分項。
需求調整環節，也將價值做相應的調整，形成新的需求，反覆迭代，形成流程的閉環。
03
建立需求優先級的準則
制定需求優先級的準則。從緊急程度、重要程度將公司的需求分成三個等級，P0爲優先級最高，P2爲優先級最低。如下圖所示，橫座標按重要程度，分爲三類：公司戰略項目、各部門重要項目、非核心業務項目。
例如：公司戰略項目和部門重要項目，同時又非常緊急的，這類項目是P0級項目。其它類型項目，你可以輕易的對號入座了。
對於P0級項目，要求所有團隊停下手中的項目，優先插入P0級項目。所以這類項目的審批要慎之又慎，因爲它對現有開發節奏傷害最大，通常在緊急情況下才允許批准這類項目，例如，離雙11還有10天，此時發現一個秒殺系統的性能瓶頸，這個需求就是P0級別，必須馬上投入資源做。建議這類需求佔比，控制在10%以內。
對於P1級項目，可以等這個迭代完成後，加入到下個迭代進行開發。因此，通常的重要項目多爲P1級項目，它的佔比能達到70%左右。
對於P2級項目，是要在完成所有P0、P1項目之後，有剩餘開發資源了，纔可以做。這類項目佔比在20%左右。
04
開發資源衝突的解決辦法
開發資源衝突解決辦法。在協商未果的情況下，自下而上層層升級，直到問題解決。此外，跟業務方的月度需求溝通會，季度需求覆盤會，這類正式溝通會議要形成常態。
除了正式溝通之外，非正式溝通也是解決資源衝突的辦法，閒聊的時候，業務方會有意無意的提到一些尚在構思中的運營想法，一來可以幫助我們更瞭解業務，二來我們能夠更早的判斷未來業務方向。
掌握了這些信息，可以及時提醒開發同學，“此處不要寫死，將來是要變的” 做到未雨綢繆，少埋坑。
05
寫在末尾的話
如果你所在的公司也面臨着需求堆積如山，業務方怨聲載道的局面，不妨礙嘗試下“以價值爲導向的需求治理機制”。引導公司和業務方，用價值說話、用數據說話，而不是誰的聲音大就聽誰的。
將公司裏最寶貴的研發資源投入到，對公司價值最大的需求上，降低公司的機會成本和開發成本，幫助公司跑得比競爭對手快，就有希望在市場競爭當中勝出。
最後，提醒一點，實施“以價值爲導向的需求治理機制”需要得到公司一把手的支持。因爲，這是一個“資源重新配置”的遊戲，權利要歸屬老闆，只有老闆有權利和職責幹這個事，如果是技術負責人來推動這個機制，他將會成爲衆矢之的，業務方不會直說機制不好，而是說你們做得太慢，是管理問題，那麼技術負責人的處境就危險了。