作者 | Jayesh Kadam, Dr. Ashay Saxena譯者 | 王強策劃 | 丁曉昀那是 7 月 20 日。隨著第一波疫情高峰的到來 100% 在傢工作的模式（WFH）已經實施瞭三個月 疫情中的數字化轉型：IBM ISC CRM 開發團隊遠程交付實踐 - 趣味新聞網

作者 | Jayesh Kadam, Dr. Ashay Saxena

譯者 | 王強

策劃 | 丁曉昀

那是 7 月 20 日。隨著第一波疫情高峰的到來，100% 在傢工作的模式（WFH）已經實施瞭三個月。

我們是 IBM 首席信息官（CIO）的 CRM 平台團隊，剛剛成功完成瞭將全球銷售團隊從內部 CRM 係統轉移到 SugarCRM 托管雲平台的項目。該項目的另一個舉措是在所有的銷售應用程序中采用精簡的産品層級。

就在我們經曆著遠程工作的新常態時，公司決定采用 Salesforce 的 SalesCloud 作為 IBM 全球銷售團隊和閤作夥伴的單一 CRM 係統。

核心目標概述如下：

所有 IBM 銷售人員和業務夥伴都轉移到一個單一的 IBM 銷售平台（CRM）。Salesforce SalesCloud 將成為 IBM 統一的 CRM/ 銷售平台，其具有一流的集成、分析和認知特性。

公司之前在進入市場（GTM）/ 銷售周期流程使用的 170 多個工具和係統都將走入曆史，而銷售團隊的整個銷售生命周期都會在 新平台上完成。

新平台將在一年內投入使用，21 年 7 月是截止時間。

本文講述的是 IBM CIO CRM 開發團隊如何在不到一年的時間裏，經曆兩輪 Covid-19 疫情，完全通過遠程工作交付名為 IBM Sales Cloud（ISC）的項目的故事。

背 景

我的敏捷之旅正式開始於 2011 年。當時我在 Wipro 工作，為幾個客戶組織的領導提供谘詢服務。在這一過程中，我考察瞭他們當時在項目和企業層麵的工作方式，然後提齣瞭一個路綫圖，說明他們項目的各個方麵需要如何改變纔能實現敏捷的工作方式。

在我的谘詢和教練過程中，一項關鍵挑戰是確保路綫圖涵蓋瞭敏捷價值和原則的所有方麵，而不是匆匆忙忙地引入一些實踐就把它們稱為敏捷瞭。

資料來源（https://dilbert.com/strip/2017-02-06）

根據麥肯锡的說法，“全麵轉型涉及到組織的每一個層麵，包括人員、流程、戰略、結構和技術“。（https://www.mckinsey.com/business-functions/people-and-organizational-performance/our-insights/the-journey-to-an-agile-organization）

圖 1：麥肯锡關於轉型期間需要關注的各個方麵的文章

當我擔任 CRM 功能開發的技術項目經理時，我根據自己的谘詢和輔導經驗定義瞭一個基於轉型杠杆的框架，該框架會關注項目的所有層麵。

項目管理框架

當我們啓動 ISC 交付時，我們使用企業敏捷性主題作為項目管理的杠杆，以確保交付能夠觸及所有層麵。

圖 2：基於轉型杠杆的項目管理框架

下麵我們來看看這些杠杆背後的關鍵原則。隨後我們會詳細研究每個杠杆。

設置團隊 ： 團隊設置的關鍵原則是，他們必須是跨職能的，而不是基於組件的。第二是試著建立獨立於功能的工作流。

流程 ： 許多大型項目麵臨的一項關鍵挑戰是，它們被設計為大型瀑布式發布流程，盡管它們聲稱自己是敏捷的。我們有意識地想避免這種情況。因此我們的流程是基於迭代和增量開發設計的。這就需要盡可能地對特性開發工作進行垂直切分，並在迭代中多次將可交付的增量轉移到更高的環境中。我們需要灌輸測試優先的理念來實現這一目標。

架構： 我們的想法是在最初的 90 天內做齣來一個初始版本，然後根據不斷變化的需求和業務反饋逐步調整。利益相關者推薦瞭一個架構審查委員會（ARB）的概念，它對這種規模的項目來說非常有效。

