分享一個來自碼哥工作中遇到的時間緊任務(wù)重，對系統(tǒng)不熟悉，沒有產(chǎn)品文檔，目標(biāo)就是將原有系統(tǒng)改造成客戶本地部署運行的多重困難跨團隊協(xié)作項目管理差點帶崩的經(jīng)歷。

通過該經(jīng)歷重點在于給大家分享如何避免項目搞砸，以及一個項目初期、中期、收尾階段需要做的工作重點和注意事項，如何管理項目規(guī)避風(fēng)險。

項目背景

項目的目標(biāo)是將公司 saas 團隊的供應(yīng)鏈金融系統(tǒng)移植到客戶獨立部署，主要有以下幾個風(fēng)險和難點。

• 團隊內(nèi)的人包括我并不熟悉該系統(tǒng)的業(yè)務(wù)流和系統(tǒng)的代碼，難以分析項目的風(fēng)險和改造點。
• 干系人分析不足，沒有將熟悉該系統(tǒng)的人引入，導(dǎo)致風(fēng)險無法識別，進(jìn)度緩慢。
• 時間和人力明顯不足：人力極致壓榨。
• 跨多個團隊協(xié)作：開發(fā)該系統(tǒng)的團隊并沒有參與此次遷移工作。
• 原系統(tǒng)與公司內(nèi)部的接口交互需要全部通過 Http 來實現(xiàn)：原有的系統(tǒng)架構(gòu)并不適用直接遷移到客戶部署，部分接口能力是調(diào)用公司的其他團隊實現(xiàn)，比如 AI 識別或用到 MQ 通信，通過 Dubbo 或者 HTTP 調(diào)用其他團隊接口實現(xiàn)邏輯，需要統(tǒng)一改造成通過 Http 調(diào)用公司開放的接口實現(xiàn)。

圖片

除此之外，該 saas 系統(tǒng)由于原先開發(fā)人員的技術(shù)能力較弱，以及歷史淵源，框架設(shè)計不合理，可讀性和可維護(hù)性比較弱的情況下，如何更好的與原維護(hù)者溝通也是一大難題。

因為技術(shù)人會容易看不上別人的代碼和設(shè)計，尤其是架構(gòu)確實有明顯不足的時候。

打開項目代碼發(fā)現(xiàn)這是一個披著微服務(wù)外衣的大單體巨石服務(wù)。一邊罵別人系統(tǒng)垃圾，一邊還要請求人家?guī)椭氖虑樾枰侠硎侄谓鉀Q。

圖片

最終發(fā)現(xiàn)拆了一堆的服務(wù)，可是實際上業(yè)務(wù)邏輯和系統(tǒng)的壓力全都集中在 web-service 上。

至于拆出來的微服務(wù)，只干了一件事：myabtis 作為 ORM 框架操作數(shù)據(jù)庫，也不懂這個項目的原開發(fā)和架構(gòu)是怎么想的，單一職責(zé)不是這樣理解的，大兄弟。

真的是「黛玉騎鬼火，該強的強，該弱的弱」。

遇到這種情況，我們一定要秉著謙虛的態(tài)度，因為還要請教他們解答項目如何遷移，需要我們想方設(shè)法用彩虹屁夸他們，讓他們覺得受到尊重，雖然很反人類，可這是我們的必修課：

1. “大佬，你們這塊的設(shè)計思路是基于什么考慮呢，能這么平穩(wěn)的運行一定有道理”
2. 這塊的設(shè)計真棒，學(xué)到了很多。

總之一定要一頓夸，切不可用技術(shù)人的視角把實際情況說出來，要是指出系統(tǒng)懂得各個不是，各種技術(shù)垃圾，你覺得別人還會幫你么？

過分悲觀 or 樂觀

在該項目中，由于項目距難度很大，但是大家又不知道到底有多大，就會出現(xiàn)過分悲觀 or 樂觀的情況。

于是團隊內(nèi)出現(xiàn)了一些這樣的聲音……

吳大佬：“這個項目一個月就要完成改造，肯定完不成，也不知道具體有哪些風(fēng)險點?！?/p>

江小白：“反正完不成，愛咋滴咋滴?！?/p>

