專案（Explore）總結之專案概述

人都是有惰性的，總想著對幾年前的這個專案（代號Explorer）做一個總結，但又總是給自己以各種各樣忙的理由給耽誤著，是懶亦是不堪回首當年的過程。

近段時間專案不多，閒來還可以學習點專案管理的理論知識，本著無事就寫總結的思想，試著從理論的視覺重新審視一下這個專案。下面首先是對專案作一概述，然後接下來的幾個章節，從專案管理的九大知識領域對此專案作一總結。

§1.1  專案概述

下面從專案背景、專案過程等方面對該專案作一概述。值得一提的是該專案代號為Explorer，寓意開拓，寄語技術有所創新，市場有所擴充。

§1.1.1背景

時間追溯到2004年，話說公司在某地市（下稱D市）給某機關開發業務系統，專案銷售經理（下稱J）經常與當地政府部門的人打麻將，這其中有一個雀友正是客戶資訊部門的二把手（下稱Y），閒聊過後，惺惺相惜，相見恨晚。自此建立聯絡後，在05、06年給客戶做了一些不痛不癢的外圍小專案，但一直未能深入接觸到客戶的核心業務系統。從客戶資訊部門瞭解到，業務系統是客戶資訊部門聯合外部資源基於C/S開發的，後臺資料庫是Oracle，客戶內部除了當時負責開發目前在負責維護的技術強人G工外，沒有人熟悉這套系統，當時聽起來感覺這G工還挺N的嘛：其他人都不懂就他能懂。

說起G工，有一次與J去拜訪客戶，正跟Y聊天，從機房出來一個人，不高不矮不胖不瘦，也就是通常所說的“其貌不揚”，Y給介紹說：這位就是G工，呵呵，原來這就是傳說中的G工。經過後來的接觸和交流，感覺G工是一個以自我為中心又十分自傲的人。首先，說起話來，總是說以前自己的科技論文寫得如何如何、現在有什麼技術問題又是如何如何自創方法解決，一副捨我其誰的氣派；其次，對別人與他自己無關的談話內容基本不感興趣，插話的時候不太理會其他人的感受經常改變原來的話題。當時的反應嘛，既然你是客戶，愛咋就咋地，基本上是附和著，偶爾還拍拍其MP。不過也在想，這麼一個好像誰都不放在眼裡的N人，做他的上級不是很難受？

隨著一些小專案的開展實施，跟資訊部門的人也逐漸熟絡了，閒聊之餘瞭解到除了G工的直接老闆B外，G工對其他老闆都不爽，當然，其他老闆對G工也不爽，但迫於業務系統捏在G工手裡，實在是有氣無處出。當時在想：這樣下去，G工遲早會下臺，而恰恰正是我們的機會。果不其然，在不算太長的時間後，我們就在友好合作的情況下開始進場接手業務系統運維。當然，為了能夠接手業務系統的運維，當時帶了2個人，花了差不多5個月時間天天在啃業務系統的遺留程式碼，沒有任何技術文件、沒有詳細程式碼註釋，硬著把前後臺之間的關係、後臺資料庫物件（如表、過程、函式等）之間的關係基本弄清楚。

舊系統運維不是長久之計，就這樣，專案Explorer應運而生了。

§1.1.2實施過程概述

專案從簽訂合同到驗收，耗費大概180個人月，前後歷時將近2年時間，其中有1年多的時間天天在加班，兩年的五一和國慶大多是在加班中度過，本人“有幸”作為這個專案的PM，親歷了這個過程，這樣的一個過程對於每一個人來說都是一種煎熬。不過，值得欣慰和難能可貴的是團隊成員離職率在專案過程中一直保持在10%以內，核心骨幹成員基本沒有離職。後來分析原因，有人笑稱這是因為太忙，沒有時間去思考，另外當年的自己都很年輕，都比較傻。

說回實施，專案中標後，大家都很高興：可以做一套屬於自己的核心業務系統，建立根據地了。但同時，大家也很擔心：公司沒有做過類似的專案（基於B/S的核心繫統），沒有任何的技術積累，沒有足夠多的高水平實施人員。專案風險很高，怎麼辦？當時想了個招，根據客戶資訊系統分散不統一的現狀，建議客戶分階段分批上線，這樣一方面可以很快的為客戶創造價值，一方面是完成技術積累和建立核心團隊，客戶對此沒提什麼意見，稀裡糊塗的也就同意了。

按此實施方案，開始制定計劃，當時做這個計劃基本是沒譜的，沒有工作分解結構、沒有工作量估算、沒有同行評審，大多憑著之前的經驗，拍腦袋確定，於是一份初定在次年的7月份整體上線執行的計劃擺在了客戶和監理面前。計劃裡面，上線的時間點有6個，分別是：

1.12月：核心系統X1上線；

2.次年3月：核心系統X2上線；

3.次年6月：核心系統X3、X4上線

4.次年7月：核心系統X5上線

5.次年8月：核心系統X6上線

6.次年10月：外圍系統上線

希望總是好的，現實總是殘酷的。實際上，X1在12月磕磕碰碰上線了，Bug改了3個月後系統才穩定下來，還產生了著名的“星期五現象”（每週五發布程式，下一週週一系統都會出問題）；X2延遲到次年6月才上線；由於計劃調整， X5在次年10月份上線，X6在次年11月上線，X3和X4則在次年的下年3月上線，外圍系統由於客戶需求變更，在驗收後才完成。專案之所以出現這麼大的計劃偏差，根源在於專案團隊無論是管理水平還是技術水平，都不足以滿足拍腦袋制定出來的計劃要求。

§1.1.3 組織資產積累

       資產積累需從過程和結果兩方面分析。首先，過程上，失敗的專案過程本身就是組織過程資產的一部分；其次，結果上，技術方面，研發了一套通用的前臺開發架構、一套數十萬行原始碼的業務系統；人員方面，透過專案一批程式設計師、系統分析員成長為系統分析員和PM，此後的軟體專案均受益於該專案的積累。

-------------------------- 本文可任意轉載，但請註明作者和出處 ----------------------------