工程和工具： 我們在最初的 30 天內建立瞭開發、暫存和生産環境；建立瞭 GitHub 存儲庫、Salesforce scratch org 作為開發環境。我們需要將可交付的增量轉移到更高的環境，這也意味著我們需要一個強大的構建、部署和測試管道。

評估和治理： 該項目的一個關鍵層麵是利益相關者的多樣性。來自銷售、運營、全球首席數據辦公室（GCDO）和首席信息官小組的高級管理人員都參與其中。除此以外，每個業務部門（BU）也有參與，因為各業務部門的銷售人員和銷售經理都是 ISC 平台的終端用戶。我們努力保持盡可能精簡的治理結構。敏捷的應用程序生命周期管理工具是項目進度的單一真相來源，也是各團隊之間的依賴管理工具。

文化： 最後，除非我們的團隊有正確的文化，否則所有這些杠杆都不會起到作用。我們再次強調，隻有當我們真正作為一個團隊共同協作時，纔能實現項目目標。我們開始的時候需要麵對很多未知數，所以我們鼓勵團隊進行實驗和學習，而不是坐等一切逐漸變得完美起來。遠程工作和不斷變化的工作範圍給團隊帶來瞭很大壓力。作為領導者，我們承認這一點，並嚮團隊保證我們可以隨時參與提供支持。

現在我們來更具體地分析每一個杠杆。

團隊設置

正如我前麵提到的，圍繞團隊設置的關鍵原則是“獨立的工作流“，目的是減少跨團隊的依賴性。這也能幫助我們更快地將可交付的增量轉移到更高的環境中。團隊的設置是與職能領域相一緻的，例如機會管理、領導 / 聯係人管理、賬戶、地區團隊等。

圖 3：ISC 項目的開發團隊設置情況

我必須再次強調，每個團隊都需要一些跨職能的技能。很多時候，我們看到企業喜歡設置很多組件團隊，例如一個是 UI 團隊，另一個是中間件 / 集成團隊，還有一個單獨的 DevOps/ 自動化團隊。如果你建立瞭很多組件團隊，你的依賴管理需求就會成倍增長。這也會造成知識 / 技能的孤島。

你可能會問，跨職能的真正含義是什麼？簡單來說，跨職能的團隊將擁有所有必要的技能，以自己的方式嚮更高的環境提供可交付的增量，而不是依賴其他團隊的這類技能。跨職能團隊的每個成員都會有 T 型技能，也就是既有一個核心專業領域，但也有其他領域的知識，可以在必要時為那些領域做齣貢獻。

這種設置的另一個關鍵層麵是對團隊的支持結構。我們有一個由平台、業務、領域架構師、軟件開發經理、設計主題專傢和項目經理組成的小組，他們提供瞭所有必要的支持，因為這些技能中的一些不是每一個團隊都具備的。

我們成立瞭 8 個開發小組來開發 CRM 功能，其中 6 個在印度，2 個在美國。除瞭這 8 個開發小組外，還有其他小組負責閤作夥伴關係模塊（Salesforce PRM）、Tableau CRM 和用戶支持等工作。

流程

我經常被問到的一個問題是，我們是否遵循什麼大規模敏捷方法來交付這個項目？在迴答這個問題之前，我先解釋一下我們所設置的流程。

根據經驗法則，我們的一個迭代設置為 2 周，並且我們每個迭代都應該有一個有效的軟件增量成果。我們需要遵循測試優先的方法來實現這一目標。這些過程原則應用於所有開發團隊。

圖 4：ISC 團隊采用的開發流程

獨立的工作流使他們能夠並行工作。這是否意味著我們沒有任何依賴性呢？並非如此。我們有一個每天進行的站會流程，我們稱為 Scrum 的 Scrum，每個開發團隊都參與其中，站會重點關注解決迭代過程中的依賴性和障礙。

考慮到項目的性質和利益相關者的多樣性，我們決定安排統一的項目迭代計劃和展示活動。開發團隊將單獨進行他們的計劃會議，並參加統一的項目會議來分享迭代中總結的關鍵特性和衝刺目標。

最後，為瞭讓利益相關者瞭解我們在定義的發布裏程碑上進展到瞭哪一步，我們跟蹤瞭迭代目標和發布目標的進展。一個版本被定義為一組需要在一個特定的地理環境中為用戶服務的特性。我們每周 / 每兩周嚮高級 CIO 領導層和項目利益相關者提供一頁項目總結，其中包括 ALM 工具的數據，以及需要執行領導支持的障礙和問題。

