疫情中的數字化轉型：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/