一個項目經理對項目「成功」的反思

來自專欄 軟體工程

自1996年，作者開始正式接觸並從事信息系統軟體開發與集成方面的工作。本文為2003年參加信息系統集成項目經理培訓後，結合自身經歷，對信息系統集成項目「成功」整理的一些文字。

當時，作者已陸續參與或直接管理過教育、工商、公安、航天、煤炭等行業軟體項目以及在新任職公司參與的一些政府、企業辦公軟體。在這次反思過程中，最大的觸動是下面的一系列問題：

對以前所經歷的項目，尤其是一些所謂「成功」的項目是不是真的是成功了？

進一步努力的方向和餘地在哪裡？

怎樣才算得上是一個合格的、真正意義上的項目經理？

怎樣才算得上是一個高效的、健康的、真正意義上的項目團隊？

怎樣才算得上是對項目進行了有效、可靠的管理與控制，使項目的成功有了真正保障？

怎樣才算得上是真正意義上成功的項目？……

案例一：「項目」往往只是進行了「開發」工作。

曾負責某校「教學管理系統」軟體的開發項目，當時開發周期僅僅3個月。沒有需求調研，僅僅根據用戶提供的一些表格開始進行資料庫設計與程序開發；開發過程中也幾乎沒有和用戶進行交流；項目小組4個人，有2人幾乎沒有參與到項目中來，基本是作者自己設計、「開發」；值得慶幸的是：最後，用戶是「認可」我們工作的，軟體的後來使用情況如何不得而知。現在回想起來，存在很多問題：

問題1：項目缺少需求調研階段，項目範圍不確定

最初，根據我們自己的認識，「閉門造車」式的完成了系統的分析。在設計資料庫表時發現，這樣的「需求」根本無法確定，於是在系統設計過程中對需求開始進行細化。

通過對其輸出要求的數據入手進行分析發現：用戶主要希望通過該系統實現自動排課、學生檔案查詢、教師檔案查詢、學生參加課程情況、教師承擔課程情況、學生課程成績、班級課程成績排名等信息的列印輸出。

於是針對信息的不同類型對數據進行了合理設計分為：學生檔案、教師檔案、班級信息、教室信息、課程信息四類元數據；通過排課、錄入考試成績等操作建立信息的關聯，從而形成課程排課表、課程成績表等計算數據。根據查詢與列印的要求，建立相應的檢索表。

利用這種「倒推法」，最終我們贏得了用戶的「認可」。

回想起來，從項目範圍上有很大的風險性：因為是無的放失，針對不確定的需求開展項目，所謂「成功」靠的是個別項目成員的開發經驗與良好的客戶關係，對項目範圍沒有進行有效管理和控制。

問題2：項目組織不力，沒有調動起全部的資源，質量與進度也難以控制。

當時的想法很簡單：那兩個成員是「新手」，與其教會他們，還沒有完全靠自己開發出來快，時間「等不及」。現在看來，是缺乏有力的項目組織與管理。如果嚴格按照軟體工程的步驟，做好詳細的系統設計，事實上個人的開發技術將不再是瓶頸。而且，設計人員過多的參與開發本身就是資源的巨大浪費。很多可以並行的工作只能逐個實施，使項目進度得不到保障。

當然，最理想的項目組是需求人員能夠挖掘到並把握客戶的真正需求，設計人員能夠完全把握需求人員的系統規劃意圖，開發人員能夠完全實現設計人員的設計要求。但是這樣的項目組往往很難找到，即使確實存在也會很容易被公司分散到不同項目。使項目組成員在項目過程中受到良好的鍛煉，本身就是項目經理應該考慮的事情。如果缺少達到期望要求的項目組成員，那就更需要逐步培養他們。

與此同時，其他項目成員參與的很少，意味著該項目的質量寄托在個別人的個人才能與經驗技巧上。一旦出現疏漏、考慮不周，往往需要返工，缺乏穩定的質量監控機制，系統質量與實施進度都無法保證。從這一角度上講，該項目在管理上是十分失敗的。

