【導(dǎo)讀】需求、提出解決方案、執(zhí)行項目、結(jié)束項目”四個階段。維護幾個階段，而在建筑業(yè)中一般將項目分成立項決策、計劃和設(shè)計、建設(shè)、移交和運行等階段。當需求被客戶確定時，項目就產(chǎn)生了。是贏得項目的關(guān)鍵，公司既要展示實力又要合理報價。如果競標成功則簽定合同，廠商開始承擔項。防治的方法是一方面在合同中明確定義項。分析項目偏差，采取必要措施以實現(xiàn)目標。別是有眾多項目同時運行的IT公司，必須建立公司一級的監(jiān)控體系跟蹤項目的運行狀態(tài)。最后，舉行慶祝儀式，讓項目成員釋放心理壓。完成階段性工作的標志，不同類型的項目里程碑不同。項目存在兩次責任。出資人可以批準啟動一個項目，也可以根據(jù)情況終止一個項目。接提出項目的要求，第二是擁有并使用項目成果。項目執(zhí)行中所有者會擔負一定職責，密切關(guān)注項。對于系統(tǒng)集成項目來說，最常見的所有者是使用系統(tǒng)的業(yè)務(wù)部門。本約束內(nèi)完成預(yù)期目標。項目經(jīng)理是責任的匯集點，需要對所有者和部門經(jīng)理負責，同時需要管理

　　

