需求變更的代價（轉）

讓我們先來看一個需求變更的典型案例：

Steven剛出任項目經理，並承接了一箇中型軟件項目。公司再三叮嚀他一定要尊重客戶，充分滿足客戶需求。項目開始比較順利，但進入到後期，客戶頻繁的需求變更帶來很多額外工作。Steven動員大家加班，保持了項目的正常進度，客戶相當滿意。

但需求變更卻越來越多。爲了節省時間，客戶的業務人員不再向Steven申請變更，而是直接找程序員商量。程序員疲於應付，往往直接改程序而不做任何記錄，很多相關文檔也忘記修改。很快Steven就發現：需求、設計和代碼無法保持一致，甚至沒有人能說清楚現在系統“到底改成什麼樣了”。版本管理也出現了混亂，很多人違反配置管理規定，直接在測試環境中修改和編譯程序。但在進度壓力下，他也只能佯裝不知此事。但因頻繁出現“改好的錯誤又重新出現”的問題，客戶已經明確表示“失去了耐心”。

而這還只是噩夢的開始。一個程序員未經許可擅自修改了核心模塊，造成系統運行異常緩慢，大量應用程序超時退出。雖然最終花費了整整3天的時間解決了這個問題，但客戶卻投訴了，表示“無法容忍這種低下的項目管理水平”。更糟糕的是，因爲擔心繫統中還隱含着其他類似的錯誤，客戶高層對項目的質量也疑慮重重。

隨後發生的事情讓Steven更加爲難：客戶的兩個負責人對界面風格的看法不一致，併爲此發生了激烈爭執。Steven知道如果發表意見可能會得罪其中一方，於是保持了沉默。最終客戶決定調整所有界面， Steven只好立刻動員大家抓緊時間修改。可後來當聽說因修改界面而造成了項目一週的延誤後，客戶方原來發生爭執的兩人這次卻非常一致，同時氣憤地質問Steven：“爲什麼你不早點告訴我們要延期！早知這樣纔不會讓你改呢！”Steven很無耐，疑惑自己到底錯在哪裏了。

對軟件需求和需求變更的理解

軟件需求是整個軟件項目的最關鍵的一個輸入，和傳統的生產企業相比較，軟件的需求具有模糊性、不確定性、變化性和主觀性的特點，它不像生產汽車、電腦等硬件的需求，是有形的、客觀的、可描述的、可檢測的。軟件需求是軟件項目最難把握的問題，同時又是關係項目成敗的關鍵因素，因此對於需求分析和需求變更的處理十分重要。

需求變更會給項目帶來巨大的風險,會導致項目的成本費用增加、開發週期延長、產品質量下降及團隊工作效率下降等不良後果，因而軟件開發項目中應該儘量減少需求變更的出現頻率。然而由於政府對特定軟件的相關要求、用戶部門市場戰略的調整、工業界的發展等因素都可能帶來需求的變更，而這些因素往往不可避免。在軟件開發過程中如果只有一條真理的話，那一定是：需求的變化是永恆的，需求不可能是完備的。因而，對於需求變更應該正確的對待，儘量將其負面影響降低到最低。

需求變更的原因

需求包括業務需求、用戶需求和功能需求。業務需求（Business Requirement ）反映了組織機構或客戶對系統、產品高層次的目標要求，用戶需求（User Requirement ）描述了用戶使用產品必須完成的任務，功能需求（Functional Requirement ）定義了開發人員必須實現的軟件功能。

會導致需求變更的原因會有很多，如老闆臨時改變想法、項目預算增加或減少、客戶對功能的需求改變等。在IT項目中，變更可能來自方案服務商、客戶或產品供應商等，也可能來源於項目組內部。在軟件系統開發過程中，有很多問題都是由於在需求分析階段沒有正確地收集、編寫、協商、修改產品真實需求而產生的，造成這樣的狀況有以下幾方面的基本原因:

（1）對需求的理解分歧

