在《人月神話》開始的時候，作者Frederick P. Brooks Jr.寫道：史前史中，沒有別的場景比巨獸們在焦油坑中垂死掙扎的場面更令人震撼。上帝見證著恐龍、猛獁象、劍齒虎在焦油中掙扎。他們掙扎的越猛烈，焦油糾纏的就越緊，沒有任何猛獸足夠強壯或具有足夠的技巧，能夠掙脫束縛，他們最後都沉到了坑底。

Frederick P. Brooks Jr.寫下上面的文字，用以比喻我們的軟體專案，一旦開始，就類似於各種動物在焦油坑中的掙扎。專案開始時的興奮、激動迅速轉變為對專案結束遙遙無期的詛咒和絕望。

對於目前國內的許多軟體專案而言，這似乎成為了定律，無論你做怎樣的掙扎，專案就是無法結束，只能靠和使用者比拼耐性，預期6個月的專案，做18個月是常有的事。我也經歷了無數的夢魘般的專案，對於如何有效的結束一個專案，在學習了PMBOK之後，我想結合最近剛剛完成的一個稅收MIS專案，談談自己的看法。

在PMBOK中，對於專案的階段，劃分為以下五個部分：

我將基本按照這五部分，描述在這個專案中，是如何將專案結束的。

1、啟動

該專案的客戶屬於我們公司長期合作的客戶，客戶與銷售經理的關係非常密切，客戶需要開發該軟體時，直接找到了我們公司，我作為技術負責人和銷售經理一起和客戶交流了該軟體的情況。在第一次接觸中，我感到客戶對於自己將要開發的軟體的需要還不是十分清楚，但是客戶方的專案經理，也就是該稅務局的資訊中心主任對於軟體開發卻有著比較豐富的經驗，曾經參與過金稅工程等大型軟體的開發。這使我感到這樣的客戶比較容易交流。實際情況也確實如此，在與客戶交流了幾次之後，該專案基本確定，我被公司任命該該專案的專案經理，負責該專案的開發。

在這個過程中，我想作為專案經理，有一個思想必須明確，那就是專案管理的目標就是實現專案的目標，結束專案。這個理念應該貫穿專案管理的始終，所以，在最初和使用者交流時，我們就要考慮該專案如何才能結束，它需要達到什麼樣的目標使用者才能夠認可，該專案的大體成本是多少，公司對於專案開發週期有沒有限制，該專案存在的風險作為專案團隊能夠承受等。

具體到這個專案中，一開始，我就發現該專案最大的風險在與使用者覺得這個專案很簡單，同時對於需求卻還是比較模糊，當然這也是大多數專案的通病，我承認這個專案與金稅工程比起來確實非常簡單（比金稅工程複雜的專案也不多J），但是如果使用者抱著這樣的心態，必然會出現專案開發時狂趕工期，後期Bug滿天飛，需求改來改去，使用者諸多抱怨，公司一面獎勵銷售，一面拿研發人員開刀的情況。因此，我想怎樣找個合適的機會將專案開發的難度以及專案管理的理念與使用者溝通。

正在我苦惱的時候，使用者提出他們資訊中心的技術人員希望進行一次培訓，以掌握該專案中的Java等技術。我知道，機會來了，在十天的技術課程的安排上，我專門抽出了一天的時間講解專案管理，課程安排發給使用者後，使用者發現了我的小祕密J，專門打來電話問我用一天時間講解專案管理是否有必要，抓住這個機會，我先給資訊中心主任講了講專案管理的重要性，以及這個軟體的難度、風險、週期等，讓使用者同意了該要求。在專案開始的時候，獲得客戶方專案經理的認可是非常必要的，如果你的理念和做法在一開始讓客戶方的專案經理感到很難認可，我想，專案做起來的難度會非常大。

接下來就是合同的簽訂和為期十天的培訓，在培訓中，我將PMBOK的專案管理理念貫穿到整個培訓中，尤其是最後的專案管理的講解，基本上達到了預期的效果，讓客戶認識到軟體的開發絕對不是程式的編寫，它涉及到方方面面，一個成功的專案沒有客戶的配合和參與是很難成功的。對於專案的結束，我也與資訊中心主任作了多次溝通，雙方基本互相瞭解了對方的需求和想法。這對於後來專案的順利進行打下了良好的基礎。

