2023年-2023年，筆者參與了乙個大型專案，雲平台下做資源、資產、電子運維管理，由德勤負責需求整合、hp負責系統門戶和硬體整合，pccw負責實施整合。ibm、中興、亞聯、億陽等十幾家廠家做開發分包。專案合同額好幾億。當時我在pccw負責資源的實施管理，與中興、亞聯、億陽一起完成所有省份的實施，一期完成北京、山東、福建的實施。這也是我第一次接觸如此規模的專案，管理多家廠商與周邊十幾家廠商協調溝通。但不幸的是這個專案最終以暫停建設的方式告一段落（好幾億的專案，涉及客戶上上下下各個部門上千人配合工作，誰也擔不起失敗的責任，只能是暫定建設）。後面跟同事討論和覆盤專案失敗的原因和如何挽救這個專案。
失敗的原因總體來說有如下幾條：
1、 系統結構框架流程混亂。
2、 廠家分工不合理
3、 沒人牽頭做差異比對
4、 廠家利益牽扯鬥爭嚴重
5、 專案大躍進式前進
下面一一闡述這幾個問題。
1、系統結構框架流程混亂
這個專案是行業內其他的集團公司（甲）和集團公司（乙）已經建設過類似的專案，並經過十餘年的完善開發，目前已經基本上可以使用。集團公司（丙）的幾個領導考察後，覺得這個專案效果不錯，讓上馬該專案。但又不想花費十年時間去調整，想借鑑使用甲和乙的成功經驗。所以超了個捷徑，讓所有參與甲和乙這些專案的廠商都來參加丙公司專案的建設開發。本意是好的，而且丙公司和甲乙公司管理的東西和相關的流程基本類似，如果使用這些廠商做這些專案多年已有的經驗，確實能大大減少這個專案的成本和工期。
但由於有三個大專案，涉及的開發廠商太多，管理起來太複雜，丙公司就找了國際上知名的幾家公司做總體管理。hp做系統門戶和硬體整合，並沒有太大問題，hp是老牌的裝置廠商和it廠商，提供硬體，做系統門戶駕輕就熟。pccw做實施管理，有一定的問題，pccw沒有做過這幾個系統的人。不過從幾個開發廠商那臨時挖角挖來幾個人，而且實施管理來說相對簡單，了解這個系統，跟進實施進度即可，問題也不太大。德勤做需求管理相對來說問題很大，德勤是世界排名前三的諮詢公司，做一些管理諮詢問題不大，但做這幾個系統的需求管理完全不是他們的專業所在，臨時從幾家公司挖人，挖的人也不是很對。德勤做資源需求的人是從廠商那挖了個研發經理（張三）做需求設計。研發經理做需求和產品經理做需求完全是兩個概念，張三每次是根據我們大家提的問題，臨時解答，尋求解決方案。產品經理做系統需求是先做乙個總體框架，然後做裡面的需求設計。
在前期做開發，調整階段，因為各個廠商都是在自己原有系統上做調整，問題還不是很明顯。到了幾個廠家彙總版本，試跑業務流程時，才發現業務流程跑不通。此時再做調整的話，成本就很大，幾個開發廠商也不願意調整自己的流程，而此時張三也給不出乙個調整的方案。所以後期在業務流程跑不通，一次又一次的延遲向丙公司董事長匯報專案的情況。我們建立的董事長匯報群，每週都在為此做準備，每次又不得不放棄。一直延續到專案暫停建設。
2、廠商分工不合理
做資源的幾個廠商都是在甲和乙公司負責十幾個甚至更多省份的資源專案，做了十幾年的資源系統，相對來說資源系統和流程比較暢通，在甲和乙公司已經基本上用起來了。但是丙公司為了加快進度，把資源系統功能一分為三，每個廠商負責一塊系統的調整開發，以為這樣會大大加快進度。殊不知，這卻大大延遲了系統的交付進度，甚至直到專案暫定建設，也沒完成系統的整合。
幾個開發廠商在甲和乙公司開發系統時，都是單獨負責某些省的系統，他們各自有各自的裝置建模、資料庫設計、流程設計、字段定義。他們的介面規範和字段定義、流程都不一樣，在丙公司做融合時，花費了很大的精力去調整，仍然有很多對接不上（德勤公司也沒給大家做整體流程設計、統一的介面規範和字段定義）。
3、沒人牽頭做差異比對
甲和乙公司的整體業務和裝置基本上和丙公司大致相同，但是還是有些許差異。丙公司建立年限更早，有一些特有的裝置，丙公司的各個部門管制職責與甲和乙公司也不盡相同。丙公司的位址定義、局站命名規範，裝置命名規範等與甲和乙公司也不完全相同。但是丙公司並沒有人牽頭做差異比對，德勤作為需求把控方，也沒提出做丙公司實際情況與甲乙公司情況差異對比，沒有安排所有的開發廠商做調整，開發廠商還是沿用甲和乙公司的規範和流程。導致在山東、北京、福建做試點時，現場的使用者使用起來，發現資料對應不上，職責混亂，錄入系統的資料也是詞不對題，資料質量完全無法保證，也沒人引導他們做系統字段講解和錄入資料標準定義，因為開發廠商也不知道丙公司的實際情況，按照甲和乙公司的規範進行講解，但與現場實際情況往往也對應不上，收到了現場使用者無數的反饋和投訴。開發公司把這情況匯報給pmo，協調德勤出面答疑，德勤也沒有人牽頭負責。
4、廠家利益牽扯鬥爭嚴重
一期的資源專案是三家開發廠商一人負責乙個省，但是後期其他省份會按照這三個試點省的使用情況進行分配。三個開發產商為了自身的利益，在合作開發的過程中，自覺地把一部分核心指令碼和程式隱藏起來，不告訴其它廠商。導致後期融合三家版本到省份實施試用時，每個省都沒辦法真正使用起來。另外兩家負責模組版本中總有各種各樣的坑。
後期想想，如果想要做成資源專案，讓三家開發廠商進入，確實會大大加快專案的進展，但是系統功能不能一分為三，而是讓三個廠商每家做一套資源系統，各自在乙個省份試執行。這樣他們使用原有的業務流程，需要調整的只是與丙公司實際情況的差異。而他們的公司有專門的產品和需求部門，有豐富的差異比對和落地實現經驗，而且又有比賽竟比性質，所以他們也會加大投入資源，短期內完成流程和規範的調整。讓試點盡快用起來，以便增加後面幾十個省份額的競爭。（不要小看乙個公司的能動性，在給甲公司的一次評比後，億陽版本落後很多，甲集團公司點名批評了下，準備下期更換，億陽召集六十多人去陝西使用者那封閉整改，兩個月完成了兩百多個整改點，後期一舉打敗了其他資源廠商，占領了大半的資源市場）。
需求架構一定要找乙個做過這個專案的公司，而非找乙個名氣大的公司。如果資源系統讓中興、億陽、亞聯其中的一家做需求管理，可能成本沒德勤那麼高，但效果會更好。
5、專案的大躍進形式前進
我入職pccw後，領導安排跟進資源實施管理，但是看到丙公司發的進度計畫就有些詫異，一星期完成調研，一星期完成開發，一星期完成版本合併，一星期完成實施，下個月給領導匯報完成情況。當時就覺得不太現實，億陽做資源系統，在甲公司做了十幾年，光梳理流程和裝置建模，資料錄入就花了十幾年的時間，才把常用的裝置建模，讓資料質量勉強達到要求，業務流程基本能跑通。其中經歷了多少產品經理和需求人員去各個省份、研究院和集團公司去確認需求。前前後後根據開發和使用反饋，甲公司召集了各個專業的專家和各個廠家的大拿，梳理下發了五六版各個專業的模型規範。研發熬了多少個通宵，進行了無數次百日大會戰，出了幾十個版本，才完成了甲公司基本業務流程。我們熬肝熬夜配合各省各專業的維護人員，導了無數次的資料，調整了無數次，定義了無數的考核規則，好多地市使用者也被扣了無數分（一分十萬），才讓資料質量勉強達標。
丙公司讓我們乙個月完成所有的進度，這不是開玩笑麼？可看了所有的人，也不像開玩笑的意思，所以的進度安排都是按照乙個月來開展的，因為領導著急要成果，所以時間緊湊些。結果每個月都是按照這個月能完成定計畫，到月底又自覺延期到下個月去完成。但沒有乙個人給領導反饋，按照乙個月定計畫，所有的細節開展不了，沒辦法交付出乙個可以使用的系統。如果定乙個長期規劃，不需要十年，三年其實也勉強夠。但是沒有乙個人提出這個，也導致，所有需要細細梳理的項都沒有開展過。每個月都是做大框架梳理，但其實對系統建設完善改進有限。每週開發廠商都在查漏補缺，而非去開發功能。
當然這個專案失敗還有很多其他的原因，在此我就不一一闡述。
乙個專案的失敗
曾經看過cmm的一些資料，當時只是覺著這些東西有些空，而且很複雜，很沒辦法在中國的軟體公司實行。可是，這麼多年過來，經歷了很多的專案，也領導過很多專案，發現對cmm有了新的認識。cmm的關鍵問題域是很多失敗和很多成功的例子所總結出來的，也許它很複雜，要求也很高，但是如果我們真的理解了這些關鍵問題域，...
乙個專案的總結
這篇文章是針對自己剛剛做過的乙個專案，自己的一些體會。其中在 中的內容是專案中的一些情況，不要求他人理解 做專案的經常出現的一種情況是弄乙個方案解決客戶的某乙個問題。通常會產生三種做法。1.問題和放案都是客戶提出來的。客戶很明確的告訴我們，有什麼問題，要用什麼方式解決。我們只需要針對客戶的解決方案，...
乙個專案的總結
我是移動網際網路行業的新手，這個月是來到這個公司的第12個月了，寫這篇東西是因為最近自己的乙個專案宣告掛起，偶爾維護不開發的狀態，在這裡有些感慨。這個專案是乙個lbs的交友軟體具體說明不能說，失敗的原因我總結了有以下幾個原因 1 我是新手 雖然已經參與開發了幾個專案了，但是我畢竟還是新手，而且我們服...