當客戶向需求分析人員提出需求的時候往往是通過自己的想法用自然語言來表達的，這樣的表達結果對於真實的需求來說是一種描述（甚至只是某個角度的描述），遠遠不能保證這樣的描述可以得到百分之百的正確理解，也許在同客戶交流的第一時刻就埋下了理解分歧的種子，打一個比方說客戶說我要的是大象，身子象一堵牆，耳朵象扇子，四條腿象四根柱子，尾巴象繩子，分析人員想，哦，牆、扇子、柱子、繩子這些我都知道，但是真的畫出來的時候客戶當然會跳起來了！這是理解分歧的問題，一般跟分析員的知識、背景，還有客戶表述的標準程度、雙方的交流情況有關。

（2）系統實施時間過長

一個大中型系統的建設可能要延續一段時間，當客戶提出要求之後，他當時並不能看到系統的運行情況，當雙方認爲理解大概沒有分歧的時候（事實上還會有個Deadline ），開發方就開始工作了。當客戶拿到差不多可以試用的產品時他可以實際操作，這時候他就會對系統的界面、操作、功能、性能等有一些切身的體會，有可能提出需求變更要求。

（3）用戶業務需求改變

當前客戶的運營情況不確定，有可能客戶行業的競爭度高，需要隨時作出調整和反應，那麼他們自然會經常提出需求變更的要求；也有可能客戶所在的行業操作不規範，本身存在很多人爲因素，這時候開發方更是需要隨時準備應變。

（4）系統正常升級

有可能是來自開發方自身版本升級或性能改進、設計修正的要求出現需求變更，這時更是無法繞開這個問題的了！

所以說就算分析人員和客戶之間不存在理解分歧，客戶對於實際的系統還是會提出一些個人意見，就算沒有個人意見，他們自己的業務會變化或環境發生變化，這些都是無法避免的，所以不要夢想那麼理想的需求分析，當你開始一個項目的時候就應該意識到，客戶需求變更一定會有的，那麼對於這樣的現狀，我們該怎麼辦呢？客戶是上帝，難道我們就象以前一樣，跟着客戶的需求不停地修改軟件，到最後工期延長，員工疲憊，成本成倍增長，客戶滿意度降低，原來的設計也會改變得支離破碎，系統難以維護？

需求變更的代價

一般來講，需求的變更通常意味着需求的增加，需求的減少相對很少，而且處理需求減少方面的問題也比較容易。當客戶提出新需求的時候，項目開發人員應該分析這些新需求對項目現階段帶來的風險，得出雙方實現變更需求的需要的成本，包括時間、人力、資源等等方面。

變更都是有代價的，應該評估一下變更的代價和對項目的影響，在評估代價並且與客戶討論的過程中，要讓客戶瞭解變更的後果，變更之後面臨最大的問題就是項目延期，讓客戶一起做判斷：“我可以修改，但您能接受後果嗎？”。現在會出現三種可能：客戶接受延期這一後果，開發人員按客戶要求做出相應修改，讓客戶知道爲此需要付出延期的代價；如果客戶認爲代價太大，那開發人員就不必修改了，可以記錄下需求，待到下一版本再做修改；客戶不接受變更的代價，導致項目夭折。 如果客戶不知道你爲變更付出的代價，對你的辛苦便難以體會，以致沒完沒了的提出新的變更。

減少需求變更

正如前文所說，需求變更往往是不可避免的。通常是項目負責人員花費了大量的氣力避免需求變更，可最後需求變更總是會出現。但是這並不意味着項目開發人員不應該做這方面的工作，項目開發人員對於需求變更的正確態度應該和軟件測試的態度一樣，在需求變更發生之前儘量減少需求變更，以將需求變更帶來的風險降低到最低。項目開發人員切忌在項目設計之前試圖消除需求變更，這樣做往往費力不討好。

相比於需求開發人員而言，客戶可能對需求變更認識不足，認爲他們出錢，程序員或軟件開發公司就要爲它服務，因此客戶對需求變更往往更加肆無忌彈，將需求變更視爲兒戲，隨個人喜好隨意變更需求。因此，在需求人員同用戶代表或用戶部門主管人員接觸時，就應該向他們挑明態度，和他們協商好，特別是應該讓他們清楚軟件的定價應該與軟件的功能相關，以及需求隨意變更所帶來的風險的承擔者應該由客戶和項目開發者共同承擔。通過這樣做，讓客戶在需求分析之前就儘量對他們所需要的功能有個整體的瞭解和確定的思路，而不是等到程序員開始編碼了，才提出以前原本在需求分析時就可以提出的需求。

