需求變更的代價

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

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）妥善儲存變更産生的相關文檔。

應對之道

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

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

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

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

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

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

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

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

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

後記：

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