導(dǎo)語：如何才能寫好一篇需求變更的管理流程，這就需要搜集整理更多的資料和文獻，歡迎閱讀由公務(wù)員之家整理的十篇范文，供你借鑒。

篇1

關(guān)鍵詞：電力施工；需求變更；管理策略；控制流程

在電力施工過程中，需求變更的問題是不可避免的，它是通過流程把變更納入可管理的范圍內(nèi)，避免產(chǎn)生這種混亂，但是如果需求變更的發(fā)展失控的話，就會使項目陷入一種混亂且不穩(wěn)定的狀況，從而嚴重破壞了整個項目的管理過程，如何正確進行需求變更的控制，是一個很重要的管理過程。所以，為了能更好地控制電工管理中的需求變更，我們必須做一些措施來使需求變更有計劃的、有目的、更順暢的進行，從而使電工施工過程進行良好的變更控制。

1 電工施工中引起需求變更的主要因素

在電力施工過程中，引起需求變更的因素有很多，例如增減工程量的清單的內(nèi)容和工作量，包括施工進度計劃的變動，施工程序的改動，質(zhì)量標注的調(diào)整，技術(shù)要求的修改和補充，這些都是在電力施工過程中引起需求變更的因素，可以分為：

1、從需求變更的性質(zhì)來看，引起需求變更的因素分為主觀因素和客觀因素。

①主觀因素。例如電力設(shè)計工作的不細致，從而使工程實施過程中發(fā)現(xiàn)了很多在設(shè)計文件中沒有考慮到或估算不準確的工程量，致使必須改變施工項目或增減工程量。

②客觀因素。這就是指在電力施工中因為一些自然災(zāi)害或不可預(yù)見的事故、社會因素引起的停工和工期拖延等，這樣的工程變更是不可避免的，也是無法預(yù)料到的。

2、從引發(fā)需求變更的對象來看，引起需求變更的主要因素

①某些施工單位主動提出工程變更。某些施工單位會向設(shè)計單位提出對圖紙、設(shè)計說明不明確的問題的詢問，或是提出技術(shù)修改圖，對施工方法、施工議案提出修改，或是要求修改圖紙等問題，這些都是施工單位主動提出的需求變更。

②由監(jiān)理單位提出的工程變更。在電力施工過程中監(jiān)理工程師要經(jīng)常在施工現(xiàn)場巡視，憑借著他們自身的豐富實踐經(jīng)驗，他們往往會發(fā)現(xiàn)工程中存在著很多問題，并針對這些問題提出工程變更的建議。

③設(shè)計單位提出需求變更。在施工過程中，設(shè)計單位或者是其駐工代表對原設(shè)計中存在的一些錯、漏、缺、碰等問題，提出一些設(shè)計的修改和完善。

④由該工程的業(yè)主提出的工程變更。為了更好地完善使用功能，從而保證工程的質(zhì)量、加快工程進度等原因，在施工過程中，業(yè)主時常提出一些工程變更的要求。

在電力施工管理中，由于需求變更會引發(fā)工程量現(xiàn)場簽證、設(shè)計、進度的變化、合同變化等問題，我們需要對需求變更進行嚴格控制，從而將項目變更的影響降低到最小。

2 對需求變更的控制策略

對于在電力施工過程中，對需求變更的控制，如果僅僅按需求加強監(jiān)督執(zhí)行是不夠的，因為這樣的做法會造成項目各方對變更控制的乏力和被動，從而引發(fā)工程質(zhì)量、工程成本等一系列問題的產(chǎn)生，甚至可能使在發(fā)展中發(fā)生變更失控的現(xiàn)象，這是要絕對避免的。要想在電力施工管理中，使需求變更得到控制，就要確定一個選擇、分析和決策的流程，使所有的需求變更都要遵循和支持改流程，從而通過這個流程對需求變更進行控制。但是在遵循這個流程中還需要注意幾方面的問題：

1、要有明確的授權(quán)。在電力施工管理之前，要事先明確工程各方有權(quán)提出變更申請的人員和有權(quán)受理變更的人員，決不允許未授權(quán)的人員進行私下協(xié)商，只有這樣做才可以對需求變更有整體的控制。

2、對需求變更進行必要的審核。對電力施工管理中的需求變更不是所有的變更都要執(zhí)行和立刻執(zhí)行，審核的目的是決定是否需要變更和何時變更。

3、評估變更的代價和影響。在電力管理中的需求變更都是有代價和影響的，所以在確定變更之前，必須事先評估變更所帶來的代價和影響，使工程雙方了解了變更的后果之后，再一起做出判斷和認可。

4、要嚴格執(zhí)行需求變更的管理流程。小的變更也會引起變更最終的不可控制，所以小的變更也要進行正規(guī)的需求管理流程，并且施工單位要嚴格避免在變更確認之前，要按變更設(shè)想進行施工，否則可能會造成需求變更的整體失控。

3 需求變更的控制流程

在電力施工管理中，需求變更控制的主要手段是要明確定義流程并且可以嚴格的執(zhí)行，主要分為提出、評估和實施的三個步驟。首先，要由授權(quán)的人員進行提出需求變更，無論是哪一方提出的需求變更，都要履行工程變更的手續(xù)，并以書面形式交給總監(jiān)。其次，要由總監(jiān)召集專業(yè)的建立工程師來進行審查，認為可行后，設(shè)計單位根據(jù)業(yè)主要求的設(shè)計變更進行設(shè)計，變更要求必須以書面形式給出，然后設(shè)計單位簽署意見和設(shè)計出圖。設(shè)計單位完成施工圖的設(shè)計后，業(yè)主需要把圖紙給專業(yè)的職能部門和審圖機構(gòu)審核，審核通過交還業(yè)主，再由業(yè)主組織設(shè)計、施工、監(jiān)理各方一起對圖紙進行會審，盡可能地把存在的問題提出來，進行研究和探討，并由設(shè)計單位做出解答，形成文字資料后作為日后施工的依據(jù)。最后要由總監(jiān)給出確認后的工程變更通知后，才可以交由施工單位進行執(zhí)行，按照施工圖進行施工。

需求變更實施之前，是要經(jīng)過工程各方的審核、評估和確認的，在進行電力實施過程中要跟蹤與驗證，確保變更的正確執(zhí)行，在變更實施的整個過程中，在沒有拿到工程變更通知前任何一個步驟出現(xiàn)異議，整個流程都要重頭開始，并且施工單位也不會進行施工，這樣是為了確保整個需求變更始終是可以控制和管理的。

4 應(yīng)注意的問題

目前，很多企業(yè)都在遵循質(zhì)量與健康、安全和環(huán)境管理體系的互相補充、相輔相成，在電力施工過程中，他們?yōu)榱嗽谛枨笞兏凶裱|(zhì)量、安全和環(huán)境管理的一體化，為了更好地實施“ISO9000質(zhì)量管理體系”和“HES-MS”的管理，他們將“ISO9000-QMS”、“HSE-MS”、“ISO14000-EMS”整合成一個系統(tǒng)，但是在具體操作中會遇到很多問題：

1、對“ISO9000質(zhì)量管理體系”和“HES-MS”的管理范圍必須明確劃分，對于它倆的共用文件和資料應(yīng)按所屬管理的范圍劃分到所屬的系統(tǒng)中，對影響二者的的文件應(yīng)確定與“HES-MS”的接口，制定出明確的管理文件。

2、機構(gòu)要統(tǒng)一，發(fā)揮資源優(yōu)勢。很多企業(yè)把質(zhì)量、安全、環(huán)保等職能部門都分開屬于不同部門管理，這樣日程工作中協(xié)調(diào)減少了，增加了管理費用，造成了資源的浪費，因此各個部門機構(gòu)要配備管理人員，從實際出發(fā)，健全管理機構(gòu)。

3、體系要統(tǒng)一，工作重點要有所側(cè)重。針對企業(yè)的具體情況，不同性質(zhì)的企業(yè)需要遵循的管理體系是不同的，在電力施工管理過程中，是必須要遵循安全、質(zhì)量、環(huán)境體系的一體化的，從而確保施工過程都有序進行，保障勞動者的安全和健康，實現(xiàn)經(jīng)濟效益、社會效益和環(huán)境效益的統(tǒng)一。

5 結(jié)論

在電力施工管理過程中的需求變更的發(fā)展如果得不到很好的控制，項目就可能會陷入不能正常進行的狀態(tài)，變更的控制對項目正常有序的施工有著重要的影響，所以，如何正確的進行需求變更的控制，是一個重要的管理過程。定義需求變更是保證變更正常有序的一個有效的措施，并且需求變更流程使得變更施工能夠有計劃、有目的地進行，也只有這樣才能對整個施工過程進行良好的變更控制。

參考文獻

[1]范偉健.淺議電力施工管理中的需求變更管理[J].現(xiàn)代企業(yè)文化，2010（18）

[2]羅韋軍.淺析電力施工管理中的需求變更控制[J].中國電力教育，2006（5）

篇2

從理論上講，需求包括業(yè)務(wù)需求、用戶需求和功能需求。業(yè)務(wù)需求（Business Requirement ）反映了組織機構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標要求，用戶需求（User Requirement ）描述了用戶使用產(chǎn)品必須完成的任務(wù)，功能需求（Functional Requirement ）定義了開發(fā)人員必須實現(xiàn)的軟件功能。這些需求在項目執(zhí)行過程中都可能發(fā)生改變，即發(fā)生需求變更。

需求變更的表現(xiàn)形式也是多方面的，如老板臨時改變想法、項目預(yù)算增加或減少、客戶對功能的需求改變等。在IT項目中，變更可能來自方案服務(wù)商、客戶或產(chǎn)品供應(yīng)商等，也可能來源于項目組內(nèi)部，比如對項目人員的臨時離職會發(fā)生突然的需求等。

原因

1、需求信息錯位

在需求分析員確定客戶需求之前，毫無疑問要和客戶做好深度溝通。但是由于溝通渠道的限制，以及雙方能力、教育、習慣背景的限制，往往會出現(xiàn)信息溝通偏差，就是我們說的需求信息錯位。

當客戶向需求分析人員提出需求的時候往往是通過自己的想法用一般語言來表達的，而且是基于客戶對自己需求的理解角度上表達的，這就引起表達的結(jié)果對于真實的需求來說是一種僅僅從某個角度的一般描述，遠遠不能保證這樣的描述可以得到百分之百的正確理解。以前有個盲人摸象的故事，這個例子可以解釋一下為什么存在信息的偏差:顧客想要畫一頭大象，可是卻不清楚大象的身子、耳朵、四條腿以及尾巴是什么具體樣子，只能描述出這幾個部分大致像什么。于是顧客告訴分析員，“我要的是大象，身子象一堵墻，耳朵象扇子，四條腿象四根柱子，尾巴象繩子”。分析員聽到這些，就按照自己對墻、扇子、柱子、繩子的理解畫出了“大象”。

結(jié)果可想而知。然而這種現(xiàn)象在軟件項目需求變更中并不少見的。

這里面還有一個細化工作的問題。細化工作是一般由需求分析人員完成，一般是根據(jù)客戶提出的描述性的、總結(jié)性的文檔去細化客戶需求，將這種需求細化到一定程度后，就可以提取其中的一個個細小的功能，并給出描述。

但是不能光靠分析員做細化工作，還應(yīng)該把這些細化過的功能描述與客戶繼續(xù)深入地溝通，否則以后將會發(fā)生因為細化而引起的不能適應(yīng)范圍的問題，比如原來是手工填入的數(shù)據(jù)，要改成根據(jù)信息系統(tǒng)計算出來，而原來的一個屬性的描述要變成描述一個實體等。

2、建設(shè)期的溝通局限性

現(xiàn)實中，一個大中型系統(tǒng)的建設(shè)可能要持續(xù)較長的一段時間。在整個建設(shè)內(nèi)，當客戶提出要求時，因為不能看到系統(tǒng)的運行情況，客戶和開發(fā)商雙方就會認為需求溝通方面不存在什么分歧，然而事實上還常常會有需求最終期限的問題，此時開發(fā)商就已經(jīng)開始工作了。

