專案背景：中國建設銀行資料集中工程（簡稱DCC）於2002年7月份啟動，目標是在全國建立南北兩個資料中心。專案完成後，38個分行的資料將全部集中到總行資料中心，而部署在分行的是大前置系統（簡稱大前置）和網點前端系統（簡稱前端）。大前置是這次資料集中專案的核心，除了接入前端的櫃面業務外，還整合龍卡、清算、重客、網銀等二十餘種重要業務系統。該專案中神州數碼負責大前置和前端系統的開發、切換，IBM負責後臺主機系統升級改造。自2002年10月起，神州數碼投入了60餘人的開發隊伍在建行外高橋開發基地進行了為期10個月的封閉開發。至2003年8月24日，經過24小時的系統切換，DCC在首個試點行—上海分行成功上線。全行327個網點一次切換成功，目前整個系統執行穩定。

筆者在DCC專案中任神州數碼的專案總監，統一管理大前置和前端兩個專案。本篇文章將結合筆者在專案中的切身經歷，談談大型軟體專案管理中的一些實際體驗。

發現問題
筆者是在中途被匆匆調入專案組的，之前只被告知專案遇到一些困難。進入專案組還不到一週即發現：儘管專案中聚集了神州數碼各方面的骨幹，但專案中存在的主要不是技術難題，而是管理的問題，主要包括三個方面：

在管理模式上，因神州數碼與客戶分別簽定了分行大前置和網點前端兩個專案，所以專案由兩套幾乎獨立的團隊分別管理，各組之間推諉、爭執時有發生！這一方面造成專案組效率低下（客戶反映總是面對兩組人，溝通困難）；另一方面，像系統切換這樣一些在中間地帶的重要工作卻無人問津。在工作方法上，壓力沒有得到傳遞，專案骨幹壓力巨大，但組員卻相對輕鬆；另外由於工作量嚴重不平衡，存在人浮於事的現象。

在客戶溝通上，缺乏必要溝通技巧和客戶意識，造成客戶關係緊張；而對於這種情況，專案組一些成員卻認為是客戶在故意找茬。

分析和解決問題
經過分析，產生上述三個問題的原因主要有以下幾點：一是缺乏一個統一的核心班子；二是缺乏有效的工作方法，特別是工作重點工作不突出；第三是缺乏與客戶在正式場合之外的非正式溝通渠道。

在明確問題原因之後，陸續採取了以下一些措施：

調整了組織結構不再按合同劃分大前置和前端兩個專案，而是按系統平臺、應用開發、切換和推廣劃分為四個小組，並明確了各小組職能。

確定重點工作核心組第一件要確定的事便是專案的重點工作。因資源有限，要確保上海分行按時上線，必須確定專案重點工作策略。當時確定的兩個重點包括：
一是分行大前置系統。一旦出現問題將造成整個分行業務癱瘓，所以系統的效能、可靠性事關全域性。因此，對於大前置系統的壓力測試和效能最佳化是第一重點。

二是系統切換。切換工作必須由經驗豐富、組織協調能力強的人員擔負。因切換工作啟動已經晚了，再從公司調集人員已經不可能，權衡再三決定讓前端的專案經理負責切換小組。事後證明雖然這一定程度上削弱了前端組力量，但系統切換工作確實完成得非常出色。

兩個非重點包括：

一是對於網點前端系統，因當時認為應用上變化不大，測試中發現的問題不多，所以比較放心。因為未作為一個工作重點，反而從該組調出了不少資源支援其他小組。但事後證明這個判斷是錯誤的，一是當時測試密度低，暴露的問題少，才造成了系統缺陷少的假象；二是後期突然修改憑證，客觀上大大增加了工作量；三是全行有近330個網點，多點版本管理的風險未引起足夠重視。所以，在後期大量進行修改時不僅人員工作強度極大，還一度造成版本管理的漏洞。

二是分行推廣。因推廣工作有一定的時間緩衝，所以當時的策略就是在不從專案組抽人的情況下儘量滿足分行支援的需求，同時優先從公司其他專案調集資源。事後證明，當時這個策略是非常正確的，對集中優勢資源保證上海分行上線起到了不容忽視的作用。

明確各組的工作目標透過會議落實各組的目標，如大前置效能必須透過的專門的壓力測試；前端組必須24小時內對變更和缺陷修改做出反饋；切換組要求將切換方案細化到單個任務的命令清單和驗證清單；分行推廣組力保不從專案組抽取人員。

穩定隊伍，嚴肅紀律和鼓舞士氣核心組任務明確後，下一步要完成的就是“帶隊伍”。首先，根據重點工作和目標要求，專案組減少了8個工作任務不明確的人員，這對留下的專案成員反而是種觸動；其次，與個別不穩定的員工進行了談話，在解決了具體問題後一些員工表現出的活力遠遠超出想象，最終只有一個人真正離開專案；第三，嚴肅紀律，對於不經同意擅自離開的人員如無明確理由一律嚴肅處理；第四，因專案週期長，所以跟公司協商按階段進度落實了部分獎金，一定程度上提升了士氣。

培訓骨幹，改進工作方法首先強調幹部要以身作則和親臨一線。其次，學會用合理的方法分配工作，如修改PTM（測試缺陷）過程中，將收到的PTM分配到每個人頭上，並在白板上公佈，同時及時更新完成狀態。

提高客戶意識，加強客戶溝通要求大家重視非正式溝通渠道。比如，在正式會議之前，對於要彙報的內容與客戶通氣，也要提前瞭解客戶要反映的情況。一次，在一個重要的會議前客戶反映大前置監控系統“根本不能用”，經進一步瞭解情況其實是使用者介面不友好，而我方的工程師態度又比較生硬，造成客戶不滿做出上述結論。如果按“根本不能用”報告，會議上沒有時間解釋，也很容易發生爭執，勢必對我方極為不利。而經過會前溝通，我方同意限期修改，客戶也同意在會上報告是“介面問題”，於是這個問題的性質就發生了根本的變化。
經過上述一系列調整措施之後，專案組的情況得到了很大的改觀。在隨後的4個多月中，各個小組都克服的重重困難按規定完成了任務。一個典型的例子是前端小組。前面也提到，由於判斷失誤對重視不足，提前從前端組調出了過多的人力，從而使專案後期前端小組遇到了前所未有的困難和空前的工作壓力，但他們不僅創造了2天完成60餘種憑證列印程式開發測試的奇蹟，並在連續2周的白天整體測試、晚上修改PTM和釋出新版本的高強度工作中表現出了驚人的能量。上線過程中，在公司高層對建行客戶進行拜訪時，建行高層領導對神州數碼專案組的成績給予充分的肯定，特別對前端組的這種拼搏精神和取得的戰果給予了高度的評價。

筆者對該專案有幾點感觸至深：一是成功的專案對於團隊的依賴性不容忽視，沒有好的團隊即使再完美的計劃也得不到實現；二是好的專案管理方法不在於多先進的理念而在於把準脈，有時一塊白板的作用遠遠大於一套理念，與客戶幾分鐘的會前溝通遠強過30頁的PPT文獻。第三，要記住團隊的個體是一個個活生生的有感情的“人”，而非“6個二級程式設計師”，他們有不同的性格和思想，只有在喚醒他們的團隊意識和潛能之後，你才能看到一個無所不能的巨人，那就是你的團隊。[@more@]

專案管理從改變團隊開始（轉）

相關文章

專案管理從改變團隊開始 （轉）

相關文章

專案管理從改變團隊開始（轉）