這兩者均建立在對項目掌控度不夠的情況下，會導(dǎo)致對于項目的判斷失誤，過分悲觀會影響到項目組同學(xué)的積極性，反之會導(dǎo)致風(fēng)險暴露在后期。

為了避免該情況發(fā)生，一定要做好項目啟動會，邀請所有干系人參會。啟動會的目的圍繞以下幾點。

1. 明確的溝通渠道和協(xié)作工具：比如企業(yè)微信群，將所有相關(guān)干系人拉到一個群里，使用 文檔協(xié)作工具。
2. 定期召開跨部門會議： 定期召開跨部門會議，讓各團隊成員分享進(jìn)展、識別問題并討論解決方案。這有助于促進(jìn)團隊之間的協(xié)作，提高信息共享和理解。
3. 建立良好的關(guān)系： 投入時間建立與其他部門的良好關(guān)系，了解他們的需求、優(yōu)先事項和工作方式。建立信任和共同理解是促進(jìn)跨部門合作的關(guān)鍵。
4. 明確項目成員的職責(zé)分工，制定清晰的溝通計劃：在項目開始階段就制定清晰的溝通計劃，包括溝通的頻率、方式和內(nèi)容。確保所有團隊成員都了解他們應(yīng)該何時收到何種信息，自己的職責(zé)是什么。
5. 設(shè)立跨部門代表： 在每個團隊中指定跨部門代表，他們可以作為溝通的橋梁，確保信息在團隊之間流動順暢，并協(xié)調(diào)解決跨部門問題。
6. 解決沖突和問題： 出現(xiàn)沖突或問題時，及時解決并采取適當(dāng)?shù)拇胧?。建立解決問題的流程，確保所有團隊成員都知道如何報告問題并參與解決方案的制定。

作為管理者，啟動會上需要做一個 PPT 來列出幾個關(guān)鍵項，讓所有參與制知道目標(biāo)和職責(zé)。

1. 項目距目標(biāo)。
2. 項目成員組織架構(gòu)。
3. 利益相關(guān)方和干系人。
4. 項目設(shè)計功能點范圍。
5. 項目成員職責(zé)分工。
6. 需求變更管理。
7. 項目溝通管理機制。
8. 項目排期計劃。

圖片

忽略細(xì)節(jié)

即墨菲定律，凡是覺得可能出錯或小概率出錯的事一定會出錯，當(dāng) review 發(fā)現(xiàn)問題時需要深入到細(xì)節(jié)中了解和推進(jìn)，避免問題最終暴露在線上。

在項目執(zhí)行過程中，由于對業(yè)務(wù)和系統(tǒng)都不熟悉，覺得只要系統(tǒng)能運行起來，我們都沒有改代碼只是將原本 Dubbo 接口替換成 http 調(diào)用。

忽略掉了一些細(xì)節(jié)，后來才發(fā)現(xiàn)事情很復(fù)雜，舊系統(tǒng)調(diào)用了公司內(nèi)部很多接口，錯綜復(fù)雜，而團隊內(nèi)沒有一個人接觸過這個系統(tǒng)，本地化部署的情況下完全無法使用，網(wǎng)絡(luò)不通。

代碼遷移和改造以及范圍影響點隨著一個問題的出現(xiàn)，在聯(lián)調(diào)階段爆炸式出現(xiàn)。

根本原因就是忽略了細(xì)節(jié)，沒有深入拆解每一項任務(wù)。但是問題又來了，原本大家都不熟悉這個系統(tǒng)，又如何拆解正確呢？

這就設(shè)計到利益關(guān)聯(lián)方干系人分析的范疇了。

利益關(guān)聯(lián)方干系人分析

事情能不能辦成，利益方一定要分析清晰。天下熙熙皆為利來，天下攘攘皆為利往。

該項目是將原 saas 系統(tǒng)改造成客戶本地化部署運行，所以利益相關(guān)方一定要將系統(tǒng)的 saas 團隊關(guān)聯(lián)上，否則注定失敗。

大家一開始想到的是需要原系統(tǒng)開發(fā)者提供技術(shù)支持就可以完成，這是個錯誤的決定。

