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

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

項(xiàng)目背景

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

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

圖片

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

因?yàn)榧夹g(shù)人會容易看不上別人的代碼和設(shè)計(jì)，尤其是架構(gòu)確實(shí)有明顯不足的時(shí)候。

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

圖片

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

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

真的是「黛玉騎鬼火，該強(qiáng)的強(qiáng)，該弱的弱」。

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

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

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

過分悲觀 or 樂觀

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

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

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

江小白：“反正完不成，愛咋滴咋滴。”

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

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

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

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

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

圖片

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

時(shí)間和人力明顯不足

影響項(xiàng)目成功的關(guān)鍵在于干系人參與程度、高層管理者的支持、清晰的需求陳述、恰當(dāng)?shù)挠?jì)劃以及項(xiàng)目的合理預(yù)期和里程碑。

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

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

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

需求陳述不清

項(xiàng)目啟動后因?yàn)橥獠扛鞣N因素感染導(dǎo)致項(xiàng)目根本沒有需求文檔，產(chǎn)品經(jīng)理一句話按照當(dāng)前原系統(tǒng)能力建設(shè)。

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

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

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

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

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

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

總結(jié)

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

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