Tuesday, September 23 2003 2:09 PM 項目背景：中國建設銀行數據集中工程（簡稱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個二級程序員”，他們有不同的性格和思想，只有在喚醒他們的團隊意識和潛能之后，你才能看到一個無所不能的巨人，那就是你的團隊。
浙公網安備 33010802003509號
杭州講師網絡科技有限公司
