疫情中的数字化转型：IBM ISC CRM 开发团队远程交付实践
那是 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/
点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！
点个在看少个 bug 👇
相关内容
微信扫码咨询专知VIP会员