在項目管理過程中，項目經理經常面對使用者的需求變更，如果不能有效處理這些需求變更，項目計劃會一再調整，軟體傳遞日期一再拖延，項目研發人員的士氣将越來越低落，将直接導緻項目成本增加、品質下降及項目傳遞日期推後。這就決定了項目組必須擁有需求管理政策和有效的落地。
讓我們一起來回顧一下實際研發過程中，通常會面臨到的需求管理挑戰：
1、缺乏需求的集中管理
按照需求工程的說法，在進入開發環節之前，開發團隊和客戶之間需要形成一份完整的需求規格說明書，詳細地說明目标軟體的各種需求，這其中包括功能性需求、非功能性需求和其他各種限制。在典型的瀑布模型中，需求規格說明書是在需求分析階段完成的。然而，由于軟體外部環境的變化，很少有哪個項目在需求分析階段就能将所有可能的需求準确無誤地包含進來，并且在開發階段不需要修改，一句話，需求的變更是不可避免的。需求的變更也需要及時地反應到需求管理中。
1）客戶初始的業務需求：很多客戶可能隻會告訴我們，它想做一個系統或者工具平台，大緻是什麼樣子，應該具備哪些功能，但這種需求往往比較抽象，缺乏細緻的分析。這種需求可能源自于一次交談，或者一封email，形式上并不正式。
2）客戶對項目快速原型的回報意見：對于需求，在實際項目開發中，客戶關注的業務功能，項目經理關注的是抽象設計，而開發人員關注的卻是具體實作。在項目初期，客戶往往也不是很清楚他們要什麼，或者理想中的産品到底最後會是什麼樣的，界面布局，操作流程等等。這一點，在新産品的開發中尤為明顯。
這時候，就需要開發團隊能夠按照現有的了解快速地開發一個原型，作為開發團隊和客戶讨論和分析需求的共同基礎，原型能夠幫助使用者更好地發掘和定義需求。客戶對于原型的論證作為回報意見也可以使開發團隊更加直覺和感性地認識客戶的需求。
3）客戶對每個疊代周期釋出的版本的修改建議
如果該企業采用的是靈活開發，每個疊代周期都要釋出一個可用的版本給客戶，該版本盡可能多地實作了目前疊代周期内的需求以及之前疊代周期内遺留下來的需求。客戶要驗證需求的實作是否符合他們的要求，并提出修改意見和建議。
4）客戶在研發周期中的需求變更
需求來源的特殊性決定了軟體開發過程中需求管理的特殊性，尤其是對于一個同時承擔數個小項目的開發團隊而言，不同的項目需求是由不同的開發人員或qa分别進行管理和跟蹤的，缺乏集中的管理，對于需求的跟蹤也比較原始。往往是手工整理需求郵件和需求清單，然後形成簡單的需求文檔，在需求查詢和狀态維護方面存在明顯不足。
2、需求變更頻繁
軟體開發的顯著特點之一就是靈活性、機動性、對變化的快速響應能力。尤其是靈活開發過程，需求變更更為頻繁。靈活開發的口号是擁抱需求變化，也就是說，開發團隊對于客戶提出的需求變更通常是抱以歡迎的态度，盡管這些變更可能會給項目計劃和項目進度帶來麻煩，但這種觀念上的轉變更能展現開發團隊和客戶之間合作的誠意。
客戶在疊代周期中的變更大緻可以分為五種類型：添加新需求、删除本次疊代周期内的需求、删除之前疊代周期内的需求、更改本次疊代周期内的需求、更改之前疊代周期内的需求。這就是說，開發團隊需要實時高效地管理這些變更，并且将需求變更涉及到的疊代周期内項目計劃和人員安排變更的影響最小化。
3、缺乏有針對性的需求管理流程
軟體開發中，需求和測試用例是緊密聯系的，通常來說，一條需求隻有通過了所有針對該需求的測試之後才能說這條需求的實作真正實作了。而測試的結果是産生bug報告，如果針對某條需求的一個測試用例沒有通過測試，換句話說，也就是産生了一個bug，這就說明該需求根本沒有完成。同時，需求的變更直接影響到與該需求相關的測試用例的更新，繼而影響到現有bug的狀态的更新。然而現實情況卻是，大多數靈活開發團隊都沒有實作需求、測試用例和bug的一體化管理。
我們希望在需求、測試用例和bug之間建立一種動态的聯系，能夠實時地更新三者的狀态，并且實作三者之間狀态的動态關聯，進而減少開發團隊在管理和維護需求、測試用例和bug時的工作量。
5、缺乏量化的項目管理回報
企業在項目管理中，需求的頻繁變更對項目管理者評估需求、制定疊代周期内的項目計劃都是個巨大的挑戰。管理者在需求評估經驗和能力上的不足，以及管理者對團隊成員開發能力認識不足容易造成需求評估出現大的誤差，雖然這種誤差是不可避免的、但是我們希望可以通過曆史評估資料的回報來幫助項目管理者積累經驗，逐漸修正和調整自己的判斷和評價體系，進而盡可能減小由于評估誤差引起的項目風險。而沒有工具的支援，曆史的準确資料則很難擷取。
總結以上問題，顯而易見，需求管理是軟體項目中一項十分重要的工作，據調查顯示在衆多失敗的軟體項目中，由于需求原因導緻的約占到45%，是以有效的需求管理是企業軟體開發項目順利達成目标的重要支撐條件。如何了解項目開發的目的和用途，梳理使用者需求，監控需求變化，進行需求确認，對需求風險進行防範，并利用工具進行有效的實施需求管理工具，方能推進軟體項目良性發展，達到使用者與軟體開發企業的雙赢。
有效的需求管理方法與工具
方法一：量化需求管理
如前所述，企業研發項目通正常模巨大，涉及部門衆多，需求功能描述檔案中包含衆多内容，若僅僅隻用整篇的文檔來指導開發和測試工作，很容易引起任務配置設定的混亂；當發生需求變更時，也很難追溯曆史版本。
techexcel公司推出的devsuite産品研發管理軟體，從實踐中提煉出一個行之有效的解決方法——用規範點（specification，以下簡稱spec）量化需求，正規表達每一個功能單元。隻需打開《需求功能描述書》的word文檔，就可以利用插件，将其中的功能單元逐條地複制出來，在需求管理系統 devspec中直接生成spec。相對于需求，spec是更面向技術人員的語言。
客戶業務需求可以在平台中進行集中管理，并以需求結構化和條目化的形式管理需求，為需求的評估、追蹤與變更管理提供了基礎。同時，通過系統強大的頁面自定義能力，我們可以管理需求的來源、難度、實作時間、實作成本等，這些資訊為需求優先級的評估，提供了量化的名額，幫助項目經理準确的排布需求優先級，讓團隊優先實作最重要、最緊急、客戶價值最高的需求。
此外，需求說明書、分析設計文檔、評審記錄等，均可以以附件形式儲存，且能對文檔的版本進行有效的管理。
方法二：有序管理需求變更
在實際項目中，實作需求變更的成本随着開發進度呈指數級增長。需求變更的流程化管理能保障正常的開發進度，将變更及時反應到開發和測試等部門。
以下描述的是一個典型過程（如圖1）。一項變更請求在需求管理系統中被送出後，與之關聯的各個部門，如市場、項目管理、産品研發、qa、測試等，都會有相關人員接到系統通知而介入。他們将組成評估團隊，根據實施難度、周期、費用、對其他機制的影響等名額，對該變更進行全面考察和評估。
devspec提供了專門的變更管理視圖，在這裡，我們可以管理各個項目中的需求變更任務，不論是需求增加、減少或是改變，我們都會為之建立一條變更記錄，在這條變更記錄中，記錄了變更的來源、原因、具體描述和變更成本、收益估算，這些資訊可以成為變更評估的标準與依據。
每個變更任務均可以和在變更中受影響的需求相關聯，包括增加的、減少的和變更的需求。通過需求變更清單，我們可以清晰的看到項目中目前有多少變更任務，影響了哪些需求，也能夠察看到整個項目周期中總計發生了多少變更，總計影響了多少需求條目。
方法三：标準的需求管理流程
需求管理的整個過程都可以用标準、有效的工作流控制起來，如需求變更流程的設定，通常包括請求、複查、讨論、調整、準許和拒絕等狀态，隻有具備權限的項目成員才能改變狀态。按照預設的流程，各方審批全部通過後，該變更才能被接受。
devsuite提供了靈活的工作流程定制和管理能力，圖形化工作流引擎将工作流圖形轉變為工作流腳本，是以項目管理者可以在圖形化界面中，輕松快速的定制項目組項目管理流程。
如上圖中紅色框内為需求的工作流程，使用者可以根據公司的實際業務流程，定制符合需要的需求流程圖，系統可以同時定義多條項目工作流程，以适應不同規模、不同類型的項目。
方法四：需求有效驅動開發與測試
在理想的研發管理平台中，需求管理與所有規劃、開發、測試管理過程相內建。是以，需求的正規表達spec，以及圍繞spec正在或将要進行的開發任務和測試任務，都能被納入綜合考慮的範疇，便于評估團隊估算該變更造成的“牽一發而動全身”的潛在影響。有時，還要結合商業需求進行考量，為了趕上産品的最佳釋出時機，有些變更将被拒絕。
變更請求被準許後，與之相關聯的開發、測試任務都會在系統中被一一标記出來，以提醒程式和測試部門的相關負責人，引發這些任務的需求已經變更，請他們做出相應的調整處理。在系統中跟蹤這些任務的進展，可以實時掌握該變更的落實情況。變更完成後，也可以核算它對開發周期和費用的實際影響，與評估時的預測相對比，找出差異的原因，為将來更準确地評估提供參考。
devsuite提供了變更辨別功能，通過變更辨別子任務，我們可以選擇受影響的開發、測試任務，建立變更辨別子任務，該子任務将以旗幟形式反映到開發、測試任務中。變更辨別子任務不但能夠辨別變更，還能夠幫助團隊進行變更回報，通過文字記錄和狀态改變，任務負責人員可以将需求變更對于任務的影響及時回饋給需求管理人員。另外，對于需求實際改變的内容，需求負責人員可以建立變更推送子任務，通過郵件系統，可以将變更資訊發送給該需求的幹系人。
方法五：需求指導項目規劃與執行
縱使項目最初都有比較全面的計劃，延期仍然會時常發生，即便是在管理機制比較成熟的大型研發企業中，跳票也不可避免。通常情況下，導緻跳票主要有以下幾點原因：功能設計規劃過多，很多又無法删除，如不增加開發時間，産品幾乎不能完成；缺乏有經驗的管理或開發人員，不能準确估計工作量；任務執行缺乏規範，開發人員随意更改功能設計，影響整體進度；過高的人員流動率，導緻知識的流失，任務不能及時跟進。
針對以上問題，隻要從量化需求入手， 有序管理需求變更，用正規表達、可量化的spec來指導項目規劃、程式設計和測試，就能把風險降到最低。
基于結構化的spec集合，可以将項目分解為多個子項目，将spec直接配置設定到各自對應的子項目中，以此來規劃和估算子項目的工作量。項目管理人員為每個子項目配置設定資源，安排優先順序，确定項目裡程碑。
在項目執行時，可以為每一個spec産生出一系列開發任務。自定義的工作流機制確定每一個任務從送出到最終解決的生命周期都嚴格符合業務流程，保證任何時刻都有唯一的負責人、狀态和截止日期。這樣，不僅能規範産品研發過程，還能降低人員流動帶來的風險。任務的流轉及相關知識文檔，如源代碼、設計資源等，都得到系統完整的記錄，還能與任務關聯，便于追溯。一旦有人離開項目，接替的人員能夠檢視任務和文檔資訊，迅速彌補人員空缺。
devsuite需求管理視圖提供産品版本樹管理，産品經理可以建立新産品和版本，每個需求和功能點可以在多個産品和版本實作。通常一個産品的各個功能可能會分布在不同的項目中實作，項目經理如何在産品釋出的時候知道每次釋出實作了那些功能，各個功能點的負責人是誰，通過devspec視圖提供的産品版本樹功能，項目經理可以輕松的過濾出每個釋出版本實作了那些客戶需求。
支援産品的版本規劃，當收集到的需求經過評審等規定流程決策後，将需求與規劃好的産品版本關聯起來，通過産品版本視圖可以直接追蹤到需求與産品版本的關系，未決定開發的需求可以不設定版本，等決定後再關聯相應産品版本。
以上所述的需求管理經驗和系統工具的支援，希望與大家共同分享與探讨，探索出一條以有效的需求管理推動項目執行、産品研發整個生命周期的最佳途徑！
====================================分割線================================
最新内容請見作者的github頁：http://qaseven.github.io/