通過該專案的啟動，我發現，在啟動時如果有條件，對客戶進行一次培訓非常有利於專案的順利進行。在培訓過程中，可以和客戶成為朋友，同時把自己專案團隊的開發方法和客戶作認真的交流，讓客戶認可開發團隊，而且經過培訓時間的緩衝，一方面，可以組織其他技術人員對於專案中可能出現的技術難關進行突破，另一方面可以在私下裡和客戶交流專案需求，這種非正式的需求交流往往比正式的需求交流更容易知道客戶發起專案的初衷和客戶希望達到的目標。

2、計劃

在計劃階段，一開始應該結合啟動階段對需求的大致瞭解做出大略的計劃，明確專案的結束日期，該計劃一方面要提交給使用者，另一方面要知會全體專案組成員和公司專案管理部門或公司領導。當然，這裡明確的專案結束日期一般情況下都和專案的真正結束日期相去甚遠（到目前為止我還沒遇到過特殊情況），這不要緊，因為在需求調研結束後，還會再細化專案計劃，重新明確專案結束日期。但是不管如何明確，這時的專案結束如期往往受到來自客戶、公司等方面的壓力，做出的計劃總是按照一種理想狀況安排的，例如下面就是我在需求結束後作的專案計劃：

這個專案計劃就是在客戶方的領導及公司的雙重壓力下做出的，這個時候，專案經理必須保持清醒的頭腦，不管計劃上的專案結束時間是多少，心裡必須清楚實際完成的大致時間和計劃時間的差距，以及這種差距客戶機公司是否能夠承受。這樣，在專案進行過程中，再根據情況對計劃逐步調整，逐步向客戶和公司彙報調整原因，容易達到客戶和公司雙方都基本滿意的結局。如果差距過大，就要據理力爭調整計劃，當然，這是比較困難的，但比起最終被客戶和公司雙重責難，還是比較值得的。

上面的計劃提交後，我估計最終的結束時間大約要比計劃晚5周左右，主要是對於系統修缺，也就是試執行開始後，使用者必然會提出許多意見，2周的時間應該完成不了，但是，如果直接在計劃上提出7周的時間，使用者絕對無法接受，公司也無法接受，專案可能就會陷入停滯，在壓力下，我做了2周的修缺，那麼，到時候怎麼辦呢？我通常的做法是，在儘量爭取長的修缺時間後，首先保證試執行的基本按時進行，這一點，相信大多數專案團隊都能夠保證，然後，在開發時採取多版本上線的方式，儘量讓使用者儘早提出修改意見，爭取儘早開始修改，第三，在試執行開始後，使用者提出意見時，及時調整專案計劃並及時通知使用者，讓使用者明白當他的意見被採納後，專案結束時間將被推遲到什麼時候，給使用者一定的壓力，可以減少意見量，儘早結束專案。還有，就是在可能的情況下，儘量將實際的估計時間和自己的主管領導進行溝通，獲得他的支援，保證無後顧之憂（這一點很重要，不過就看你和領導的關係了J）。

事後證明，我當初的估計基本是對的，專案結束的時間大約比計劃時間晚了4周左右，這是由於使用者對於軟體開發的熟悉和配合，如果碰上比較麻煩的客戶，時間大約會再晚一些，但只要事先有充分的估計，就不會手忙腳亂。

3、執行

執行過程相對比較順利，由於和客戶保持了良好的關係，得到了客戶的大力支援，基本上沒有提出刁鑽的問題。在這個過程中，一開始的部分，我們是在公司開發，這個過程中，我們開發了部分模組，作為0.1版，到現場給使用者進行了安裝。

這樣做，我認為有幾個好處，首先，可以讓使用者感到專案一直在進行，而不至於破壞和使用者的信任關係，其次，可以儘早瞭解現場的實際情況，如果發現問題，及時調整開發方向或者讓使用者調整現場環境。再次，可以讓使用者對部分模組儘早提出修改意見，在開發其餘模組時，就可以對這部分進行修改，同時把意見貫穿到其他模組中去，減少後面修改的時間。

