需求變更的管理流程范文
時間：2024-03-05 17:49:06
導語：如何才能寫好一篇需求變更的管理流程，這就需要搜集整理更多的資料和文獻，歡迎閱讀由公務員之家整理的十篇范文，供你借鑒。
篇1
在電力施工過程中，需求變更的問題是不可避免的，它是通過流程把變更納入可管理的范圍內，避免產生這種混亂，但是如果需求變更的發展失控的話，就會使項目陷入一種混亂且不穩定的狀況，從而嚴重破壞了整個項目的管理過程，如何正確進行需求變更的控制，是一個很重要的管理過程。所以，為了能更好地控制電工管理中的需求變更，我們必須做一些措施來使需求變更有計劃的、有目的、更順暢的進行，從而使電工施工過程進行良好的變更控制。
1 電工施工中引起需求變更的主要因素
在電力施工過程中，引起需求變更的因素有很多，例如增減工程量的清單的內容和工作量，包括施工進度計劃的變動，施工程序的改動，質量標注的調整，技術要求的修改和補充，這些都是在電力施工過程中引起需求變更的因素，可以分為：
1、從需求變更的性質來看，引起需求變更的因素分為主觀因素和客觀因素。
①主觀因素。例如電力設計工作的不細致，從而使工程實施過程中發現了很多在設計文件中沒有考慮到或估算不準確的工程量，致使必須改變施工項目或增減工程量。
②客觀因素。這就是指在電力施工中因為一些自然災害或不可預見的事故、社會因素引起的停工和工期拖延等，這樣的工程變更是不可避免的，也是無法預料到的。
2、從引發需求變更的對象來看，引起需求變更的主要因素
①某些施工單位主動提出工程變更。某些施工單位會向設計單位提出對圖紙、設計說明不明確的問題的詢問，或是提出技術修改圖，對施工方法、施工議案提出修改，或是要求修改圖紙等問題，這些都是施工單位主動提出的需求變更。
②由監理單位提出的工程變更。在電力施工過程中監理工程師要經常在施工現場巡視，憑借著他們自身的豐富實踐經驗，他們往往會發現工程中存在著很多問題，并針對這些問題提出工程變更的建議。
③設計單位提出需求變更。在施工過程中，設計單位或者是其駐工代表對原設計中存在的一些錯、漏、缺、碰等問題，提出一些設計的修改和完善。
④由該工程的業主提出的工程變更。為了更好地完善使用功能，從而保證工程的質量、加快工程進度等原因，在施工過程中，業主時常提出一些工程變更的要求。
在電力施工管理中，由于需求變更會引發工程量現場簽證、設計、進度的變化、合同變化等問題，我們需要對需求變更進行嚴格控制，從而將項目變更的影響降低到最小。
2 對需求變更的控制策略
對于在電力施工過程中，對需求變更的控制，如果僅僅按需求加強監督執行是不夠的，因為這樣的做法會造成項目各方對變更控制的乏力和被動，從而引發工程質量、工程成本等一系列問題的產生，甚至可能使在發展中發生變更失控的現象，這是要絕對避免的。要想在電力施工管理中，使需求變更得到控制，就要確定一個選擇、分析和決策的流程，使所有的需求變更都要遵循和支持改流程，從而通過這個流程對需求變更進行控制。但是在遵循這個流程中還需要注意幾方面的問題：
1、要有明確的授權。在電力施工管理之前，要事先明確工程各方有權提出變更申請的人員和有權受理變更的人員，決不允許未授權的人員進行私下協商，只有這樣做才可以對需求變更有整體的控制。
2、對需求變更進行必要的審核。對電力施工管理中的需求變更不是所有的變更都要執行和立刻執行，審核的目的是決定是否需要變更和何時變更。
3、評估變更的代價和影響。在電力管理中的需求變更都是有代價和影響的，所以在確定變更之前，必須事先評估變更所帶來的代價和影響，使工程雙方了解了變更的后果之后，再一起做出判斷和認可。
4、要嚴格執行需求變更的管理流程。小的變更也會引起變更最終的不可控制，所以小的變更也要進行正規的需求管理流程，并且施工單位要嚴格避免在變更確認之前，要按變更設想進行施工，否則可能會造成需求變更的整體失控。
3 需求變更的控制流程
在電力施工管理中，需求變更控制的主要手段是要明確定義流程并且可以嚴格的執行，主要分為提出、評估和實施的三個步驟。首先，要由授權的人員進行提出需求變更，無論是哪一方提出的需求變更，都要履行工程變更的手續，并以書面形式交給總監。其次，要由總監召集專業的建立工程師來進行審查，認為可行后，設計單位根據業主要求的設計變更進行設計，變更要求必須以書面形式給出，然后設計單位簽署意見和設計出圖。設計單位完成施工圖的設計后，業主需要把圖紙給專業的職能部門和審圖機構審核，審核通過交還業主，再由業主組織設計、施工、監理各方一起對圖紙進行會審，盡可能地把存在的問題提出來，進行研究和探討，并由設計單位做出解答，形成文字資料后作為日后施工的依據。最后要由總監給出確認后的工程變更通知后，才可以交由施工單位進行執行，按照施工圖進行施工。
需求變更實施之前，是要經過工程各方的審核、評估和確認的，在進行電力實施過程中要跟蹤與驗證，確保變更的正確執行，在變更實施的整個過程中，在沒有拿到工程變更通知前任何一個步驟出現異議，整個流程都要重頭開始，并且施工單位也不會進行施工，這樣是為了確保整個需求變更始終是可以控制和管理的。
4 應注意的問題
目前，很多企業都在遵循質量與健康、安全和環境管理體系的互相補充、相輔相成，在電力施工過程中，他們為了在需求變更中遵循質量、安全和環境管理的一體化，為了更好地實施“ISO9000質量管理體系”和“HES-MS”的管理，他們將“ISO9000-QMS”、“HSE-MS”、“ISO14000-EMS”整合成一個系統，但是在具體操作中會遇到很多問題：
1、對“ISO9000質量管理體系”和“HES-MS”的管理范圍必須明確劃分，對于它倆的共用文件和資料應按所屬管理的范圍劃分到所屬的系統中，對影響二者的的文件應確定與“HES-MS”的接口，制定出明確的管理文件。
2、機構要統一，發揮資源優勢。很多企業把質量、安全、環保等職能部門都分開屬于不同部門管理，這樣日程工作中協調減少了，增加了管理費用，造成了資源的浪費，因此各個部門機構要配備管理人員，從實際出發，健全管理機構。
3、體系要統一，工作重點要有所側重。針對企業的具體情況，不同性質的企業需要遵循的管理體系是不同的，在電力施工管理過程中，是必須要遵循安全、質量、環境體系的一體化的，從而確保施工過程都有序進行，保障勞動者的安全和健康，實現經濟效益、社會效益和環境效益的統一。
5 結論
在電力施工管理過程中的需求變更的發展如果得不到很好的控制，項目就可能會陷入不能正常進行的狀態，變更的控制對項目正常有序的施工有著重要的影響，所以，如何正確的進行需求變更的控制，是一個重要的管理過程。定義需求變更是保證變更正常有序的一個有效的措施，并且需求變更流程使得變更施工能夠有計劃、有目的地進行，也只有這樣才能對整個施工過程進行良好的變更控制。
參考文獻
[1]范偉健.淺議電力施工管理中的需求變更管理[J].現代企業文化，2010（18）
[2]羅韋軍.淺析電力施工管理中的需求變更控制[J].中國電力教育，2006（5）
篇2
從理論上講，需求包括業務需求、用戶需求和功能需求。業務需求（Business Requirement ）反映了組織機構或客戶對系統、產品高層次的目標要求，用戶需求（User Requirement ）描述了用戶使用產品必須完成的任務，功能需求（Functional Requirement ）定義了開發人員必須實現的軟件功能。這些需求在項目執行過程中都可能發生改變，即發生需求變更。
需求變更的表現形式也是多方面的，如老板臨時改變想法、項目預算增加或減少、客戶對功能的需求改變等。在IT項目中，變更可能來自方案服務商、客戶或產品供應商等，也可能來源于項目組內部，比如對項目人員的臨時離職會發生突然的需求等。
原因
1、需求信息錯位
在需求分析員確定客戶需求之前，毫無疑問要和客戶做好深度溝通。但是由于溝通渠道的限制，以及雙方能力、教育、習慣背景的限制，往往會出現信息溝通偏差，就是我們說的需求信息錯位。
當客戶向需求分析人員提出需求的時候往往是通過自己的想法用一般語言來表達的，而且是基于客戶對自己需求的理解角度上表達的，這就引起表達的結果對于真實的需求來說是一種僅僅從某個角度的一般描述，遠遠不能保證這樣的描述可以得到百分之百的正確理解。以前有個盲人摸象的故事，這個例子可以解釋一下為什么存在信息的偏差:顧客想要畫一頭大象，可是卻不清楚大象的身子、耳朵、四條腿以及尾巴是什么具體樣子，只能描述出這幾個部分大致像什么。于是顧客告訴分析員，“我要的是大象，身子象一堵墻，耳朵象扇子，四條腿象四根柱子，尾巴象繩子”。分析員聽到這些，就按照自己對墻、扇子、柱子、繩子的理解畫出了“大象”。
結果可想而知。然而這種現象在軟件項目需求變更中并不少見的。
這里面還有一個細化工作的問題。細化工作是一般由需求分析人員完成，一般是根據客戶提出的描述性的、總結性的文檔去細化客戶需求，將這種需求細化到一定程度后，就可以提取其中的一個個細小的功能，并給出描述。
但是不能光靠分析員做細化工作，還應該把這些細化過的功能描述與客戶繼續深入地溝通，否則以后將會發生因為細化而引起的不能適應范圍的問題，比如原來是手工填入的數據，要改成根據信息系統計算出來，而原來的一個屬性的描述要變成描述一個實體等。
2、建設期的溝通局限性
現實中，一個大中型系統的建設可能要持續較長的一段時間。在整個建設內，當客戶提出要求時，因為不能看到系統的運行情況，客戶和開發商雙方就會認為需求溝通方面不存在什么分歧，然而事實上還常常會有需求最終期限的問題，此時開發商就已經開始工作了。
最后當客戶從開發商那里拿到差不多可以試用的產品時候，因為現在可以實際操作，他就會對現實的系統提出很多問題，就是我們說的需求變更，比如系統的界面、操作、功能、性能等方面。
3、客戶所在環境的改變
當前客戶的運營情況不確定，有可能客戶行業的競爭度高，需要隨時做出調整和反應，那么他們自然會經常提出需求變更的要求;也有可能客戶所在的行業操作不規范，本身存在很多人為因素，這時候開發變更是需要隨時準備應變。
一般說來客戶會要求改變界面，改變操作方式，甚至改變業務，客戶甚至會說:“當時我是那樣要求的，不過現在我們的業務調整了。”這一切都是由行業大環境成的，所以對于這方面的需求變更必須要有一定的預測措施。
4、開發商的系統升級
為適應市場需求，或是由于競爭等因素，開發商自身會有可能存在進行開發系統版本的升級或性能改進、設計修正的要求，因此會出現需求變更。這時誰也無法繞開這個問題。
從上面的分析可以看出，就算分析人員和客戶之間不存在理解分歧，客戶對于實際的系統還是會提出一些個人意見，就算沒有個人意見，他們自己的業務會變化或環境發生變化，這些都是無法避免的，所以項目團隊，或者說是開發商不要夢想會存在多么理想的需求分析，應該從一開始就要有客戶需求變更一定會存在的準備。
代價
任何項目只要存在某個方面變更，那么就要付出對應的代價。需求的變更通常意味著需求的增加，同時也意味著相應的代價。當客戶提出新需求的時候，項目開發人員應該分析這些新需求對項目現階段帶來的風險，得出雙方實現變更需求所需要的成本，包括時間、人力、資源等方面。
同時，在評估代價、與客戶討論的過程中，要讓客戶了解變更的后果，變更之后面臨最大的問題就是項目延期，讓客戶一起做是否繼續修改還是要接受修改后果的決策。這樣就會出現三種可能:
1、客戶接受延期的后果，開發人員按客戶要求做出修改，讓客戶知道為此需要付出延期的代價;
2、客戶認為代價太大，那么開發人員就不必修改了，可以記錄下需求，待到下一版本再做修改;
3、客戶不接受變更的代價，導致項目夭折。
所以變更引起的后果一定要和客戶溝通，確保客戶了解后果。如果客戶不知道項目開發人員為變更付出的代價，對他們的辛苦便難以體會，以致沒完沒了的提出新的變更。
然而對于這樣的現狀，我們該怎么辦呢？
積極應對
1、完善軟件項目需求變更的管理
需求變更管理就是要把項目的需求變更對項目的負面影響降到最低，即不為消除，只為減少。需求變更的出現主要是因為在項目的需求確定階段，用戶往往不能確切地定義自己需要什么。
這時，如果開發團隊缺少明確的需求變更控制過程或采用的變更控制機制無效，或不按變更控制流程來管理需求變更，那么很可能造成項目進度拖延、成本不足、人力緊缺，甚至導致整個項目失敗。
當然，即使按照需求變更控制流程進行管理，由于受進度、成本等因素的制約，軟件質量還是會受到不同程度的影響。但實施嚴格的軟件需求管理會最大限度地控制需求變更給軟件質量造成的負面影響。
2、項目啟動階段的變更預防
應對變更應該是從項目啟動的需求分析階段就開始了。 首先就是要和客戶有一個深度溝通的過程，然后再做需求細分，做需求分析，同時在做這些的時候和客戶實時溝通。
對一個需求分析做得很好的項目來說，基準文件定義的范圍越詳細清晰，雙方的分界線也就越清晰，所以用戶和項目經理扯皮的幌子就越少了。假如需求沒做好，基準文件里的范圍含糊不清，被客戶抓住空子，往往要付出許多無謂的犧牲。
如果需求做得好，文檔清晰且又有客戶簽字，那么后期客戶提出的變更就超出了合同范圍，需要另外收費，這樣就可以彌補一下項目開發團隊的損失。所以只要前面的需求分析做好了后面就會一帆風順了。
3、項目實施階段的需求變更
項目的實施過程中，需求變更是必然的，但是同時也是可控的、有益的。項目實施階段的變更控制需要做的是分析變更請求以及評估變更可能帶來的風險和修改基準文件。主要從以下幾點考慮:
1）需求要與投入有聯系，如果需求變更的成本由開發方來承擔，則項目需求的變更就成為必然了。所以，無論是開發方還是出資方在項目開始前都要明確一條:需求變，軟件開發的投人也要變。
2）需求的變更要經過出資者的認可，這樣才會對需求的變更有成本的概念，能夠慎重地對待需求的變更。
3）小的需求變更也要經過正規的需求管理流程，否則會積少成多。冰凍三尺非一日之寒。在實踐中，人們往往不愿意為小的需求變更去執行正規的需求管理過程，認為降低了開發效率，浪費了時間，這樣就使需求逐漸變為不可控，甚至導致項目的失敗。
4、項目收尾階段的總結
能力的提高往往不是從成功的經驗中來，而是從失敗的教訓中來。項目開發團隊要提高對項目總結的重視，以從以前的項目中吸取教訓。
鏈 接
實施需求變更管理的的原則：
建立需求基線；
制定簡單、有效的變更控制流程，并形成文檔；
成立項目變更控制委員會或相關職能的類似組織，負責裁定接受哪些變更；
需求變更一定要先申請然后再評估，最后經過與變更大小相當級別的評審確認；
篇3
一番景象。
自上而下
需求變更是軟件開發人員面臨的最大難題，很少有一個項目能從頭至尾保持同樣的需求。因此，可跟蹤性是所有軟件開發流程的基礎部分，它可以及時發現流程中的問題，并及時修復。統計表明，如果在需求收集階段修復一個缺陷需花費1美元，那么在設計階段修復該缺陷就需花費兩美元。依此類推，直至產品投入使用后才發現該缺陷，修復所需的費用將增至69美元。
通常情況下，跟蹤通過自上而下的方法得以實現，即從需求定義開始，經過執行、構建、組裝直到交付工作。自上而下的跟蹤、報告有助于項目經理和測試人員在開發流程中協調分配、規劃開發和監控狀態。自上而下方法的核心是，確保正確管理和跟蹤需求變更，保證軟件代碼的變更與需求變更同步。
形成閉環
但是，對于大多數質量、審計和測試驗證程序而言，自上而下這種跟蹤形式仍有不足，因為它不能分析實際生產的產品，也就無法確保按計劃交付預期的需求、修復或請求，至少在開銷極大的測試階段之前無法完成上述任務。在此背景下，閉環跟蹤的方法應運而生。所謂閉環跟蹤就是將自上而下和自下而上兩種方法結合在一起。自下而上的方法是通過有效的需求驅動開發流程來控制變更的執行，跟蹤每個開發任務。此方法使用先進的構建分析和報告功能來實現，使得項目主管和測試人員可以在構建或測試階段有效實施錯誤修復。
閉環跟蹤的優勢在于可以確保最后交付的代碼符合客戶的需求；開發人員可對流程中的各種變更進行全面評估，從而提高項目管理的可見性，增強項目管理的可預測性；有助于提高開發產品質量，提高客戶滿意度；推動符合能力成熟度模型集成(CMMI)標準的過程改進，有助于企業降低研發投入成本，加快投入產出進程。
篇4
通過對每一次收養過程進行嚴格的流程控制，動物保護協會最大程度上保護了動物的權利和人類的安全。其實流程存在于人類工作和生活的每一個地方，尤其是多人協作的情況，為了保證行動的最佳效果，減少失誤，最佳的流程往往會被固定下來。不要小看流程固化的重要性，即使任何一個簡單的活動，在不斷的重復和大負載情況下，沒有固定的執行流程，出錯的機會還是很大的。
用流程應對變更
復雜的軟件開發通常需要大量的人員參與，這其中流程的作用至為重要，尤其是對于開發過程中的各種變更，例如需求的變更、軟件版本的變更等，更需要一套嚴密的流程體系來管控，才能最終保證變更被成功控制，而不是演變成為災難。
軟件開發不同于傳統意義的工程技術(如建筑、機械等)，市場變化以及技術上的高速更新都注定了軟件變更是非常頻繁并且是不可避免的，可以說變更是軟件開發的基石。一方面在軟件開發環境下的內部活動以新特性、新功能增強以及缺陷修復等方式不停地制造著變更，另一方面外部因素，例如新操作環境，新工具的集成，工程技術和市場條件的改善等以另一種力量驅動著變更，而管理變更的能力就成為項目成敗的關鍵。
作為國第一家在紐交所上市的軟件企業，東南融通在不斷發展壯大過程中就遇到了這種困擾。東南融通在全國設有3個研發中心、5個技術交付中心和70個服務機構，為了保證異地開發、交付團隊的協同工作，提高軟件質量，2006年，東南融通決定引入成熟的軟件配置、變更工具。
首先在處理需求變更上，東南融通副總裁葉壽生告訴記者，在之前在沒有成熟的執行流程情況下，客戶A提出了需求，開發人員趕快在軟件中進行修改，很快B又提出了一個不同的需求，而這兩個需求可能是沖突的，開發人員就無所適從，同時混亂的修改過程使得最終的軟件質量也無法確保。
而在引入了IBM Rational的配置及變更管理套件ClearCase和ClearQuest后，需求變化得到了很好的控制。需求變更提出后，被提交到變更委員會進行評估，以確定這個變更是否可以實現，需要多長時間、多少投入，同時經過分析后的需求也更加清晰，更易于開發者實現，
另外在版本管理上，采用了ClearCase和ClearQuest后，開發團隊，尤其是異地協作的開發團隊使用的版本得到了統一。葉壽生介紹，在每一個項目實施完成后都會形成一個不同的軟件版本，而這些版本對應哪個客戶，之前都要靠人的腦子來記憶，結果很在維護的時候就容易造成混亂，不知道該在哪個版本上進行更新和重新部署。
東南融通測試中心經理翁旭驥詳細地介紹了身處廈門和上海的開發團隊和身處廈門的測試團隊是如何通過ClearCase和ClearQuest進行異地協同開發的。
首先，廈門的測試人員測試并提交了多個缺陷，系統會在指定的時間自動雙向同步廈門和上海的ClearQuest數據庫和ClearCase的VOB(Versioned。bJect Base)庫。
當ClearQuest數據庫接收到數據后，系統自動發送郵件給上海該項目的缺陷分配人，缺陷分配人收到郵件通知后，會登錄ClearQuest并對待分配缺陷進行分配。當缺陷分配完后，修改缺陷的開發者就會收到缺陷處理的郵件通知。
當開發人員處理完分配給他的缺陷后，便會在ClearQuest中執行Resolve操作，于是缺陷自動變成“已解決”狀態，等待測試人員驗證。
當執行同步的時間到達后，系統自動將ClearQuest數據庫以及ClearCase的VOB庫進行雙向同步。在同步完成后，廈門的測試人員會收到驗證缺陷的郵件通知。測試后如果缺陷仍然存在，上海的開發人員就可以看到這條被駁回的缺陷，如果修改后該版本的程序驗證通過，廈門的管理員就會在集成流上打一條基線，這條基線標識的版本即測試通過的版本。
ClearCase帶來的對軟件開發流程的嚴格管控，工作流程得到了固化和自動執行，免去了人工控制流程中可能出現的遺漏或拖延。同時，ClearQuest會對開發過程中的所有變更進行詳細的記錄，并要求修改者注明修改理由，并能夠追溯到開發中修改的任意一個版本，讓每一次變更都有跡可循。更值得一提的是，ClearCase還同時適用于Linux、Unix和Windows平臺，最大程度地消除了平臺之間的鴻溝，確保了團隊合作的親密無間。
在導人了Rational UCM以后，東南融通擁有了更嚴格而順暢的開發流程，不但能夠有效掌控開發周期和質量，也能有效降低維護成本，數據統計方面，更節省了50％以上的人力投入。
不僅是工具，更是平臺
翁旭驥介紹，起初，測試部門采用了好幾套開源的工具，但是這些工具彼此之間是割裂的，版本控制和缺陷跟蹤彼此無法溝通，這給項目管理造成了很多的麻煩。而之所以看重IBM Rational的配置及變更管理套件，翁旭驥認為他們主要看中了兩個方面，首先是其中蘊含的優秀的管理思想和最佳實踐，其次是平臺化的工具和強大的二次開發能力。
ClearCase和ClearQuest首先是Rational的一部分，它滲透進了Rational RUP(統一軟件開發過程)的思想，變更被置于整個軟件工程的視野下來考慮。另外針對變更管理，IBM提出了UCM(統一變更管理)的解決方案，具體產品就是Rational ClearCase和ClearQuest。
UCM是第三代的配置管理解決方案，在UCM中有兩個重要概念：活動管理和工件管理，它們提供對所有類型的變更請求(例如產品缺陷、增強請求、文檔變動等)的捕獲和跟蹤，還有對貫穿項目生命周期的所有工件的管理框架。
UCM通過抽象層次的提升簡化了軟件開發，從而使得軟件開發團隊從更高的層次，根據活動(activity)來管理變更。通過Rational UCM，一個開發活動可以自動地同其變更集(封裝了所有用于實現該活動的項目工件)相關聯，這樣避免了管理人員手動跟蹤所有文件變更。
篇5
[關鍵詞]項目管理軟件需求開發進度成本質量管理模型
一、引言
軟件需求開發是軟件工程的一個重要環節，在軟件生命周期中的需求、設計、編碼、測試和維護等各個階段中，需求開發處于軟件工程的開始部分，它提供構建軟件項目的根基，決定軟件開發成果滿足客戶需求的匹配程度。軟件需求開發環節的失誤會隨著開發進度的擴大而蔓延，資料表明，軟件項目中由于需求開發管理混亂而造成的返工開銷幾乎占了總開發的50％。本文應用項目管理理論分析軟件需求開發階段的系統構成，并設計管理模型來提高軟件需求開發的管理效率。
二、軟件需求開發管理過程
由于計算機技術的迅速發展，使得軟件需求具有模糊性、不確定性、變化性、主觀性等特點，并帶來軟件需求開發管理的復雜性。軟件需求開發是一定的組織利用有限的資源在規定的時間內完成，可以作為項目來進行管理，其管理過程由需求獲取、需求分析、編寫軟件需求規格和需求驗證四個階段構成。
1.需求獲取
需求獲取是在問題和最終解決方案之間架設橋梁，其主要任務是和用戶方的領導層、業務層人員進行溝通，獲取用戶的具體需求，并了解用戶的組織架構、業務流程、硬件環境、軟件環境、現有的運行系統等具體情況，同用戶建立起良好的溝通渠道和方式。軟件需求獲取的方法有：與用戶交談，向用戶提問題；參觀用戶的工作流程，觀察用戶的操作；用戶工作的情景分析；現有系統的問題報告和改進要求，事件和響應；市場調查和向用戶群體發調查問卷；與同行、專家交談，聽取他們的意見；分析已經存在的同類軟件產品，提取需求；從現有產品或競爭產品的文檔中提取需求；從行業標準、規則中提取需求；從Internet上搜查相關資料等。
2.需求分析
需求分析主要通過建立業務模型的方式來描述用戶的功能需求，為客戶、用戶、開發方等不同參與者提供一個交流的渠道。業務模型可以映射出軟件產品的核心需求，即功能需求。功能需求應描述軟件提供的功能和服務、對輸入的響應，并描述特定條件下的系統構成等。軟件產品本身可能還存在與業務無直接關系的非功能需求，具體與系統的總體特性有關，如可靠性、響應時間、存儲空間等。非功能需求定義系統提供服務或功能的約束，包括時間約束、空間約束、開發過程約束及應遵循的標準等。通常這兩類需求構成軟件需求的總集。
3.編制軟件需求規格
軟件需求規格的編制是為了使用戶和軟件開發者雙方對該軟件的初始規定有一個共同的理解，使之成為整個開發工作的基礎，需求分析完成的標志就是提交一份完整的軟件需求規格說明書。軟件需求規格說明書以一種開發人員可用的技術形式闡述軟件必須提供的功能和具備的性能，以及必須考慮的限制條件。軟件項目客戶通過軟件需求規格了解軟件項目能夠提供的軟件產品，檢查軟件需求是否滿足需要；項目管理人員根據軟件需求規格制定項目的開發計劃和管理過程；軟件開發人員通過軟件需求規格理解要開發的產品及具體要開發的內容；軟件測試人員通過軟件需求規格驗證軟件。
4.需求評審
編寫的軟件需求規格說明書還應當進行需求評審，確保需求確定的科學性。可采用下列指標進行評審：(1)正確性:每條需求都正確代表構建軟件系統所要完成的事情。(2)無歧義:每條需求只有一種解釋。(3)完備性:需求不能發生遺漏，應全面考慮相關問題。(4)一致性:用戶需求必須和業務需求一致，功能需求必須和用戶需求一致。(5)重要性和穩定性分級:現有資源不足以實現所有需求時，可以根據級別的高低決定實現的先后，舍棄一些級別低的需求以保證項目的按期交付。(6)可驗證性:需求分析是可測試的，只有系統的所有需求都是可以被測試的，才能夠保證軟件始終圍繞著用戶的需要，保證軟件系統是成功的。(7)可修改性:每一條需求都易于完整一致的進行變更，且不改變需求集的結構和風格。(8)可跟蹤性:每條需求都是可溯源的，且存在一種機制使得在以后的工作中引用需求是可行的。(9)可理解性:用戶和開發人員都完全理解需求集的整體行為、所提供的功能及其中的每條需求的含義。
三、軟件需求開發管理模型
1.軟件需求開發管理模型構建原則
軟件需求開發是一項復雜的系統工程，管理模型的構建應遵循下列原則:(1)程序性原則：軟件需求開發管理應遵循固定的業務流程，可將其劃分為需求獲取、需求分析、編寫軟件需求規格和需求驗證四個階段，前一階段的工作完成后才能進入下一階段。(2)系統性原則：軟件需求開發要在限定的時間、成本條件約束下達到一定的質量，實現軟件系統的最優，要求管理遵循系統管理原則，實現目標最優。(3)簡化性原則：化繁為簡，將模糊的、潛在的復雜問題明確化，以圖表的形式表示出，并以簡化的解決方案解決問題，便于項目管理。(4)平衡性原則：管理軟件需求開發的具體事務要有一定的側重。對于需求開發過程事項，應根據影響大小分清主次，關鍵的事項或者事項里的某個多發問題點，著重管理，達到在管理上的主次平衡。(5)高效性原則:模型的設計必須以促進需求開發目標的實現為前提，提供給相關人員一個展示需求開發管理和有效解決方案的平臺。（6）時時控制性原則:及時控制需求開發過程中影響進度、成本、質量等問題，及時發現解決沖突事件，做到事前、事中、事后控制，保證項目按時保質保量完成。(7)動態性原則:開發中應關注信息技術的發展，將先進的技術應用到軟件需求開發中，并學習借鑒相關軟件需求開發的成果。
2．軟件需求開發管理模型
基于以上分析，本文構建了軟件需求開發管理模型，見下圖：
該模型遵循了軟件需求開發的管理流程。啟動階段，軟件開發進行了可行性研究，軟件項目已立項，項目正式啟動。軟件需求開發管理階段是模型的主要部分，按照項目流程，依次劃分為需求獲取、需求分析、編寫軟件需求規格和需求驗證四個階段。總結階段，對軟件需求開發管理進行總結，并進入到軟件程序設計階段。模型的核心部分是應用項目管理的進度管理、成本管理、質量管理，對軟件需求開發進行動態管理。進度管理就是制定出經濟合理的進度計劃，然后在計劃執行過程中，檢查實際進度與計劃進度之間的差異，并及時找出出現差異的原因，采取有效的補救措施，以確保項目按時按質完成。進度管理應加強溝通，掌握可能延誤進度的環節，并嚴格控制進度變更。成本管理就是對項目所需的成本情況進行詳細地分析和估算，編制資源需求計劃，并編制項目所需的成本估算和預算，在執行過程中，采取相應的措施對項目成本進行控制。成本管理應嚴格控制加班、浪費等額外支出。質量管理是為了保證項目的可交付成果能夠滿足客戶的需求，圍繞項目質量而進行的計劃、協調和控制等活動，其具體內容涉及質量規劃、實施質量保證和質量控制。通過進度管理、成本管理和質量管理，使軟件需求開發成為進度快、成本低和質量合格的有機統一體。
該模型規范了軟件需求開發的業務流程，并在整個軟件需求開發的不同環節之間建立聯系，明確需求開發過程與自身各任務項之間以及項目其余環節所存在的各種聯系。模型各環節間的相關性、可追溯性保證了軟件項目需求開發過程，可以遵循統一的管理模式。該模型具備可配置性。每個軟件項目，都具有個性化管理需求，在進度管理、成本管理、質量管理等方面有不同的要求，可以針對具體的開發團隊，項目要求，管理側重點，擴增相應的管理模塊，將此模型推廣到任何一個軟件需求開發項目。
3.模型應用
由于軟件需求開發具有復雜性，其主要表現為需求描述問題，明確表達需求較難確定，并且難以統一；需求完備問題，需求沒有遺漏，難以準確劃定系統范圍；需求的變更問題，需求變化是永恒，需求不可能是完備。模型應用需做好以下工作：（1）文檔化管理。需求必須有文檔來記錄，該文檔必須是正確的，是經過驗證的，是在受控的狀態下變更的。開發或管理人員常常會在含糊的情況下把認為是相對簡單的需求忽視而省略文檔記錄，其實未必簡單，只有想清楚、寫清楚、說清楚才說明已經真正把需求整理清楚了，同時方便日后維護工作的展開。需求含糊的情況下要進行會議形式處理，并邀請相關人員參加進行需求澄清及確定，需求在進行多方確定后進行歸檔。同時軟件需求的復用率也是相當高的，可以避免升級時重新將需求再次獲取，只需要在原來的基礎上作為文擋需求復用升級處理。（2）審核評估需求變更，減少變更的影響。在管理軟件開發過程中，需求漸變是必然的，無論需求變化的程度如何，只要需求變更就必須進行評估。在需求變更之前必須由項目管理人員審核，再傳給開發人員進行評估等工作。管理人員必需依據對整套系統的了解程度分析需求變更過程中可能受影響的系統及受關聯的功能模塊，并制定積極應對措施。(3)整體管理。應識別、確定、結合、統一與協調軟件需求開發管理過程中所需要進行的各種過程和活動，保證進度、成本、質量等各要素的相互協調。
四、結語
軟件需求開發在軟件項目管理中具有重要地位。本文應用項目管理理論，設計了軟件需求開發管理模型。該模型遵循項目管理流程，將軟件需求開發劃分啟動、需求開發過程、總結三個階段，并將軟件需求開發過程劃分為需求獲取、需求分析、編寫軟件需求規格和需求驗證四個階段，模型應用項目管理的進度管理、成本管理、質量管理，對軟件需求開發進行動態管理，實現軟件需求開發項目目標最優。該模型能夠提高軟件需求開發管理效率，確保軟件開發能夠按進度，低成本，高質量地完成。
參考文獻：
[1]景慎艷:軟件項目需求管理的探索與實踐[J].電腦知識與技術，2008（27）
[2]左懷遠:軟件項目中的風險管理研究[J].世界科技研究與發展，2008（3）
[3]孫琦龍:加強軟件項目管理的實踐模式[J].科技信息，2008（7）
篇6
關鍵詞：測試風險管理；風險管理；軟件測試
中圖分類號：TP311文獻標識碼：A文章編號：1009-3044(2012)11-2518-03
軟件本身的復雜性以及測試本身的特性決定了測試活動實施過程中風險的大量存在，而風險會影響測試活動的成敗，嚴重時還可能導致整個項目的失敗。因此，對測試風險的管理越來越引起人們的重視。
1風險存在的必然性
軟件測試項目的風險來自于軟件和測試自身的特點。
1.1軟件的特點
1）軟件產品是不可見的：軟件項目的開發進度和軟件質量管控過程是否符合標準很難衡量，使得軟件的管理也難于把握；
2）軟件生產過程形式多樣，不存在絕對正確的形式：不同的軟件開發項目，應采取不同的或者特定的軟件開發過程。但在項目開發之初卻不能確定正確的形式，只能根據項目的特點和開發經驗選擇，并在開發過程中不斷的調整，真正適合該軟件的開發過程只有在項目開發結束才能確定；
3）大型軟件項目往往是“一次性”：項目一次性的特點使得過去的經驗不能被廣泛的借鑒。控制軟件管理風險的唯一途徑是設立監測系統，開展有效的風險監控和管理。
1.2測試的特點[1]
1）完全測試是不可能的：在有限的資源和時間條件下，找出所有的軟件缺陷和錯誤，使軟件趨于完美是不可能的，主要原因為是輸入量太大、輸出結果太多、路徑組合太多；
2）測試具有病毒一樣的免疫性：軟件缺陷具有病毒一樣可怕地免疫性，對其采用的測試越多，免疫能力就越強，軟件測試工程師想要找出更多軟件缺陷就更加困難；
3）測試是“泛型概念”：軟件測試涵蓋需求分析、概要設計等在內的整個軟件生命周期，以確保每一個階段都經住考驗；另外，測試自身也需要來自第三方的評估和監督，以確保測試的可靠性；
4）80-20原則：80%的軟件缺陷常常生存在20%的軟件模塊中。我們在系統分析、系統設計、系統實現階段只能檢測和規避80%的軟件缺陷。在下一步的系統測試中，可以幫助我們找到剩余缺陷的80%，剩余4%的缺陷只有在系統交付使用后經過大范圍長時間使用后才會暴露出來。所以，軟件測試只能保證盡可能多的發現軟件缺陷，卻無法保證能夠發現所有的軟件缺陷；
5）缺陷的必然性：由于軟件測試中錯誤的相關性，并非全部的軟件缺陷都能夠被成功修復。在缺陷的修復過程中會不可避免的引入新的錯誤，另外，在修復的過程中，我們往往還會受到時間、成本等各方面因素的限制，導致最終不可能完全的修復所有的軟件缺陷。
2風險的評估
風險的管理基本的內容有兩項：風險評估和風險控制。
風險評估是在風險識別的基礎上，對識別出來的風險進行評估，主要從下列四個方面入手[2]：
1）風險概率分析，即對風險發生的可能性設置一個尺度，如很高、較高、中等、較低、很低等；
2）描述風險并預測風險發生后，對軟件產品和測試結果可能產生的影響或造成的損失等；
3）確定風險評估的正確性，要對每個風險的表現、范圍、時間做出盡量準確的判斷；
4）根據損失（影響）和風險概率的乘積，來確定風險的優先級別，定制風險應對措施。
3風險控制的原則
風險控制是建立在風險評估的基礎之上的，主要工作原則有[2]：
1）針對有些可以避免的風險，例如測試用例執行率未達到100%，可以通過制定測試規范，要求測試人員嚴格按照測試用例執行測試，并記錄用例執行情況，來避免該類風險；
2）有些不可避免的風險，采取措施降低風險，尤其是等級較高的風險，將其轉化為不會引起嚴重后果的等級較低的風險；
3）凡事預則立，事先做好風險管理計劃，當風險成為現實時，可以更好的避免、轉移或減低風險；
4）對風險的處理制定應急、高效的解決方案。
4軟件測試風險分析與管理方法
軟件生命周期包括問題定義及規劃、需求分析、軟件設計、程序編碼、軟件測試和運行維護六個階段，而軟件測試前面的任何一個環節的不嚴謹都可能增加軟件測試活動的風險。軟件測試活動中也存在各種各樣的風險，其中常見風險有需求變更風險、測試過程風險、測試組織和人員風險。
4.1需求變更風險
在軟件測試項目尤其是歷時較長的大項目的實施過程中，總會不可避免的出現需求的變更。如何把握好需求的變更，減少需求變更帶來的風險，成為影響整個項目成敗的關鍵。
4.1.1軟件測試項目需求變更的管理[3]
1）設定需求變更的參考標準，將需求基線。當軟件測試項目組確認要產生需求變更時，用標準的變更申請表格將委托方的變更申請記錄存檔。每次的變更都應在需求基線的基礎上進行。
2）軟件測試項目組收到委托方提交的需求變更申請后，成立項目變更控制委員會(CCB)，負責對項目變更所帶來的影響進行評估，包括測試項目的人力、物力、資金、管理、時間、質量、工作負荷等內部因素，以及資本、委托方要求的完工時間、項目負債情況等各個方面的影響。
3）變更確定后，選擇可行的實施方案。為了將項目變更的風險降低到最小，力求在盡可能小的變動幅度內對測試項目的目標、預算、團隊以及項目的進度等主要的因素進行微調。
4）需求變更后，要重新確定新的需求基線；受影響的軟件計劃、產品、活動等也要進行相應的變更，以保證和最新需求的一致性。
4.2測試過程風險
在測試工作中，主要的風險有[4]：
1）需求的臨時或突然變化，導致設計的修改和代碼的重寫，使得測試時間不夠；
2）測試用例沒有得到100%的執行；
3）質量需求或產品的特性理解不準確，造成測試范圍分析的誤差，結果某些地方始終測試不到或驗證的標準不對；
4）質量標準不都是很清晰的，如適用性的測試，仁者見仁、智者見智；
5）測試用例設計不到位，忽視了一些深層次的邏輯、邊界條件、用戶場景等；
6）測試環境與實際生產環境一般情況下都不可能完全一致，造成測試結果的誤差；
7）有些缺陷出現頻率不是百分之百，不容易被重現；如果代碼質量差，軟件缺陷很多，被漏檢的缺陷可能性就大；
8）回歸測試一般是選擇性的執行部分測試用例，必然帶來風險。
前面3種風險可以通過前期調研人員或測試人員與客戶加強溝通或者制定嚴格的制度來避免的，而針對有些不可避免的風險，采取一些有效的測試風險控制方法來盡量降低風險，例如測試環境不正確，可以通過事先列出要檢查的所有條目，在測試環境設置好后，由其他人員按已列出條目逐條檢查；針對程序中總是存在的“未發現的缺陷”，可以通過提高測試用例的覆蓋率（如達到99.9%）來降低這種風險；針對經常出現的產品前夕，在某個不是很重要的新功能上發現一個嚴重缺陷的問題，可以通過去掉該新功能來轉移因為修改此缺陷可能引起的某個原有功能上的缺陷的風險。回歸測試只執行部分用例帶來的風險是可以避免的，但出于時間或成本的綜合考慮，一般是存在的。
提前做好風險管理計劃和風險控制策略，可以更好的避免、轉移或者降低風險：
1）在執行項目計劃，做資源、時間、成本等的估算時，要留有余地；
2）在項目開始前，制定風險管理計劃，重點把握邊界上可能會出現變化、難以控制的因素；
3）重視人員隊伍的培養，對每個關鍵性技術崗位人員培養后備人員，確保項目不受人員流動的嚴重影響；
4）制定工作機制和文檔標準，保證文檔的及時產生，便于項目知識的分享和移交；
5）對工作進行相互審查，不同的測試人員在不同測試模塊上相互調換，及時發現問題；
6）日常跟蹤所有工作過程，及時發現風險的跡象，以避免風險。
4.3測試組織和人員風險
4.3.1測試組織風險
測試人員不獨立于開發者，測試人員獨立與開發者的程度將影響測試結果。
1）成立專門的測試組織；
2）制定專門的測試管理流程和質量保證手冊，規范測試過程，保證測試的質量；
3）委托專門的測試組織執行測試活動。
4.3.2人員風險[4]
測試項目尤其是周期較長的項目幾乎不可避免的要面臨人員的流動，從而增加項目失敗的風險系數。及早預防是降低這種人員風險的基本策略。下面從第三方測試的角度具體介紹一下人員風險的控制方法：
1）指派一名項目副經理或項目經理助理協調項目經理管理項目工作，降低關鍵崗位人員流動的風險。但是一般只建議在項目經理這種比較重要的崗位采用這種冗余復制的策略來預防人員風險，否則將大大增加項目成本；
2）建立良好的文檔管理機制，包括項目組進度文檔，個人進度文檔（測試日志）、版本控制文檔、整體技術文檔（測試策略、測試用例）、個人技術文檔（測試執行記錄、缺陷報告）等。一旦出現人員的變動，替補組員能夠根據完整的文檔盡早接手工作；
3）控制項目團隊中外包或兼職人員的比例，且項目核心部分的工作應該盡量由全職人員來擔任，以減少兼職人員對項目組人員不穩定性的影響；
4）加強測試項目組內的技術交流，定期召開項目例會，使測試組成員能夠相互熟悉對方的工作和進度，能夠在必要的時候接替對方工作；
5）為項目測試工作的開展提供盡可能好的基礎環境，比如待遇、項目組內良好的人際關系和工作氛圍等。良好的工作環境對于穩定項目組人員以及提高生產效率都有不可忽視的作用。
4.3.3外包人員風險
1）制定相關的管理流程文件，規范外包人員的活動，防患于未然，規避外包風險；
2）通過外派監管團隊的方式對整個測試活動進行監控；
3）通過對測試活動的中間交付物進行檢查保證測試的質量，例如：對設計的測試用例進行評審、對編寫的測試代碼進行抽查、檢查測試執行的日志等；
4）對于外包測試的形式，除了避免承包方項目人員的泄密，還要注意雙方數據傳輸過程中的信息保密。在采用外包測試的時候，不可避免地要進行各種信息的傳送，可能是雙方的電話、E-Mail交流，也可能是軟件版本的傳輸，在條件允許的情況下要盡量使用VPN等方式。如果有必要，對傳輸的數據要進行加密。
5結束語
測試過程中的風險總是存在的，該文對測試活動中主要的風險進行識別和控制，并確定針對性措施，避免風險發生，或者把風險降到最小。要想做好風險管理工作，就必須徹底改變測試項目的管理方式，建立防患于未然的管理意識，并結合具體的實踐工作不斷地分析遇到的風險，總結各種風險的應對措施，指導實踐，降低產品質量風險。
參考文獻：
[1]張華.軟件測試的常識[EB/OL].省略/html/2010-01-13/100144.htm.
篇7
近年來，中國的汽車市場迎來了爆發式的增長，從2010年開始，中國一躍成為世界規模第一的汽車生產國，成為全球最具活力的汽車市場之一，全國各省市先后出臺了促進汽車產業發展的規劃，各大汽車廠商也紛紛跑馬圈地，產能成倍地增長。這意味著汽車廠商在迎來千載難逢的市場機遇的同時，也必將面臨著激烈的市場競爭。
本文將通過對北京汽車股份有限公司（以下簡稱“北京汽車”）零部件采購現狀的分析，運用項目管理的方法來規劃和實施采購信息化系統建設，同時和大家分享項目實施過程中在范圍管理、溝通管理和質量管理方面的一些經驗。
一、北京汽車零部件采購現狀
2010年9月，北京汽車正式成立，雖然有不少有經驗、背景的人才加入，但是對北汽自主品牌來說，從研發、采購到生產的全過程還是像個蹣跚學步的小孩，一點點在摸索中成長。就零部件采購來說，其存在的主要問題是：整車廠以自身利益為中心, 不顧零部件企業的實際情況和利益, 用零部件企業的大量庫存來換取自身的零庫存, 并把價格戰的壓力推向零部件企業, 導致汽車行業整體供應鏈競爭力減弱；信息溝通的手段和工具落后，主要還是采用傳統方式( 電話、傳真、信件、E - mail）與供應商進行信息交流, 使信息不能及時傳達, 導致采購效率低下, 企業對市場的反應速度遲滯, 造成生產與市場的脫節, 而供應商為了適應由于信息不暢造成的需求變化, 只得加大庫存量, 導致流動資金占用過多；零部件定點和開發認可進度風險管控困難，成本對標與統計完全靠手工臺賬處理，人員流失導致數據信息流失，這種狀態已經嚴重制約了采購業務的開展，尤其是在整車行業競爭如此激烈的大環境下，要求規范采購業務流程、提高工作效率、與供應商協同合作、共同發展的呼聲越來越高，采購信息化管理也就勢在必行。
二、北京汽車采購信息化系統分階段實施計劃
2011年下半年，在北京汽車各方領導的大力支持下，采購中心協同信息技術部開始規劃零部件采購信息化系統，即SRM（Supplier Relationship Management，供應商關系管理）系統，這個系統是一種不斷優化供應商選擇，縮短采購周期，貫徹集中采購，并實現與供應商建立和維持長久、緊密伙伴關系的管理思想和軟件技術解決方案。筆者作為該項目的項目經理有幸參與了整個規劃和實施過程。根據采購實際業務開展的緊迫程度，將系統規劃實施分成三個階段進行，具體安排見下表。
三、北京汽車采購信息化系實施過程的管理模式
1.項目組織類型選擇
由于采購SRM系統開發與實施涉及多個部門，如生產部門、零部件采購部門、供應商管理部門、財務部門、信息技術部、軟件開發商等，根據項目需要每個部門需要安排一名關鍵用戶，對參與項目的關鍵用戶的要求是對部門業務熟悉且表達能力強，同時需求調研階段和測試階段需要全程參與，其余時間還是要參與到部門事務中去，所以項目的組織類型選擇矩陣式管理。矩陣式管理較其他組織結構相比，至少有三大優點：一是提高工作效率，由于采用了靈活的組織結構，在資源上進行了共享，當項目出現的時候，可以馬上調集與之相匹配的資源，組建跨功能部門的項目團隊，提高了團隊執行力，減少了溝通環節，加快了信息的共享，提高了反應速度，矩陣式管理使各個部門的管理聚焦到公司的業務發展上，更加有利于公司的戰略實施；二是資源得到共享，在矩陣式的組織結構中，各個部門的資源得到了共享，使資源得到了充分的利用，減少了以前出現的“忙的忙死，閑的閑死”的情況，根據研究表明，采用矩陣式的管理模式比采用傳統組織結構的管理模式要減少20%的資源；三是更加有利于人才的發展，采用矩陣式管理模式并不會影響到人才的晉升通道，而且采用跨部門的協作模式，有利于提高員工的綜合能力的培養。矩陣式管理更加有利于人員的團隊合作精神，避免了以前的部門本位主義。
2.項目的范圍管理
項目范圍是指為了達到項目目標，項目所規定要完成的工作及過程。利益相關方必須在產品方面達成共識，也要在如何完成這一項目達成一致的意見。項目范圍管理是指對項目包括什么與不包括什么定義與控制的過程。這個過程用于確保項目團隊和利益相關者對作為項目結果的項目產品以及生產這些產品所用到的過程有一個共同的理解，簡單地說，項目范圍管理就是為項目劃定一個界限，劃定哪些方面是屬于項目應該做的，哪些是不應該包括在項目之內的，定義項目的工作邊界，確定項目的目標和主要的項目可交付成果。
針對SRM項目實施來說，需求調研階段生成的需求文檔就是對系統開發范圍的界定，這個也是整個項目實施中的重點和難點，一般會占整個開發周期三分之一的時間。“磨刀不誤砍柴工”，前期需求越明確，后續開發返工才會越少，進度才越有保障。否則有可能開發出來的產品和業務部門想要的內容南轅北轍，項目只能以延時或是失敗告終。需求調研階段，首先根據立項報告中的功能模塊定義，規定好每個模塊的調研時間，也就是確認需求調研計劃和參與人員，當然時間是很緊湊的了。然后，我們組織關鍵用戶和軟件公司開發顧問一起進行頭腦風暴，每個人根據自己業務的實際需要，提出需要哪些功能，業務流程應該是什么樣的，頁面該如何展示，審批流程應該是什么樣的等等，開發顧問會詳細記錄這個需求內容，同時對討論未決事項確定責任人，需要找相關領導確認明確需求，并生成會議紀要下發再次征詢意見。討論會后，需要關鍵用戶將模塊的業務流程進行梳理，生成模塊的流程圖。每個模塊大概都需要三輪需求討論才能定第一稿需求文檔。由于關鍵用戶一般都是業務骨干，但不是部門經理，沒有決定權。第一稿確定后，需要集中各部門領導進行宣講和征詢意見，根據領導的意見再次修改后審批完成才能最終定稿。需求文檔必須明確標記每個模塊需要哪些頁面、頁面功能和字段有哪些、頁面功能之間的關系、權限的設定、審批流等詳細信息。同時為了以防萬一，擔心開發人員理解有誤，需要軟件開發商根據需求文檔提供系統界面原型，作為需求調研階段另一個交付物，界面原型同樣需要關鍵用戶和相關領導審批通過才能生效，這也是需求調研階段的雙保險，根據以往的經驗，這樣做后續開發過程中的分歧會比較少。
當然，再完善的需求也很難避免由于各種原因而出現需求變更或新增需求（范圍變更）的問題。針對需求變化，首先需要提出部門提交變更申請單，項目組內部進行綜合評估，首先判斷這個需求是否真的有必要體現，如果需要，就要看需求變更對其他功能的影響，影響有多大；如果該變更不開發將影響其他業務流程，那一定要在本期上線前開發完成，否則系統無法使用。這種情況就需要調整開發計劃，形成新的項目計劃基線。如果該變更是單獨功能，不影響其他功能的使用，看開發進度是否允許，時間充裕可以上線前開發；否則協商后可以系統上線后開發，但規定好具體完成時間。如果經項目組評估后覺得功能根本沒必要體現，需求變更不予實施。變更申請單需要層級審批后，由開發經理評估費用和時間進度，按計劃執行。變更申請單由信息技術部存檔，作為項目收尾時結算的依據。
3.項目的溝通模式
項目溝通主要是項目團隊與其他組織、項目團隊成員之間的信息傳遞和理解。項目溝通貫穿于項目的整個生命周期，在確認系統需求階段需要溝通；在項目計劃階段制定各類計劃時需要溝通；系統開發和實施階段需要溝通；在系統測試階段需要溝通，以及上線運維階段都需要溝通；可見溝通在整個項目實施過程中的重要地位，有效的溝通對項目的成功具有重要的意義。如果溝通不暢，相關人員不能理解項目經理的意圖，無法做到上傳下達，最終會導致項目混亂甚至失敗。另一方面，項目團隊內部及其與外部環境之間的信息溝通可以使項目組及時準確地獲取項目的進展情況，對項目進行合理的組織和控制，因為只有以準確、完整、及時的信息為依據，項目組才能做出正確的決策和合理的計劃。
針對SRM項目來說，采用的是輪式溝通渠道模式，就是項目經理作為信息中心分別與項目中不同類型角色發生聯系，集中匯集和傳遞來自各個部門的信息，但是不同角色之間彼此之間不發生聯系，只分別掌握本部門的情況，接受主管人員的指令并反饋信息。溝通的方式主要以書面溝通的形式，會議上溝通討論的以會議紀要為準，個別溝通的內容以郵件為準，或是根據項目要求提交各類報告，這些信息可以長期保存且信息描述周密、邏輯性強，不容易產生誤解和糾紛。但是缺點是耗費的時間比口頭溝通要多，同時無法保證接收者是否能夠正確理解，綜合兩者的優缺點，我們最終采用的溝通方式是以書面溝通為主，口頭和書面相結合的方式，每次口頭溝通后會落實到文字上雙方認可再實施，保證溝通的有效性。
4.項目的質量管理
項目質量管理是為滿足項目利益相關者的需要而開展的項目管理活動。針對SRM項目的質量管理就是軟件功能測試，包括單元測試和集成測試。由于我們此次合作的軟件開發商沒有專業的測試團隊，只是開發人員交換測試，一方面由于時間進度緊而測試不充分，另一方面對別人開發的模塊需求不清晰測不出業務流程的正確與否。所以到單元測試和集成階段，關鍵用戶就要參與進來，每個關鍵用戶測試自己所熟悉的領域，除了對頁面字段功能進行驗收外，還要對功能之間的業務邏輯進行驗證，這樣開發與測試并行進行，有利于保證進度。但是從另一方面來看，我們收到的最初的交付物錯誤百出，通過問題清單的形式發給開發經理進行修改和再次驗證。雖然我們驗證的比較充分，但是這樣項目組面對的工作量就會成倍的增加。建議以后最好選有專業測試團隊的軟件開發商，讓其分擔項目組的測試工作量。
四、小結
篇8
關鍵詞：軟件公司；成本控制；探索
1經營決策階段的成本及其控制
經營決策階段成本是指公司經營方向的選擇，這是成本管理的第一個也是最為核心的環節。不過對于大多數IT軟件業公司而言，這個階段往往是最大的問題之所在，有時經常憑一個覺得是靈感的想法或者對市場初步的直觀層面的調研就進行的決策。而這樣的結果是往往沒有摸透市場的真實情況，輕率上馬項目，造成方向性錯誤，以至于導致企業的危機。
該階段的成本控制，關鍵在于經營決策前科學而深入的市場調研及準確分析，目前很多中小型IT軟件企業，其經營部的職員大多都并不是社會調查專業的，因而他們做市場調查的過程中所采用的方法不太科學，如在樣本選取及抽樣過程不合理，沒有按照嚴格的社會調查方法進行調查和數據分析，甚至問卷設計都存在傾向性導致調查數據信度偏低。此外，大量的公司自我宣傳的各種形式的軟文和競爭對手有意的攻擊性文章夾雜在其中，并不是很容易的進行分辨，更何況數據的隨意性，來源的不可追溯性各種情況，所以只能作為參考。
2需求整理及分析確認階段的成本及其控制
需求整理指市場經營人員根據高管對于市場方向的決策，而提出的具體的產品或者項目的原始需求，需求分析是指技術員對市場部門的需求進行分析，評估其可實現性以及實現難度，大致工時等，提交相關需求分析報告，最后市場經營部門進行確認這個階段。
該階段的成本控制，首先需要搞清這種溝通過程中產生偏差的原因，最為主要的往往并不是技術語言和市場語言的差異，或者市場人員和技術人員之間的思維定勢的差異，而在于兩者缺乏確定的科學的流程和在交流之前的準備以及相關概念約定俗成的定義造成的問題，同時還由于溝通和確認環節由于其特殊性，經常難以被有效的納入進度管理程序流程當中。而提高該階段的成本控制效率，必須逐一針對性的解決以上問題，首先要清晰的確定并嚴格執行市場和技術溝通的流程，尤其是要明確每個環節的控制點，也就是雙方交付給對方的關鍵交付物，一定要有清晰的共同確認的模板，同時每次溝通前必須對于一些概念有著清晰的界定，然后公布這些信息，并在溝通前做好充足的準備，明確每次溝通前要溝通什么，要解決哪些問題，溝通結束后要交付哪些文檔讓雙方進行確認等，同時一定要通過線上或者線下的管理模式，講所有溝通環節全盤把握，并納入進度管理。
3規劃階段成本及其控制
規劃階段成本是指在需求已經得到確認后，進入技術規劃階段的相關成本控制，該階段有些軟件開發公司常常出現的問題是對于規劃予以過度的期望和過于沉重的內涵，在實際項目操作過程中，這個規劃實際上包含著技術規劃和非技術規劃兩個部分，因為對這兩個部分的混淆，導致一些技術層面和市場層面的東西不必要的糾纏在一起，并且直接導致項目進度的拖欠，而且會導致由于非技術規劃的不清晰，直接影響技術規劃層面的實施。
該階段的成本控制，必須清晰的區分非技術規劃和技術規劃，尤其在公司內部技術部門和市場經營部門之間的職責，需要設立一個在提出需求到技術規劃之間過渡的位置，即對于需求具體細節的整理，要對于交付物有著清晰的確定，尤其是在不同時期交付不同的關鍵文檔，如除了上面說的那六個文檔外，技術部項目組長在需求分析的時候，還應該明確提交功能模塊分析，開發代價，功能流程圖，功能關聯性圖，可維護性及可拓展性分析等六個文檔，此外在項目開發規劃階段，還要對于控制點的一些要素進行詳細的規劃用來提交給市場部門，如詳細頁面元素，頁面元素價值度分析，表現形式，頁面結構，頁面效果等。
4開發階段的成本及其控制
開發階段的成本指需求確定并且規劃清晰后的具體開發過程的成本管理問題，該階段相對其他階段來說比較清晰，但這里筆者認為需要關注的是，如何使得人力資源得到最大程度的利用，它是指公司第一線技術人員的能力最大程度發揮的狀態，包含幾個層次，（1）全部時間利用，（2）最大效率利用，（3）最大潛力激勵利用，這三步需要逐步遞進實現。這個需要一種完善的內部管理制度，以及公平公正的價值認定模式和績效制度，從而一方面促進員工本身的發展，一方面增加對人才的吸引力。
該階段的成本控制，可以引入最大可控制成本的概念，這里是指人力資源最大程度發揮后所能控制的成本，是公司在一定投入前提下，最大的可能的減少因管理導致人力發揮不足夠而造成的成本，該成本為人力資源的極致成本，無法再進一步降低，此成本狀態下的仍然出現效益不佳情況，則可說明在經營定位和經營方向上的問題，而非內部問題。促使人力資源得到最大利用度和發揮度，在此基礎上的成本，為最大可控制成本，以上可以通過內部的管理系統來很好的實現。5需求變更成本及其控制
需求變更成本指在開發過程中，由于市場部門的需求改變導致的成本增加而實施的控制，對于項目開發的過程中，需求的頻繁變更就成本控制而言是致命的，很多項目由于需求的變更而導致破產。
該階段的成本控制，最關鍵的是要對于需求變更過程進行嚴格的管理，要從需求變更的開始，對于整個變更的每個具體的步驟進行跟蹤，并且嚴格核算每次變更所需要的工作時，從而做好評估。同時，務必要明晰需求變更的必要性和風險性，以及所帶來的實際成本的增加，所以需求要盡量經過詳細的論證。
6測試成本及其控制
測試成本指項目開發完成階段，在交付驗收前進行的測試過程中導致的成本及其控制，測試階段對于一個項目的最終交付具有重大的意義，往往在測試階段要才是使得項目真正完善的階段，很多細節的修補都在測試階段完成，正是測試使得一個項目成為一個可以交付，可以應用，可以產生效益的產品。但對于一些中小型軟件開發公司而言，往往缺乏真正建制齊全的測試部門和專業測試人員，經常是技術人員進行兼任，這種方式相當普遍。但同時也導致了一些問題，主要是對于測試缺乏經驗積累管理，或者說是錯誤管理，經常上次測試完出現的問題，過段時間又會出現，或者是開發下個項目的過程中又再次出現，增加不必要的成本。
該階段的成本控制，筆者認為最關鍵的是對測試進行錯誤管理模式，采取“有錯必改，凡錯必究，錯不再犯，預錯于先”的管理辦法，盡量在項目開發之前，就能整理出之前開發中出現過的所有問題，并用列表的方式進行技術會議，讓所有開發人員進行錯誤共享，盡量把測試中可能出現的問題消滅再開發階段，另外需要把測試過程化、即時化，每周甚至每天都要求每個開發人員在交付自己的子模塊的之前就暗中預先準備的測試手冊進行測試，通過后再提交，同時定時抽查某些核心功能模塊，進行某個點的測試，這樣全過程的控制，會最大程度的減少測試成本，同時要加快反應速度，一發現開發中，或者測試過程中的相關問題，必須跟進徹底解決，并納入績效考核中，杜絕再犯。
參考文獻
［1］頡茂華，現代市場經濟成本的成本控制新理念［J］.財會月刊2002,(06).
篇9
一、項目經理要有較強的觀察分析能力，能夠透過現象看本質，規劃出執行步驟和措施；
二、項目經理需要有較強的經算能力，能夠掌握具體任務的成本、工期及進度；
三、項目經理需要思路清晰表達準確，能夠把遇到的問題、過程、解決方案，清晰地反饋給客戶；
四、項目要較強需求分析確認意識；
五、項目要有較好需求變更控制技巧，做到項目成果于需求變更的雙向跟蹤；
六、項目經理要有較強的綜合調度技巧和能力，對項目各環節清楚，也能使別人清楚，還要合理何時合適地調度各類人力資源。以上使我從實際項目建設過程總結的經驗，現在我分別一一詳細闡述，以供參考，相互學習。
正文
2006年，我作為項目經理參與了青島市應急聯動指揮系統的建設。該項目是奧運會帆船比賽城市青島的110、122、119三警合一平臺及應急聯動單位協作平臺，為了提升整個城市對應急突發實踐的響應效率和處置能力而建設平安奧運而做。該項目的主持單位是青島市公安局，項目構成有110、122、119接警平臺，處警平臺，聯動平臺，計算機網絡，服務器，視頻監控及錄音服務系統等。
在項目建設過程中，我從客戶需求調研、需求設計、需求確認、軟件開發、整體實施各個環節的實際工作體驗中，發現項目經理的能力幾乎市項目成敗的一個決定性因素。在項目經理作用于項目建設諸多能力中，我覺得以下幾個方面尤其重要：
一、觀察分析能力。
能夠面對綜合復雜的現象，分析處問題本質所在，抓住主要矛盾，并且很快建立應對步驟及措施，項目建設過程出現的問題都能被及時解決，項目才能順利進行。具體來說，對于出現的問題和現象，項目經理能夠分析出“是什么”，又能指出“有什么”（有哪些細節），進行采取合理的“怎么辦”（解決問題的方法和步驟），最后再說明“影響什么”（有哪些風險）。這樣，項目建設才能清清楚楚地進行（每一個干系人了解清楚），有條不紊地開展（每個人力資源明白措施及步驟）。觀察分析，是一個綜合能力。學者經書子集學富五車可謂之淵博；而運籌帷幄決勝千里方是致勝之道。項目經理應該注意將所學用于實際的觀察分析，從復雜的想象中指出應對措施和步驟。商鞅變法時，遍歷秦國風土人情，觀察分析所存在的想象及問題，指出解決各類問題的步驟及措施（各類法令），就是一個典型的觀察分析能力運用的結果。重視觀察能力的培養和練習，項目才能走出項目的迷霧，讓自己清楚，才能讓別人清楚。我在青島項目建設后期，總是習慣于清楚地分析問題“是什么”，指出“有什么”，設計“怎么辦”，讓觀察分析能力充分發揮，所起的作用和前期有明顯區別，終于由客戶的抱怨轉化成贊成。
二、精算能力。
大型項目建設，不是個人單槍匹馬獨闖獨斗；而是一個團隊協同作戰。常聽到一句話：“老虎統帥的綿羊可以戰勝綿羊統帥的老虎”，正驗證了這個道理。想做好統帥，就要了解和熟悉每一個細節，知道整個項目有哪些子任務，分解到哪些人力資源來完成，并評估到工期和進度。如果出現遺漏，就會造成工期延誤。精算能力，正是體現項目經理這方面的才干。我在青島項目建設之初，簡單地分解工作任務，結果造成工作任務遺忘，工期受到延誤；后來認真分解任務，精算到位，合理分配每一個細節，項目工期才得以彌補。
三、思路清晰表達準確。
如果自己的思路都不清楚，怎么讓別人清楚呢？我們在生活中，經常碰到這樣的人。他說話時，東扯一句，西扯一句，聽著不明白他的中心思想，很難理解他所表達的事物。與其說思路清晰表達準確是一種能力，還不如說其是一種意識。這個技能從小學課文都已經開始練習了（小學課文都將中心思想和段落大意），應該每一個人都做好。如果說話前，先想一想自己要說的中心思想，然后在逐步分層表達，每一個都能說清楚自己要表達的意識。但是很多偏不這么干，沒想好怎么說就開始表達，聽得別人云山霧罩。包括我自己，在青島項目建設之初，我說話前不喜歡做語言上的準備，說得別人越聽越糊涂。后來我堅持，表達前先設計思路，然后在準備語言進行準確表達，就避免了客戶越聽越糊涂的現象。
四、需求分析確認意識。
項目尤其本身的特點，就是一次性滿足固定客戶的特殊需求。項目經理說做的目標就是滿足這個客戶需求。需求是什么，有什么，怎么辦，項目經理需要于客戶溝通，獲取確認后，方是客戶所要的需求。需求的確認就是完成這個工作的。項目經理應該使需求的理解，需求的設計結果得到客戶確認；否則一個沒有經過客戶確認的需求和設計，使工程返工，推倒從來，白白浪費成本的導火索。我在青島項目經歷過這樣的教訓，客戶提出需求后，我盲目開工，結果客戶不滿意，團隊成員抱怨，成功工期都出現了問題。后來堅持需求簽字確認，就大大降低了返工的概率。
五、變更控制技巧。
項目經理需要較好的需求變更控制技巧。對于項目的建設，由于客戶隨開發方一樣，都是一個逐步熟悉的過程。項目的需求變化使一件很普遍的事情。有的開發人員抱怨客戶變化無常，一天一個樣。其實這是沒有站在客戶的立場想問題。對于需求變更一味地接受，增加公司的成本，也會造成工期延誤；一味地拒絕，客戶難以滿意，甚至反感。其實這里需要一定的技巧和方法。其一、使客戶準確完面地提出問題，堅持走一定的變更流程。例如需求要經過變更會議多方全面討論分析，再經過需求理解設計，風險分析及實施分析等。其二、經過簽字或者其他形式的確認。這樣需求變更不是一個客戶隨意的行為，避免客戶故意生事；開發方也能避免無效的多次返工，即使返工也是各方干系人都認可的工作。
六、綜合調度能力。
項目經理對整個工程的把握，知道在合適的時間，調用合適的人力，完成合適的任務，使整個項目進展按時按步進行，體現其綜合調度能力。大型項目建設是一種復雜而艱巨的任務，項目經理需要完成的事情很多。整體性思考問題，合時合適地安排調度，時其另一個重要的技巧。
以上是我在實際項目中體會的經驗。其實在項目建設過程中，項目經理需要總結和吸取的經驗還很多。項目經理應該從實際出發不斷地總結、學習和體會，以讓自己項目管理能力日趨完善。
篇10
關鍵詞 業主 工程變更 核電站
一、引言
由于建筑工程項目的單一性、復雜性和長期性的特點，其工程變更是不可避免的。如果業主對工程變更控制經驗不足，管理不善，往往會導致工期延誤、投資失控等情況的發生，因此業主必須重視工程變更的管理，確保項目的順利實施。我國紀檢部門已明文規定：工程變更將作為紀檢部門對工程建設項目重點控制、檢查的四個工作環節之一。國外一些發達國家，例如美國，對工程變更的控制也很重視，據美國有關部門統計，一般工程變更費占合同價格的10-25%，對工程投資影響很大，政府會對投資項目提出嚴格要求并進行專門檢查和評估。
作為中國的第一座引進國外技術并由國外公司承包建設的大型商業核電站，大亞灣核電站不僅引進了核電技術，也引進了先進的工程管理經驗。目前在國家積極發展核電的能源政策下，大亞灣核電站應運成為了中國廣東核電集團發展核電的人才和技術基地，近幾年需新建大批的住宿、辦公、培訓、招待、運動場館等行政基建項目。行政基建項目組借鑒電站建造時的工程管理經驗，結合行政基建項目的特點，對工程變更管理做了及時的總結反饋，完善了變更管理，取得了一定的成效。在工程管理的實踐中總結的一些體會和經驗相信對業界同仁會有些啟發和幫助。
二、業主對工程變更的管理經驗
（一）要結合公司和項目，分析引起工程變更的風險因素或原因。
引起工程變更的常見因素（見圖1），可以作為參考，另外要結合自己公司和項目實際，分析引起變更的因素，以便有的放矢，從源頭上控制變更。以大亞灣核電站的行政基建項目為例，通過對2006年引起各項目變更因素的分析，發現主要有四條：一是施工圖設計質量差；二是用戶需求變化，功能性變更；三是施工技術規范書不完善，施工范圍不清或項目遺漏；四是客觀的不可見因素。對引起變更最多的設計因素（約占總變更額的50%），進一步分析，主要為各專業間接口（特別是安裝和土建的接口的矛盾）和設計深度問題。
針對引起變更的主要原因，要及時采取有效應對措施，完善變更控制管理。如針對施工圖設計質量差，采取了一系列措施。首先，對設計任務委托書，進行分析評估，找出業主設計任務委托書中的不足，并借助工程咨詢公司的力量，編制了《建設工程設計任務委托書標準模板》，規范了今后設計任務委托書的編寫，也使質量有了保證。其次，在設計招標中，采用綜合評標法，并增加技術標在綜合評標中的比例，最高到40%，使設計院加大技術力量投入。第三，在合同條款中明確規定，由于設計院的圖紙缺陷，引起工程變更，造成業主損失，設計院要承擔相應的經濟責任。第四，加大圖紙審查力度。除了業主以及施工和監理單位審查外，在施工發標前，還委托專業公司進行第三方圖紙審查。第三方審查范圍也從國家規定的強規的符合性審查擴大到圖紙接口的審查。另外，把那些出圖紙質量差的設計院從公司潛在承包商數據庫中刪除，今后不再允許其參加設計投標。
（二）工程變更控制要采用全過程管理，以預防為主。
工程變更發生在實施階段，但一些工程變更，特別是重大變更往往潛伏在項目初始的籌劃階段。在該階段用戶需求調查、相互溝通以及項目籌劃人員的預見能力，對項目的正確定位和預防重大變更的發生尤為重要。大亞灣核電基地行政基建項目前期的設計階段中，有幾個項目發生的重大變更都是由于用戶需求和形勢變化，導致原方案不再適用。用戶一般不是專業的工程技術人員，在項目初期很難系統提出一份專業、完整的需求報告，而往往是工程建到一定階段，用戶看到實物后又會提出很多變更要求，使項目陷入被動。針對用戶特點，我們把用戶需求標準化，做成一個覆蓋面很廣的菜單式需求表，讓用戶填寫，并簽字確認。在設計階段，應做出直觀的效果圖和模型，讓用戶在方案設計階段提出意見。這就基本解決了用戶在工程建造階段提出變更要求的問題。另外，項目的籌劃要建立在清楚用戶需求的基礎上，還要從專業角度了解更多信息，用發展的眼光明確項目定位，重大項目在必要時可請專業咨詢公司協助進行前期籌劃。項目初期完善、深入的工作，可以有效地預防重大變更的產生。
（三）項目管理中，要控制和減少的是不合理的工程變更。
工程變更可能會導致工程項目延期和投資失控，但業主人員也不要談虎色變，一味避免或減少工程變更。實際上有些工程變更的實施可以提升項目的功能價值或減少業主損失，對工程建設或項目全周期費用控制有利。因此，要辨證地看待工程變更，充分利用變更，使業主利益最大化。如在大亞灣核電基地員工宿舍二期的建設中，有幾棟樓的原始地坪較高，且為基巖，原設計中采用爆破施工降低地坪。在施工過程中，由于該現場與其他已投用的建筑物較近，且在人口較多的生活區，爆破施工時風險很大，進度緩慢。業主技術人員經研究將建筑物基礎標高提高1米，也不影響建筑物的正常使用，經設計院同意，決定發出工程變更。該變更為業主節省施工費用約138萬，縮短了工期，也大大減少了爆破施工的風險。
（四）建立規范的變更控制流程，并正確處理變更控制與效率的關系。
做好工程變更管理，業主首先要建立變更控制的流程和分級授權審批制度。以大亞灣核電運營管理公司為例，在公司的《合同采購政策》中，規定了變更處理的原則，如“除非涉及重大質量安全問題或可以為公司爭取明顯的效益，應盡可能減少設計和技術要求的變更。”而且一旦項目累計變更金額超過合同額的15%，變更要由批準原合同的上一級授權人批準。對于行政基建項目，由于合同額相對較大，如果超過15%，一般要公司董事會批準。在此政策下，項目部也制定了《行政基建項目工程變更管理》程序，對變更的定義、處理流程做了詳細規定。一般來講，變更審批環節越多，越容易控制變更的數量和變更的費用，而且各部門在審批中互相補充、制約，也能在一定程度預防個人主觀因素甚至個人違規損害公司利益的情況發生。繁瑣的變更審批流程，需要較長的流轉時間，往往會影響變更的及時實施，甚至影響整個項目的工期。但過分簡化變更控制流程，甚至先實施、再辦變更手續的做法也是不可取的。建設單位要根據本公司的整體管理的要求以及工程項目的特點，正確處理變更控制與工程效率的關系。
（五）變更控制要充分利用支持單位的力量。
對一般業主單位來講，由于工程建設是階段性的，一般不會有太多的專業工程管理和技術人員及相關的經驗，與專職從事工程施工的承包商單位相比處于劣勢。因此建設單位可以和一些專業公司簽訂一些技術支持服務合同，充分利用外部單位的力量和成熟經驗。如大亞灣核電基地的行政建設項目管理中，項目負責人由業主人員擔當，負責項目的總體協調管理。在發標階段，請造價咨詢單位編制工程量清單，請招標單位編制招標文件并進行技術評標。在項目實施中，請專業公司進行第三方圖紙審查，請監理公司負責變更令的編寫、完工工程量簽認，請造價咨詢單位對擬發出的工程變更進行估價并負責承包商變更報價審核。這樣專業公司介入了工程管理的各個環節，有效地控制了變更，彌補了業主技術和經驗不足的缺點。
（六）在變更管理中，要明確各方責任，進行適當的考核和激勵。
由于變更產生的原因很多，控制的環節也較多，再加上引進外部支持力量參與的人員和單位也多，如果不明確各方的責任，加強考核，變更控制的有效實施也很困難。在大亞灣核電基地的行政基建項目變更管理中，首先在建設單位內部，對每個變更按引起的原因進行分類，用戶需求變化引起的變更責任方為用戶，技術變更責任方在土建處，先控制由各部門引起變更的累計金額占合同金額的比例，作為部門考核指標，然后再由部門分解到員工量化績效考核中，考核直接和年度考績及獎金掛鉤。對于外部單位，在合同條件中也明確規定了獎懲細則，考核他們的工作效率和效能。這樣充分調動了所有參與人員的責任心和主動性，構筑起控制變更的道道屏障。
三、案例分析
大亞灣核電基地員工宿舍二期工程主要包括9棟6層的宿舍樓及小區的道路、綠化和半地下停車場。項目的預算金額為7000萬元人民幣，各種合同（含設計、監理、咨詢、家具、施工等）的累計合同額為6500萬。在工程變更的管理中，業主項目組嚴格按照規定的變更流程（見圖2），充分利用支持單位的技術力量和經驗，對每個變更的必要性、合理性進行把關，對變更方案和工程量及造價進行嚴格審查，并充分汲取員工宿舍一期的經驗，調動項目管理人員的積極性，使工程變更得到了有效控制。
以土建施工部分為例，其合同額為5760萬，工期為12個月。工程變更統計如表1。
其中最大的一個費用變更是由于設計院沒有充分考慮大亞灣沿海、雨量大、臺風多的氣候條件，屋面和墻體防水設計不完善所造成的，單個變更的金額為49.7萬元。
大亞灣核電站作為中國上世紀引進國外技術的最大的合資項目，工程的管理和公司的商務流程引進了香港和法國的模式，一直發揮著良好的作用。文中所述的行政基建項目的變更管理是在原來工程管理經驗的基礎上，結合目前的實際情況，不斷總結、完善而形成，在工程實踐中得到了驗證。在近期完工的三個項目中，工程變更累計金額與合同額的比例分別為10%、5.5%和負2.4%，并且全部在項目的預算金額內。工程變更管理貫穿于工程全過程，對工程影響重大。業主作為項目的投資方和受益方，要高度重視，勤于總結反饋，充分利用外部經驗和力量，結合公司和項目的特點，制定完善的工程變更管理制度，對工程進行科學管理，以保證項目的順利實施。
（作者單位：大亞灣核電運營管理公司，天津大學管理系96屆畢業生）
參考文獻
李維芳：工程變更確認與控制，《建筑經濟》，2007年第3期。
孟憲海：國際工程變更因果分析與管理，《施工技術》，2007年第2期。