讓客戶明白減少需求變更的重要性後，需求分析人員應該採取合適的方法同客戶交流，幫助他們明確他們的需求。需求分析人員和客戶的關係不應該僅僅是記錄人員和需求提供者，他們的關係應該更多的是戰略合作伙伴關係。雖然需求分析人員和客戶存在着服務商和顧客的關係，但是他們有着一個共同的目標：開發出適合客戶需求的軟件，因此需求分析人員除了記錄客戶提出的需求以外，還應和用戶討論，提出一些建議，使用合適的工具幫助客戶提出需求。在需求分析時，儘量多的召集需求研討會，邀請開發人員和客戶共同協商探討，在研討會上允許任意的提出需求，並將這些需求整理成檔後由客戶代表和需求分析人員共同商議可選的功能，這樣能夠儘量使得需求完備。在需求開發時，開發人員採用原型的方法啓發客戶思考功能需求也不失爲一個好辦法。

雖然需求不可能是完備的、變更不可能沒有的，但是在項目開始設計時使得需求儘可能完備還是應該的，也是值得的，完備需求的過程也就相應的減少了因爲需求不清楚而產生變更的機率。

如何控制需求變更

按照現代項目管理的概念，一個項目的生命週期分爲啓動、實施、收尾三個過程。需求變更的控制不應該只是項目實施過程考慮的事情，而是要分佈在整個項目生命週期的全過程。爲了將項目變更的影響降低到最小，就需要採用綜合變更控制方法。綜合變更控制主要內容有找出影響項目變更的因素、判斷項目變更範圍是否已經發生等。

進行綜合變更控制的主要依據是項目計劃、變更請求提供了項目執行狀況信息的績效報告。爲保證項目變更的規範和有效實施，通常項目實施組織會有以下幾種措施：

（1）項目啓動階段的變更預防

對於任何項目，變更都無可避免，也無從逃避，只能積極應對，這個應對應該是從項目啓動的需求分析階段就開始了。對一個需求分析做得很好的項目來說，基準文件定義的範圍越詳細清晰，用戶跟項目經理扯皮的幌子就越少。如果需求沒做好，基準文件裏的範圍含糊不清，被客戶抓住空子，往往要付出許多無謂的犧牲。如果需求做得好，文檔清晰且又有客戶簽字，那麼後期客戶提出的變更就超出了合同範圍，需要另外收費。這個時候千萬不能手軟，這並非要刻意賺取客戶的錢財，而是不能讓客戶養成經常變更的習慣，否則後患無窮。相對於需求來說，什麼WBS、風險管理、計劃進度都是次要的，只要需求做好了就會一帆風順。

（2）項目實施階段的需求變更

成功項目和失敗項目的區別就在於項目的整個過程是否是可控的。項目經理應該樹立一個理念——“需求變更是必然的、可控的、有益的”。項目實施階段的變更控制需要做的是分析變更請求，評估變更可能帶來的風險和修改基準文件。控制需求漸變需要注意以下幾點：

需求一定要與投入有聯繫，如果需求變更的成本由開發方來承擔，則項目需求的變更就成爲必然了。所以，在項目的開始，無論是開發方還是出資方都要明確這一條：需求變，軟件開發的投入也要變。

需求的變更要經過出資者的認可，這樣纔會對需求的變更有成本的概念，能夠慎重地對待需求的變更。

小的需求變更也要經過正規的需求管理流程，否則會積少成多。在實踐中，人們往往不願意爲小的需求變更去執行正規的需求管理過程，認爲降低了開發效率，浪費了時間。但正是由於這種觀念才使需求逐漸變爲不可控，最終導致項目的失敗。

精確的需求與範圍定義並不會阻止需求的變更。並非對需求定義得越細，就越能避免需求的漸變，這是兩個層面的問題。太細的需求定義對需求漸變沒有任何效果。因爲需求的變化是永恆的，並非需求寫細了，它就不會變化了。

