前段時間，我出任項目經理承接了一個中型軟件項目，公司再三叮嚀我一定要尊重客戶，充分滿足客戶需求。項目開始比較順利，辛辛苦苦熬了幾個月的通宵，基本保持項目的正常進度，客戶相當滿意。但進入后期以來，客戶頻繁的需求變更卻帶來很多額外工作。
需求變更不但越來越多，更可怕的是為了節省時間，客戶不再向我申請變更，而是直接找程序員商量。程序員疲于應付，往往直接改程序而不做任何記錄，很多相關文檔也忘記修改。很快就出現一個問題，就是需求、設計和代碼無法保持一致，甚至沒有人能說清楚現在系統到底改成什么樣。后來因頻繁出現改好的錯誤又重新出現，客戶投訴表示無法容忍這種低下的項目管理水平。這讓我很無奈，疑惑自己到底錯在哪里。
什么是需求變更?
(1)什么是需求分析?
要知道需求變更是什么，首先要知道什么是需求分析。
需求分析是一個復雜的問題。作為軟件開發人員，一定了解軟件工程學，而這門科學的第一步就是需求分析。打開任何一本軟件工程的書籍，翻看目錄就知道需求分析的地位。軟件需求分析是整個軟件開發最關鍵的一個輸入。和傳統的生產企業相比較，軟件需求具有模糊性、不確定性、變化性和主觀性的特點，它不像生產汽車、電腦等硬件的需求，是有形的、客觀的、可描述的、可檢測的。因此，軟件需求是軟件項目最難把握的問題。
簡單的說：需求分析是指理解客戶需求，就軟件功能與客戶達成一致，估計軟件風險和評估項目成本代價，最終形成開發計劃的一個復雜過程。需求分析主要包括：業務需求、客戶需求和功能需求三個部分。業務需求意為客戶對產品的目標或者要求，客戶需求意為客戶在使用產品過程中需要完成的一系列任務，功能需求則指定了產品系統必須提供的功能。
(2)什么是需求變更?
在軟件開發過程中，開發經理所要面對的將是一系列和多方面的考驗。其中，最讓開發經理頭痛的就是需求變更。根據軟件工程思想定義，需求說明書一般要經過論證，如果在需求說明書經過論證以后，需要在原有需求基礎上追加和補充新的需求，或對原有需求進行修改和削減，均屬于需求變更。而且，客戶變更需求是軟件開發與生俱來的特性，也是一個無法避免的事實。
需求變更好比是萬惡之源，為項目的正常開展帶來不盡的麻煩。需求變更的表現形式是多方面的，如客戶臨時改變想法、項目預算增加或減少、客戶對功能的需求改變等。需求變更問題是每個開發人員最頭痛的問題。因為一旦發生了需求變化，就不得不重新修改設計、重寫代碼、修改測試用例、調整項目計劃等。這時，如果開發團隊缺少明確的需求變更控制過程或采用的變更控制無效，很可能會造成開發進度拖延、成本超支、人員士氣低落，而且越往后的需求變更產生的風險將越大，甚至導致整個項目失敗。
【需求變更無可避免】
對于需求變更，我們總認為能夠完全掌握它，可實際情況是——需求變更往往在所難免。以前出現這種情況時，總覺得很沮喪，覺得自己的工作做得還不細，有些內容要讓用戶簽字確認就好了。可在經過多次需求變更的痛苦后，才恍然大悟：軟件開發的需求變更是無可避免的。
(1)三極世界和需求變更的必然性
需求、客戶、開發人員是一個三極世界。這三極的溝通是很不容易的。客戶向我們滔滔不絕地描述需求，開發者聽得頭暈腦脹，但又不得不根據這些來理解需求。有的時候我們也會派好幾撥人輪番折騰客戶，這樣客戶也暈頭轉向，巴不得趕快需求調研結束。這樣的需求調研像透過布滿小水珠的玻璃看世界一樣，即使能夠看清輪廓，但細節的丟失在所難免。
之所以這樣，是有原因的：第一，是因為客戶自己對需求進行了過濾，有時是因為客戶對需求的理解也不準確，有時是客戶的視角與我們的不同。第二，是開發者對需求的理解偏差。有可能是由于缺乏知識，開發者對需求理解錯了;還可能是開發團隊內部造成的偏差，比如需求調研人員往往同時做好幾個項目，在調研完成后便不在開發團隊中，這樣偏差便在所難免。還有就是內部溝通、人員更替造成的偏差。因此，在這樣一個三極世界，需求變更是必然的。
(2)合同簽訂馬虎，沒有真正明白客戶需求
當我以合同上沒有規定的需求不予開發時，客戶搬出銷售人員的承諾這一招，更讓我幾乎吐血。銷售人員在簽訂合同時缺乏對客戶需求的認真對待，導致需求描述不清，為開發帶來了許多困惑和后患。例如，銷售人員有時為使客戶能夠快速地簽訂合同，往往草率決定和片面同意客戶提出的需求。當客戶提出新的需求時，往往是銷售人員一看“應該”只是一個小小的修改，沒有太大的影響，所以直接答應能變更。
該問題的關鍵是合同簽署得太爛，沒有把需求明確再簽合同，而且也沒有把需求變更的流程寫入合同。如果在簽合同前就把客戶需求弄清楚，后期就根本不需要頻繁地變更需求。簽訂合同時明確定義開發需求的范圍，可以為以后各項開發工作的開展奠定好的基礎。
【需求變更為何沒完沒了?】
在軟件開發中，最常抱怨的是這樣一個問題：客戶為什么總是反反復復?造成需求變更沒完沒了的原因，可以是這樣幾個方面存在問題。
(1)沒有明確的需求變更流程沒有明確的需求變更管理流程，就會使需求變更變得泛濫，在這一點上我嘗盡了苦頭。并不是所有的變更都要修改，也不是所有變更都要立刻修改，明確需求變更管理流程的目的是為了決定什么類型的變更需要修改和什么時候修改。比如單純的界面風格問題，就可以先不修改，或者規劃一下修改的時間待到以后進行優化。另外，對于核心功能的修改沒有嚴格把關流程，有些小需求看起來工作量不大，但是哪些銷售人員或者客戶沒有考慮到的細節問題實際上需要花費開發人員相當長的時間去完成，從而是撿了芝麻掉了西瓜，得不償失，使開發進度失控和資源浪費。
(2)沒有讓客戶知道需求變更的代價對變更的影響沒有進行成本評估是需求變更泛濫的根本原因，這是我從單純的技術人員轉變到統籌兼顧成本管理的轉變點之一，當然為了這一點我也付出了血與淚，為此飽受公司領導和客戶的重重抱怨和責備。變更都是有代價的，應該要評估變更的代價和對項目的影響，要讓客戶了解需求變更的后果。如果客戶不知道需求變更付出的代價，對開發人員的辛苦就會難以體會。在評估代價(包括成本、時間等多方面)過程中，可以請客戶一起做判斷：“我可以修改，但您能接受后果嗎?”
【如何有效控制需求變更?】
需求變更對軟件開發項目成敗有重要影響，既不能一概拒絕客戶的變更要求，也不能一味地遷就客戶，所以實施需求變更之前必須做好控制。需求變更控制的目的不是控制變更的發生，而是對變更進行管理，確保變更有序進行。
(1)明確合同約束，建立需求基線需求變更給軟件開發帶來的影響有目共睹，所以在與客戶簽訂合同時，可以增加一些相關條款，如限定客戶提出需求變更的時間，規定何種情況的變更可以接受、拒絕或部分接受，還可以規定發生需求變更時必須執行變更管理流程。雖然軟件開發合同很難在簽訂之初就能夠精確定義每項需求，單靠合同是幫不上忙的，但也不能忽視合同的約束力。
明確和樹立需求基線是需求變更的依據。在開發過程中，需求確定并經過評審后(客戶參與評審)，建立第一個需求基線。此后每次變更并經過評審后，都要重新確定新的需求基線，做到小需求可以變更，但大方向要力保不頻繁變更。例如，對于項目中的需求，可以實行分級管理，以達到對需求變更的控制和管理。
(2)建立變更審批流程在實踐中，人們往往不愿意為小的需求變更去執行正規的需求管理過程，認為降低開發效率，浪費時間。正是這種觀念才使需求變更變得不可控，最終導致項目的失敗。因此，小的需求變更也要經過正規的需求管理流程，否則會積少成多，積重難返。
明確需求變更審批環節、審批人員、審批事項、審批流程。這么做的目的有兩個：一是將客戶下達變更的流程盡可能地規范化，減少張嘴就來的非必要、非緊急、非合理、非高層領導意圖的無效變更。二是留下書面依據，為今后可能的成本變更和索賠準備好“變更賬”。凡未履行審批程序的“變更”，一律是無效變更不予受理。
(3)分級管理變更，定時批量處理軟件開發項目中，“客戶永遠是對的”和“客戶是上帝”并不完全正確，因為在已經簽定的項目合同中，任何新需求的變更和增加除了影響項目的正常進行以外，還影響到客戶的成本投入收益。因此，用戶不斷提出對項目進度有重大影響的需求對雙贏也并不是好事。
當遇到客戶提出需求，不及時處理可能會使項目不能驗收通過時，也不能一味拒絕不予開發。因此，當客戶堅持變更新需求時，可以建議客戶將新需求按重要和緊迫程度劃分檔次，作為需求變更評估的一項依據。例如，每周或每兩周甚至每月召開一次需求變更專題會議，集中研究處理這些零碎變更事項，主動控制好工作節奏，盡量避免由于處理零碎變更而影響項目進度。針對會議結果可向客戶正式提交一份需求變更計劃，注明變更引起的時間、成本、工期代價和增加工作量等。要求客戶配合需求變更計劃，確定變更時限，控制變更規模，過時變更不候，離譜變更不做，保大局棄小變。
(4)安排專職人員負責變更管理有時開發任務較重，開發人員容易陷入開發工作中而忽略了與客戶的隨時溝通。因此，需要安排一名專職的需求變更聯絡人員，負責與客戶及時交流，跟蹤和匯報需求變更完成進度和情況。同時，可以成立項目變更控制小組，負責裁定接受哪些變更，小組由項目所涉及的多方人員共同組成，應該包括客戶方和開發方的決策人員在內。
(5)確認客戶是否接受變更的代價要讓客戶認識到變更都是有代價的，要和客戶一起判斷需求變更是否依然進行。例如，變更是沒有問題的，但是要明確客戶能否接受由此引起的如進度延遲、費用增加、效率下降等問題。一般來說，如果客戶認為該變更是必須的(不是其上級領導拍腦袋提出的)就會接受這些后果。通過與客戶協商，這樣開發團隊即使沒有回報，也不會招致公司和客戶雙方的埋怨。
如果客戶認為該變更雖然有必要但是可以暫緩，雙方簽署備忘錄后留待以后解決。如果客戶認為該變更可有可無，多數情況下會取消變更。這樣即可防止頻繁變更，也讓客戶認識到不是所有的需求都需要變更。
以上方法和措施的落地還需要通過IT工具來實現，才有可能實施到位，這種事情如果是依靠人來監督，很難成功！所以引進PLM系統+研發管理顧問的指導----該問題就不難解決啦！
......歡迎交流......
浙公網安備 33010802003509號
杭州講師網絡科技有限公司