開發大致結束後，我們進入現場給使用者進行安裝除錯，然後再進行系統修改，這是最艱苦的時期，在這時，使用者、公司、專案團隊都很容易疲憊、厭煩、憤怒、絕望，並把這一切的罪過都堆到專案經理的頭上。所以這時作為專案經理，要保持高度的警惕，必須有完整的專案日誌，記錄每天的進度；必須保持和使用者方專案經理良好的溝通，隨時將問題及進度報告客戶及公司，讓他們明白每天專案團隊在做什麼，為什麼結束時間會一推再推；必須觀察專案組成員的情況，防止由於疲憊而出現人員流失的現象；必須隨時提醒自己，專案的目標就是結束專案，所作的一切都要圍繞結束專案而進行。

在這個過程中，我們專案組基本熬了過來，在我的預想時間內結束了專案，雖然還有很多不令人滿意的地方，但畢竟隨著專案的結束，大家的壓力減輕，可以更好的總結經驗。

4、控制

在專案進行的過程中，會出現各種各樣想象不到的問題，遇到這種突發情況，需要專案經理及時解決。

在這個專案進行的過程中，在開發進入最關鍵的時刻，專案組的技術骨幹突然提出要離職，這是我事先沒有思想準備的，如果他真的離職，將會對專案造成極大的麻煩。這個時候，我和他進行了長時間的溝通，瞭解他離職的原因，如果能夠挽留，儘量挽留。

經過交流，發現他提出離職是基於三個原因，一是對公司長期的不滿，在一個公司待長了就會對公司產生種種不滿，這是人之常情，雖然我提出增加薪水及提升職位，但很難讓他對於公司的不滿得到根本解決，二是具體生活的壓力，在我們這個二級城市的薪水待遇很難解決結婚買房等具體壓力，因此他希望能夠到北京這樣薪水待遇比較好的地方，這也是我們公司目前面臨的人員流失的重大挑戰，但這個問題短期內恐怕沒有更好的方法，三是對於外面世界的嚮往，在一個二級城市呆的時間長了，對於北京這樣緊挨的全國資訊中心必然產生嚮往，希望技術、思想等各方面能夠在北京得到提升。

這些問題也是普遍問題，我無法通通為他解決，但為專案考慮，經過勸說，由於平時大家關係非常好，他答應留下來一個月左右的時間，解決好他負責部分的技術問題，同時做好交接工作。這對於專案來說，危機就解除了，因為有一個月的時間，完全可以安排好一切。

針對這樣的危機，我想，作為專案經理，一是平時就要注意和團隊成員的關係，當發生各種情況時，即便是用人情，也可以幫助自己度過危機；二是對於許多問題，要在平時就瞭解到團隊成員的需要，能幫大家解決的，盡力解決，不要等到發生問題的時候，實在解決不了的，要讓大家知道公司的難處和具體環境的限制，不要讓大家記恨公司；三是要牢記團隊建設的核心是團隊成員的個人發展，要給每個成員成長的空間，包括技術、薪水、職位等，否則，一旦團隊成員達到發展的頂峰，就會感到沒有前途，離職恐怕是必然的選擇。

5、收尾

收尾階段最大的困難是什麼？進度！這個時候，面臨專案結束，所有人對會對進度非常關注。如何設法說服使用者，結束沒完沒了地更改，順利地結束專案，是每個專案經理都必須面對的問題。

在這個專案中，由於前期作了大量的工作，在臨近收尾時，我們準備了完備的文件，解決了當前存在的Bug，並承諾了以後的服務，雙方都比較滿意，順利地簽署了初驗報告，使用者也支付了專案款項，結束了該專案。

所以，我覺得，順利地收尾並不取決於收尾階段的工作，而是要把收尾工作貫穿到專案始終，如果前期準備充分，收尾時最大的衝突，進度，就不會成為專案經理最大的問題，相反，如果收尾階段才開始考慮如何結束專案，那恐怕專案的結束就會遙遙無期。

這個專案目前除了日常維護和簡單的修改外，已經沒有大量的工作了，雖然專案的順利結束，有很多偶然的因素，例如使用者的積極配合（這在其他專案中是少見的，一般是使用者的百般刁難），但我想，他仍然具備一些中小專案共同的特點，作為專案經理，我提出來和大家分享的目的是希望我們總結經驗，能跳出專案的焦油坑，順利地結束每一個專案。