注意溝通的技巧。實際情況是用戶、開發者都認識到了上面的幾點問題，但是由於需求的變更可能來自客戶方，也可能來自開發方，因此，作爲需求管理者，項目經理需要採用各種溝通技巧來使項目的各方各得其所。

在開發上儘量根據情況採用多次迭代的方式進行項目的開發，在每次迭代的同時讓客戶參與和使用軟件，對下一步的開發做出建議爭取在項目前期有效的減少後期可能出現的變更情況。

（3）項目收尾階段的總結

能力的提高往往不是從成功的經驗中來，而是從失敗的教訓中來。許多項目經理不注重經驗教訓總結和積累，即使在項目運作過程中碰得頭破血流，也只是抱怨運氣、環境和團隊配合不好，很少系統地分析總結，或者不知道如何分析總結，以至於同樣的問題反覆出現。

事實上，項目總結工作應作爲現有項目或將來項目持續改進工作的一項重要內容，同時也可以作爲對項目合同、設計方案內容與目標的確認和驗證。項目總結工作包括項目中事先識別的風險和沒有預料到而發生的變更等風險的應對措施的分析和總結，也包括項目中發生的變更和項目中發生問題的分析統計的總結。

需求變更的管理

需求變更是因爲需求發生變化。根據軟件工程思想，需求說明書一般要經過論證，如果在需求說明書經過論證以後，需要在原有需求基礎上追加和補充新的需求或對原有需求進行修改和削減，均屬於需求變更。

需求變更的出現主要是因爲在項目的需求確定階段，用戶往往不能確切地定義自己需要什麼。用戶常常以爲自己清楚，但實際上他們提出的需求只是依據當前的工作所需，而採用的新設備、新技術通常會改變他們的工作方式;或者要開發的系統對用戶來說也是個未知數，他們以前沒有過相關的使用經驗。隨着開發工作的不斷進展，系統開始展現功能的雛形，用戶對系統的瞭解也逐步深入。於是，他們可能會想到各種新的功能和特色，或對以前提出的要求進行改動。他們瞭解得越多，新的要求也就越多，需求變更因此不可避免地一次又一次出現。

這時，如果開發團隊缺少明確的需求變更控制過程或採用的變更控制機制無效，抑或不按變更控制流程來管理需求變更，那麼很可能造成項目進度拖延、成本不足、人力緊缺，甚至導致整個項目失敗。當然，即使按照需求變更控制流程進行管理，由於受進度、成本等因素的制約，軟件質量還是會受到不同程度的影響。但實施嚴格的軟件需求管理會最大限度地控制需求變更給軟件質量造成的負面影響，這也正是我們進行需求變更管理的目的所在。

實施需求變更管理需要遵循以下六大原則

（1）建立需求基線，需求基線是需求變更的依據。在開發過程中，需求確定並經過評審後（用戶參與評審），可以建立第一個需求基線。此後每次變更並經過評審後，都要重新確定新的需求基線。

（2）制訂簡單、有效的變更控制流程，並形成文檔。在建立了需求基線後提出的所有變更都必須遵循這個控制流程進行控制。同時，這個流程具有一定的普遍性，對以後的項目開發和其他項目都有借鑑作用。

（3）成立項目變更控制委員會（CCB）或相關職能的類似組織，負責裁定接受哪些變更。CCB由項目所涉及的多方人員共同組成，應該包括用戶方和開發方的決策人員在內。

（4）需求變更一定要先申請然後再評估，最後經過與變更大小相當級別的評審確認。

（5）需求變更後，受影響的軟件計劃、產品、活動都要進行相應的變更，以保持和更新的需求一致。

（6）妥善保存變更產生的相關文檔。

應對之道

需求變更控制一般要經過變更申請、變更評估、決策、回覆這四大步驟。如果變更被接受，還要增加實施變更和驗證兩個步驟，有時還會有取消變更的步驟。針對變更控制流程，在實際工作中總結出了軟件開發人員在需求變更管理實踐中的幾點對策：