問題3：項目浮於客戶需求的表面，為了信息化而信息化，並沒有做深層次的工作。

就當時的項目實際而言，我們提供的交付物：該軟體是針對於特定業務的，至於該業務對學校工作有無深層次的意義和影響，當時根本就沒有考慮，充其量不過是一個方便的列印、查詢工具而已，難以稱其為「系統」，由於最初設計的局限，採集的信息數據再利用也存在麻煩。

總體而言，該項目完成了客戶交給的開發工作，至於為什麼開發，又開發了一個什麼東西卻並不是很清楚。同時，對項目沒有進行有效的管理與控制，項目經理在項目組中僅僅是帶頭開發的程序員，既不是什麼項目組織者，也更稱不上是項目的管理者。

案例二：「項目」往往迴避了客戶真正的需求。

客戶真正的需求往往需要仔細研究才能獲得，系統規劃初期，難以發現客戶真正的需求。到後期，為了項目的「成功」，總是不得不迴避掉那些用戶的真正需求，使系統的可用性降低，使我們的整個行業解決方案大大折扣。

問題：所忽略的正是用戶所需要的

2001年，曾負責一集團型國有企業的辦公自動化項目建設。在兩周內，我和一位同事「高效」完成了該系統的需求調研、用戶評審工作，得到了該系統的軟體需求。

最初，我們並未真正領會所謂的「二級單位OA系統」意味著什麼。只是想表示將來的系統可以為二級單位所使用。對於二級單位的需求只是看了一個重點單位的情況，並未做全面、深入的了解。

實際開發出來的系統是單層的，根本不存在二級系統的概念。最初，客戶並未馬上提出二級系統的需求。系統試運行後一個月，用戶提出在二級單位的OA系統如何實現的問題，並提出如下具體要求：

1. 二級OA系統業務模塊組成與第一級OA系統基本相同，但具體功能要求、表現形式的要求有所不同；
2. 二級OA系統要實現與第一級OA系統間的數據通訊和網路互通、互連，同時數據存放要保持獨立性，互不影響。

由於當時系統已經建成，我們對該需求進行了技術攻關分析，得出三種方案：

1. 二級單位各自有各自的伺服器，彼此分別建設獨立的系統，滿足不同級應用的要求，通過多伺服器間的數據級通訊實現互相通訊；
2. 仍然採用統一、集中的伺服器和應用資料庫，通過許可權來控制數據的獨立性，同時可以確保數據級的相互通訊、訪問；
3. 統一、集中的伺服器和分別存放的應用資料庫，通過個性化設置滿足各級應用的不同需要，同一伺服器的數據級通訊也不難實現。

然後，從技術難度、開發成本、所需工作量三個關鍵指標的角度，對上述三個方案作出如下分析：

經過分析，基於當時項目的進展情況，方案C是容易實施和可以讓各方接受的，同時也是與用戶的真實需求差距比較大的。

事實上，如果從設計之初意識到用戶真正的需求，在系統規劃、設計階段方案B是可以實現的，並且對成本、技術難度等指標的影響並不大。方案C是一種後續的、補救的方案，而不是技術實現上的最佳方案，同時開發商投入更多的成本，最終用戶卻獲得了較低的收益。

後來，該項目贏得客戶滿意度還不錯，這更多地源於我們的工作態度和規範的工作方法、習慣。單從技術實現質量上來考核，該項目不能算是一個成功的項目。

案例三 「項目」往往讓團隊「不堪回首」。

曾負責某行業業務系統的開發工作，當時已經有較為明確的客戶需求，規範的行業標準，也有足夠的人力，同時是專門的小組進行開發。面臨的問題是工期緊：一個月。於是，項目組進行了充分分工：資料庫設計獨立進行；業務模塊分塊突擊開發。一時間，各項工作齊頭並進。兩周後出現下列問題：

