一個真實的項目經歷，很多東西大家可以借鑑下

【背景介紹】
Z公司接了一個國外客戶Y的交易系統開發實施項目，雙方沒有簽署任何的協議，Z公司希望通過這個項目的合作，將此係統作爲產品佔領該國市場。
項目的組成人員包括1個PM，10個左右開發人員，4個左右測試人員，1個翻譯，外加工程、市場、銷售、客戶經理等，總共約20人蔘與此項目，項目管理和交付由PM負責。PM有多年行業經驗，但是無項目管理經驗。Z公司對客戶承諾：核心團隊將在客戶現場開發。
由於雙方無協議，所以項目的進度安排完全由Z公司決定。傳言此項目合同將達到200萬$，項目經理估算可以在6個月內上線成功。項目進展過程如下：
(1) 項目從2008年1月份啓動，按計劃將在6月份上線成功；
(2) 但是6個月後，發現系統不能滿足對方的交易要求，交付時間將無限期推遲，同時合同額將會少於200萬RMB（是不是人民幣升值太快了？。。。）；
(3) 10個月後，由於一些政策的需要，客戶不得不使用這個交易系統；
(4)15個月時，Y公司根據集團公司的要求，召開招標會，Z公司的項目領導堅信必定中標，可是經過2輪招標，本地公司中標；雙方繼續溝通中。
(5)17個月後，終於宣佈停止開發。Z公司依然派人在現場做維護，希望客戶能夠租用此係統。（第一次聽到，軟件系統可以租用......）
歷時17個月，始終保持近20人的團隊，而且平均10人長期客戶現場開發，成本高達700萬RMB，白花花的銀子就這樣沒了......

