需求管理是大部分研發型企業十分重視的一項管理活動，但在實際的執行運作過程中，仍然會出現一些問題，影響管理的效果，導致項目偏離預期。

Q1：需求鎖定偏晚，該如何解決？

問：需求管理可能是一些公司的通病，目前我司流程比較完善，問題主要在執行層面上。比如需求的鎖定偏晚，該如何解決？

答：需求確定比較晚一般情況下是由于以下幾方面原因引起的，針對不同病因應對癥下藥，以下基于三種不同原因進行分析并解答。

1．公司不重視需求開發與管理過程，項目經常“裸奔”，立項后不進行充分的需求開發與分析，經常在需求相對模糊的狀態下就進入設計過程。

解決辦法：系統地梳理產品需求開發與管理流程，對負責需求開發與管理的幾個關鍵角色（市場人員、產品經理、系統工程師）進行合理的分工與集成，把需求調研與收集、需求整理與分析、需求定義與分配、需求轉化與跟蹤、需求實現幾個過程進行端到端串聯，同步引入需求評審機制，每個節點進行有效評審。一方面是確保前后分解的需求一一對應，另一方面是確保每一個過程的需求符合該過程的要求時，才能進入下一環節，以此來保證需求鎖定及時、準確、有效。

2．需求開發過程中覆蓋不全面，沒有圍繞產品包進行需求開發，往往只關注了產品的功能/性能需求，卻忽略了其他方面的需求。

解決方法：首先，產品需求定義一定要有“包需求”的概念，從產品價值需求（滿足用戶的哪些核心價值）、實際產品需求（功能、性能、包裝、質量、品牌等）、產品附加需求（可制造、可服務、可運輸安裝、用戶體驗等）三個層次自內向外地進行需求分析，可以確保需求的覆蓋度相對完整，不會有重大遺漏。其次，在“包需求”開發過程中一定要覆蓋到能提供需求信息的所有領域，比如客戶、終端用戶、電商平臺、競爭對手、行業分析報告、各種大會、展會、公司的客服及運維窗口，內部產品開發團隊渠道均要有效覆蓋。收集和匯總相應領域的產品需求反饋，進行綜合分析，以保證需求來源的全面。有時候，并不是我們無法鎖定需求，而是沒有考慮到某些需求的來源和渠道，盡可能地覆蓋需求開發的來源可以有效幫助我們提升需求開發的效率。

3．如果以上兩點都沒有問題，但需求轉化過程不清晰，產品需求定義顆粒度不夠，為開發過程中的需求增減和變更埋下隱患。

解決方法：完整的需求開發過程根據需求在不同過程中的形態和要求把需求分為“初始需求、原始需求、特性需求、系統需求”四個階段形態。但很多企業并不清楚這些需求的對應和轉換關系，很多只簡單地定義了初始需求，例如“產品需要更加便攜、易攜帶”。這個需求實際上是客戶或者用戶的一個訴求，看似需求明確，實則非常模糊，我們一般叫做初始需求。“便攜”的標準是什么？是輕、是小、還是可以移動？沒有說清楚。隨著產品開發的進行，試驗了無數次把產品做小，但效果不佳，最后加了兩個輪子實現了便攜移動的功能。但實際上在初始需求描述的基礎上繼續分析，是可以定義出“產品安裝4個移動輪，實現推行”這樣的特性需求的，再往下如何在產品上安裝4個輪子，大小、規格、位置的定義是系統需求的定義。按照這個邏輯，一個客戶訴求（初始需求）可能會衍生出多個特性、系統需求，只有逐一地向下分解和分析，才能得到更全面、更有價值的產品需求。這個傳遞過程一來可以幫助我們清晰完整的定義產品，二來也可以把最初的初始需求與最后的產品設計元素建立起一一對應關系，更有助于過程中對需求的跟蹤、評審和驗收管理。

Q2：如何減少需求變更？

問：需求變更較多，比例較大，如何減少需求變更，并進行有效的變更管理？

答：如何減少需求變更這個話題一定要從變更的源頭上談起，不同的變更原因有不同的改進辦法，追本溯源，一般一起大量需求變更現場的產生不外乎兩個原因：

1．需求定義不足、漏洞百出，后期當然要增加對所遺漏定義的需求。

解決辦法:首先就是項目概念階段就把需求定義全面，具體做法可以參考上一個問題中所述的解決辦法；其次就是為需求定義的角色（市場或產品經理）分配需求穩定度的指標，在項目過程的不同階段，定義出允許需求變更的類別和范圍是什么，超出范圍的變更一旦執行，就要反饋到需求定義角色的績效中，通過這種方法促使需求定義人員一開始就把需求定義工作做好。

