那是 7 月 20 日。随着第一波疫情高峰的到来，100%在家工作的模式（WFH）已经实施了三个月。
我们是 IBM 首席信息官（CIO）的 CRM 平台团队，刚刚成功完成了将全球销售团队从内部 CRM 系统转移到托管云平台的项目。该项目的另一个举措是在所有的销售应用程序中采用精简的产品层级。
就在我们经历着远程工作的新常态时，公司决定采用 Salesforce 的SalesCloud作为 IBM 全球销售团队和合作伙伴的单一 CRM 系统。
核心目标概述如下 ：
本文讲述的是 IBM CIO CRM 开发团队如何在不到一年的时间里，经历两轮 Covid-19 疫情，完全通过远程工作交付名为 IBM Sales Cloud（ISC）的项目的故事。
背景
我的敏捷之旅正式开始于 2011 年。当时我在 Wipro 工作，为几个客户组织的领导提供咨询服务。在这一过程中，我考察了他们当时在项目和企业层面的工作方式，然后提出了一个路线图，说明他们项目的各个方面需要如何改变才能实现敏捷的工作方式。
在我的咨询和教练过程中，一项关键挑战是确保路线图涵盖了敏捷价值和原则的所有方面，而不是匆匆忙忙地引入一些实践就把它们称为敏捷了。
根据麦肯锡的说法，“全面转型涉及到组织的每一个层面，包括人员、流程、战略、结构和技术“。
图 1：麦肯锡关于转型期间需要关注的各个方面的文章
当我担任 CRM 功能开发的技术项目经理时，我根据自己的咨询和辅导经验定义了一个基于转型杠杆的框架，该框架会关注项目的所有层面。
当我们启动 ISC 交付时，我们使用企业敏捷性主题作为项目管理的杠杆，以确保交付能够触及所有层面。
图 2：基于转型杠杆的项目管理框架
下面我们来看看这些杠杆背后的关键原则。随后我们会详细研究每个杠杆。
现在我们来更具体地分析每一个杠杆。
团队设置
正如我前面提到的，围绕团队设置的关键原则是“独立的工作流“，目的是减少跨团队的依赖性。这也能帮助我们更快地将可交付的增量转移到更高的环境中。团队的设置是与职能领域相一致的，例如机会管理、领导/联系人管理、账户、地区团队等。
图 3：ISC 项目的开发团队设置情况
我必须再次强调，每个团队都需要一些跨职能的技能。很多时候，我们看到企业喜欢设置很多组件团队，例如一个是 UI 团队，另一个是中间件/集成团队，还有一个单独的 DevOps/自动化团队。如果你建立了很多组件团队，你的依赖管理需求就会成倍增长。这也会造成知识/技能的孤岛。
你可能会问，跨职能的真正含义是什么？简单来说，跨职能的团队将拥有所有必要的技能，以自己的方式向更高的环境提供可交付的增量，而不是依赖其他团队的这类技能。跨职能团队的每个成员都会有 T 型技能，也就是既有一个核心专业领域，但也有其他领域的知识，可以在必要时为那些领域做出贡献。
这种设置的另一个关键层面是对团队的支持结构。我们有一个由平台、业务、领域架构师、软件开发经理、设计主题专家和项目经理组成的小组，他们提供了所有必要的支持，因为这些技能中的一些不是每一个团队都具备的。
我们成立了 8 个开发小组来开发 CRM 功能，其中 6 个在印度，2 个在美国。除了这 8 个开发小组外，还有其他小组负责合作伙伴关系模块（Salesforce PRM）、Tableau CRM 和用户支持等工作。
流程
我经常被问到的一个问题是，我们是否遵循什么大规模敏捷方法来交付这个项目？在回答这个问题之前，我先解释一下我们所设置的流程。
根据经验法则，我们的一个迭代设置为 2 周，并且我们每个迭代都应该有一个有效的软件增量成果。我们需要遵循测试优先的方法来实现这一目标。这些过程原则应用于所有开发团队。
图 4：ISC 团队采用的开发流程
独立的工作流使他们能够并行工作。这是否意味着我们没有任何依赖性呢？并非如此。我们有一个每天进行的站会流程，我们称为 Scrum 的 Scrum，每个开发团队都参与其中，站会重点关注解决迭代过程中的依赖性和障碍。
考虑到项目的性质和利益相关者的多样性，我们决定安排统一的项目迭代计划和展示活动。开发团队将单独进行他们的计划会议，并参加统一的项目会议来分享迭代中总结的关键特性和冲刺目标。
最后，为了让利益相关者了解我们在定义的发布里程碑上进展到了哪一步，我们跟踪了迭代目标和发布目标的进展。一个版本被定义为一组需要在一个特定的地理环境中为用户服务的特性。我们每周/每两周向高级 CIO 领导层和项目利益相关者提供一页项目总结，其中包括 ALM 工具的数据，以及需要执行领导支持的障碍和问题。
我们没有遵循任何定义好的敏捷或大规模敏捷框架。我们的重点是在开发团队所做的一切工作中遵循极限编程（XP）实践，然后使用一些 Scrum 活动。
架构
许多组织都很难在架构这个领域中采用敏捷工作方式。当 ISC 项目启动时，设想的项目架构会跨越三个主要领域：
我们设置了一个架构审查委员会（ARB）。它由各职能部门的架构师和产品负责人组成。他们的工作重点是帮助开发团队确定最终架构决策。他们还审查了由产品负责人起草的特性（ALM 语言的 Epics），并提供反馈。这有助于加快解释说明过程，并确保开发团队有初步的设计输入。开发团队可以在一个迭代中多次联系 ARB，并在特性的增量开发过程中寻求他们的支持和审查。
项目中的 Salesforce 架构师在项目启动后的头两个月内发起了沟通说明会议。主要参与者包括产品负责人、业务、平台和 Salesforce 架构师，会议重点关注以下内容：
集成和数据架构是由 CIO 的 CRM 团队的企业架构师设计的，重点包括对源 CRM 进行数据建模，以及可信源、中间件架构和 DevSecOps 实践。
对我们来说，架构方面的一个重要经验是，尽管我们正在做一个一揽子实现（Salesforce）项目，但架构也需要灵活适应变化和用户反馈。基于这一原则，我们重新设计了区域和账户等级解决方案。
工程实践和工具链
建立跨职能部门的团队让我们能够与工程实践和工具链方面的一系列关键原则保持一致。这些原则是：
我们鼓励开发团队遵循测试优先的方法，从而实现了 90%的功能测试自动化覆盖率。
在设置集成时，我们通过专门的 CI-CD 管道将基础设施配置、构建、测试和部署的所有方面都实现了自动化，从而以更快的速度实现了中间件集成服务。与以前的部署相比，该团队可以节省 75%的时间。
我们也是为数不多的使用Salesforce DX的企业项目之一。我们在集成环境下构建 ISC Salesforce 包，然后以自动化的方式将其部署到暂存和生产环境。
以下是中间件微服务的 CI-CD 管道设置的一些突出特点。
团队的主要学习成果和收益如下：
评估和治理
在我参加的一次早期会议上，我对敏捷有了更好的理解。与会者一直质疑的一个问题就是指标。
一个普遍的问题是，像 burn-up、速度、周期时间或 throughout 这些指标，并不能真正反映项目的进展情况。领导层怎么才能知道一切都在轨道上或不在轨道上呢？
主持人巧妙地解释了这一点。他问了一个问题：“你在开车时多久看一次汽车仪表盘？每次看多长时间？“
“如果你过多地关注仪表盘，你就会忽略路况。更糟的是，这可能会导致一场事故“，他解释说。
在我看来，如果敏捷团队专注于遵循宣言中的价值观和原则、与业务部门合作开展最优先的工作、经常构建和部署能正常运行的软件、寻求反馈并采取行动，那么进展对所有人来说都会是透明的，你就不需要那么多治理工作了。
我们在为 ISC 项目建立团队和项目层面的管理体系时采用了以下原则：
图 8：ISC 项目在不同组织级别上的治理工作
我们鼓励团队主动讨论团队间的依赖关系（如果有的话），并在迭代过程中规划它们。由于我们是 100%的远程工作，ALM 工具可以帮助我们以数字方式展现障碍和依赖。这些都是在每天的团队间会议上讨论的，会议重点是立即解决障碍。会议还会讨论意外情况以及迭代项目的其他部分所需的更新。
密切关注所有开发团队在每个迭代中的综合进展是非常重要的。我们每周与来自 CIO 和运营领导团队的关键利益相关者一起审查项目，重点关注：
销售和运营部门的执行领导层开展了一个名为“转型星期二“的项目，在这个项目中，销售领导和来自所有业务部门的代表将被告知项目的整体进展、即将推出的特性和产品发现研讨会的结果，以及他们提出的关键问题的答案。同时，我们会通过专门的 Slack 频道、新闻简报、早期用户的视频以及组织变革管理团队准备的用户文档，与销售社区进行定期交流。
文化
如何定义一个团队的文化？在我看来，文化就是你每天在与其他团队成员、同行、领导和利益相关者的互动中所经历的体验。
ISC CRM 开发团队的一个重点是，我们要在 2020 年 2 月将所有的 IBM 卖家接入当前的 SugarCRM 云平台。这些里程碑是由一个团队在办公室里协作完成的。
这已经是一个紧密相连的团队了。我们从现有的 3 个 CRM 团队中划分出 6 个小团队。我们的目标是让每个开发团队有不同的技能和经验。一组新的团队成员担任了业务分析师和迭代经理等角色。印度的整个团队之前没有任何 Salesforce 方面的经验。
我们也有大约 15 名新成员是从其他部门调来 CRM 开发团队的，或是来自大学校园的新人。与现有的团队成员不同，我们需要额外关注这些成员，以确保他们能够在完全远程的环境中能够充分参与进来——即便我们并没有面对面接触过。
我们试图遵循以下原则：
图 9：团队同心的文化。来源：SpencerStuart（2019）
麦肯锡在他们关于“项目领导力的艺术“的报告中对文化是这样说的：
所有团队成员都认可了“团队同心“的态度，这帮助我们在一年的时间里克服了各种挑战。我们全程远程工作，还要在两轮疫情中模糊工作和家庭的界限，但这些障碍并没有阻止团队前进的步伐，因为我们意识到了项目目标背后有着更大的意义。
取得的成果
从 20 年 7 月底的 ISC 项目启动开始，我们每一次迭代都将新的特性部署到生产环境中。第一个 GEO 所有 BU 的销售在 21 年 2 月都转到了 ISC 上。随后，21 年 5 月是第二个 GEO。21 年 7 月，其余的所有 GEO 都完成了转型。
截至今天，来自所有业务部门的约 30,000 名销售正按照设想在该平台上工作。
该项目还从之前的 CRM 系统向 ISC 迁移了每个 GEO 的数据。所有对象的 1000 多万条记录完成了迁移，并实时流向下游应用程序。
测试优先的方法帮助我们在整个项目期间都能确保交付质量。开发团队只收到一个与开发的特性有关的一级严重事件。同时，所有的工作都通过了对 GEO 特定数据可见性和其他合规性要求的审查。
IBM 领导团队也分享了他们对该项目转型成功的看法。
学到的经验
那么，我们从这么大规模的转型项目的工作和交付中学到了哪些经验？
图 11：CIO 开发团队学到的 ISC 项目经验
如果让我用一个词来概括这一年的旅程，那就是“韧性“。这些团队为实现所有的项目里程碑付出了巨大的努力。作为这一有着惊人成绩的团队的一员，我心中充满感激。
作者介绍：
Jayesh Kadam 在 IT 领域有 21 年的经验，涵盖了软件产品的开发和咨询工作。作为 IBM 的一员，他目前正在领导一个项目，负责交付 CRM 软件——该软件被全球约 3 万名 IBM 销售使用。在加入 IBM 之前，Jayesh 在 Cognizant 和 Wipro 工作。作为这些组织的一员，他在负责的许多客户那里倡导敏捷和 DevOps 转型。他曾在印度、美国和加拿大工作，与全球客户和团队合作。他热衷于将敏捷的价值观和原则渗透到日常工作中。除了工作之外，他还热衷于运动，喜欢看好电影。
Ashay Saxena 博士目前在 IBM 担任产品负责人。他拥有印度管理学院班加罗尔分校信息系统领域的博士学位。他深入研究了解软件团队采用的管理方法，以便在团队分布于全球的形式下通过敏捷方法取得成功。他曾在英特尔、通用电气、Mindtree 和 ThoughtWorks 等全球跨国公司进行深入的案例研究。他曾在一些国际论坛上发表演讲和研究报告，如澳大利亚信息系统会议、ACM 计算机与人研究会议、印度敏捷会议、敏捷领导力峰会、印度敏捷周和软件产品管理峰会。
原文链接：
Going Digital in the Middle of a Pandemic