最后當客戶從開發(fā)商那里拿到差不多可以試用的產(chǎn)品時候，因為現(xiàn)在可以實際操作，他就會對現(xiàn)實的系統(tǒng)提出很多問題，就是我們說的需求變更，比如系統(tǒng)的界面、操作、功能、性能等方面。

3、客戶所在環(huán)境的改變

當前客戶的運營情況不確定，有可能客戶行業(yè)的競爭度高，需要隨時做出調(diào)整和反應(yīng)，那么他們自然會經(jīng)常提出需求變更的要求;也有可能客戶所在的行業(yè)操作不規(guī)范，本身存在很多人為因素，這時候開發(fā)變更是需要隨時準備應(yīng)變。

一般說來客戶會要求改變界面，改變操作方式，甚至改變業(yè)務(wù)，客戶甚至會說:“當時我是那樣要求的，不過現(xiàn)在我們的業(yè)務(wù)調(diào)整了?！边@一切都是由行業(yè)大環(huán)境成的，所以對于這方面的需求變更必須要有一定的預(yù)測措施。

4、開發(fā)商的系統(tǒng)升級

為適應(yīng)市場需求，或是由于競爭等因素，開發(fā)商自身會有可能存在進行開發(fā)系統(tǒng)版本的升級或性能改進、設(shè)計修正的要求，因此會出現(xiàn)需求變更。這時誰也無法繞開這個問題。

從上面的分析可以看出，就算分析人員和客戶之間不存在理解分歧，客戶對于實際的系統(tǒng)還是會提出一些個人意見，就算沒有個人意見，他們自己的業(yè)務(wù)會變化或環(huán)境發(fā)生變化，這些都是無法避免的，所以項目團隊，或者說是開發(fā)商不要夢想會存在多么理想的需求分析，應(yīng)該從一開始就要有客戶需求變更一定會存在的準備。

代價

任何項目只要存在某個方面變更，那么就要付出對應(yīng)的代價。需求的變更通常意味著需求的增加，同時也意味著相應(yīng)的代價。當客戶提出新需求的時候，項目開發(fā)人員應(yīng)該分析這些新需求對項目現(xiàn)階段帶來的風險，得出雙方實現(xiàn)變更需求所需要的成本，包括時間、人力、資源等方面。

同時，在評估代價、與客戶討論的過程中，要讓客戶了解變更的后果，變更之后面臨最大的問題就是項目延期，讓客戶一起做是否繼續(xù)修改還是要接受修改后果的決策。這樣就會出現(xiàn)三種可能:

1、客戶接受延期的后果，開發(fā)人員按客戶要求做出修改，讓客戶知道為此需要付出延期的代價;

2、客戶認為代價太大，那么開發(fā)人員就不必修改了，可以記錄下需求，待到下一版本再做修改;

3、客戶不接受變更的代價，導(dǎo)致項目夭折。

所以變更引起的后果一定要和客戶溝通，確保客戶了解后果。如果客戶不知道項目開發(fā)人員為變更付出的代價，對他們的辛苦便難以體會，以致沒完沒了的提出新的變更。

然而對于這樣的現(xiàn)狀，我們該怎么辦呢？

積極應(yīng)對

1、完善軟件項目需求變更的管理

需求變更管理就是要把項目的需求變更對項目的負面影響降到最低，即不為消除，只為減少。需求變更的出現(xiàn)主要是因為在項目的需求確定階段，用戶往往不能確切地定義自己需要什么。

這時，如果開發(fā)團隊缺少明確的需求變更控制過程或采用的變更控制機制無效，或不按變更控制流程來管理需求變更，那么很可能造成項目進度拖延、成本不足、人力緊缺，甚至導(dǎo)致整個項目失敗。

當然，即使按照需求變更控制流程進行管理，由于受進度、成本等因素的制約，軟件質(zhì)量還是會受到不同程度的影響。但實施嚴格的軟件需求管理會最大限度地控制需求變更給軟件質(zhì)量造成的負面影響。

2、項目啟動階段的變更預(yù)防

應(yīng)對變更應(yīng)該是從項目啟動的需求分析階段就開始了。 首先就是要和客戶有一個深度溝通的過程，然后再做需求細分，做需求分析，同時在做這些的時候和客戶實時溝通。

對一個需求分析做得很好的項目來說，基準文件定義的范圍越詳細清晰，雙方的分界線也就越清晰，所以用戶和項目經(jīng)理扯皮的幌子就越少了。假如需求沒做好，基準文件里的范圍含糊不清，被客戶抓住空子，往往要付出許多無謂的犧牲。

如果需求做得好，文檔清晰且又有客戶簽字，那么后期客戶提出的變更就超出了合同范圍，需要另外收費，這樣就可以彌補一下項目開發(fā)團隊的損失。所以只要前面的需求分析做好了后面就會一帆風順了。

3、項目實施階段的需求變更

項目的實施過程中，需求變更是必然的，但是同時也是可控的、有益的。項目實施階段的變更控制需要做的是分析變更請求以及評估變更可能帶來的風險和修改基準文件。主要從以下幾點考慮:

1）需求要與投入有聯(lián)系，如果需求變更的成本由開發(fā)方來承擔，則項目需求的變更就成為必然了。所以，無論是開發(fā)方還是出資方在項目開始前都要明確一條:需求變，軟件開發(fā)的投人也要變。

2）需求的變更要經(jīng)過出資者的認可，這樣才會對需求的變更有成本的概念，能夠慎重地對待需求的變更。

3）小的需求變更也要經(jīng)過正規(guī)的需求管理流程，否則會積少成多。冰凍三尺非一日之寒。在實踐中，人們往往不愿意為小的需求變更去執(zhí)行正規(guī)的需求管理過程，認為降低了開發(fā)效率，浪費了時間，這樣就使需求逐漸變?yōu)椴豢煽?，甚至?dǎo)致項目的失敗。

4、項目收尾階段的總結(jié)

能力的提高往往不是從成功的經(jīng)驗中來，而是從失敗的教訓中來。項目開發(fā)團隊要提高對項目總結(jié)的重視，以從以前的項目中吸取教訓。

鏈 接

實施需求變更管理的的原則：

建立需求基線；

制定簡單、有效的變更控制流程，并形成文檔；

成立項目變更控制委員會或相關(guān)職能的類似組織，負責裁定接受哪些變更；

需求變更一定要先申請然后再評估，最后經(jīng)過與變更大小相當級別的評審確認；

篇3

一番景象。

自上而下

需求變更是軟件開發(fā)人員面臨的最大難題，很少有一個項目能從頭至尾保持同樣的需求。因此，可跟蹤性是所有軟件開發(fā)流程的基礎(chǔ)部分，它可以及時發(fā)現(xiàn)流程中的問題，并及時修復(fù)。統(tǒng)計表明，如果在需求收集階段修復(fù)一個缺陷需花費1美元，那么在設(shè)計階段修復(fù)該缺陷就需花費兩美元。依此類推，直至產(chǎn)品投入使用后才發(fā)現(xiàn)該缺陷，修復(fù)所需的費用將增至69美元。

通常情況下，跟蹤通過自上而下的方法得以實現(xiàn)，即從需求定義開始，經(jīng)過執(zhí)行、構(gòu)建、組裝直到交付工作。自上而下的跟蹤、報告有助于項目經(jīng)理和測試人員在開發(fā)流程中協(xié)調(diào)分配、規(guī)劃開發(fā)和監(jiān)控狀態(tài)。自上而下方法的核心是，確保正確管理和跟蹤需求變更，保證軟件代碼的變更與需求變更同步。

形成閉環(huán)

但是，對于大多數(shù)質(zhì)量、審計和測試驗證程序而言，自上而下這種跟蹤形式仍有不足，因為它不能分析實際生產(chǎn)的產(chǎn)品，也就無法確保按計劃交付預(yù)期的需求、修復(fù)或請求，至少在開銷極大的測試階段之前無法完成上述任務(wù)。在此背景下，閉環(huán)跟蹤的方法應(yīng)運而生。所謂閉環(huán)跟蹤就是將自上而下和自下而上兩種方法結(jié)合在一起。自下而上的方法是通過有效的需求驅(qū)動開發(fā)流程來控制變更的執(zhí)行，跟蹤每個開發(fā)任務(wù)。此方法使用先進的構(gòu)建分析和報告功能來實現(xiàn)，使得項目主管和測試人員可以在構(gòu)建或測試階段有效實施錯誤修復(fù)。

閉環(huán)跟蹤的優(yōu)勢在于可以確保最后交付的代碼符合客戶的需求；開發(fā)人員可對流程中的各種變更進行全面評估，從而提高項目管理的可見性，增強項目管理的可預(yù)測性；有助于提高開發(fā)產(chǎn)品質(zhì)量，提高客戶滿意度；推動符合能力成熟度模型集成(CMMI)標準的過程改進，有助于企業(yè)降低研發(fā)投入成本，加快投入產(chǎn)出進程。

篇4

通過對每一次收養(yǎng)過程進行嚴格的流程控制，動物保護協(xié)會最大程度上保護了動物的權(quán)利和人類的安全。其實流程存在于人類工作和生活的每一個地方，尤其是多人協(xié)作的情況，為了保證行動的最佳效果，減少失誤，最佳的流程往往會被固定下來。不要小看流程固化的重要性，即使任何一個簡單的活動，在不斷的重復(fù)和大負載情況下，沒有固定的執(zhí)行流程，出錯的機會還是很大的。

用流程應(yīng)對變更

復(fù)雜的軟件開發(fā)通常需要大量的人員參與，這其中流程的作用至為重要，尤其是對于開發(fā)過程中的各種變更，例如需求的變更、軟件版本的變更等，更需要一套嚴密的流程體系來管控，才能最終保證變更被成功控制，而不是演變成為災(zāi)難。

軟件開發(fā)不同于傳統(tǒng)意義的工程技術(shù)(如建筑、機械等)，市場變化以及技術(shù)上的高速更新都注定了軟件變更是非常頻繁并且是不可避免的，可以說變更是軟件開發(fā)的基石。一方面在軟件開發(fā)環(huán)境下的內(nèi)部活動以新特性、新功能增強以及缺陷修復(fù)等方式不停地制造著變更，另一方面外部因素，例如新操作環(huán)境，新工具的集成，工程技術(shù)和市場條件的改善等以另一種力量驅(qū)動著變更，而管理變更的能力就成為項目成敗的關(guān)鍵。

作為國第一家在紐交所上市的軟件企業(yè)，東南融通在不斷發(fā)展壯大過程中就遇到了這種困擾。東南融通在全國設(shè)有3個研發(fā)中心、5個技術(shù)交付中心和70個服務(wù)機構(gòu)，為了保證異地開發(fā)、交付團隊的協(xié)同工作，提高軟件質(zhì)量，2006年，東南融通決定引入成熟的軟件配置、變更工具。

首先在處理需求變更上，東南融通副總裁葉壽生告訴記者，在之前在沒有成熟的執(zhí)行流程情況下，客戶A提出了需求，開發(fā)人員趕快在軟件中進行修改，很快B又提出了一個不同的需求，而這兩個需求可能是沖突的，開發(fā)人員就無所適從，同時混亂的修改過程使得最終的軟件質(zhì)量也無法確保。

而在引入了IBM Rational的配置及變更管理套件ClearCase和ClearQuest后，需求變化得到了很好的控制。需求變更提出后，被提交到變更委員會進行評估，以確定這個變更是否可以實現(xiàn)，需要多長時間、多少投入，同時經(jīng)過分析后的需求也更加清晰，更易于開發(fā)者實現(xiàn)，

另外在版本管理上，采用了ClearCase和ClearQuest后，開發(fā)團隊，尤其是異地協(xié)作的開發(fā)團隊使用的版本得到了統(tǒng)一。葉壽生介紹，在每一個項目實施完成后都會形成一個不同的軟件版本，而這些版本對應(yīng)哪個客戶，之前都要靠人的腦子來記憶，結(jié)果很在維護的時候就容易造成混亂，不知道該在哪個版本上進行更新和重新部署。

東南融通測試中心經(jīng)理翁旭驥詳細地介紹了身處廈門和上海的開發(fā)團隊和身處廈門的測試團隊是如何通過ClearCase和ClearQuest進行異地協(xié)同開發(fā)的。