【正文】 Delphi 法） 、類比估算（根據(jù)以前類似項目的實際成本作為當前項目的估算依據(jù)）、參數(shù)模型（根據(jù)項目特征，用數(shù)學(xué)模型來預(yù)測項目的成本）。從實際工作情況來看，如果歷史數(shù)據(jù)比較豐富，類比估算法相對比較準確。 成本預(yù)算是在確定總體成本后的分解過程。分解主要是做兩個方面工作：一是按工作包分攤成本。這樣可以對照檢查每項工作的成本，出現(xiàn)偏差時可以確定是哪項工作出了問題；二是按工期時段分攤成本，將預(yù)算成本分攤到工期的各個時段，可以確定在未來某個時點累計應(yīng)該花費的成本（可以用 S曲線表示），這樣做的好處是可以在任何時間檢查偏差，并評價成本績 效，避免 “ 只要不超 TBC就沒問題 ” 的誤解。 綜上所述，制定進度計劃要綜合考慮邏輯約束，還要考慮活動適合最早或最遲開始，并平衡資源配置。預(yù)算包括估算和預(yù)算兩個步驟，預(yù)算的關(guān)鍵是要知道每個工作包成本和未來具體時點累計成本。 下期預(yù)知 項目的變更控制 項目管理過程之變更控制 項目的變更控制 變更控制的目的并 不是控制變更的發(fā)生，而是對變更進行管理，確保變更有序進行。對于軟件開發(fā)項目來說，發(fā)生變更的環(huán)節(jié)比較多，因此變更控制顯得格外重要。 IT 項目中引起變更的因素有兩個：一是來自外部的變更要求，如客戶要求修改工作范圍和需求等；二是開發(fā)過程內(nèi)部的變更要求，如為解決測試中發(fā)現(xiàn)的一些錯誤而修改源碼甚至設(shè)計。比較而言，最難處理的是來自外部的需求變更，因為 IT 項目需求變更的概率大，引發(fā)的工作量也大（特別是到項目的后期）。 變更控制不能僅在過程中靠流程控制，有效的方法是在事前明確定義。事前控制的一種方法是在項目開始前明 確定義，否則 “ 變化 ” 也無從談起。工作范圍（以前章節(jié)談過）；另一種方法是評審，特別是對需求進行評審，這往往是項目成敗的關(guān)鍵。需求評審的目的不僅是 “ 確認 ” ，更重要的是找出不正確的地方并進行修改，使其盡量接近 “ 真實 ” 需求。另外，需求通過正式評審后應(yīng)作為重要基線，從此之后即開始對需求變更進行控制。 雖然可以事前定義好變更控制流程，但在各種壓力下真正 “ 控制 ” 起來其實非常困難。下面給大家分析一個變更失控的項目案例： 王先生剛出任項目經(jīng)理，并承接了一個中型軟件項目。上任時公司高層再三叮嚀他一定要尊重客戶，充分滿足客戶 需求。項目開始比較順利，但進入到后期，客戶頻繁的需求變更帶來很多額外工作。王先生動員大家加班，保持了項目的正常進度，客戶相當滿意。 但需求變更卻越來越多。為了節(jié)省時間，客戶的業(yè)務(wù)人員不再向王先生申請變更，而是直接找程序員商量。程序員疲于應(yīng)付，往往直接改程序而不做任何記錄，很多相關(guān)文檔也忘記修改。很快王先生就發(fā)現(xiàn)：需求、設(shè)計和代碼無法保持一致，甚至沒有人能說清楚現(xiàn)在系統(tǒng) “ 到底改成什么樣了 ” 。版本管理也出現(xiàn)了混亂，很多人違反配置管理規(guī)定，直接在測試環(huán)境中修改和編譯程序。但在進度壓力下，他也只能佯裝不知此事。但 因頻繁出現(xiàn) “ 改好的錯誤又重新出現(xiàn) ” 的問題，客戶已經(jīng)明確表示 “ 失去了耐心 ” 。 而這還只是噩夢的開始。一個程序員未經(jīng)許可擅自修改了核心模塊，造成系統(tǒng)運行異常緩慢，大量應(yīng)用程序超時退出。雖然最終花費了整整 3天的時間解決了這個問題，但客戶卻投訴了，表示 “ 無法容忍這種低下的項目管理水平 ” 。更糟糕的是，因為擔心系統(tǒng)中還隱含著其他類似的錯誤，客戶高層對項目的質(zhì)量也疑慮重重。 隨后發(fā)生的事情讓王先生更加為難：客戶的兩個負責人對界面風(fēng)格的看法不一致，并為此發(fā)生了激烈爭執(zhí)。王先生知道如果發(fā)表意見可能會得罪其中一方，于是保持 了沉默。最終客戶決定調(diào)整所有界面， 王先生只好立刻動員大家抓緊時間修改?？珊髞懋斅犝f因修改界面而造成了項目一周的延誤后，客戶方原來發(fā)生爭執(zhí)的兩人這次卻非常一致，同時氣憤地質(zhì)問王先生： “ 為什么你不早點告訴我們要延期！早知這樣才不會讓你改呢！ ” 王先生委屈極了，疑惑自己到底錯在哪里了。 從上面的案例中可以看到各種變更失控的現(xiàn)象和造成的后果，王先生主要犯了幾個錯誤： 1) 沒有明確的授權(quán)。 事先應(yīng)該明確客戶方有權(quán)提出變更申請的人員和實施方有權(quán)受理變更的人員，并要控制雙方人數(shù)。這樣做才可以對變更有整體的控制。絕不能 進行 “ 私下交易 ” ，而沒有人能完整地知道到底改了些什么。另外，授權(quán)雙方接口人的好處是可以屏蔽客戶內(nèi)部的矛盾，如果只有一個接口人，內(nèi)部尚未達成一致時變更是無法提出來的。從實際經(jīng)驗看，授權(quán)可以顯著減少變更，特別是那些因內(nèi)部看法不同而導(dǎo)致的反復(fù)變更。 2) 對變更沒有進行必要的審核。 并不是所有的變更都要修改，也不是所有變更都要立刻修改，審核的目的就是為了決定是否需要修改和什么時候修改。比如案例中提到的界面風(fēng)格問題，就可以先不修改，或者規(guī)劃一下修改的時間待到以后進行優(yōu)化。另外，對于核心模塊的修改要嚴格審核把關(guān)，否則 會引起全局問題，案例中提到的 “ 擅自修改核心模塊 ” 造成的事故就是因為沒有審核而造成的。 3) 對變更的影響沒有評估。 變更都是有代價的，應(yīng)該評估一下變更的代價和對項目的影響，要讓客戶了解變更的后果，并與客戶一起做判斷。案例中客戶最后的質(zhì)問正是因為沒有事前告訴客戶變更的影響造成的。如果客戶不知道你為變更付出的代價，對你的辛苦便難以體會。案例中客戶剛開始對王先生加班處理變更相當滿意，但只是對工作態(tài)度滿意，后期當變更引發(fā)一系列問題時客戶并沒有感謝王先生的苦勞。 4) 應(yīng)該讓客戶確認是否接受變更的代價。 在評估代價并 且與客戶討論的過程中，可以請客戶一起做判斷： “ 我可以修改，但您能接受后果嗎？ ” 。案例中如果王先生評估了修改界面的工作量并請客戶確認，則有三種可能：客戶預(yù)先接受延期這一后果，也就不會再質(zhì)問王先生了；如果客戶認為代價太大，則王先生就不必修改了；如果認為可以縮短延期時間，則王先生至少爭取到了與客戶協(xié)商的機會，讓客戶知道為此項目組需要付出加班的代價，吃個 “ 明虧 ” 。 上述步驟完成后，要等客戶確認變更再組織實施變更的相關(guān)工作。變更要按配置管理（讀者可以查閱相關(guān)的資料）的規(guī)定執(zhí)行，確保所有交付物的一致性和完整性。同時， 對所有的變更要跟蹤和驗證，確保都按要求完成了。 最后，要特別提醒的是：要在項目開始就對項目組和客戶進行宣傳和培訓(xùn)，讓所有成員都理解變更控制的重要意義；在項目過程中要對變更控制的執(zhí)行情況進行審計，發(fā)現(xiàn)違反規(guī)定的事件要嚴肅處理，否則過程很快就會失效。 綜上所述，變更控制的目的是管理變化。變更控制對項目成敗有重要影響，事前要明確定義，事中要嚴格執(zhí)行。實施變更之前有四個重要控制點：授權(quán)、審核、評估和確認；在實施過程要進行跟蹤和驗證，確保變更被正確執(zhí)行。 項目的生命周期 概述 項目的生命周期描述了項目 從開始到結(jié)束所經(jīng)歷的各個階段，最一般的劃分是將項目分為 “ 識別需求、提出解決方案、執(zhí)行項目、結(jié)束項目 ” 四個階段。實際工作中根據(jù)不同領(lǐng)域或不同方法再進行具體的劃分。例如，按照軟件開發(fā)項目劃分為需求分析、系統(tǒng)設(shè)計、系統(tǒng)開發(fā)、系統(tǒng)測試、運行維護幾個階段，而在建筑業(yè)中一般將項目分成立項決策、計劃和設(shè)計、建設(shè)、移交和運行等階段。 項目生命周期的劃分 對于 IT 服務(wù)項目來說，從廠商看項目是從接到合同開始，到完成規(guī)定工作結(jié)束，但如果從客戶角度看，項目是從確認有需求開始，到使用項目的成果實現(xiàn)商務(wù)目標結(jié)束，生命周期的跨度要 比前者大。因為項目的根本目標是滿足客戶的需求，所以按后者劃分考慮比較有益，對項目管理成功也大有幫助： 第一，識別需求。當需求被客戶確定時，項目就產(chǎn)生了。這個階段的主要任務(wù)是確認需求，分析投資收益比，研究項目的可行性，分析廠商所應(yīng)具備的條件。商務(wù)上這個階段以客戶提出明確的《需求建議書》或《招標書》為結(jié)束標志。這個階段盡管可以由客戶單獨完成，但如果廠商介入則非常有利：一方面可了解客戶真正需要什么；另一方面早期的交流可建立良好客戶關(guān)系，為后續(xù)的投標和合同奠定基礎(chǔ)。第二，提出解決方案。主要由各廠商向客戶提交標書、 介紹解決方案。這個階段是贏得項目的關(guān)鍵，公司既要展示實力又要合理報價。如果競標成功則簽定合同，廠商開始承擔項目成敗的責任。這個階段容易出的問題是：因看不見最終產(chǎn)品，銷售人員可以 “ 隨便說 ” ，甚至過度承諾（因不用他們?nèi)?zhí)行），由此會造成公司的損失。防治的方法是一方面在合同中明確定義項目的目標和工作范圍，另一方面在公司一層建立合同審核機制。 第三，執(zhí)行項目。從公司角度來看這才是項目的開始。這個階段項目經(jīng)理和項目組將代表公司完全承擔合同規(guī)定的任務(wù)。一般需要細化目標，制定工作計劃，協(xié)調(diào)人力和其他資源；定期監(jiān)控進展，分析項目偏差，采取必要措施以實現(xiàn)目標。因為 IT 項目的不確定性，項目監(jiān)控顯得非常重要，特別是有眾多項目同時運行的 IT 公司，必須建立公司一級的監(jiān)控體系跟蹤項目的運行狀態(tài)。 第四，結(jié)束項目。主要包括移交工作成果，幫助客戶實現(xiàn)商務(wù)目標；系統(tǒng)交接給維護人員；結(jié)清各種款項。完成這些工作后一般進行項目評估。評估可以請客戶參加，讓其表達意見，并爭取下一個商業(yè)機會，或請求將項目作為燈塔向其他客戶展示。最后，舉行慶祝儀式，讓項目成員釋放心理壓力、享受成果。 在上述項目生命周期中存在 2 次責任轉(zhuǎn)移：第一次在簽定合同時，標志著項 目成敗的責任已經(jīng)由客戶轉(zhuǎn)移給承約方；第二次是交付產(chǎn)品時，標志著承約方完成任務(wù)，開始由客戶承擔實現(xiàn)商務(wù)目標的責任。第一次責任轉(zhuǎn)移時清晰定義工作范圍非常重要，開始說得越清楚則完工后越容易交回去。如果開始沒說清楚也會 “ 皆大歡喜 ” ，因為承約方覺得 “ 反正沒說清楚，到時咱不做 ” ；而客戶覺得“ 到時讓他們做，當然不會另外加錢了 ” 。而一旦發(fā)生這樣的情況客戶是占上風(fēng)的，一是客戶可以拒絕付款，二是一個不滿的客戶會使廠商喪失大量商業(yè)機會。 項目生命周期中的重要概念 項目生命周期中有三個與時間相關(guān)的重要概念：檢查點（ CheckPoint）、里程碑（ Mile Stone）和基線（ Base Line），描述了在什么時候（ When）對項目進行什么樣控制。 檢查點。指在規(guī)定的時間間隔內(nèi)對項目進行檢查，比較實際與計劃之間的差異，并根據(jù)差異進行調(diào)整?？蓪z查點看作是一個固定 “ 采樣 ” 時點，而時間間隔根據(jù)項目周期長短不同而不同，頻度過小會失去意義，頻度過大會增加管理成本。常見的間隔是每周一次，項目經(jīng)理需要召開例會并上交周報。 里程碑。完成階段性工作的標志，不同類型的項目里程碑不同。里程碑在項目管理中具有重要意義，我們用一個例子說明：情況一：你 讓一個程序員一周內(nèi)編寫一個模塊，前 3天你們可能都挺悠閑，可后 2 天就得拼命加班編程序了，而到周末時又發(fā)現(xiàn)系統(tǒng)有錯誤和遺漏，必須修改和返工，于是周末又得加班了。 情況二：實際上你有另一種選擇，即周一與程序員一起列出所有需求，并請業(yè)務(wù)人員評審，這時就可能發(fā)現(xiàn)遺漏并即時修改；周二要求程序員完成模塊設(shè)計并由你確認，如果沒有大問題，周三、周四就可讓程序員編程。同時自己準備測試案例，周五完成測試；一般經(jīng)過需求、設(shè)計確認，如果程序員合格則不會有太大問題，周末可以休息了。 第二種方式增加了 “ 需求 ” 和 “ 設(shè)計 ” 兩個里程碑，這 看似增加了額外工作，但其實有很大意義：首先，對一些復(fù)雜的項目，需要逐步逼近目標，里程碑產(chǎn)出的中間 “ 交付物 ” 是每一步逼近的結(jié)果，也是控制的對象。如果沒有里程碑，中間想知道 “ 他們做的怎么樣了 ” 是很困難的。其次，可以降低項目風(fēng)險。通過早期評審可以提前發(fā)現(xiàn)需求和設(shè)計中的問題，降低后期修改和返工的可能性。另外，還可根據(jù)每個階段產(chǎn)出結(jié)果分期確認收入，避免血本無歸。第三，一般人在工作時都有 “ 前松后緊 ” 的習(xí)慣，而里程碑強制規(guī)定在某段時間做什么，從而合理分配工作，細化管理 “ 粒度 ” 。 基線。指一個（或一組）配置項在項目生命周 期的不同時間點上通過正式評審而進入正式受控的一種狀態(tài)?；€其實是一些重要的里程碑，但相關(guān)交付物要通過正式評審并作為后續(xù)工作的基準和出發(fā)點?；€一旦建立后變化需要受控制。 綜上所述，項目生命周期可以分成識別需求、提出解決方案、執(zhí)行項目和結(jié)束項目四個階段。項目存在兩次責任轉(zhuǎn)移，所以開始前要明確定義工作范圍。項目應(yīng)該在檢查點進行檢查，比較實際和計劃的差異并進行調(diào)整；通過設(shè)定里程碑漸近目標、增強控制、降低風(fēng)險；而基線是重要的里程碑，交付物應(yīng)通過評審并開始受控。 項目計劃和預(yù)算 進度和資源計劃 進度計劃的作用是 將工作安排反映到日歷上，它不僅規(guī)定整個項目以及各階段的起止日期，還具體規(guī)定了所有活動的開始和結(jié)束日期。常用描述進度計劃的工具有甘特圖和時間表： 1) 甘特圖又稱為 “Gantt Chart” 或 “Bar Chart” ，用橫軸表示時間刻度，縱軸表示活動，而用一條 “ 橫條 ” 表示該活動的起始和結(jié)束時間。傳統(tǒng)的甘特圖不能表示活動之間的相互關(guān)系，現(xiàn)在一些工具（如 MS Project）可以用橫條之間的箭頭表示活動的依賴關(guān)系。甘特圖的特點是直觀性強，缺點是一旦改變進度安排整個圖形的形狀就改變了，必須重新繪制。 2) 時 間表一般配合網(wǎng)絡(luò)圖使用。網(wǎng)絡(luò)圖描述任務(wù)間依賴關(guān)系，而時間表記錄每項活動的 “ 計劃開始時間 ” 、 “ 計劃結(jié)束時間 ” 、 “ 實際開始時間 ” 和 “ 實際結(jié)束時間 ” 。這種方式最大的特點是修改方便，可以直接記錄最新狀態(tài)并進行重新推算；但缺點是直觀性較差。制定進度計劃時一般要考慮以下因素： 1) 活動間約束關(guān)系。如前文介紹的網(wǎng)絡(luò)圖描述的那樣，項目中的活動之間存在各種依賴關(guān)系，一些活動必須在某些活