需求變更，相信大家一定都遭遇過，即使項目在啟動時已經具備完整的需求，在項目啟動后還是可能會變動。而且由於管理模型的不同，在項目啟動后對需求變更會是件特別耗時費力的事。
這就是為什么我們需要一個持續的需求管理流程，這樣能不僅能幫助控制成本，避免規模失控，還能保證完整的可追溯性。好的需求管理系統在需求變化時，能夠實現靈活地管理，還能高效地交付功能。我們在實踐中總結了一些能幫助我們避免需求的頻繁變更的方法，下面就來簡單介紹。
一、盡可能多的渠道搜集需求
首先是搜集需求。這個過程要包含所有相關的渠道：比如新老用戶、管理人員、業務分析師和其他的參與人員。尤其是注意那些會真正使用系統的用戶，因為在系統性能和用戶界面方面，他們會給你提供最可用的信息。把他們作為最高級別的需求來源能讓你的產品或服務真正解決客戶的痛點。
怎么從用戶獲得需求？
注意用戶非正式的評價或吐槽 - 需求也許就藏在其中。
對於預設的問題，要捕捉用戶的反應。
和那些能與用戶直接交流的管理人員持續的開展頭腦風暴。
仔細的看看用戶所處的環境。
更多的從用戶角度去了解 - 比如他們日常是如何使用產品來開展任務的，他們的工作流程、任務的排序、內部規則、可能會遇到哪類問題，或者是用戶、團隊成員之間的交流。
我們通過PingCode，匯集了用戶、市場人員、售前、客服等不同渠道的用戶需求
二、確定需求優先級
分類需求並不是一件簡單的事。當項目成熟時，我們要把需求文檔化，並把所有信息保持在最新狀態，來保證其在測試和驗證時可追溯。需求的優先級整理，能確保團隊發現缺失，矛盾或者是重復。清晰的需求結構有助於測試管理期間更容易的決定執行哪些操作，包括指定相關的測試用例。這兩個流程彼此緊密關聯，只有在受控和良好的計划下進行，才能達到項目目標。
在與相關人員商量需求的優先級時，他們自然會提出各種的意見：哪些關鍵，哪些想要，又有哪些是強制或可選的。關於需求的優先級，讓所有參與者統一意見是困難的， 這也是為什么這件事最好在項目早期做。為了更好的掌握需求的優先級及其依賴關系，按層級關系把它們組織在樹狀圖中是最佳途徑。
通過組織確定需求的優先級，可以使團隊快速篩選出缺失、重復或者矛盾的需求
三、盡可能邀請所有相關人員參與評審，並達成共識
一旦需求整理完畢，與所有相關人員開會評審是必須的。並且盡可能確保項目成員都參與進來。這個過程中中即使是在會議的最后一刻需求也可會發生變動，而這恰好是大家取得共識的關鍵時刻。在整個應用生命周期中，我們需要確保系統的開發不只是盲目的在符合一組寬泛的需求，而是應該靈活處理，優先減少成本，盡早交付。這就是為什么要盡早確定需求的優先級，然后再是是集齊需求，等待最終評審。這些需求以及他們的優先級將指明項目未來的方向。在此之后，剩下的就是讓那些具備豐富需求管理經驗的同事來檢驗你的需求規范。
總之，在核實需求時我們要注意下列標准：
1.特有的、整個項目過程完整不變。
2.易於測試、可追溯。
3.在團隊能力范圍之內，便於后期驗證。
如果你覺得哪些需求沒有達到這些標准，修改或干脆刪掉。
四、需求驗證
通常，要時不時的讓提出需求的相關人員來審核文檔，並且要盡力幫助他們理解需求。當這些需求實現時，還要准備好相關的說明文件。根據不同的工作流程，你要提供不同格式的比如活動圖，工作流模型圖以及流程圖來說明。最好是把需求以文件夾形式的來組織，並以樹狀圖顯示，方便用來驗證。這樣你就能構建一個包含少數功能的可用環境，用戶就可以在需求最終評審之前嘗試不同的方法來驗證。另外，這種組織形式還能讓參與者明了，具體的需求是如何代表他們的工作目標，以及它們是如何組成項目的總體目標。同理，清晰的展示所有對象間的關系和問題也同樣重要。
五、評估需求變更的影響
這種類型的評估會讓團隊認識到需求變更帶來的影響，能幫助團隊做出最有效的業務決策。影響力分析在那些重視質量和安全性的項目中非常重要（比如醫療或自動化項目）。這種分析用來檢查需求的變更會導致哪些組件也需要更改。
大體來說，影響力分析是指：
理解需求變更帶來的影響 - 例如， 在產品中新增一組功能會降低性能，對部分用戶來說是不可接受的；
如果需求變更了，要指出哪些文檔，模型，和文件可能需要修改。
明白哪些任務涉及到變更的需求，以及要實現這個變動要花費的成本，兩者同樣重要。
如同你改變已有的需求，系統本身也會變動。開發團隊需要良好的版本管理機制來控制這些變動，包括測試管理在內，還要有個的組織良好的后期執行方案，來降低因成員間誤解帶來的風險。
六、用好需求管理工具
使用PingCode管理需求
借助正確的工具來搜集和文檔化需求是最有效的。如果你的開發團隊使用PingCode，就可以很好的進行需求管理。因為它覆蓋了包含項目、任務、需求、缺陷、迭代規划、測試、目標管理在內的研發管理全流程。
就以需求管理來說，借助於PingCode，你能夠通過建立一個項目便捷的匯集市場人員、銷售人員、及內部其他渠道產生的需求或者缺陷，並且使用史詩/特性/用戶故事對需求進行分級管理，讓產品負責人可以為需求設定優先級以及指定需求的業務價值。而這些，都可以作為迭代規划時的依據。
閱讀更多關於產品研發管理的文章
文章來源Dzmitry Hryb
譯|WT劉亮