首先，廈門的測試人員測試并提交了多個缺陷，系統(tǒng)會在指定的時間自動雙向同步廈門和上海的ClearQuest數(shù)據(jù)庫和ClearCase的VOB(Versioned。bJect Base)庫。

當ClearQuest數(shù)據(jù)庫接收到數(shù)據(jù)后，系統(tǒng)自動發(fā)送郵件給上海該項目的缺陷分配人，缺陷分配人收到郵件通知后，會登錄ClearQuest并對待分配缺陷進行分配。當缺陷分配完后，修改缺陷的開發(fā)者就會收到缺陷處理的郵件通知。

當開發(fā)人員處理完分配給他的缺陷后，便會在ClearQuest中執(zhí)行Resolve操作，于是缺陷自動變成“已解決”狀態(tài)，等待測試人員驗證。

當執(zhí)行同步的時間到達后，系統(tǒng)自動將ClearQuest數(shù)據(jù)庫以及ClearCase的VOB庫進行雙向同步。在同步完成后，廈門的測試人員會收到驗證缺陷的郵件通知。測試后如果缺陷仍然存在，上海的開發(fā)人員就可以看到這條被駁回的缺陷，如果修改后該版本的程序驗證通過，廈門的管理員就會在集成流上打一條基線，這條基線標識的版本即測試通過的版本。

ClearCase帶來的對軟件開發(fā)流程的嚴格管控，工作流程得到了固化和自動執(zhí)行，免去了人工控制流程中可能出現(xiàn)的遺漏或拖延。同時，ClearQuest會對開發(fā)過程中的所有變更進行詳細的記錄，并要求修改者注明修改理由，并能夠追溯到開發(fā)中修改的任意一個版本，讓每一次變更都有跡可循。更值得一提的是，ClearCase還同時適用于Linux、Unix和Windows平臺，最大程度地消除了平臺之間的鴻溝，確保了團隊合作的親密無間。

在導(dǎo)人了Rational UCM以后，東南融通擁有了更嚴格而順暢的開發(fā)流程，不但能夠有效掌控開發(fā)周期和質(zhì)量，也能有效降低維護成本，數(shù)據(jù)統(tǒng)計方面，更節(jié)省了50％以上的人力投入。

不僅是工具，更是平臺

翁旭驥介紹，起初，測試部門采用了好幾套開源的工具，但是這些工具彼此之間是割裂的，版本控制和缺陷跟蹤彼此無法溝通，這給項目管理造成了很多的麻煩。而之所以看重IBM Rational的配置及變更管理套件，翁旭驥認為他們主要看中了兩個方面，首先是其中蘊含的優(yōu)秀的管理思想和最佳實踐，其次是平臺化的工具和強大的二次開發(fā)能力。

ClearCase和ClearQuest首先是Rational的一部分，它滲透進了Rational RUP(統(tǒng)一軟件開發(fā)過程)的思想，變更被置于整個軟件工程的視野下來考慮。另外針對變更管理，IBM提出了UCM(統(tǒng)一變更管理)的解決方案，具體產(chǎn)品就是Rational ClearCase和ClearQuest。

UCM是第三代的配置管理解決方案，在UCM中有兩個重要概念：活動管理和工件管理，它們提供對所有類型的變更請求(例如產(chǎn)品缺陷、增強請求、文檔變動等)的捕獲和跟蹤，還有對貫穿項目生命周期的所有工件的管理框架。

UCM通過抽象層次的提升簡化了軟件開發(fā)，從而使得軟件開發(fā)團隊從更高的層次，根據(jù)活動(activity)來管理變更。通過Rational UCM，一個開發(fā)活動可以自動地同其變更集(封裝了所有用于實現(xiàn)該活動的項目工件)相關(guān)聯(lián)，這樣避免了管理人員手動跟蹤所有文件變更。

篇5

[關(guān)鍵詞]項目管理軟件需求開發(fā)進度成本質(zhì)量管理模型

一、引言

軟件需求開發(fā)是軟件工程的一個重要環(huán)節(jié)，在軟件生命周期中的需求、設(shè)計、編碼、測試和維護等各個階段中，需求開發(fā)處于軟件工程的開始部分，它提供構(gòu)建軟件項目的根基，決定軟件開發(fā)成果滿足客戶需求的匹配程度。軟件需求開發(fā)環(huán)節(jié)的失誤會隨著開發(fā)進度的擴大而蔓延，資料表明，軟件項目中由于需求開發(fā)管理混亂而造成的返工開銷幾乎占了總開發(fā)的50％。本文應(yīng)用項目管理理論分析軟件需求開發(fā)階段的系統(tǒng)構(gòu)成，并設(shè)計管理模型來提高軟件需求開發(fā)的管理效率。

二、軟件需求開發(fā)管理過程

由于計算機技術(shù)的迅速發(fā)展，使得軟件需求具有模糊性、不確定性、變化性、主觀性等特點，并帶來軟件需求開發(fā)管理的復(fù)雜性。軟件需求開發(fā)是一定的組織利用有限的資源在規(guī)定的時間內(nèi)完成，可以作為項目來進行管理，其管理過程由需求獲取、需求分析、編寫軟件需求規(guī)格和需求驗證四個階段構(gòu)成。

1.需求獲取

需求獲取是在問題和最終解決方案之間架設(shè)橋梁，其主要任務(wù)是和用戶方的領(lǐng)導(dǎo)層、業(yè)務(wù)層人員進行溝通，獲取用戶的具體需求，并了解用戶的組織架構(gòu)、業(yè)務(wù)流程、硬件環(huán)境、軟件環(huán)境、現(xiàn)有的運行系統(tǒng)等具體情況，同用戶建立起良好的溝通渠道和方式。軟件需求獲取的方法有：與用戶交談，向用戶提問題；參觀用戶的工作流程，觀察用戶的操作；用戶工作的情景分析；現(xiàn)有系統(tǒng)的問題報告和改進要求，事件和響應(yīng)；市場調(diào)查和向用戶群體發(fā)調(diào)查問卷；與同行、專家交談，聽取他們的意見；分析已經(jīng)存在的同類軟件產(chǎn)品，提取需求；從現(xiàn)有產(chǎn)品或競爭產(chǎn)品的文檔中提取需求；從行業(yè)標準、規(guī)則中提取需求；從Internet上搜查相關(guān)資料等。

2.需求分析

需求分析主要通過建立業(yè)務(wù)模型的方式來描述用戶的功能需求，為客戶、用戶、開發(fā)方等不同參與者提供一個交流的渠道。業(yè)務(wù)模型可以映射出軟件產(chǎn)品的核心需求，即功能需求。功能需求應(yīng)描述軟件提供的功能和服務(wù)、對輸入的響應(yīng)，并描述特定條件下的系統(tǒng)構(gòu)成等。軟件產(chǎn)品本身可能還存在與業(yè)務(wù)無直接關(guān)系的非功能需求，具體與系統(tǒng)的總體特性有關(guān)，如可靠性、響應(yīng)時間、存儲空間等。非功能需求定義系統(tǒng)提供服務(wù)或功能的約束，包括時間約束、空間約束、開發(fā)過程約束及應(yīng)遵循的標準等。通常這兩類需求構(gòu)成軟件需求的總集。

3.編制軟件需求規(guī)格

軟件需求規(guī)格的編制是為了使用戶和軟件開發(fā)者雙方對該軟件的初始規(guī)定有一個共同的理解，使之成為整個開發(fā)工作的基礎(chǔ)，需求分析完成的標志就是提交一份完整的軟件需求規(guī)格說明書。軟件需求規(guī)格說明書以一種開發(fā)人員可用的技術(shù)形式闡述軟件必須提供的功能和具備的性能，以及必須考慮的限制條件。軟件項目客戶通過軟件需求規(guī)格了解軟件項目能夠提供的軟件產(chǎn)品，檢查軟件需求是否滿足需要；項目管理人員根據(jù)軟件需求規(guī)格制定項目的開發(fā)計劃和管理過程；軟件開發(fā)人員通過軟件需求規(guī)格理解要開發(fā)的產(chǎn)品及具體要開發(fā)的內(nèi)容；軟件測試人員通過軟件需求規(guī)格驗證軟件。

4.需求評審

編寫的軟件需求規(guī)格說明書還應(yīng)當進行需求評審，確保需求確定的科學性?？刹捎孟铝兄笜诉M行評審：(1)正確性:每條需求都正確代表構(gòu)建軟件系統(tǒng)所要完成的事情。(2)無歧義:每條需求只有一種解釋。(3)完備性:需求不能發(fā)生遺漏，應(yīng)全面考慮相關(guān)問題。(4)一致性:用戶需求必須和業(yè)務(wù)需求一致，功能需求必須和用戶需求一致。(5)重要性和穩(wěn)定性分級:現(xiàn)有資源不足以實現(xiàn)所有需求時，可以根據(jù)級別的高低決定實現(xiàn)的先后，舍棄一些級別低的需求以保證項目的按期交付。(6)可驗證性:需求分析是可測試的，只有系統(tǒng)的所有需求都是可以被測試的，才能夠保證軟件始終圍繞著用戶的需要，保證軟件系統(tǒng)是成功的。(7)可修改性:每一條需求都易于完整一致的進行變更，且不改變需求集的結(jié)構(gòu)和風格。(8)可跟蹤性:每條需求都是可溯源的，且存在一種機制使得在以后的工作中引用需求是可行的。(9)可理解性:用戶和開發(fā)人員都完全理解需求集的整體行為、所提供的功能及其中的每條需求的含義。

三、軟件需求開發(fā)管理模型

1.軟件需求開發(fā)管理模型構(gòu)建原則

軟件需求開發(fā)是一項復(fù)雜的系統(tǒng)工程，管理模型的構(gòu)建應(yīng)遵循下列原則:(1)程序性原則：軟件需求開發(fā)管理應(yīng)遵循固定的業(yè)務(wù)流程，可將其劃分為需求獲取、需求分析、編寫軟件需求規(guī)格和需求驗證四個階段，前一階段的工作完成后才能進入下一階段。(2)系統(tǒng)性原則：軟件需求開發(fā)要在限定的時間、成本條件約束下達到一定的質(zhì)量，實現(xiàn)軟件系統(tǒng)的最優(yōu)，要求管理遵循系統(tǒng)管理原則，實現(xiàn)目標最優(yōu)。(3)簡化性原則：化繁為簡，將模糊的、潛在的復(fù)雜問題明確化，以圖表的形式表示出，并以簡化的解決方案解決問題，便于項目管理。(4)平衡性原則：管理軟件需求開發(fā)的具體事務(wù)要有一定的側(cè)重。對于需求開發(fā)過程事項，應(yīng)根據(jù)影響大小分清主次，關(guān)鍵的事項或者事項里的某個多發(fā)問題點，著重管理，達到在管理上的主次平衡。(5)高效性原則:模型的設(shè)計必須以促進需求開發(fā)目標的實現(xiàn)為前提，提供給相關(guān)人員一個展示需求開發(fā)管理和有效解決方案的平臺。（6）時時控制性原則:及時控制需求開發(fā)過程中影響進度、成本、質(zhì)量等問題，及時發(fā)現(xiàn)解決沖突事件，做到事前、事中、事后控制，保證項目按時保質(zhì)保量完成。(7)動態(tài)性原則:開發(fā)中應(yīng)關(guān)注信息技術(shù)的發(fā)展，將先進的技術(shù)應(yīng)用到軟件需求開發(fā)中，并學習借鑒相關(guān)軟件需求開發(fā)的成果。

2．軟件需求開發(fā)管理模型

基于以上分析，本文構(gòu)建了軟件需求開發(fā)管理模型，見下圖：