2．需求定義不準，嚴謹度不足，導致后期經常調整，比如需求中本來定義了“通過藍牙進行信息傳輸”的功能，但在開發進程中又提出客戶更希望通過“Wifi傳輸”,導致需求隨之變更。

解決辦法:類似這種現象，要么是需求定義過程缺陷或者人員能力問題，可以根據企業能力對需求開發與管理過程進行優化，并對需求分析人員能力進行提升；要么就是需求定義人員的態度問題，因為變更很簡單，沒有約束，那為什么要花很大心思在前面做那么多功課呢？反正錯了可以改。如果是這種原因，就必須制定行之有效的措施加以改進和糾正：

第一，改進變更申請流程，所有申請需求變更的來源必須經過主管領導的審核和批準才能提交到項目組，從源頭上正視變更這件事，告訴所有人這是一件很嚴肅的事情；

第二，嚴格按照變更流程執行，進行充分的變更影響分析（時間延期、成本增加、質量風險，產生的浪費等），把這些數據都反饋給變更申請者，如果執行變更，申請者就需要對上述的變化負責。事實經驗說明，一旦對變更進行了充分的數據分析，再把數據反饋給變更申請者，很多變更就會取消，因為大家不愿意接受大的變化、影響或者風險。之所以原來肆無忌憚，是因為變更申請者和項目團隊都沒有認真分析過變更影響，都以為任何變更都很簡單。所以數據分析很重要；

第三，建立變更控制委員會（CCB），變更交由CCB裁決，同步按照第一點的要求進行記錄和統計變更原因，影響變更責任者績效。

通過以上三個措施改進可以大幅減少無效的變更，同時可以促使上游（需求分析和需求定義）過程做的更加精確。

同時也要注意，需求變更的目的是把產品做好，所以不要認為有變更就一定是錯的，因為即使你再牛，也不可能一開始就把所有需求都百分百定義全面和準確，只是通過以上方法盡可能地讓這個數據逼近100%，剩余的按照變更流程正常執行即可。

Q3：需求管理過程中，如何減少“扯皮”現象？

問：在實際執行中，困難在于需求的多頭管理和下發，出問題的時候互相推責任。怎樣能夠解決這些問題，實現有效的需求管理？

答：產品需求從“初始需求、原始需求、特性需求、系統需求”幾個過程逐級向下分解，在系統需求層面，把每個需求點分配給不同的開發者，并通過需求跟蹤矩陣進行實時的跟蹤與驗收，每個階段評審都需要對需求的滿足度進行評估，而不是等到產品驗收時才返回來講說這個需求沒滿足，那個需求沒滿足，這個時候“扯皮”現象就會屢禁不止。所以總結下來做到以下三點，可很大程度上緩解上述問題：

1.需求細化到系統設計規格，可以落實到具體責任人；

2.建立需求跟蹤矩陣進行需求跟蹤；

3.每個階段實施驗收，未滿足的需求當下分析責任。

Q4：產品定義中如何融入客戶需求與用戶需求？

問：客戶需求與用戶需求的區別？在產品定義中如何將二者的需求進行合理融入？

答：用戶一般是指產品的最終使用者，客戶一般是指品牌商、運營商、代理商等產品鏈中與產品運營相關的機構或個人。通常來講，廣義的客戶包含了終端用戶，產品本質上是要滿足終端用戶的需求，唯有如此，產品才具備價值，才能讓產品運作的整個鏈條獲得利益。從這個角度來看，我們和客戶的立場是一致的，用戶需求分析時更多的考慮產品包需求中的價值需求與實際產品需求，客戶需求分析時更多的考慮外圍需求。但往往用戶期望價格更便宜，客戶期望能夠多賺錢，所以要賣的貴一些，這時出現的用戶需求與客戶需求的沖突，實際上是一個商業運作和平衡的問題。平衡這個問題既要考慮用戶與客戶的利益，還要考慮自身的品牌價值以及客戶的粘性等諸多因素。建議可以在產品需求定義中，單獨對客戶的需求進行說明定義，重點考慮價格、利潤、維護、運輸、安裝和服務、以及品牌合作等方面，以確保產品的商業運作符合客戶的基本需求。

產品定義的目的是確保產品是滿足開發者、客戶、用戶及其他利益相關者的利益訴求，所以產品定義過程實際上是在做需求平衡的工作，核心思想就是每個利益相關者都能夠獲得自己的價值和利益。