我們沒有遵循任何定義好的敏捷或大規模敏捷框架。我們的重點是在開發團隊所做的一切工作中遵循極限編程（XP）實踐，然後使用一些 Scrum 活動。

架構

許多組織都很難在架構這個領域中采用敏捷工作方式。當 ISC 項目啓動時，設想的項目架構會跨越三個主要領域：

業務架構： 重點放在關於銷售團隊最終如何使用該平台的業務視角上。

平台架構： 側重於利用 Salesforce 的開箱即用的功能、特定的定製，以及利用從 IBM 以前實現的 Salesforce Service Cloud 中獲得的經驗。

集成和數據架構： 重點是利用 IBM 的混閤雲戰略，為賬戶、聯係人、區域、銷售綫索、産品層級、報價到現金應用程序、用戶訪問和各種下遊應用的數據流設置帶有可信來源的集成。

圖 5：ISC 架構的關鍵原則

我們設置瞭一個架構審查委員會（ARB）。它由各職能部門的架構師和産品負責人組成。他們的工作重點是幫助開發團隊確定最終架構決策。他們還審查瞭由産品負責人起草的特性（ALM 語言的 Epics），並提供反饋。這有助於加快解釋說明過程，並確保開發團隊有初步的設計輸入。開發團隊可以在一個迭代中多次聯係 ARB，並在特性的增量開發過程中尋求他們的支持和審查。

項目中的 Salesforce 架構師在項目啓動後的頭兩個月內發起瞭溝通說明會議。主要參與者包括産品負責人、業務、平台和 Salesforce 架構師，會議重點關注以下內容：

銷售角色和旅程圖，以實現 ISC 的 UI 和 UX 界麵設計。

業務架構

集成和數據架構是由 CIO 的 CRM 團隊的企業架構師設計的，重點包括對源 CRM 進行數據建模，以及可信源、中間件架構和 DevSecOps 實踐。

對我們來說，架構方麵的一個重要經驗是，盡管我們正在做一個一攬子實現（Salesforce）項目，但架構也需要靈活適應變化和用戶反饋。基於這一原則，我們重新設計瞭區域和賬戶等級解決方案。

工程實踐和工具鏈

建立跨職能部門的團隊讓我們能夠與工程實踐和工具鏈方麵的一係列關鍵原則保持一緻。這些原則是：

在頭 30 天內建立 ISC 開發、暫存和生産環境。

從一開始就做到構建、部署和測試自動化。

安全和投訴的基礎設施與 IBM 混閤雲戰略保持一緻。

我們鼓勵開發團隊遵循測試優先的方法，從而實現瞭 90% 的功能測試自動化覆蓋率。

在設置集成時，我們通過專門的 CI-CD 管道將基礎設施配置、構建、測試和部署的所有方麵都實現瞭自動化，從而以更快的速度實現瞭中間件集成服務。與以前的部署相比，該團隊可以節省 75% 的時間。

我們也是為數不多的使用 Salesforce DX 的企業項目之一。我們在集成環境下構建 ISC Salesforce 包，然後以自動化的方式將其部署到暫存和生産環境。

圖 6：CI-CD 管道的工具棧

以下是中間件微服務的 CI-CD 管道設置的一些突齣特點。

圖 7：中間件 CI-CD 管道的好處

團隊的主要學習成果和收益如下：

重用為傳統 CRM 中間件建立的管道庫。

由於之前積纍的關於 IBM 雲 Kubernetes 服務（IKS）的專業知識，團隊可以輕鬆適應新技術（如 IBM RedHat OpenShift）。

內建的代碼質量和安全性

花在中間件部署上的時間比傳統 CRM 減少 75%。

團隊同心的 DevSecOps 模式――各個團隊的跨職能技能有助於加快 ISC 平台上所有工具的開發速度。

評估和治理

在我參加的一次早期會議上，我對敏捷有瞭更好的理解。與會者一直質疑的一個問題就是指標。

一個普遍的問題是，像 burn-up、速度、周期時間或 throughout 這些指標，並不能真正反映項目的進展情況。領導層怎麼纔能知道一切都在軌道上或不在軌道上呢？

主持人巧妙地解釋瞭這一點。他問瞭一個問題：“你在開車時多久看一次汽車儀錶盤？每次看多長時間？“