該模型遵循了軟件需求開發(fā)的管理流程。啟動階段，軟件開發(fā)進行了可行性研究，軟件項目已立項，項目正式啟動。軟件需求開發(fā)管理階段是模型的主要部分，按照項目流程，依次劃分為需求獲取、需求分析、編寫軟件需求規(guī)格和需求驗證四個階段?？偨Y(jié)階段，對軟件需求開發(fā)管理進行總結(jié)，并進入到軟件程序設(shè)計階段。模型的核心部分是應(yīng)用項目管理的進度管理、成本管理、質(zhì)量管理，對軟件需求開發(fā)進行動態(tài)管理。進度管理就是制定出經(jīng)濟合理的進度計劃，然后在計劃執(zhí)行過程中，檢查實際進度與計劃進度之間的差異，并及時找出出現(xiàn)差異的原因，采取有效的補救措施，以確保項目按時按質(zhì)完成。進度管理應(yīng)加強溝通，掌握可能延誤進度的環(huán)節(jié)，并嚴格控制進度變更。成本管理就是對項目所需的成本情況進行詳細地分析和估算，編制資源需求計劃，并編制項目所需的成本估算和預(yù)算，在執(zhí)行過程中，采取相應(yīng)的措施對項目成本進行控制。成本管理應(yīng)嚴格控制加班、浪費等額外支出。質(zhì)量管理是為了保證項目的可交付成果能夠滿足客戶的需求，圍繞項目質(zhì)量而進行的計劃、協(xié)調(diào)和控制等活動，其具體內(nèi)容涉及質(zhì)量規(guī)劃、實施質(zhì)量保證和質(zhì)量控制。通過進度管理、成本管理和質(zhì)量管理，使軟件需求開發(fā)成為進度快、成本低和質(zhì)量合格的有機統(tǒng)一體。

該模型規(guī)范了軟件需求開發(fā)的業(yè)務(wù)流程，并在整個軟件需求開發(fā)的不同環(huán)節(jié)之間建立聯(lián)系，明確需求開發(fā)過程與自身各任務(wù)項之間以及項目其余環(huán)節(jié)所存在的各種聯(lián)系。模型各環(huán)節(jié)間的相關(guān)性、可追溯性保證了軟件項目需求開發(fā)過程，可以遵循統(tǒng)一的管理模式。該模型具備可配置性。每個軟件項目，都具有個性化管理需求，在進度管理、成本管理、質(zhì)量管理等方面有不同的要求，可以針對具體的開發(fā)團隊，項目要求，管理側(cè)重點，擴增相應(yīng)的管理模塊，將此模型推廣到任何一個軟件需求開發(fā)項目。

3.模型應(yīng)用

由于軟件需求開發(fā)具有復(fù)雜性，其主要表現(xiàn)為需求描述問題，明確表達需求較難確定，并且難以統(tǒng)一；需求完備問題，需求沒有遺漏，難以準確劃定系統(tǒng)范圍；需求的變更問題，需求變化是永恒，需求不可能是完備。模型應(yīng)用需做好以下工作：（1）文檔化管理。需求必須有文檔來記錄，該文檔必須是正確的，是經(jīng)過驗證的，是在受控的狀態(tài)下變更的。開發(fā)或管理人員常常會在含糊的情況下把認為是相對簡單的需求忽視而省略文檔記錄，其實未必簡單，只有想清楚、寫清楚、說清楚才說明已經(jīng)真正把需求整理清楚了，同時方便日后維護工作的展開。需求含糊的情況下要進行會議形式處理，并邀請相關(guān)人員參加進行需求澄清及確定，需求在進行多方確定后進行歸檔。同時軟件需求的復(fù)用率也是相當高的，可以避免升級時重新將需求再次獲取，只需要在原來的基礎(chǔ)上作為文擋需求復(fù)用升級處理。（2）審核評估需求變更，減少變更的影響。在管理軟件開發(fā)過程中，需求漸變是必然的，無論需求變化的程度如何，只要需求變更就必須進行評估。在需求變更之前必須由項目管理人員審核，再傳給開發(fā)人員進行評估等工作。管理人員必需依據(jù)對整套系統(tǒng)的了解程度分析需求變更過程中可能受影響的系統(tǒng)及受關(guān)聯(lián)的功能模塊，并制定積極應(yīng)對措施。(3)整體管理。應(yīng)識別、確定、結(jié)合、統(tǒng)一與協(xié)調(diào)軟件需求開發(fā)管理過程中所需要進行的各種過程和活動，保證進度、成本、質(zhì)量等各要素的相互協(xié)調(diào)。

四、結(jié)語

軟件需求開發(fā)在軟件項目管理中具有重要地位。本文應(yīng)用項目管理理論，設(shè)計了軟件需求開發(fā)管理模型。該模型遵循項目管理流程，將軟件需求開發(fā)劃分啟動、需求開發(fā)過程、總結(jié)三個階段，并將軟件需求開發(fā)過程劃分為需求獲取、需求分析、編寫軟件需求規(guī)格和需求驗證四個階段，模型應(yīng)用項目管理的進度管理、成本管理、質(zhì)量管理，對軟件需求開發(fā)進行動態(tài)管理，實現(xiàn)軟件需求開發(fā)項目目標最優(yōu)。該模型能夠提高軟件需求開發(fā)管理效率，確保軟件開發(fā)能夠按進度，低成本，高質(zhì)量地完成。

參考文獻：

[1]景慎艷:軟件項目需求管理的探索與實踐[J].電腦知識與技術(shù)，2008（27）

[2]左懷遠:軟件項目中的風險管理研究[J].世界科技研究與發(fā)展，2008（3）

[3]孫琦龍:加強軟件項目管理的實踐模式[J].科技信息，2008（7）

篇6

關(guān)鍵詞：測試風險管理；風險管理；軟件測試

中圖分類號：TP311文獻標識碼：A文章編號：1009-3044(2012)11-2518-03

軟件本身的復(fù)雜性以及測試本身的特性決定了測試活動實施過程中風險的大量存在，而風險會影響測試活動的成敗，嚴重時還可能導(dǎo)致整個項目的失敗。因此，對測試風險的管理越來越引起人們的重視。

1風險存在的必然性

軟件測試項目的風險來自于軟件和測試自身的特點。

1.1軟件的特點

1）軟件產(chǎn)品是不可見的：軟件項目的開發(fā)進度和軟件質(zhì)量管控過程是否符合標準很難衡量，使得軟件的管理也難于把握；

2）軟件生產(chǎn)過程形式多樣，不存在絕對正確的形式：不同的軟件開發(fā)項目，應(yīng)采取不同的或者特定的軟件開發(fā)過程。但在項目開發(fā)之初卻不能確定正確的形式，只能根據(jù)項目的特點和開發(fā)經(jīng)驗選擇，并在開發(fā)過程中不斷的調(diào)整，真正適合該軟件的開發(fā)過程只有在項目開發(fā)結(jié)束才能確定；

3）大型軟件項目往往是“一次性”：項目一次性的特點使得過去的經(jīng)驗不能被廣泛的借鑒。控制軟件管理風險的唯一途徑是設(shè)立監(jiān)測系統(tǒng)，開展有效的風險監(jiān)控和管理。

1.2測試的特點[1]

1）完全測試是不可能的：在有限的資源和時間條件下，找出所有的軟件缺陷和錯誤，使軟件趨于完美是不可能的，主要原因為是輸入量太大、輸出結(jié)果太多、路徑組合太多；

2）測試具有病毒一樣的免疫性：軟件缺陷具有病毒一樣可怕地免疫性，對其采用的測試越多，免疫能力就越強，軟件測試工程師想要找出更多軟件缺陷就更加困難；

3）測試是“泛型概念”：軟件測試涵蓋需求分析、概要設(shè)計等在內(nèi)的整個軟件生命周期，以確保每一個階段都經(jīng)住考驗；另外，測試自身也需要來自第三方的評估和監(jiān)督，以確保測試的可靠性；

4）80-20原則：80%的軟件缺陷常常生存在20%的軟件模塊中。我們在系統(tǒng)分析、系統(tǒng)設(shè)計、系統(tǒng)實現(xiàn)階段只能檢測和規(guī)避80%的軟件缺陷。在下一步的系統(tǒng)測試中，可以幫助我們找到剩余缺陷的80%，剩余4%的缺陷只有在系統(tǒng)交付使用后經(jīng)過大范圍長時間使用后才會暴露出來。所以，軟件測試只能保證盡可能多的發(fā)現(xiàn)軟件缺陷，卻無法保證能夠發(fā)現(xiàn)所有的軟件缺陷；

5）缺陷的必然性：由于軟件測試中錯誤的相關(guān)性，并非全部的軟件缺陷都能夠被成功修復(fù)。在缺陷的修復(fù)過程中會不可避免的引入新的錯誤，另外，在修復(fù)的過程中，我們往往還會受到時間、成本等各方面因素的限制，導(dǎo)致最終不可能完全的修復(fù)所有的軟件缺陷。

2風險的評估

風險的管理基本的內(nèi)容有兩項：風險評估和風險控制。

風險評估是在風險識別的基礎(chǔ)上，對識別出來的風險進行評估，主要從下列四個方面入手[2]：

1）風險概率分析，即對風險發(fā)生的可能性設(shè)置一個尺度，如很高、較高、中等、較低、很低等；

2）描述風險并預(yù)測風險發(fā)生后，對軟件產(chǎn)品和測試結(jié)果可能產(chǎn)生的影響或造成的損失等；

3）確定風險評估的正確性，要對每個風險的表現(xiàn)、范圍、時間做出盡量準確的判斷；

4）根據(jù)損失（影響）和風險概率的乘積，來確定風險的優(yōu)先級別，定制風險應(yīng)對措施。

3風險控制的原則

風險控制是建立在風險評估的基礎(chǔ)之上的，主要工作原則有[2]：

1）針對有些可以避免的風險，例如測試用例執(zhí)行率未達到100%，可以通過制定測試規(guī)范，要求測試人員嚴格按照測試用例執(zhí)行測試，并記錄用例執(zhí)行情況，來避免該類風險；

2）有些不可避免的風險，采取措施降低風險，尤其是等級較高的風險，將其轉(zhuǎn)化為不會引起嚴重后果的等級較低的風險；

3）凡事預(yù)則立，事先做好風險管理計劃，當風險成為現(xiàn)實時，可以更好的避免、轉(zhuǎn)移或減低風險；

4）對風險的處理制定應(yīng)急、高效的解決方案。

4軟件測試風險分析與管理方法

軟件生命周期包括問題定義及規(guī)劃、需求分析、軟件設(shè)計、程序編碼、軟件測試和運行維護六個階段，而軟件測試前面的任何一個環(huán)節(jié)的不嚴謹都可能增加軟件測試活動的風險。軟件測試活動中也存在各種各樣的風險，其中常見風險有需求變更風險、測試過程風險、測試組織和人員風險。

4.1需求變更風險

在軟件測試項目尤其是歷時較長的大項目的實施過程中，總會不可避免的出現(xiàn)需求的變更。如何把握好需求的變更，減少需求變更帶來的風險，成為影響整個項目成敗的關(guān)鍵。

4.1.1軟件測試項目需求變更的管理[3]

1）設(shè)定需求變更的參考標準，將需求基線。當軟件測試項目組確認要產(chǎn)生需求變更時，用標準的變更申請表格將委托方的變更申請記錄存檔。每次的變更都應(yīng)在需求基線的基礎(chǔ)上進行。

2）軟件測試項目組收到委托方提交的需求變更申請后，成立項目變更控制委員會(CCB)，負責對項目變更所帶來的影響進行評估，包括測試項目的人力、物力、資金、管理、時間、質(zhì)量、工作負荷等內(nèi)部因素，以及資本、委托方要求的完工時間、項目負債情況等各個方面的影響。

3）變更確定后，選擇可行的實施方案。為了將項目變更的風險降低到最小，力求在盡可能小的變動幅度內(nèi)對測試項目的目標、預(yù)算、團隊以及項目的進度等主要的因素進行微調(diào)。

4）需求變更后，要重新確定新的需求基線；受影響的軟件計劃、產(chǎn)品、活動等也要進行相應(yīng)的變更，以保證和最新需求的一致性。

4.2測試過程風險

在測試工作中，主要的風險有[4]：

1）需求的臨時或突然變化，導(dǎo)致設(shè)計的修改和代碼的重寫，使得測試時間不夠；

2）測試用例沒有得到100%的執(zhí)行；

3）質(zhì)量需求或產(chǎn)品的特性理解不準確，造成測試范圍分析的誤差，結(jié)果某些地方始終測試不到或驗證的標準不對；

4）質(zhì)量標準不都是很清晰的，如適用性的測試，仁者見仁、智者見智；