• 一項目成員離職，其負責的部分未完成；
• 各開發人員缺乏統一規範，開發結果各有千秋；
• 資料庫設計頻頻更新，同時發現行標中一些描述有二義性；
• 各模塊之間的銜接出現問題。

針對上述問題，在項目經理組織下，項目組採取了果斷措施：

1. 增加人手；
2. 按功能特性重新劃分任務，規範開發要求；
3. 整體規劃資料庫設計；
4. 整體規劃模塊間介面設計。

同時，項目組開始「趕工」：天天晚上加班、周周周末加班，到月末，只有一個模塊開發基本符合要求，其他80%模塊不是沒有完成、就是必須修改！但經過冷靜分析，我們得出如下結論：

1. 最初的進度要求在當時的資源狀況下根本無法完成；
2. 缺少統一的規劃和控制是造成後期開發進度、質量問題的重要因素；
3. 開發前的準備工作不足（分析行標、詳細分析需求、規劃設計）；
4. 中間的過程式控制制起到了良好作用，只是效果並未顯式的反映出來。比如：資料庫設計核心表格結構與相互關係已經比較合理，並趨於穩定。

通過上述分析，項目組決定，調整、更新原有的計劃組（進度、成本、資源等）將最終完成日期定為兩個月後。後來，該項目的開發按時完成，但項目組成員回憶起來還是後怕不已。當時項目組面臨的局面宛如噩夢、令人心悸！因為不僅僅是高強度的工作、無休止的加班，而且還面臨一個最鬱悶的情況：加班並不能解決問題，達不到預期的效果。

反思起來，主要是忽略了一個重要的項目管理原則：有些階段是不可逾越的，否則將為之付出慘重的代價。項目經理在原則問題上必須堅持立場，不能完全被動、機械地執行管理層行政命令。要分析，從技術角度進行分析，得出合理的方案，而不是一味迎合上層領導意圖，這樣才能對項目做到真正的管控。要不然，難免會讓大家有勁使不到點兒上。

該項目需求分析、系統設計時間很短，造成開發目標沒有很好地明確下來就開始了開發工作。同時，留給項目組成員的印象是「不想再想起這件事」。

十年前，曾參與實施工商行業某項目，項目開展的從表面過程上看很成功，最後用戶也對系統進行了驗收，但規模龐大的系統，使用率很低，根本沒有起到系統預期的作用，究其原因，主要有以下幾點：

1. 對客戶的宣傳、實施準備不足；
2. 客戶高層的實施力度不夠；
3. 系統本身的親和力不夠。

單純從技術上考察、從商務上考核，該項目無疑是「成功」的，但是，沒有用戶、沒有應用的項目又有什麼成功可言呢？

無數開發商都在高喊：「要讓用戶將系統用起來」。殊不知，要達到這一目標，項目經理和項目團隊在項目啟動之時就必須學會從客戶的角度思考問題，從客戶的角度來看待每一個項目活動和項目產品。

曾負責某醫藥行業項目，通過項目組的共同奮戰和「良好」的項目管理與控制，項目驗收了。但客戶的問題從來沒有終止過，雖然客戶也承認是自己不斷的在變換想法。

可是，反思一下：又何嘗不是我們項目組在項目建設初期可能忽視了用戶的某些隱式需求，沒有提供充分的、足夠的設計方案。真的追起責任來，恐怕最終用戶有20%，項目組（包括建設單位和客戶代表）要佔80%。

上邊所述的案例都是很普通的信息系統建設項目，反思起來，它們在說明著一些看似「成功」的項目，並不是真正成功的項目。

那麼，怎樣才是一個真正成功的項目呢？對於這個問題，很難做出被普遍認同的答案。但有一點是很明確的：項目經理作為項目成敗的直接責任人，不斷總結先前項目的經驗和教訓，在後續項目管理和控制中不斷改進和提高，將有助於項目的真正成功。

本文寫於2003年，首次網路發表在希賽網（於2010年1月），2018年5月修改後發佈於個人公眾號。