“如果你過多地關注儀錶盤，你就會忽略路況。更糟的是，這可能會導緻一場事故“，他解釋說。

在我看來，如果敏捷團隊專注於遵循宣言中的價值觀和原則、與業務部門閤作開展最優先的工作、經常構建和部署能正常運行的軟件、尋求反饋並采取行動，那麼進展對所有人來說都會是透明的，你就不需要那麼多治理工作瞭。

我們在為 ISC 項目建立團隊和項目層麵的管理體係時采用瞭以下原則：

使用 ALM 工具嚮利益相關者分享統一的進度視圖。

對關鍵特性和團隊間的依賴關係進行可視化跟蹤。

透明展現障礙和需要領導支持的問題。

圖 8：ISC 項目在不同組織級彆上的治理工作

我們鼓勵團隊主動討論團隊間的依賴關係（如果有的話），並在迭代過程中規劃它們。由於我們是 100% 的遠程工作，ALM 工具可以幫助我們以數字方式展現障礙和依賴。這些都是在每天的團隊間會議上討論的，會議重點是立即解決障礙。會議還會討論意外情況以及迭代項目的其他部分所需的更新。

密切關注所有開發團隊在每個迭代中的綜閤進展是非常重要的。我們每周與來自 CIO 和運營領導團隊的關鍵利益相關者一起審查項目，重點關注：

生産環境中特性的可用性與特定 GEO 版本的要求

供開發團隊挑選的就緒特性與高優先級特性的管道

CIO 內部各分組的依賴性、集成的可信源團隊、産品負責人等

需要行政領導幫助的內容（如果有的話）

銷售和運營部門的執行領導層開展瞭一個名為“轉型星期二“的項目，在這個項目中，銷售領導和來自所有業務部門的代錶將被告知項目的整體進展、即將推齣的特性和産品發現研討會的結果，以及他們提齣的關鍵問題的答案。同時，我們會通過專門的 Slack 頻道、新聞簡報、早期用戶的視頻以及組織變革管理團隊準備的用戶文檔，與銷售社區進行定期交流。

文 化

如何定義一個團隊的文化？在我看來，文化就是你每天在與其他團隊成員、同行、領導和利益相關者的互動中所經曆的體驗。

ISC CRM 開發團隊的一個重點是，我們要在 2020 年 2 月將所有的 IBM 賣傢接入當前的 SugarCRM 雲平台。這些裏程碑是由一個團隊在辦公室裏協作完成的。

這已經是一個緊密相連的團隊瞭。我們從現有的 3 個 CRM 團隊中劃分齣 6 個小團隊。我們的目標是讓每個開發團隊有不同的技能和經驗。一組新的團隊成員擔任瞭業務分析師和迭代經理等角色。印度的整個團隊之前沒有任何 Salesforce 方麵的經驗。

我們也有大約 15 名新成員是從其他部門調來 CRM 開發團隊的，或是來自大學校園的新人。與現有的團隊成員不同，我們需要額外關注這些成員，以確保他們能夠在完全遠程的環境中能夠充分參與進來――即便我們並沒有麵對麵接觸過。

我們試圖遵循以下原則：

靈活性：團隊進行實驗，從中學習，並在迭代中逐漸適應。每個團隊都有不同的技能組閤。之前的 CRM 領域經驗與擁有全棧開發技能的新團隊成員很好地結閤在瞭一起。

透明度：鼓勵團隊在每個迭代過程中對麵臨的問題和挑戰保持透明度。這有助於在團隊和利益相關者之間建立信任關係。

領導支持：所有軟件開發經理都親力親為，並在整個項目期間隨時為團隊提供支持。

圖 9：團隊同心的文化。來源：SpencerStuart（2019）

麥肯锡在他們關於“項目領導力的藝術“的報告中對文化是這樣說的：

高效的項目團隊有一種獨特和共同的身份認同，並能創造一個相互信任和協作的文化。項目領導者應該闡明目的、樹立行為榜樣，並培養理想的文化氛圍。

所有團隊成員都認可瞭“團隊同心“的態度，這幫助我們在一年的時間裏剋服瞭各種挑戰。我們全程遠程工作，還要在兩輪疫情中模糊工作和傢庭的界限，但這些障礙並沒有阻止團隊前進的步伐，因為我們意識到瞭項目目標背後有著更大的意義。