優先排序 分批實現　每個需求的重要性是不同的。由於資源或技術條件的限制，會顯得“僧多粥少”，因此不可能把所有的需求一次完成。怎麼辦？把每個需求按照對效益的貢獻打個分，排出個優先級來，優先級高的需求先實現，低的到一下版式本實現。由於不斷有新的需求進來，有的需求可能永遠沒有機會被子實現，但不緊，還是要記錄下來，並一起參加排序，保證在每個版本發佈時重要的需求先得到滿足。每個需求的實現是需要花時間的，沒人有百分百的把握預估得很清楚，但借鑑過去的經驗可以大概估算出人力成本，然後根據開發人員和開發週期得出可用人力投入作爲上限。從優先級高的需求中挑，直到挑中的人力成本總和剛剛低於可用投入上限，這樣得出的就是需求的錄取榜。今後的軟件開發規劃也會以此爲依據，分期分批地在不同的回合中實現。最合理的不一定是優先級最高的，也就是說不一不定是最先考慮的，“經濟爲本”是指導優先排序的最終原則。

相互協作　很難想像遭到用戶抵制的項目能夠成功。在討論需求時，開發人員與用戶應該儘量採取相互理解、相互協作的態度，對能解決的問題儘量解決。即使用戶提出了在開發人員看來"過分"的要求，也應該仔細分析原因，積極提出可行的替代方案。

充分交流　需求變更管理的過程很大程度上就是用戶與開發人員的交流過程。軟件開發人員必須學會認真聽取用戶的要求、考慮和設想，並加以分析和整理。同時，軟件開發人員應該向用戶說明，進入設計階段以後，再提出需求變更會給整個開發工作帶來什麼樣的衝擊和不良後果。

安排專職人員負責需求變更管理　有時開發任務較重，開發人員容易陷入開發工作中而忽略了與用戶的隨時溝通，因此需要一名專職的需求變更管理人員負責與用戶及時交流。

合同約束　需求變更給軟件開發帶來的影響有目共睹，所以在與用戶簽訂合同時，可以增加一些相關條款，如限定用戶提出需求變更的時間，規定何種情況的變更可以接受、拒絕接受或部分接受，還可以規定發生需求變更時必須執行變更控制流程。

區別對待　隨着開發進展，有些用戶會不斷提出一些在項目組看來確實無法實現或工作量比較大、對項目進度有重大影響的需求。遇到這種情況，開發人員可以向用戶說明，項目的啓動是以最初的基本需求作爲開發前提的，如果大量增加新的需求（雖然用戶認爲是細化需求，但實際上是增加了工作量的新需求），會使項目不能按時完成。如果用戶堅持實施新需求，可以建議用戶將新需求按重要和緊迫程度劃分檔次，作爲需求變更評估的一項依據。同時，還要注意控制新需求提出的頻率。

選用適當的開發模型　採用建立原型的開發模型比較適合需求不明確的開發項目。開發人員先根據用戶對需求的說明建立一個系統原型，再與用戶溝通。一般用戶看到一些實際的東西后，對需求會有更爲詳細的解釋，開發人員可根據用戶的說明進一步完善系統原型。這個過程重複幾次後，系統原型逐漸向最終的用戶需求靠攏，從根本上減少需求變更的出現。目前業界較爲流行的疊代式開發方法對工期緊迫的項目的需求變更控制很有成效。

用戶參與需求評審　作爲需求的提出者，用戶理所當然是最具權威的發言人之一。實際上，在需求評審過程中，用戶往往能提出許多有價值的意見。同時，這也是由用戶對需求進行最後確認的機會，可以有效減少需求變更的發生。

後記：

對於軟件開發項目來說,開發的過程中不可避免的會出現需求變更，發生變更的環節也比較多，因此變更控制顯得格外重要。變更控制對項目成敗有重要影響，項目開發之前要明確定義，開發過程中要嚴格執行。對變更控制的目的並不是控制變更的發生，而是對變更進行管理，以便更好的處理變更，確保變更有序進行，從而減少因爲需求變更而帶來的損失，加快項目的開發速度。