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