5）測試用例設(shè)計不到位，忽視了一些深層次的邏輯、邊界條件、用戶場景等；

6）測試環(huán)境與實際生產(chǎn)環(huán)境一般情況下都不可能完全一致，造成測試結(jié)果的誤差；

7）有些缺陷出現(xiàn)頻率不是百分之百，不容易被重現(xiàn)；如果代碼質(zhì)量差，軟件缺陷很多，被漏檢的缺陷可能性就大；

8）回歸測試一般是選擇性的執(zhí)行部分測試用例，必然帶來風險。

前面3種風險可以通過前期調(diào)研人員或測試人員與客戶加強溝通或者制定嚴格的制度來避免的，而針對有些不可避免的風險，采取一些有效的測試風險控制方法來盡量降低風險，例如測試環(huán)境不正確，可以通過事先列出要檢查的所有條目，在測試環(huán)境設(shè)置好后，由其他人員按已列出條目逐條檢查；針對程序中總是存在的“未發(fā)現(xiàn)的缺陷”，可以通過提高測試用例的覆蓋率（如達到99.9%）來降低這種風險；針對經(jīng)常出現(xiàn)的產(chǎn)品前夕，在某個不是很重要的新功能上發(fā)現(xiàn)一個嚴重缺陷的問題，可以通過去掉該新功能來轉(zhuǎn)移因為修改此缺陷可能引起的某個原有功能上的缺陷的風險。回歸測試只執(zhí)行部分用例帶來的風險是可以避免的，但出于時間或成本的綜合考慮，一般是存在的。

提前做好風險管理計劃和風險控制策略，可以更好的避免、轉(zhuǎn)移或者降低風險：

1）在執(zhí)行項目計劃，做資源、時間、成本等的估算時，要留有余地；

2）在項目開始前，制定風險管理計劃，重點把握邊界上可能會出現(xiàn)變化、難以控制的因素；

3）重視人員隊伍的培養(yǎng)，對每個關(guān)鍵性技術(shù)崗位人員培養(yǎng)后備人員，確保項目不受人員流動的嚴重影響；

4）制定工作機制和文檔標準，保證文檔的及時產(chǎn)生，便于項目知識的分享和移交；

5）對工作進行相互審查，不同的測試人員在不同測試模塊上相互調(diào)換，及時發(fā)現(xiàn)問題；

6）日常跟蹤所有工作過程，及時發(fā)現(xiàn)風險的跡象，以避免風險。

4.3測試組織和人員風險

4.3.1測試組織風險

測試人員不獨立于開發(fā)者，測試人員獨立與開發(fā)者的程度將影響測試結(jié)果。

1）成立專門的測試組織；

2）制定專門的測試管理流程和質(zhì)量保證手冊，規(guī)范測試過程，保證測試的質(zhì)量；

3）委托專門的測試組織執(zhí)行測試活動。

4.3.2人員風險[4]

測試項目尤其是周期較長的項目幾乎不可避免的要面臨人員的流動，從而增加項目失敗的風險系數(shù)。及早預(yù)防是降低這種人員風險的基本策略。下面從第三方測試的角度具體介紹一下人員風險的控制方法：

1）指派一名項目副經(jīng)理或項目經(jīng)理助理協(xié)調(diào)項目經(jīng)理管理項目工作，降低關(guān)鍵崗位人員流動的風險。但是一般只建議在項目經(jīng)理這種比較重要的崗位采用這種冗余復(fù)制的策略來預(yù)防人員風險，否則將大大增加項目成本；

2）建立良好的文檔管理機制，包括項目組進度文檔，個人進度文檔（測試日志）、版本控制文檔、整體技術(shù)文檔（測試策略、測試用例）、個人技術(shù)文檔（測試執(zhí)行記錄、缺陷報告）等。一旦出現(xiàn)人員的變動，替補組員能夠根據(jù)完整的文檔盡早接手工作；

3）控制項目團隊中外包或兼職人員的比例，且項目核心部分的工作應(yīng)該盡量由全職人員來擔任，以減少兼職人員對項目組人員不穩(wěn)定性的影響；

4）加強測試項目組內(nèi)的技術(shù)交流，定期召開項目例會，使測試組成員能夠相互熟悉對方的工作和進度，能夠在必要的時候接替對方工作；

5）為項目測試工作的開展提供盡可能好的基礎(chǔ)環(huán)境，比如待遇、項目組內(nèi)良好的人際關(guān)系和工作氛圍等。良好的工作環(huán)境對于穩(wěn)定項目組人員以及提高生產(chǎn)效率都有不可忽視的作用。

4.3.3外包人員風險

1）制定相關(guān)的管理流程文件，規(guī)范外包人員的活動，防患于未然，規(guī)避外包風險；

2）通過外派監(jiān)管團隊的方式對整個測試活動進行監(jiān)控；

3）通過對測試活動的中間交付物進行檢查保證測試的質(zhì)量，例如：對設(shè)計的測試用例進行評審、對編寫的測試代碼進行抽查、檢查測試執(zhí)行的日志等；

4）對于外包測試的形式，除了避免承包方項目人員的泄密，還要注意雙方數(shù)據(jù)傳輸過程中的信息保密。在采用外包測試的時候，不可避免地要進行各種信息的傳送，可能是雙方的電話、E-Mail交流，也可能是軟件版本的傳輸，在條件允許的情況下要盡量使用VPN等方式。如果有必要，對傳輸?shù)臄?shù)據(jù)要進行加密。

5結(jié)束語

測試過程中的風險總是存在的，該文對測試活動中主要的風險進行識別和控制，并確定針對性措施，避免風險發(fā)生，或者把風險降到最小。要想做好風險管理工作，就必須徹底改變測試項目的管理方式，建立防患于未然的管理意識，并結(jié)合具體的實踐工作不斷地分析遇到的風險，總結(jié)各種風險的應(yīng)對措施，指導(dǎo)實踐，降低產(chǎn)品質(zhì)量風險。

參考文獻：

[1]張華.軟件測試的常識[EB/OL].省略/html/2010-01-13/100144.htm.

篇7

近年來，中國的汽車市場迎來了爆發(fā)式的增長，從2010年開始，中國一躍成為世界規(guī)模第一的汽車生產(chǎn)國，成為全球最具活力的汽車市場之一，全國各省市先后出臺了促進汽車產(chǎn)業(yè)發(fā)展的規(guī)劃，各大汽車廠商也紛紛跑馬圈地，產(chǎn)能成倍地增長。這意味著汽車廠商在迎來千載難逢的市場機遇的同時，也必將面臨著激烈的市場競爭。

本文將通過對北京汽車股份有限公司（以下簡稱“北京汽車”）零部件采購現(xiàn)狀的分析，運用項目管理的方法來規(guī)劃和實施采購信息化系統(tǒng)建設(shè)，同時和大家分享項目實施過程中在范圍管理、溝通管理和質(zhì)量管理方面的一些經(jīng)驗。

一、北京汽車零部件采購現(xiàn)狀