取得的成果

從 20 年 7 月底的 ISC 項目啓動開始，我們每一次迭代都將新的特性部署到生産環境中。第一個 GEO 所有 BU 的銷售在 21 年 2 月都轉到瞭 ISC 上。隨後，21 年 5 月是第二個 GEO。21 年 7 月，其餘的所有 GEO 都完成瞭轉型。

截至今天，來自所有業務部門的約 30,000 名銷售正按照設想在該平台上工作。

圖 10：ISC 成果的相關數據

該項目還從之前的 CRM 係統嚮 ISC 遷移瞭每個 GEO 的數據。所有對象的 1000 多萬條記錄完成瞭遷移，並實時流嚮下遊應用程序。

測試優先的方法幫助我們在整個項目期間都能確保交付質量。開發團隊隻收到一個與開發的特性有關的一級嚴重事件。同時，所有的工作都通過瞭對 GEO 特定數據可見性和其他閤規性要求的審查。

IBM 全球銷售主管 Jennifer Kady 說：

用一個單一的視圖來統一團隊也加快瞭銷售的速度、加強瞭決策能力。以前，IBM 的許多銷售流程都是在平台之外的電子錶格和演示中進行的。孤立的項目意味著銷售人員不確定誰的數字是正確的，在試圖預測整個賬戶時還會造成混亂。現在，團隊可以通過基於社區協作的內置模闆獲得相同的頁麵，從而擴展業務流程，如賬戶規劃等。而通過人工智能，IBM 可以實現銷售流程的自動化，並更好地預測客戶成果。

IBM 領導團隊也分享瞭他們對該項目轉型成功的看法。

學到的經驗

那麼，我們從這麼大規模的轉型項目的工作和交付中學到瞭哪些經驗？

由於項目的時間錶和 GEO 的上綫裏程碑是神聖不可侵犯的，領導層的支持和對團隊的支持是剋服疫情期間完全遠程工作帶來的各種挑戰的關鍵。

如果我們不遵循迭代和增量開發流程，且每次迭代都能交付生産環境可用的軟件，我們就不可能實現項目目標。建立所有的流程、工具和實踐，重點關注可交付的增量是關鍵所在。

與各部門和終端用戶接觸，徵求他們對關鍵銷售流程轉型領域的反饋意見是非常重要的。我們有時忽略瞭這一點，但它卻以特性修正工作的形式迴來瞭。

有目的的工作、建立跨職能的團隊，以及一定要完成任務的態度有助於團隊應對頻繁齣現的變化。

企業架構也需要逐步發展，以適應 BU 和終端用戶的反饋。

圖 11：CIO 開發團隊學到的 ISC 項目經驗

如果讓我用一個詞來概括這一年的旅程，那就是“韌性“。這些團隊為實現所有的項目裏程碑付齣瞭巨大的努力。作為這一有著驚人成績的團隊的一員，我心中充滿感激。

作者介紹：

Jayesh Kadam 在 IT 領域有 21 年的經驗，涵蓋瞭軟件産品的開發和谘詢工作。作為 IBM 的一員，他目前正在領導一個項目，負責交付 CRM 軟件――該軟件被全球約 3 萬名 IBM 銷售使用。在加入 IBM 之前，Jayesh 在 Cognizant 和 Wipro 工作。作為這些組織的一員，他在負責的許多客戶那裏倡導敏捷和 DevOps 轉型。他曾在印度、美國和加拿大工作，與全球客戶和團隊閤作。他熱衷於將敏捷的價值觀和原則滲透到日常工作中。除瞭工作之外，他還熱衷於運動，喜歡看好電影。

Ashay Saxena 博士目前在 IBM 擔任産品負責人。他擁有印度管理學院班加羅爾分校信息係統領域的博士學位。他深入研究瞭解軟件團隊采用的管理方法，以便在團隊分布於全球的形式下通過敏捷方法取得成功。他曾在英特爾、通用電氣、Mindtree 和 ThoughtWorks 等全球跨國公司進行深入的案例研究。他曾在一些國際論壇上發錶演講和研究報告，如澳大利亞信息係統會議、ACM 計算機與人研究會議、印度敏捷會議、敏捷領導力峰會、印度敏捷周和軟件産品管理峰會。

https://www.infoq.com/articles/going-digital-pandemic/