IT 經理把項目帶崩是因為這幾點沒做好
分享一個來自碼哥工作中遇到的時間緊任務重，對系統不熟悉，沒有產品文檔，目標就是將原有系統改造成客戶本地部署運行的多重困難跨團隊協作項目管理差點帶崩的經歷。
通過該經歷重點在于給大家分享如何避免項目搞砸，以及一個項目初期、中期、收尾階段需要做的工作重點和注意事項，如何管理項目規避風險。
項目背景
項目的目標是將公司 saas 團隊的供應鏈金融系統移植到客戶獨立部署，主要有以下幾個風險和難點。
- 團隊內的人包括我并不熟悉該系統的業務流和系統的代碼，難以分析項目的風險和改造點。
- 干系人分析不足，沒有將熟悉該系統的人引入，導致風險無法識別，進度緩慢。
- 時間和人力明顯不足：人力極致壓榨。
- 跨多個團隊協作：開發該系統的團隊并沒有參與此次遷移工作。
- 原系統與公司內部的接口交互需要全部通過 Http 來實現：原有的系統架構并不適用直接遷移到客戶部署，部分接口能力是調用公司的其他團隊實現，比如 AI 識別或用到 MQ 通信，通過 Dubbo 或者 HTTP 調用其他團隊接口實現邏輯，需要統一改造成通過 Http 調用公司開放的接口實現。
圖片
除此之外，該 saas 系統由于原先開發人員的技術能力較弱，以及歷史淵源，框架設計不合理，可讀性和可維護性比較弱的情況下，如何更好的與原維護者溝通也是一大難題。
因為技術人會容易看不上別人的代碼和設計，尤其是架構確實有明顯不足的時候。
打開項目代碼發現這是一個披著微服務外衣的大單體巨石服務。一邊罵別人系統垃圾，一邊還要請求人家幫助的事情需要合理手段解決。
圖片
最終發現拆了一堆的服務，可是實際上業務邏輯和系統的壓力全都集中在 web-service 上。
至于拆出來的微服務，只干了一件事：myabtis 作為 ORM 框架操作數據庫，也不懂這個項目的原開發和架構是怎么想的，單一職責不是這樣理解的，大兄弟。
真的是「黛玉騎鬼火，該強的強，該弱的弱」。
遇到這種情況，我們一定要秉著謙虛的態度，因為還要請教他們解答項目如何遷移，需要我們想方設法用彩虹屁夸他們，讓他們覺得受到尊重，雖然很反人類，可這是我們的必修課：
- “大佬，你們這塊的設計思路是基于什么考慮呢，能這么平穩的運行一定有道理”
- 這塊的設計真棒，學到了很多。
總之一定要一頓夸，切不可用技術人的視角把實際情況說出來，要是指出系統懂得各個不是，各種技術垃圾，你覺得別人還會幫你么？
過分悲觀 or 樂觀
在該項目中，由于項目距難度很大，但是大家又不知道到底有多大，就會出現過分悲觀 or 樂觀的情況。
于是團隊內出現了一些這樣的聲音……
吳大佬：“這個項目一個月就要完成改造，肯定完不成，也不知道具體有哪些風險點。”
江小白：“反正完不成，愛咋滴咋滴。”
這兩者均建立在對項目掌控度不夠的情況下，會導致對于項目的判斷失誤，過分悲觀會影響到項目組同學的積極性，反之會導致風險暴露在后期。
為了避免該情況發生，一定要做好項目啟動會，邀請所有干系人參會。啟動會的目的圍繞以下幾點。
- 明確的溝通渠道和協作工具：比如企業微信群，將所有相關干系人拉到一個群里，使用 文檔協作工具。
- 定期召開跨部門會議： 定期召開跨部門會議，讓各團隊成員分享進展、識別問題并討論解決方案。這有助于促進團隊之間的協作，提高信息共享和理解。
- 建立良好的關系： 投入時間建立與其他部門的良好關系，了解他們的需求、優先事項和工作方式。建立信任和共同理解是促進跨部門合作的關鍵。
- 明確項目成員的職責分工，制定清晰的溝通計劃：在項目開始階段就制定清晰的溝通計劃，包括溝通的頻率、方式和內容。確保所有團隊成員都了解他們應該何時收到何種信息，自己的職責是什么。
- 設立跨部門代表： 在每個團隊中指定跨部門代表，他們可以作為溝通的橋梁，確保信息在團隊之間流動順暢，并協調解決跨部門問題。
- 解決沖突和問題： 出現沖突或問題時，及時解決并采取適當的措施。建立解決問題的流程，確保所有團隊成員都知道如何報告問題并參與解決方案的制定。
作為管理者，啟動會上需要做一個 PPT 來列出幾個關鍵項，讓所有參與制知道目標和職責。
- 項目距目標。
- 項目成員組織架構。
- 利益相關方和干系人。
- 項目設計功能點范圍。
- 項目成員職責分工。
- 需求變更管理。
- 項目溝通管理機制。
- 項目排期計劃。
圖片
忽略細節
即墨菲定律，凡是覺得可能出錯或小概率出錯的事一定會出錯，當 review 發現問題時需要深入到細節中了解和推進，避免問題最終暴露在線上。
在項目執行過程中，由于對業務和系統都不熟悉，覺得只要系統能運行起來，我們都沒有改代碼只是將原本 Dubbo 接口替換成 http 調用。
忽略掉了一些細節，后來才發現事情很復雜，舊系統調用了公司內部很多接口，錯綜復雜，而團隊內沒有一個人接觸過這個系統，本地化部署的情況下完全無法使用，網絡不通。
代碼遷移和改造以及范圍影響點隨著一個問題的出現，在聯調階段爆炸式出現。
根本原因就是忽略了細節，沒有深入拆解每一項任務。但是問題又來了，原本大家都不熟悉這個系統，又如何拆解正確呢？
這就設計到利益關聯方干系人分析的范疇了。
利益關聯方干系人分析
事情能不能辦成，利益方一定要分析清晰。天下熙熙皆為利來，天下攘攘皆為利往。
該項目是將原 saas 系統改造成客戶本地化部署運行，所以利益相關方一定要將系統的 saas 團隊關聯上，否則注定失敗。
大家一開始想到的是需要原系統開發者提供技術支持就可以完成，這是個錯誤的決定。
因為不符合人性，系統成敗與原開發者無關，那必然不會投入精力來幫助，讓別人來幫助還會被說『幫助我們不是義務，是情意』。
這就難受了，我們求著別人心里憋屈，別人還不樂意，只怪他們本就是利益相關方，卻只是將他們作為咨詢身份參與，無關利益，打錯打錯，項目注定要崩潰。
項目一開始，我們都是去咨詢原系統開發者，久而久之別人不耐其煩。
項目后期風險越來越大，碼哥強烈要求原開發者加入該項目才得以將風險降下來。
只有這個項目的成敗和利益與原系統開發者息息相關，項目的風險才能控制。
時間和人力明顯不足
影響項目成功的關鍵在于干系人參與程度、高層管理者的支持、清晰的需求陳述、恰當的計劃以及項目的合理預期和里程碑。
而此次項目一個運行迭代了 5 年的系統在一個月內改造完就可以斷定這是一個扯淡計劃。
但是人在屋檐下，人力的極致壓榨，領導者就是讓大家每天加班到晚上十一點半，周六日來加班實現，打工人只能沖一把。
于是乎，作為項目負責人也只能竟可能做好項目計劃、降低上層管理者的預期、干系人分析，提出人力缺口，讓上面的管理者去其他團隊借調資源。
需求陳述不清
項目啟動后因為外部各種因素感染導致項目根本沒有需求文檔，產品經理一句話按照當前原系統能力建設。
這也是項目容易崩的原因，連需求文檔都沒有。一句話照搬原有系統即可，雖然是笑話，可是就是發生了。
怎么辦呢？這就特別管理者的能力了，需要了解高層管理的時間要求，以及客戶希望系統的范圍和質量；
碼哥作為技術管理者在項目執行的過程中需要不斷的和產品經理溝通去梳理出真正的需求，同時還要識別出風險，鼓勵組內的開發把事情做好，解決項目部署遇到的問題以及技術難點。
遇到一心只想甩鍋的產品經理那更加考驗你的心態。
產品經理：“項目什么時候可以提測，風險這么高你們都不管么？你就是想讓大家都陪你加班。”
所以，一定要有需求文檔梳理產品的范圍，一定不要就按照老系統有的功能都要有這樣的一句話需求。
總結
主要遇到的問題和吸取的經驗如下：
- 過分悲觀 or 樂觀：這兩者均建立在對項目掌控度不夠的情況下，會導致對于項目的判斷失誤，過分悲觀會影響到項目組同學的積極性，反之會導致風險暴露在后期。
- 忽略細節：即墨菲定律，凡是覺得可能出錯或小概率出錯的事一定會出錯，當 review 發現問題時需要深入到細節中了解和推進，避免問題最終暴露在線上。
- 利益關聯方、干系人分析不合理：事情能不能辦成，利益方一定要分析清晰。天下熙熙皆為利來，天下攘攘皆為利往。
- 需求陳述不清：項目啟動后因為外部各種因素感染導致項目根本沒有需求文檔，產品經理一句話按照當前原系統能力建設。
- 前松后緊：不合理的規劃會導致項目陷入這種狀態，導致提測時問題過多，開發未自測質量差等情況。