2010年9月，北京汽車正式成立，雖然有不少有經(jīng)驗、背景的人才加入，但是對北汽自主品牌來說，從研發(fā)、采購到生產(chǎn)的全過程還是像個蹣跚學步的小孩，一點點在摸索中成長。就零部件采購來說，其存在的主要問題是：整車廠以自身利益為中心, 不顧零部件企業(yè)的實際情況和利益, 用零部件企業(yè)的大量庫存來換取自身的零庫存, 并把價格戰(zhàn)的壓力推向零部件企業(yè), 導(dǎo)致汽車行業(yè)整體供應(yīng)鏈競爭力減弱；信息溝通的手段和工具落后，主要還是采用傳統(tǒng)方式( 電話、傳真、信件、E - mail）與供應(yīng)商進行信息交流, 使信息不能及時傳達, 導(dǎo)致采購效率低下, 企業(yè)對市場的反應(yīng)速度遲滯, 造成生產(chǎn)與市場的脫節(jié), 而供應(yīng)商為了適應(yīng)由于信息不暢造成的需求變化, 只得加大庫存量, 導(dǎo)致流動資金占用過多；零部件定點和開發(fā)認可進度風險管控困難，成本對標與統(tǒng)計完全靠手工臺賬處理，人員流失導(dǎo)致數(shù)據(jù)信息流失，這種狀態(tài)已經(jīng)嚴重制約了采購業(yè)務(wù)的開展，尤其是在整車行業(yè)競爭如此激烈的大環(huán)境下，要求規(guī)范采購業(yè)務(wù)流程、提高工作效率、與供應(yīng)商協(xié)同合作、共同發(fā)展的呼聲越來越高，采購信息化管理也就勢在必行。

二、北京汽車采購信息化系統(tǒng)分階段實施計劃

2011年下半年，在北京汽車各方領(lǐng)導(dǎo)的大力支持下，采購中心協(xié)同信息技術(shù)部開始規(guī)劃零部件采購信息化系統(tǒng)，即SRM（Supplier Relationship Management，供應(yīng)商關(guān)系管理）系統(tǒng)，這個系統(tǒng)是一種不斷優(yōu)化供應(yīng)商選擇，縮短采購周期，貫徹集中采購，并實現(xiàn)與供應(yīng)商建立和維持長久、緊密伙伴關(guān)系的管理思想和軟件技術(shù)解決方案。筆者作為該項目的項目經(jīng)理有幸參與了整個規(guī)劃和實施過程。根據(jù)采購實際業(yè)務(wù)開展的緊迫程度，將系統(tǒng)規(guī)劃實施分成三個階段進行，具體安排見下表。

三、北京汽車采購信息化系實施過程的管理模式

1.項目組織類型選擇

由于采購SRM系統(tǒng)開發(fā)與實施涉及多個部門，如生產(chǎn)部門、零部件采購部門、供應(yīng)商管理部門、財務(wù)部門、信息技術(shù)部、軟件開發(fā)商等，根據(jù)項目需要每個部門需要安排一名關(guān)鍵用戶，對參與項目的關(guān)鍵用戶的要求是對部門業(yè)務(wù)熟悉且表達能力強，同時需求調(diào)研階段和測試階段需要全程參與，其余時間還是要參與到部門事務(wù)中去，所以項目的組織類型選擇矩陣式管理。矩陣式管理較其他組織結(jié)構(gòu)相比，至少有三大優(yōu)點：一是提高工作效率，由于采用了靈活的組織結(jié)構(gòu)，在資源上進行了共享，當項目出現(xiàn)的時候，可以馬上調(diào)集與之相匹配的資源，組建跨功能部門的項目團隊，提高了團隊執(zhí)行力，減少了溝通環(huán)節(jié)，加快了信息的共享，提高了反應(yīng)速度，矩陣式管理使各個部門的管理聚焦到公司的業(yè)務(wù)發(fā)展上，更加有利于公司的戰(zhàn)略實施；二是資源得到共享，在矩陣式的組織結(jié)構(gòu)中，各個部門的資源得到了共享，使資源得到了充分的利用，減少了以前出現(xiàn)的“忙的忙死，閑的閑死”的情況，根據(jù)研究表明，采用矩陣式的管理模式比采用傳統(tǒng)組織結(jié)構(gòu)的管理模式要減少20%的資源；三是更加有利于人才的發(fā)展，采用矩陣式管理模式并不會影響到人才的晉升通道，而且采用跨部門的協(xié)作模式，有利于提高員工的綜合能力的培養(yǎng)。矩陣式管理更加有利于人員的團隊合作精神，避免了以前的部門本位主義。

2.項目的范圍管理

項目范圍是指為了達到項目目標，項目所規(guī)定要完成的工作及過程。利益相關(guān)方必須在產(chǎn)品方面達成共識，也要在如何完成這一項目達成一致的意見。項目范圍管理是指對項目包括什么與不包括什么定義與控制的過程。這個過程用于確保項目團隊和利益相關(guān)者對作為項目結(jié)果的項目產(chǎn)品以及生產(chǎn)這些產(chǎn)品所用到的過程有一個共同的理解，簡單地說，項目范圍管理就是為項目劃定一個界限，劃定哪些方面是屬于項目應(yīng)該做的，哪些是不應(yīng)該包括在項目之內(nèi)的，定義項目的工作邊界，確定項目的目標和主要的項目可交付成果。

針對SRM項目實施來說，需求調(diào)研階段生成的需求文檔就是對系統(tǒng)開發(fā)范圍的界定，這個也是整個項目實施中的重點和難點，一般會占整個開發(fā)周期三分之一的時間?！澳サ恫徽`砍柴工”，前期需求越明確，后續(xù)開發(fā)返工才會越少，進度才越有保障。否則有可能開發(fā)出來的產(chǎn)品和業(yè)務(wù)部門想要的內(nèi)容南轅北轍，項目只能以延時或是失敗告終。需求調(diào)研階段，首先根據(jù)立項報告中的功能模塊定義，規(guī)定好每個模塊的調(diào)研時間，也就是確認需求調(diào)研計劃和參與人員，當然時間是很緊湊的了。然后，我們組織關(guān)鍵用戶和軟件公司開發(fā)顧問一起進行頭腦風暴，每個人根據(jù)自己業(yè)務(wù)的實際需要，提出需要哪些功能，業(yè)務(wù)流程應(yīng)該是什么樣的，頁面該如何展示，審批流程應(yīng)該是什么樣的等等，開發(fā)顧問會詳細記錄這個需求內(nèi)容，同時對討論未決事項確定責任人，需要找相關(guān)領(lǐng)導(dǎo)確認明確需求，并生成會議紀要下發(fā)再次征詢意見。討論會后，需要關(guān)鍵用戶將模塊的業(yè)務(wù)流程進行梳理，生成模塊的流程圖。每個模塊大概都需要三輪需求討論才能定第一稿需求文檔。由于關(guān)鍵用戶一般都是業(yè)務(wù)骨干，但不是部門經(jīng)理，沒有決定權(quán)。第一稿確定后，需要集中各部門領(lǐng)導(dǎo)進行宣講和征詢意見，根據(jù)領(lǐng)導(dǎo)的意見再次修改后審批完成才能最終定稿。需求文檔必須明確標記每個模塊需要哪些頁面、頁面功能和字段有哪些、頁面功能之間的關(guān)系、權(quán)限的設(shè)定、審批流等詳細信息。同時為了以防萬一，擔心開發(fā)人員理解有誤，需要軟件開發(fā)商根據(jù)需求文檔提供系統(tǒng)界面原型，作為需求調(diào)研階段另一個交付物，界面原型同樣需要關(guān)鍵用戶和相關(guān)領(lǐng)導(dǎo)審批通過才能生效，這也是需求調(diào)研階段的雙保險，根據(jù)以往的經(jīng)驗，這樣做后續(xù)開發(fā)過程中的分歧會比較少。

當然，再完善的需求也很難避免由于各種原因而出現(xiàn)需求變更或新增需求（范圍變更）的問題。針對需求變化，首先需要提出部門提交變更申請單，項目組內(nèi)部進行綜合評估，首先判斷這個需求是否真的有必要體現(xiàn)，如果需要，就要看需求變更對其他功能的影響，影響有多大；如果該變更不開發(fā)將影響其他業(yè)務(wù)流程，那一定要在本期上線前開發(fā)完成，否則系統(tǒng)無法使用。這種情況就需要調(diào)整開發(fā)計劃，形成新的項目計劃基線。如果該變更是單獨功能，不影響其他功能的使用，看開發(fā)進度是否允許，時間充?？梢陨暇€前開發(fā)；否則協(xié)商后可以系統(tǒng)上線后開發(fā)，但規(guī)定好具體完成時間。如果經(jīng)項目組評估后覺得功能根本沒必要體現(xiàn)，需求變更不予實施。變更申請單需要層級審批后，由開發(fā)經(jīng)理評估費用和時間進度，按計劃執(zhí)行。變更申請單由信息技術(shù)部存檔，作為項目收尾時結(jié)算的依據(jù)。

3.項目的溝通模式

項目溝通主要是項目團隊與其他組織、項目團隊成員之間的信息傳遞和理解。項目溝通貫穿于項目的整個生命周期，在確認系統(tǒng)需求階段需要溝通；在項目計劃階段制定各類計劃時需要溝通；系統(tǒng)開發(fā)和實施階段需要溝通；在系統(tǒng)測試階段需要溝通，以及上線運維階段都需要溝通；可見溝通在整個項目實施過程中的重要地位，有效的溝通對項目的成功具有重要的意義。如果溝通不暢，相關(guān)人員不能理解項目經(jīng)理的意圖，無法做到上傳下達，最終會導(dǎo)致項目混亂甚至失敗。另一方面，項目團隊內(nèi)部及其與外部環(huán)境之間的信息溝通可以使項目組及時準確地獲取項目的進展情況，對項目進行合理的組織和控制，因為只有以準確、完整、及時的信息為依據(jù)，項目組才能做出正確的決策和合理的計劃。

針對SRM項目來說，采用的是輪式溝通渠道模式，就是項目經(jīng)理作為信息中心分別與項目中不同類型角色發(fā)生聯(lián)系，集中匯集和傳遞來自各個部門的信息，但是不同角色之間彼此之間不發(fā)生聯(lián)系，只分別掌握本部門的情況，接受主管人員的指令并反饋信息。溝通的方式主要以書面溝通的形式，會議上溝通討論的以會議紀要為準，個別溝通的內(nèi)容以郵件為準，或是根據(jù)項目要求提交各類報告，這些信息可以長期保存且信息描述周密、邏輯性強，不容易產(chǎn)生誤解和糾紛。但是缺點是耗費的時間比口頭溝通要多，同時無法保證接收者是否能夠正確理解，綜合兩者的優(yōu)缺點，我們最終采用的溝通方式是以書面溝通為主，口頭和書面相結(jié)合的方式，每次口頭溝通后會落實到文字上雙方認可再實施，保證溝通的有效性。

4.項目的質(zhì)量管理

項目質(zhì)量管理是為滿足項目利益相關(guān)者的需要而開展的項目管理活動。針對SRM項目的質(zhì)量管理就是軟件功能測試，包括單元測試和集成測試。由于我們此次合作的軟件開發(fā)商沒有專業(yè)的測試團隊，只是開發(fā)人員交換測試，一方面由于時間進度緊而測試不充分，另一方面對別人開發(fā)的模塊需求不清晰測不出業(yè)務(wù)流程的正確與否。所以到單元測試和集成階段，關(guān)鍵用戶就要參與進來，每個關(guān)鍵用戶測試自己所熟悉的領(lǐng)域，除了對頁面字段功能進行驗收外，還要對功能之間的業(yè)務(wù)邏輯進行驗證，這樣開發(fā)與測試并行進行，有利于保證進度。但是從另一方面來看，我們收到的最初的交付物錯誤百出，通過問題清單的形式發(fā)給開發(fā)經(jīng)理進行修改和再次驗證。雖然我們驗證的比較充分，但是這樣項目組面對的工作量就會成倍的增加。建議以后最好選有專業(yè)測試團隊的軟件開發(fā)商，讓其分擔項目組的測試工作量。

四、小結(jié)

篇8

關(guān)鍵詞：軟件公司；成本控制；探索

1經(jīng)營決策階段的成本及其控制

經(jīng)營決策階段成本是指公司經(jīng)營方向的選擇，這是成本管理的第一個也是最為核心的環(huán)節(jié)。不過對于大多數(shù)IT軟件業(yè)公司而言，這個階段往往是最大的問題之所在，有時經(jīng)常憑一個覺得是靈感的想法或者對市場初步的直觀層面的調(diào)研就進行的決策。而這樣的結(jié)果是往往沒有摸透市場的真實情況，輕率上馬項目，造成方向性錯誤，以至于導(dǎo)致企業(yè)的危機。

該階段的成本控制，關(guān)鍵在于經(jīng)營決策前科學而深入的市場調(diào)研及準確分析，目前很多中小型IT軟件企業(yè)，其經(jīng)營部的職員大多都并不是社會調(diào)查專業(yè)的，因而他們做市場調(diào)查的過程中所采用的方法不太科學，如在樣本選取及抽樣過程不合理，沒有按照嚴格的社會調(diào)查方法進行調(diào)查和數(shù)據(jù)分析，甚至問卷設(shè)計都存在傾向性導(dǎo)致調(diào)查數(shù)據(jù)信度偏低。此外，大量的公司自我宣傳的各種形式的軟文和競爭對手有意的攻擊性文章夾雜在其中，并不是很容易的進行分辨，更何況數(shù)據(jù)的隨意性，來源的不可追溯性各種情況，所以只能作為參考。

2需求整理及分析確認階段的成本及其控制

需求整理指市場經(jīng)營人員根據(jù)高管對于市場方向的決策，而提出的具體的產(chǎn)品或者項目的原始需求，需求分析是指技術(shù)員對市場部門的需求進行分析，評估其可實現(xiàn)性以及實現(xiàn)難度，大致工時等，提交相關(guān)需求分析報告，最后市場經(jīng)營部門進行確認這個階段。

該階段的成本控制，首先需要搞清這種溝通過程中產(chǎn)生偏差的原因，最為主要的往往并不是技術(shù)語言和市場語言的差異，或者市場人員和技術(shù)人員之間的思維定勢的差異，而在于兩者缺乏確定的科學的流程和在交流之前的準備以及相關(guān)概念約定俗成的定義造成的問題，同時還由于溝通和確認環(huán)節(jié)由于其特殊性，經(jīng)常難以被有效的納入進度管理程序流程當中。而提高該階段的成本控制效率，必須逐一針對性的解決以上問題，首先要清晰的確定并嚴格執(zhí)行市場和技術(shù)溝通的流程，尤其是要明確每個環(huán)節(jié)的控制點，也就是雙方交付給對方的關(guān)鍵交付物，一定要有清晰的共同確認的模板，同時每次溝通前必須對于一些概念有著清晰的界定，然后公布這些信息，并在溝通前做好充足的準備，明確每次溝通前要溝通什么，要解決哪些問題，溝通結(jié)束后要交付哪些文檔讓雙方進行確認等，同時一定要通過線上或者線下的管理模式，講所有溝通環(huán)節(jié)全盤把握，并納入進度管理。

3規(guī)劃階段成本及其控制

規(guī)劃階段成本是指在需求已經(jīng)得到確認后，進入技術(shù)規(guī)劃階段的相關(guān)成本控制，該階段有些軟件開發(fā)公司常常出現(xiàn)的問題是對于規(guī)劃予以過度的期望和過于沉重的內(nèi)涵，在實際項目操作過程中，這個規(guī)劃實際上包含著技術(shù)規(guī)劃和非技術(shù)規(guī)劃兩個部分，因為對這兩個部分的混淆，導(dǎo)致一些技術(shù)層面和市場層面的東西不必要的糾纏在一起，并且直接導(dǎo)致項目進度的拖欠，而且會導(dǎo)致由于非技術(shù)規(guī)劃的不清晰，直接影響技術(shù)規(guī)劃層面的實施。

該階段的成本控制，必須清晰的區(qū)分非技術(shù)規(guī)劃和技術(shù)規(guī)劃，尤其在公司內(nèi)部技術(shù)部門和市場經(jīng)營部門之間的職責，需要設(shè)立一個在提出需求到技術(shù)規(guī)劃之間過渡的位置，即對于需求具體細節(jié)的整理，要對于交付物有著清晰的確定，尤其是在不同時期交付不同的關(guān)鍵文檔，如除了上面說的那六個文檔外，技術(shù)部項目組長在需求分析的時候，還應(yīng)該明確提交功能模塊分析，開發(fā)代價，功能流程圖，功能關(guān)聯(lián)性圖，可維護性及可拓展性分析等六個文檔，此外在項目開發(fā)規(guī)劃階段，還要對于控制點的一些要素進行詳細的規(guī)劃用來提交給市場部門，如詳細頁面元素，頁面元素價值度分析，表現(xiàn)形式，頁面結(jié)構(gòu)，頁面效果等。

4開發(fā)階段的成本及其控制

開發(fā)階段的成本指需求確定并且規(guī)劃清晰后的具體開發(fā)過程的成本管理問題，該階段相對其他階段來說比較清晰，但這里筆者認為需要關(guān)注的是，如何使得人力資源得到最大程度的利用，它是指公司第一線技術(shù)人員的能力最大程度發(fā)揮的狀態(tài)，包含幾個層次，（1）全部時間利用，（2）最大效率利用，（3）最大潛力激勵利用，這三步需要逐步遞進實現(xiàn)。這個需要一種完善的內(nèi)部管理制度，以及公平公正的價值認定模式和績效制度，從而一方面促進員工本身的發(fā)展，一方面增加對人才的吸引力。

該階段的成本控制，可以引入最大可控制成本的概念，這里是指人力資源最大程度發(fā)揮后所能控制的成本，是公司在一定投入前提下，最大的可能的減少因管理導(dǎo)致人力發(fā)揮不足夠而造成的成本，該成本為人力資源的極致成本，無法再進一步降低，此成本狀態(tài)下的仍然出現(xiàn)效益不佳情況，則可說明在經(jīng)營定位和經(jīng)營方向上的問題，而非內(nèi)部問題。促使人力資源得到最大利用度和發(fā)揮度，在此基礎(chǔ)上的成本，為最大可控制成本，以上可以通過內(nèi)部的管理系統(tǒng)來很好的實現(xiàn)。5需求變更成本及其控制

需求變更成本指在開發(fā)過程中，由于市場部門的需求改變導(dǎo)致的成本增加而實施的控制，對于項目開發(fā)的過程中，需求的頻繁變更就成本控制而言是致命的，很多項目由于需求的變更而導(dǎo)致破產(chǎn)。

該階段的成本控制，最關(guān)鍵的是要對于需求變更過程進行嚴格的管理，要從需求變更的開始，對于整個變更的每個具體的步驟進行跟蹤，并且嚴格核算每次變更所需要的工作時，從而做好評估。同時，務(wù)必要明晰需求變更的必要性和風險性，以及所帶來的實際成本的增加，所以需求要盡量經(jīng)過詳細的論證。

6測試成本及其控制

測試成本指項目開發(fā)完成階段，在交付驗收前進行的測試過程中導(dǎo)致的成本及其控制，測試階段對于一個項目的最終交付具有重大的意義，往往在測試階段要才是使得項目真正完善的階段，很多細節(jié)的修補都在測試階段完成，正是測試使得一個項目成為一個可以交付，可以應(yīng)用，可以產(chǎn)生效益的產(chǎn)品。但對于一些中小型軟件開發(fā)公司而言，往往缺乏真正建制齊全的測試部門和專業(yè)測試人員，經(jīng)常是技術(shù)人員進行兼任，這種方式相當普遍。但同時也導(dǎo)致了一些問題，主要是對于測試缺乏經(jīng)驗積累管理，或者說是錯誤管理，經(jīng)常上次測試完出現(xiàn)的問題，過段時間又會出現(xiàn)，或者是開發(fā)下個項目的過程中又再次出現(xiàn)，增加不必要的成本。

該階段的成本控制，筆者認為最關(guān)鍵的是對測試進行錯誤管理模式，采取“有錯必改，凡錯必究，錯不再犯，預(yù)錯于先”的管理辦法，盡量在項目開發(fā)之前，就能整理出之前開發(fā)中出現(xiàn)過的所有問題，并用列表的方式進行技術(shù)會議，讓所有開發(fā)人員進行錯誤共享，盡量把測試中可能出現(xiàn)的問題消滅再開發(fā)階段，另外需要把測試過程化、即時化，每周甚至每天都要求每個開發(fā)人員在交付自己的子模塊的之前就暗中預(yù)先準備的測試手冊進行測試，通過后再提交，同時定時抽查某些核心功能模塊，進行某個點的測試，這樣全過程的控制，會最大程度的減少測試成本，同時要加快反應(yīng)速度，一發(fā)現(xiàn)開發(fā)中，或者測試過程中的相關(guān)問題，必須跟進徹底解決，并納入績效考核中，杜絕再犯。

參考文獻

［1］頡茂華，現(xiàn)代市場經(jīng)濟成本的成本控制新理念［J］.財會月刊2002,(06).

篇9

一、項目經(jīng)理要有較強的觀察分析能力，能夠透過現(xiàn)象看本質(zhì)，規(guī)劃出執(zhí)行步驟和措施；

二、項目經(jīng)理需要有較強的經(jīng)算能力，能夠掌握具體任務(wù)的成本、工期及進度；

三、項目經(jīng)理需要思路清晰表達準確，能夠把遇到的問題、過程、解決方案，清晰地反饋給客戶；

四、項目要較強需求分析確認意識；

五、項目要有較好需求變更控制技巧，做到項目成果于需求變更的雙向跟蹤；

六、項目經(jīng)理要有較強的綜合調(diào)度技巧和能力，對項目各環(huán)節(jié)清楚，也能使別人清楚，還要合理何時合適地調(diào)度各類人力資源。以上使我從實際項目建設(shè)過程總結(jié)的經(jīng)驗，現(xiàn)在我分別一一詳細闡述，以供參考，相互學習。

正文

2006年，我作為項目經(jīng)理參與了青島市應(yīng)急聯(lián)動指揮系統(tǒng)的建設(shè)。該項目是奧運會帆船比賽城市青島的110、122、119三警合一平臺及應(yīng)急聯(lián)動單位協(xié)作平臺，為了提升整個城市對應(yīng)急突發(fā)實踐的響應(yīng)效率和處置能力而建設(shè)平安奧運而做。該項目的主持單位是青島市公安局，項目構(gòu)成有110、122、119接警平臺，處警平臺，聯(lián)動平臺，計算機網(wǎng)絡(luò)，服務(wù)器，視頻監(jiān)控及錄音服務(wù)系統(tǒng)等。

在項目建設(shè)過程中，我從客戶需求調(diào)研、需求設(shè)計、需求確認、軟件開發(fā)、整體實施各個環(huán)節(jié)的實際工作體驗中，發(fā)現(xiàn)項目經(jīng)理的能力幾乎市項目成敗的一個決定性因素。在項目經(jīng)理作用于項目建設(shè)諸多能力中，我覺得以下幾個方面尤其重要：

一、觀察分析能力。

能夠面對綜合復(fù)雜的現(xiàn)象，分析處問題本質(zhì)所在，抓住主要矛盾，并且很快建立應(yīng)對步驟及措施，項目建設(shè)過程出現(xiàn)的問題都能被及時解決，項目才能順利進行。具體來說，對于出現(xiàn)的問題和現(xiàn)象，項目經(jīng)理能夠分析出“是什么”，又能指出“有什么”（有哪些細節(jié)），進行采取合理的“怎么辦”（解決問題的方法和步驟），最后再說明“影響什么”（有哪些風險）。這樣，項目建設(shè)才能清清楚楚地進行（每一個干系人了解清楚），有條不紊地開展（每個人力資源明白措施及步驟）。觀察分析，是一個綜合能力。學者經(jīng)書子集學富五車可謂之淵博；而運籌帷幄決勝千里方是致勝之道。項目經(jīng)理應(yīng)該注意將所學用于實際的觀察分析，從復(fù)雜的想象中指出應(yīng)對措施和步驟。商鞅變法時，遍歷秦國風土人情，觀察分析所存在的想象及問題，指出解決各類問題的步驟及措施（各類法令），就是一個典型的觀察分析能力運用的結(jié)果。重視觀察能力的培養(yǎng)和練習，項目才能走出項目的迷霧，讓自己清楚，才能讓別人清楚。我在青島項目建設(shè)后期，總是習慣于清楚地分析問題“是什么”，指出“有什么”，設(shè)計“怎么辦”，讓觀察分析能力充分發(fā)揮，所起的作用和前期有明顯區(qū)別，終于由客戶的抱怨轉(zhuǎn)化成贊成。

二、精算能力。

大型項目建設(shè)，不是個人單槍匹馬獨闖獨斗；而是一個團隊協(xié)同作戰(zhàn)。常聽到一句話：“老虎統(tǒng)帥的綿羊可以戰(zhàn)勝綿羊統(tǒng)帥的老虎”，正驗證了這個道理。想做好統(tǒng)帥，就要了解和熟悉每一個細節(jié)，知道整個項目有哪些子任務(wù)，分解到哪些人力資源來完成，并評估到工期和進度。如果出現(xiàn)遺漏，就會造成工期延誤。精算能力，正是體現(xiàn)項目經(jīng)理這方面的才干。我在青島項目建設(shè)之初，簡單地分解工作任務(wù)，結(jié)果造成工作任務(wù)遺忘，工期受到延誤；后來認真分解任務(wù)，精算到位，合理分配每一個細節(jié)，項目工期才得以彌補。

三、思路清晰表達準確。

如果自己的思路都不清楚，怎么讓別人清楚呢？我們在生活中，經(jīng)常碰到這樣的人。他說話時，東扯一句，西扯一句，聽著不明白他的中心思想，很難理解他所表達的事物。與其說思路清晰表達準確是一種能力，還不如說其是一種意識。這個技能從小學課文都已經(jīng)開始練習了（小學課文都將中心思想和段落大意），應(yīng)該每一個人都做好。如果說話前，先想一想自己要說的中心思想，然后在逐步分層表達，每一個都能說清楚自己要表達的意識。但是很多偏不這么干，沒想好怎么說就開始表達，聽得別人云山霧罩。包括我自己，在青島項目建設(shè)之初，我說話前不喜歡做語言上的準備，說得別人越聽越糊涂。后來我堅持，表達前先設(shè)計思路，然后在準備語言進行準確表達，就避免了客戶越聽越糊涂的現(xiàn)象。

四、需求分析確認意識。

項目尤其本身的特點，就是一次性滿足固定客戶的特殊需求。項目經(jīng)理說做的目標就是滿足這個客戶需求。需求是什么，有什么，怎么辦，項目經(jīng)理需要于客戶溝通，獲取確認后，方是客戶所要的需求。需求的確認就是完成這個工作的。項目經(jīng)理應(yīng)該使需求的理解，需求的設(shè)計結(jié)果得到客戶確認；否則一個沒有經(jīng)過客戶確認的需求和設(shè)計，使工程返工，推倒從來，白白浪費成本的導(dǎo)火索。我在青島項目經(jīng)歷過這樣的教訓，客戶提出需求后，我盲目開工，結(jié)果客戶不滿意，團隊成員抱怨，成功工期都出現(xiàn)了問題。后來堅持需求簽字確認，就大大降低了返工的概率。

五、變更控制技巧。

項目經(jīng)理需要較好的需求變更控制技巧。對于項目的建設(shè)，由于客戶隨開發(fā)方一樣，都是一個逐步熟悉的過程。項目的需求變化使一件很普遍的事情。有的開發(fā)人員抱怨客戶變化無常，一天一個樣。其實這是沒有站在客戶的立場想問題。對于需求變更一味地接受，增加公司的成本，也會造成工期延誤；一味地拒絕，客戶難以滿意，甚至反感。其實這里需要一定的技巧和方法。其一、使客戶準確完面地提出問題，堅持走一定的變更流程。例如需求要經(jīng)過變更會議多方全面討論分析，再經(jīng)過需求理解設(shè)計，風險分析及實施分析等。其二、經(jīng)過簽字或者其他形式的確認。這樣需求變更不是一個客戶隨意的行為，避免客戶故意生事；開發(fā)方也能避免無效的多次返工，即使返工也是各方干系人都認可的工作。

六、綜合調(diào)度能力。

項目經(jīng)理對整個工程的把握，知道在合適的時間，調(diào)用合適的人力，完成合適的任務(wù)，使整個項目進展按時按步進行，體現(xiàn)其綜合調(diào)度能力。大型項目建設(shè)是一種復(fù)雜而艱巨的任務(wù)，項目經(jīng)理需要完成的事情很多。整體性思考問題，合時合適地安排調(diào)度，時其另一個重要的技巧。

以上是我在實際項目中體會的經(jīng)驗。其實在項目建設(shè)過程中，項目經(jīng)理需要總結(jié)和吸取的經(jīng)驗還很多。項目經(jīng)理應(yīng)該從實際出發(fā)不斷地總結(jié)、學習和體會，以讓自己項目管理能力日趨完善。

篇10

關(guān)鍵詞 業(yè)主 工程變更 核電站

一、引言

由于建筑工程項目的單一性、復(fù)雜性和長期性的特點，其工程變更是不可避免的。如果業(yè)主對工程變更控制經(jīng)驗不足，管理不善，往往會導(dǎo)致工期延誤、投資失控等情況的發(fā)生，因此業(yè)主必須重視工程變更的管理，確保項目的順利實施。我國紀檢部門已明文規(guī)定：工程變更將作為紀檢部門對工程建設(shè)項目重點控制、檢查的四個工作環(huán)節(jié)之一。國外一些發(fā)達國家，例如美國，對工程變更的控制也很重視，據(jù)美國有關(guān)部門統(tǒng)計，一般工程變更費占合同價格的10-25%，對工程投資影響很大，政府會對投資項目提出嚴格要求并進行專門檢查和評估。

作為中國的第一座引進國外技術(shù)并由國外公司承包建設(shè)的大型商業(yè)核電站，大亞灣核電站不僅引進了核電技術(shù)，也引進了先進的工程管理經(jīng)驗。目前在國家積極發(fā)展核電的能源政策下，大亞灣核電站應(yīng)運成為了中國廣東核電集團發(fā)展核電的人才和技術(shù)基地，近幾年需新建大批的住宿、辦公、培訓、招待、運動場館等行政基建項目。行政基建項目組借鑒電站建造時的工程管理經(jīng)驗，結(jié)合行政基建項目的特點，對工程變更管理做了及時的總結(jié)反饋，完善了變更管理，取得了一定的成效。在工程管理的實踐中總結(jié)的一些體會和經(jīng)驗相信對業(yè)界同仁會有些啟發(fā)和幫助。

二、業(yè)主對工程變更的管理經(jīng)驗

（一）要結(jié)合公司和項目，分析引起工程變更的風險因素或原因。

引起工程變更的常見因素（見圖1），可以作為參考，另外要結(jié)合自己公司和項目實際，分析引起變更的因素，以便有的放矢，從源頭上控制變更。以大亞灣核電站的行政基建項目為例，通過對2006年引起各項目變更因素的分析，發(fā)現(xiàn)主要有四條：一是施工圖設(shè)計質(zhì)量差；二是用戶需求變化，功能性變更；三是施工技術(shù)規(guī)范書不完善，施工范圍不清或項目遺漏；四是客觀的不可見因素。對引起變更最多的設(shè)計因素（約占總變更額的50%），進一步分析，主要為各專業(yè)間接口（特別是安裝和土建的接口的矛盾）和設(shè)計深度問題。

針對引起變更的主要原因，要及時采取有效應(yīng)對措施，完善變更控制管理。如針對施工圖設(shè)計質(zhì)量差，采取了一系列措施。首先，對設(shè)計任務(wù)委托書，進行分析評估，找出業(yè)主設(shè)計任務(wù)委托書中的不足，并借助工程咨詢公司的力量，編制了《建設(shè)工程設(shè)計任務(wù)委托書標準模板》，規(guī)范了今后設(shè)計任務(wù)委托書的編寫，也使質(zhì)量有了保證。其次，在設(shè)計招標中，采用綜合評標法，并增加技術(shù)標在綜合評標中的比例，最高到40%，使設(shè)計院加大技術(shù)力量投入。第三，在合同條款中明確規(guī)定，由于設(shè)計院的圖紙缺陷，引起工程變更，造成業(yè)主損失，設(shè)計院要承擔相應(yīng)的經(jīng)濟責任。第四，加大圖紙審查力度。除了業(yè)主以及施工和監(jiān)理單位審查外，在施工發(fā)標前，還委托專業(yè)公司進行第三方圖紙審查。第三方審查范圍也從國家規(guī)定的強規(guī)的符合性審查擴大到圖紙接口的審查。另外，把那些出圖紙質(zhì)量差的設(shè)計院從公司潛在承包商數(shù)據(jù)庫中刪除，今后不再允許其參加設(shè)計投標。

（二）工程變更控制要采用全過程管理，以預(yù)防為主。

工程變更發(fā)生在實施階段，但一些工程變更，特別是重大變更往往潛伏在項目初始的籌劃階段。在該階段用戶需求調(diào)查、相互溝通以及項目籌劃人員的預(yù)見能力，對項目的正確定位和預(yù)防重大變更的發(fā)生尤為重要。大亞灣核電基地行政基建項目前期的設(shè)計階段中，有幾個項目發(fā)生的重大變更都是由于用戶需求和形勢變化，導(dǎo)致原方案不再適用。用戶一般不是專業(yè)的工程技術(shù)人員，在項目初期很難系統(tǒng)提出一份專業(yè)、完整的需求報告，而往往是工程建到一定階段，用戶看到實物后又會提出很多變更要求，使項目陷入被動。針對用戶特點，我們把用戶需求標準化，做成一個覆蓋面很廣的菜單式需求表，讓用戶填寫，并簽字確認。在設(shè)計階段，應(yīng)做出直觀的效果圖和模型，讓用戶在方案設(shè)計階段提出意見。這就基本解決了用戶在工程建造階段提出變更要求的問題。另外，項目的籌劃要建立在清楚用戶需求的基礎(chǔ)上，還要從專業(yè)角度了解更多信息，用發(fā)展的眼光明確項目定位，重大項目在必要時可請專業(yè)咨詢公司協(xié)助進行前期籌劃。項目初期完善、深入的工作，可以有效地預(yù)防重大變更的產(chǎn)生。

（三）項目管理中，要控制和減少的是不合理的工程變更。

工程變更可能會導(dǎo)致工程項目延期和投資失控，但業(yè)主人員也不要談虎色變，一味避免或減少工程變更。實際上有些工程變更的實施可以提升項目的功能價值或減少業(yè)主損失，對工程建設(shè)或項目全周期費用控制有利。因此，要辨證地看待工程變更，充分利用變更，使業(yè)主利益最大化。如在大亞灣核電基地員工宿舍二期的建設(shè)中，有幾棟樓的原始地坪較高，且為基巖，原設(shè)計中采用爆破施工降低地坪。在施工過程中，由于該現(xiàn)場與其他已投用的建筑物較近，且在人口較多的生活區(qū)，爆破施工時風險很大，進度緩慢。業(yè)主技術(shù)人員經(jīng)研究將建筑物基礎(chǔ)標高提高1米，也不影響建筑物的正常使用，經(jīng)設(shè)計院同意，決定發(fā)出工程變更。該變更為業(yè)主節(jié)省施工費用約138萬，縮短了工期，也大大減少了爆破施工的風險。

（四）建立規(guī)范的變更控制流程，并正確處理變更控制與效率的關(guān)系。

做好工程變更管理，業(yè)主首先要建立變更控制的流程和分級授權(quán)審批制度。以大亞灣核電運營管理公司為例，在公司的《合同采購政策》中，規(guī)定了變更處理的原則，如“除非涉及重大質(zhì)量安全問題或可以為公司爭取明顯的效益，應(yīng)盡可能減少設(shè)計和技術(shù)要求的變更?！倍乙坏╉椖坷塾嬜兏痤~超過合同額的15%，變更要由批準原合同的上一級授權(quán)人批準。對于行政基建項目，由于合同額相對較大，如果超過15%，一般要公司董事會批準。在此政策下，項目部也制定了《行政基建項目工程變更管理》程序，對變更的定義、處理流程做了詳細規(guī)定。一般來講，變更審批環(huán)節(jié)越多，越容易控制變更的數(shù)量和變更的費用，而且各部門在審批中互相補充、制約，也能在一定程度預(yù)防個人主觀因素甚至個人違規(guī)損害公司利益的情況發(fā)生。繁瑣的變更審批流程，需要較長的流轉(zhuǎn)時間，往往會影響變更的及時實施，甚至影響整個項目的工期。但過分簡化變更控制流程，甚至先實施、再辦變更手續(xù)的做法也是不可取的。建設(shè)單位要根據(jù)本公司的整體管理的要求以及工程項目的特點，正確處理變更控制與工程效率的關(guān)系。

（五）變更控制要充分利用支持單位的力量。

對一般業(yè)主單位來講，由于工程建設(shè)是階段性的，一般不會有太多的專業(yè)工程管理和技術(shù)人員及相關(guān)的經(jīng)驗，與專職從事工程施工的承包商單位相比處于劣勢。因此建設(shè)單位可以和一些專業(yè)公司簽訂一些技術(shù)支持服務(wù)合同，充分利用外部單位的力量和成熟經(jīng)驗。如大亞灣核電基地的行政建設(shè)項目管理中，項目負責人由業(yè)主人員擔當，負責項目的總體協(xié)調(diào)管理。在發(fā)標階段，請造價咨詢單位編制工程量清單，請招標單位編制招標文件并進行技術(shù)評標。在項目實施中，請專業(yè)公司進行第三方圖紙審查，請監(jiān)理公司負責變更令的編寫、完工工程量簽認，請造價咨詢單位對擬發(fā)出的工程變更進行估價并負責承包商變更報價審核。這樣專業(yè)公司介入了工程管理的各個環(huán)節(jié)，有效地控制了變更，彌補了業(yè)主技術(shù)和經(jīng)驗不足的缺點。

（六）在變更管理中，要明確各方責任，進行適當?shù)目己撕图睢?/p>

由于變更產(chǎn)生的原因很多，控制的環(huán)節(jié)也較多，再加上引進外部支持力量參與的人員和單位也多，如果不明確各方的責任，加強考核，變更控制的有效實施也很困難。在大亞灣核電基地的行政基建項目變更管理中，首先在建設(shè)單位內(nèi)部，對每個變更按引起的原因進行分類，用戶需求變化引起的變更責任方為用戶，技術(shù)變更責任方在土建處，先控制由各部門引起變更的累計金額占合同金額的比例，作為部門考核指標，然后再由部門分解到員工量化績效考核中，考核直接和年度考績及獎金掛鉤。對于外部單位，在合同條件中也明確規(guī)定了獎懲細則，考核他們的工作效率和效能。這樣充分調(diào)動了所有參與人員的責任心和主動性，構(gòu)筑起控制變更的道道屏障。

三、案例分析

大亞灣核電基地員工宿舍二期工程主要包括9棟6層的宿舍樓及小區(qū)的道路、綠化和半地下停車場。項目的預(yù)算金額為7000萬元人民幣，各種合同（含設(shè)計、監(jiān)理、咨詢、家具、施工等）的累計合同額為6500萬。在工程變更的管理中，業(yè)主項目組嚴格按照規(guī)定的變更流程（見圖2），充分利用支持單位的技術(shù)力量和經(jīng)驗，對每個變更的必要性、合理性進行把關(guān)，對變更方案和工程量及造價進行嚴格審查，并充分汲取員工宿舍一期的經(jīng)驗，調(diào)動項目管理人員的積極性，使工程變更得到了有效控制。

以土建施工部分為例，其合同額為5760萬，工期為12個月。工程變更統(tǒng)計如表1。

其中最大的一個費用變更是由于設(shè)計院沒有充分考慮大亞灣沿海、雨量大、臺風多的氣候條件，屋面和墻體防水設(shè)計不完善所造成的，單個變更的金額為49.7萬元。

大亞灣核電站作為中國上世紀引進國外技術(shù)的最大的合資項目，工程的管理和公司的商務(wù)流程引進了香港和法國的模式，一直發(fā)揮著良好的作用。文中所述的行政基建項目的變更管理是在原來工程管理經(jīng)驗的基礎(chǔ)上，結(jié)合目前的實際情況，不斷總結(jié)、完善而形成，在工程實踐中得到了驗證。在近期完工的三個項目中，工程變更累計金額與合同額的比例分別為10%、5.5%和負2.4%，并且全部在項目的預(yù)算金額內(nèi)。工程變更管理貫穿于工程全過程，對工程影響重大。業(yè)主作為項目的投資方和受益方，要高度重視，勤于總結(jié)反饋，充分利用外部經(jīng)驗和力量，結(jié)合公司和項目的特點，制定完善的工程變更管理制度，對工程進行科學管理，以保證項目的順利實施。

（作者單位：大亞灣核電運營管理公司，天津大學管理系96屆畢業(yè)生）

參考文獻

李維芳：工程變更確認與控制，《建筑經(jīng)濟》，2007年第3期。

孟憲海：國際工程變更因果分析與管理，《施工技術(shù)》，2007年第2期。