因為不符合人性，系統(tǒng)成敗與原開發(fā)者無關(guān)，那必然不會投入精力來幫助，讓別人來幫助還會被說『幫助我們不是義務(wù)，是情意』。

這就難受了，我們求著別人心里憋屈，別人還不樂意，只怪他們本就是利益相關(guān)方，卻只是將他們作為咨詢身份參與，無關(guān)利益，打錯打錯，項目注定要崩潰。

項目一開始，我們都是去咨詢原系統(tǒng)開發(fā)者，久而久之別人不耐其煩。

項目后期風(fēng)險越來越大，碼哥強烈要求原開發(fā)者加入該項目才得以將風(fēng)險降下來。

只有這個項目的成敗和利益與原系統(tǒng)開發(fā)者息息相關(guān)，項目的風(fēng)險才能控制。

時間和人力明顯不足

影響項目成功的關(guān)鍵在于干系人參與程度、高層管理者的支持、清晰的需求陳述、恰當(dāng)?shù)挠媱澮约绊椖康暮侠眍A(yù)期和里程碑。

而此次項目一個運行迭代了 5 年的系統(tǒng)在一個月內(nèi)改造完就可以斷定這是一個扯淡計劃。

但是人在屋檐下，人力的極致壓榨，領(lǐng)導(dǎo)者就是讓大家每天加班到晚上十一點半，周六日來加班實現(xiàn)，打工人只能沖一把。

于是乎，作為項目負(fù)責(zé)人也只能竟可能做好項目計劃、降低上層管理者的預(yù)期、干系人分析，提出人力缺口，讓上面的管理者去其他團隊借調(diào)資源。

需求陳述不清

項目啟動后因為外部各種因素感染導(dǎo)致項目根本沒有需求文檔，產(chǎn)品經(jīng)理一句話按照當(dāng)前原系統(tǒng)能力建設(shè)。

這也是項目容易崩的原因，連需求文檔都沒有。一句話照搬原有系統(tǒng)即可，雖然是笑話，可是就是發(fā)生了。

怎么辦呢？這就特別管理者的能力了，需要了解高層管理的時間要求，以及客戶希望系統(tǒng)的范圍和質(zhì)量；

碼哥作為技術(shù)管理者在項目執(zhí)行的過程中需要不斷的和產(chǎn)品經(jīng)理溝通去梳理出真正的需求，同時還要識別出風(fēng)險，鼓勵組內(nèi)的開發(fā)把事情做好，解決項目部署遇到的問題以及技術(shù)難點。

遇到一心只想甩鍋的產(chǎn)品經(jīng)理那更加考驗?zāi)愕男膽B(tài)。

產(chǎn)品經(jīng)理：“項目什么時候可以提測，風(fēng)險這么高你們都不管么？你就是想讓大家都陪你加班?！?/p>

所以，一定要有需求文檔梳理產(chǎn)品的范圍，一定不要就按照老系統(tǒng)有的功能都要有這樣的一句話需求。

總結(jié)

主要遇到的問題和吸取的經(jīng)驗如下：

• 過分悲觀 or 樂觀：這兩者均建立在對項目掌控度不夠的情況下，會導(dǎo)致對于項目的判斷失誤，過分悲觀會影響到項目組同學(xué)的積極性，反之會導(dǎo)致風(fēng)險暴露在后期。
• 忽略細(xì)節(jié)：即墨菲定律，凡是覺得可能出錯或小概率出錯的事一定會出錯，當(dāng) review 發(fā)現(xiàn)問題時需要深入到細(xì)節(jié)中了解和推進(jìn)，避免問題最終暴露在線上。
• 利益關(guān)聯(lián)方、干系人分析不合理：事情能不能辦成，利益方一定要分析清晰。天下熙熙皆為利來，天下攘攘皆為利往。
• 需求陳述不清：項目啟動后因為外部各種因素感染導(dǎo)致項目根本沒有需求文檔，產(chǎn)品經(jīng)理一句話按照當(dāng)前原系統(tǒng)能力建設(shè)。
• 前松后緊：不合理的規(guī)劃會導(dǎo)致項目陷入這種狀態(tài)，導(dǎo)致提測時問題過多，開發(fā)未自測質(zhì)量差等情況。