【敗因分析】
根據項目的實施過程，導致項目失敗的原因相當多，主要有：
1. 工作量估算方法錯誤。如果說工作量估算錯誤，是整個項目組的責任，那麼估算方法錯誤，是PM的責任了。PM是這樣估算的：根據人員配置情況，我們需要9個月完成，但是我們可以通過晚上加班和節假日加班，我們可以把交付時間縮短30%，這樣就可以6個月完成了。一般的項目經理都會在工作量估算結果的基礎上，再增加20%的冗餘度，他卻壓縮了30%，佩服，高手。
2. 項目計劃混亂。一開始的時候，有個初步的項目計劃，但是沒有落實到具體的WBS上，後來，項目計劃都沒了，項目已經沒有終點了。
3. 不懂項目管理流程，沒有系統開發實施經驗。不去了解客戶的需求，悶頭編碼，一個簡單功能，要修改N次，不僅降低客戶滿意度，同時導致生產率及其低下，估計有效代碼的生產率不超過10行/人天。直到17個月後的今天，還沒有完整的客戶需求。
4. 模塊包乾，缺乏溝通。整個開發過程，只有編碼，把整個系統分成若干模塊，每人負責一個或若干個模塊，從瞭解業務到編碼完成，都是一個人負責到底。由於缺乏必要的溝通，各個模塊的融合性存在相當大的缺陷。
5. 項目組缺少必須的溝通能力。這包括2方面：語言能力和需求溝通能力。由於是國外客戶，長期呆在客戶現場的開發人員沒有1人可以和客戶用英語進行溝通（甚至英文郵件都寫不來），包括項目經理，雙方的溝通必須通過翻譯來實現。這樣一來，開發人員獲得客戶信息肯定會打折。可能由於以前都缺少需求收集的經驗，開發人員不會主動去收集需求，最後通過N次溝通，得到的需求仍然是不完整的。每次得到1個要點，然後立即修改，下一次演示時，客戶說還有1個要點，開發人員又去修改，如此反覆。甚至連項目經理都說“客戶沒有需求”。暈死了，沒有需求，對方願意花幾百萬做啥？不是客戶沒有需求，而是項目組不會收集需求、挖掘需求。
6. 忽視測試組的作用。整個過程中，一直不重視測試組的作用，需求也不會發給測試組，更多的只是由開發人員口頭轉達；很多時候，開發組不經過測試，就將升級包直接扔給測試組測試，測試組對模塊功能有異議，開發組一般是不會做出調整的。
7. 版本發佈升級管理太爛，軟件質量差。一方面，開發組提供的升級包或者新版本，很多時候是沒有經過測試的，很多次，在升級後，系統的核心模塊就直接不能使用。另一方面，升級太頻繁，10個月後，幾乎每天有升級包；有一陣子，每天的升級包超過3個。提供給客戶的升級包，約80%不能用，也就是說發送5個升級包，纔有可能1個升級包是正確可用的。Z公司一向對客戶宣稱系統的性能超級優越，在全球同行業中可以排第一，但是項目組測試人員卻抱怨系統運行太慢，點個按鈕半天沒反應。系統運行結果經常出問題，項目組採用的彌補措施是直接修改數據庫記錄。
8. 客戶關係逐漸僵化。由於缺少需求收集的過程，開發人員完成的功能肯定不能一次性滿足客戶的要求，導致需求變更的次數很多。最後開發人員開始拒絕客戶的需求變更，理由也相當充分，比如“我們的系統設計（或者架構）不支持這個功能”、“國內沒有這個業務”等等。
9. 人員管理混亂，獨攬大權，一意孤行，合適的人不在合適的崗位。項目經理喜歡直接把任務指派給每個人，包括測試人員，他大事小事百事都管，小到bug工具的維護，大到客戶關係的維護、部門節假日放假安排，都要插一手。項目組中也有英語尚好，能夠與客戶溝通的人，但是這幾個人基本上都留在國內。工作時間安排超長，周1到周6，現場工作時間從早上9:00到晚上22:30，相當疲勞，效率極低。管理混亂，不僅在此項目中體現，而且整個部門管理混亂。部門經理是空降兵，一直在海外知名外企做高層管理，部門成立將近1年，從來沒有看過1次部門全體人員會議，一共才2個項目，他卻啥事都不管，推說“這是小事，自己要忙更重要的事”。
10. 團隊成員缺少大局概念。項目的不斷拖延，大家都已經無所謂了，今天做到哪裏是哪裏，做不完了，也可以無限期的拖。甚至有人說：“項目做長了更好，出差補貼拿得多，我暫時還不想回去呢。”
11. 沒有交付的概念。他們對客戶做出了很多次的交付承諾，這些承諾基本上是空頭支票---不可能真正交付的。到了承諾的時間點，他們要麼把交付的時間點延後，要麼就是給客戶演示一下，看一下界面，就算交付了。給客戶的文檔中，沒有培訓手冊或者操作手冊，反而把接口設計說明文檔給客戶。
12. 管理層缺少成本管理意識。項目做了8個月的時候，根據項目進展情況和客戶的態度，就有成員內部在交流，懷疑這個項目的可能性，甚至建議直接停止這個項目。但是部門經理、項目經理、銷售一直在吹捧這個項目。當時的成本已經遠遠超過200萬了。
13. 你能否容忍2套系統同時使用？系統目前上線，但是需要老系統配合使用，業務人員每天在2套系統之間倒數據，我想這是任何一個業務人員都無法忍受的工作。據說招標的時候，就是因爲業務人員的強烈反對，客戶才決定不用我們的系統。爲什麼不把必須的功能做到新系統中呢？
14. 想要破壞商業潛規則？項目負責人對這個項目信心爆滿的一個主要原因是：客戶的一個副總收禮了，如果項目不給我們做，我們可以搞他。我真的覺得他們好幼稚，你有能力破壞商業潛規則嗎？更何況是在異國他鄉......

【反思】
整個項目，都是一個徹底失敗的項目。商務上，客戶關係丟失；成本上，17個月超過300個人月的投入，高達幾百萬RMB的投入，全部付之東流；項目管理上，一團糟糕，團隊如同散沙，先後至少有10人離開；團隊成員仍然無法完成需求收集，無法團體完成系統設計，唯一的提高就是Delphi編碼能力和Oracle應用能力。
此項目最大的敗因就是：項目經理缺乏項目管理經驗。一味的以爲“有行業經驗就夠了，其他都不需要”，錯誤的以爲“全球的交易業務都是類似的”，從而導致項目計劃盲目樂觀，不去分析客戶的需求，悶頭就編碼。


【雷言（雷人的名言）】
1. 我們這個項目要啓動了，去，在Mantis上立項。
2. 你們怎麼可以沒有護照呢？在中國，護照和身份證一樣重要，要天天隨時帶在身邊。唉，你們這些人辦事真是的。

QQ羣裏的記錄
CC(320***86) 11:28:36
web的系統全世界都是一個樣,沒看到過好的,工行,招行都很垃圾
CC(320***86) 11:28:50
微軟就更糟糕了
EE(804***99) 11:28:52
頂！
YY(190***01) 11:28:55
有亮仔
CC(320***86) 11:29:01
我們的交易系統已經算不錯了