多变环境中的灵活转型——IBM企业信息技术运维部门的敏捷重组实践

编辑整理/Cindy Zhu

本案例荣获2017中国组织发展价值大奖最佳敏捷组织奖

项目背景

IBM的CIO（企业信息技术运维部门）自2016年开始进行了一场向敏捷组织转型的实践，此次转型仅用时6个月便达到了预设的目标，并在IBM全球范围内作为典范推广。现在看来，CIO部门如此迫切地寻求转型有着以下几个不可忽视的背景因素：

1  外部环境驱使

随着全球化程度日益加深、智能设备的普及以及云计算、大数据的崛起，企业所处的环境也充满了各种变数和不确定性，我们都熟知的一个词——VUCA，即是对这个环境最准确的描述。面对这样的环境，企业需要能够快速、敏捷地随着市场的变化灵活调整战略方向才能更好地生存下去，而传统的IT架构越来越难以满足企业对信息化不断变化的要求。IBM作为一家历史悠久的IT企业，意识到转型对于企业的重要性。进一步来看，由于信息化在企业中所占的比重越来越大，因此，CIO部门能够成功转型对整个企业的转型起着举足轻重的作用。

2  内部团队背景及汇报线复杂

在转型之前，IBM大中华区IT部门支持着服务于四万多员工和每年预算几千万的IT架构。庞大的支持团队成员跨职能部门、跨业务单元，甚至跨公司到网络运营商，而且，每个人的汇报线又分为GCG（大中华区）-AP（亚太）-Global（全球）三个层级。

此外，随着客户对IT的需求越来越多变，技术复杂度也不断增加，同时，对系统故障的边界和速度之间的矛盾越来越难以界定。因此，无论开展项目还是日常维护，都需要不同技术部门相互协作。转型前，IBM按照不同的技术类型划分人员的职责，在协作过程中，不同职责的人员需要遵循各自不同的审批流程，这使得沟通的成本居高不下。在部分复杂项目开始的时候，还需要更多高层人员介入审批，这导致项目成本高、IT服务质量低、客户需求响应慢、用户体验差等问题。

3  合作模式与项目流程繁琐

除了团队内复杂的人员背景和汇报线，公司内项目流程也较为复杂。每个项目的流程中会牵涉至少4个不同时区的超过8个国家的人参与，这于无形之中增加了团队合作的成本。而且，按照转型前的工作模式，每当有新项目或新产品时，都会临时组建一个新的团队来负责这个项目。由于人员技能的分散性、跨地域、跨部门以及跨时区性，往往在组建团队环节就要耗去大量的时间和金钱。此外， IBM有着完整的流程体系，这导致员工每申请一个项目，大约需要遵守数十个流程，平均每个流程包含10-20个步骤。仅走完项目申请流程，至少就需要87个工作日，同样，项目完结流程也需要1个月的时间才能完成。

基于以上原因，IBM大中华区的CIO团队开始了组织重组敏捷转型的项目。该项目的目标为在6个月内，用敏捷的方法重构敏捷团队，以实现精简组织架构，提升团队能力；优化流程，为用户提供高效的端到端的服务；建立新的衡量体系，以取得团队持续进步的目的。

项目过程

1. 探索阶段

在项目设计探索阶段，项目组首先对旧有的组织架构进行了全面剖析。正如上文谈到的，变革前的IBM组织架构异常复杂，往往一个团队中的成员来自不同的业务单元甚至是有些成员属于外部公司。此外，项目组将CIO团队在工作中牵涉的流程、工作职责范围、汇报结构及考核指标逐一进行分析，并将其工作流程单独拎出来仔细分析团队协作的各个环节，找到问题的关键点及可能的解决办法。基于对现状的清晰认知，项目组与领导层对此次变革调整的愿景做了清晰的界定，明确了此次变革的目的，即：

精简组织架构，提升团队能力

优化流程，为用户提供高效的端到端的服务

建立新的衡量体系，以取得团队的持续进步

2. 组建团队

项目组在变革之初便明确了朝着敏捷型组织转型的方向，因此，决定打破传统的垂直型团队合作模式，代之以squad小分队的形式以达到更加灵活的工作效果。随后，根据团队需要提供服务的类型、支持的系统、服务的用户等情况确定了squad小分队的数量及主要职责。为了尽可能提高小分队的敏捷性，项目组在组建团队时根据其提供的服务类型、支持的系统、服务的用户等情况灵活安排具备不同技能的员工到squad小分队中，以求每个团队都能提供端到端的全流程服务。每个squad小分队在选择队员时一般会遵循以下几个原则：

同一个Squad小分队的成员属于同一时区

同一个Squad小分队的成员技能要具有互补性

每一个成员都需要认可敏捷的工作方法

目前，每个小队中有8-10名成员，且配备一个Iteration Manager（IM，即迭代经理），这个IM须对小队成员的擅长方向、工作能力有清晰的认知。中国区的所有小分队均隶属于一个Tribe（部落），Tribe中设有一位Product Owner（产品经理）来管理所有小分队的工作。

由于IM与PO对于IBM来说是全新的角色，因此在确定这两个职位的具体人选时，经过了一些摸索，最终确定了目标候选人的大方向，并且随着团队敏捷程度的提高，这些角色的职责内容也不断丰富。具体来看，PO一方面需要具备与业务部门对话的能力，能全面搜集业务部门的需求，且根据这些需求的轻重缓急做出排序；另一方面，还要对所有小分队的情况了如指掌。基于这两方面要求，项目组最终找出PO的最佳人选。在实际工作中，PO需要对用户需求做出清晰的解释，并最终决定小分队的工作内容。

IM的选择则根据具体的团队性质分为两种情况：对于技术偏向的团队，项目组会倾向于选择技术能力较强，且知识面广的人担任该团队的IM；对于运营偏向的团队，则倾向于选择沟通能力强，能和团队打成一片的人。但总的来说，无论何种偏向的IM，均须对squad小分队成员的情况有清晰的了解，且随着项目的推进，其自身的能力都需要进行相应提升。如，专于技术的IM会填补其沟通能力的空白部分，擅长团队沟通的IM也会提升自己的业务水平以跟上整个小队的脚步。在实际工作中，IM一般通过仆人式的领导带领队员完成PO安排的工作，具体来看，其职责包括：1）保证小分队在一个迭代内完成PO分配的工作；2）用心观察队员的状态，并在需要的时候提供教练服务，使队员能够对“敏捷”这个概念有更深入的理解，并按照敏捷的原则工作；3）营造专注工作的氛围，帮助队员挡掉来自于团队外部的干扰，使其专注于目前迭代中需要完成的工作。此外，IM还会为队员提供其工作需要的各种资源与帮助。

3. 分配工作

在squad小分队组建成功后，项目组与PO（Product Owner产品经理）一起，将所有需要完成的工作全部罗列出来，并且根据PO的要求，对工作作出优先级排序。每一次迭代开始前，所有IM（迭代经理）会和PO一起确定该迭代需要完成的所有工作，之后IM会根据Squad小分队的工作量将不同的工作放到Squad小分队的待做事项列表中。每个小分队的成员都会自动从待做事项中抓取他们能够完成的工作，并通过团队讨论为每一份工作制定一个分数，用来表明工作量的多寡以及工作的复杂程度；且每一份工作都由整个团队端到端地负责。Squad小分队需要在2周内完成一次迭代，每次迭代结束之后，IM会对工作完成情况进行回顾，并根据完成工作任务所得到的分数情况，在下一个Iteration做相应的调整。不仅如此，项目组还会定期对整个小队的规划进行回顾，并持续改善团队的架构，真正做到灵活敏捷地应对业务需求。

4.考核管理

1） 团队考核

    最后，在考核方面，以往的考核大部分都只针对个人。转型之后，项目组为小队设置了全新的绩效考核标准，不同于以往的职能分权制，其对敏捷小组采取了联邦分权制，对每个小队进行整体的绩效考核。

为了增强squad小分队敏捷工作及沟通的效率，项目组尝试使用过多种工具对其工作量、绩效等进行量化的考核，但由于工作种类的多样性、复杂性，一般的工具难以满足这一需求。因此项目组引入了基于云工作流管理工具——Trello。该工具可以实现待做事项可视化，并管理工作进度、量化工作量，此外还可以针对每次迭代或对每个小组成员进行数据分析。项目组可根据该分析结果对团队模型或工作分配进行调整。

在trello中：

每个团队拥有自己的看板

每个看板分为“待做事项”、“正在进行”、“等待”以及“完成”4个列表

每一个工作由一张卡片表示

每张卡片可以指派给一位或多位队员

每个卡片根据工作量及困难程度被赋予不同的分数

也就是说，每当团队拿到工作任务时，会将其在trello中分解成多个不同的user story（用户故事）放到卡片中，每张卡片有一个所有者，即团队中的队员。卡片根据工作内容的具体状态会在“待做事项”、“正在进行”、“等待”、“完成”4个列表中流转。这种方式能够直观地将团队的工作进度展示出来，而且，通过对比团队每次完成任务所需时间，即可判断该团队的工作效率、客户需求响应速度等是否提高。

具体来看，IBM对小分队的考核主要从tribe（部落）层面以及Squad（团队）层面分别进行，考核集中在以下几个方面：

是否达成了成本降低的目标

是否能灵活快速响应客户需求

是否促进了业务增长

是否提升了服务质量

是否改变了成员的工作方式

其中squad层面的考核主要关注团队内部工作效率是否提高，强调对于敏捷理念的传递与实践；tribe层面的考量则集中在BU对团队提供服务的满意度是否提升、是否产生了业务价值等方面。

2） 个人考核

在旧的组织架构里面，CIO的团队成员来自不同的业务部门，且有各自不同的汇报经理。在项目初期经常会出现一个成员须同时汇报给2-3个不同经理的情况，这使得IM对队员的影响力非常小，进而降低敏捷工作的效率。如果这部分员工的考核归属继续放在其原公司，那敏捷组织的转型将很难继续推进。意识到这个问题后，项目组通过与人力资源及相关部门进行了协调，同时将遇到的问题及阻力向全球更高层的相关领导反馈，要求支持。最终将所有团队成员的考核归属争取到新组织中，解决了因考核归属导致的沟通效率低下的问题。

新组织架构下，对团队成员个人的考核有了很大不同，考核指标主要集中在以下几个方面：

是否以客户的需求为工作重点

是否践行敏捷的工作方法和理念

是否对团队有所贡献

在具体的考核过程中,IBM不再对squad小分队的队员设置具体的KPI，而是通过定义员工的工作范畴，由其领导、同事或客户对其工作给予反馈；同时，PO和IM会分别给团队、队员进行打分。员工最终考核则结合各方反馈及PO、IM的打分最终评定一个分数。可以看出，新的考核模式中，IM及PO对员工的薪酬绩效发挥着较大的影响，这有效提高了squad小分队的工作效率及工作质量。

沟通创新

1  沟通的方式。

为了配合小分队灵活敏捷的工作模式，IBM项目组在沟通方式上也做了相应的调整，由传统的经理对员工的工作指派、员工对经理直线汇报的方式转变为每天开15-30分钟的小组会议的方式。所有队员在会议上陈述已完成与将要完成的工作，同时提出自己遇到的困难，由大家共同讨论最终找出可能的解决方案，此外，每个队员须在会议中对自己的工作做出承诺。通过小组会议的方式进行团队内部沟通，能够做到时刻保持工作透明化，而且员工能快速从队友那里找到所需的帮助，这大大提高了团队工作的效率。

此外，每次迭代后，小组成员会召开一个回顾会议，会议主要讨论此次迭代过程中出现的问题，逐一对其进行分析，做得好的地方继续强化，而需要改进的地方则记录下来持续跟进。不仅如此，为了让员工随时表达自己的工作情绪，同时，为了方便IM关注团队的工作状态，并根据目前的状态做出调整与改进，项目组还在沟通环节中为员工设置了相应的情绪出口，即“情绪墙”与“情绪球”。在“情绪墙”中，员工每天根据自己的心情选择不同颜色的贴片贴到自己头像下方，贴片分为绿、黄、红三种颜色，分别对应不同的心情。“情绪球”与“情绪墙”类似，员工可依据当天的心情投掷不同颜色的球到相应容器中，一个迭代结束后，IM只需观察容器中球的颜色分布便可大致清楚这段时间内员工的工作情绪如何。项目组认为，用这种方法来了解员工的工作心情要比做问卷调查或面谈要敏捷得多。

2  沟通的工具

为了提高团队内部即时沟通的效率，squad小分队降低了邮件的使用频率，放弃了老旧的传统即时通讯工具，并启用了最新的通讯工具——Slack。Slack作为一个安全加密的平台，可支持团队进行小组讨论、文件分享，并且能够和许多外部系统进行集成，提升沟通效率。此外，项目组通过二次开发，使全部重要的系统告警均能够自动推送到Slack的指定频道，同时，将Slack和Trello进行了无缝整合：通过Slack可以自动在Trello中建立相应的工作卡，而当Trello上面的工作卡有更新时，系统也会自动将消息推送至Slack。

工具创新

敏捷的工作模式在软件开放上有颇为成熟的实践，但是此次在IT基础架构项目和运维上开展敏捷实践几乎没有可供参考的案例。因此，项目组在摸索的过程中采用了新的技术和工具来帮助其克服项目推进过程中遇到的困难。这些技术和工具包括：

1  基于云的视频会议平台Zoom

由于团队成员分布在不同的城市，传统的电话会议不能满足敏捷团队的要求，因此项目组将所有的会议全部改用视频的方式，通过基于云端的视频会议平台，使团队成员可以面对面进行高效快速的沟通交流。同时，其充分利用了该平台的投票、分组讨论、会议录制等功能，在降低会议费用的前提下，大幅提高了会议效率，增加了团队凝聚力。

2  大数据分析平台和设计思维

项目组使用了公司的大数据分析平台，对过去收集的所有系统数据及日志进行建模，建立不同的用户画像，从而为各个不同的系统设置相应的指标参数。通过对比最新数据与指标参数的变化量，可以从系统层面得出用户满意度的变化曲线。同时，加入用户报障的历史记录，结合当时系统的运营数据，设置不同系统参数的告警阀值，使团队可以预先感知系统运营瓶颈，及时调整从而提升用户体验及满意度。

3  团队流程协作管理工具Trello

传统运营和管理团队最大的难点就是跟踪工作内容，敏捷团队最重要的改变就是使工作内容透明化。在一个团队中，其成员需要清晰的了解所有人的工作内容及进度，而在Trello里， 团队成员可以方便地记录新的工作进展，为工作设置需要完成的步骤，然后邀请队员与之一起进行其中的某一步。在工作状态发生变化后，通过简单的拖拽，就可以将任务放到更新的状态列表里面，以便下一个成员接手。借助Trello，每个小组成员正在进行的工作、工作进度、待做事项等一目了然。如此，团队成员之间的配合更加得心应手，IM也能够更清晰的了解团队成员的工作负载。

项目调整

在转型推进的几个月时间里，项目组尝试过多种不同的合作模式，这也是一个不断试错的过程，往往在设计时被认为完美的模型，在实际运用的过程中会出现一些意外的情况。根据这些情况不断对细节进行调整，才能使项目最终达到预期效果。具体来看，在初期，squad小分队的模式在工作过程中出现过以下问题：

不同的小队对敏捷的理解程度差别比较大；

缺乏具有经验的iteration manager迭代经理；

小队之间存在过多工作交接；

为敏捷增加了过多的工作和报告；

单个小队规模难以对某些具体问题承担端到端的责任。

针对上述问题，项目组对整个项目做了一下调整与完善：

1  打磨细节，应需而变

其在每一次阶段性回顾会议上对当前出现的问题进行梳理，并找到提升点。同时，项目组用4个迭代的时间来重构squad小分队，并通过内部甄选、指派寻找具有合适技能的成员加入小分队。经过调整，其最终减少了小队数量，最大化地降低了工作交接带来的时间成本。此外，在最初的设计中，项目组希望每个小队的队员能够面对面坐在一起讨论、执行工作，但实际上，由于需要同时考虑成员技能的多样性，所以很难在同一地点的办公室中找到一个团队所需具备的所有技能，因此，小队中的成员基本上分散在北上广深港等地的办公室中。为了强化团队成员之间的联系，项目组引入新的沟通工具，即上文提到的Slack及zoom等工具，来弥补团队成员不在同一城市的补足。新工具的引入让团队成员之间建立了牢靠的信任关系，也最大程度地降低了工作交接的数量和成本。

2  敏捷培训，补充技能

新的工作方法引入了新的职位设置，如Product Owner（产品经理）、Iteration Manager（迭代经理）等，新角色需要新能力来保证可持续的敏捷工作环境；而在项目初期，很难直接在组织中找到具备相应能力的人担任这些新职位。为此，项目组开展了针对队员的敏捷培训。敏捷培训主要分为两部分，第一部分为线上课程，第二部分为线下培训。

线上敏捷课程针对IBM所有员工开放，侧重对于敏捷的理念、原则、价值等基础内容的培训。线下培训则通过教练的方式进行，项目组会邀请公司内部的敏捷教练全程督导，并对有潜力的队员做定向技能培训，使其能够快速胜任新角色。教练需要在团队中与小队成员一起工作一段时间，全面了解该团队目前的工作内容、工作方式及流程等，并根据其观察给出具体的定制化的意见。同时，敏捷教练会在这个过程中不断重申敏捷组织的理念，使队员对“敏捷”这一概念有更清晰的理解。

项目难点

IBM的CIO团队在6个月内迅速完成了向敏捷组织的转型，其在向新型组织转型的过程中不断探索、调适，使整个团队处在最佳的敏捷状态。当然，这也是一个充满挑战的历程，这些挑战包括：

没有现成的经验可参考。整个团队可谓在“摸着石头过河”，其每一步，如划分小组、组建团队等都需要项目组花费心思精雕细琢，而且需要通过不断地实践来试错、检验其正确与否。

协调利益相关者。此次转型相当于对整个架构做了一次大手术，这必然牵涉到众多利益相关者。变与不变的观念会自然地将之分为两派，其中权力的变更也会碰到部分人的利益，因此，这对项目组来说是比较大的压力。

培养员工的“敏捷”理念。IBM是一家奉行流程至上的公司，其员工的工作内容只涉及整个流程中的一部分。当项目组引入“敏捷”的理念时，大部分员工关于流程的根深蒂固的观念很难转变，其仍然将旧有的工作方式带到新团队中。因此项目组需要不断观察团队成员的工作状态，并对其进行观念上的梳理，将团队拉回正确的方向。此外，由于敏捷组织对于人的主观能动性的要求大大增加，因此如何激发成员的动力和创造性也是项目组常常需要思考的问题。

“敏捷”型组织不是一成不变的。敏捷是指能够对外界多变的环境做出灵活的反应，这也在一定程度上决定了它不是一种固定状态。项目组在探索的过程中尝试过不同类型的“敏捷”，发现即便外界有成型的敏捷实践，也不能直接生搬硬套。因为，具体到不同的团队，其对“敏捷”的理解与要求都存在较大的差异。适合本团队的模式需要不断实践、调适才能最终摸索出来。即使是已经取得诸多成果的squad小分队模式也是在不断变化的过程中。

项目成果

项目组根据敏捷的原则，从上到下简化了整个组织架构，组建了灵活、稳定、跨职能且专职的squad小分队为客户提供端到端的服务，大大减少了工作交接和审批环节。小分队成员对敏捷的工作方法、原则及价值观形成了共识，提高了工作热情，并通过迭代的方式为客户提供持续完善的产品和服务。项目组为squad小分队争取到的工具也使得其能够充分发挥创造力，良好的工作氛围也吸引了更多人才加入。

目前，该项目基本达成了精简组织架构、优化流程及提升客户满意度的最初目标。总体来看，其成功最关键的因素是公司总部的大力支持。CIO领衔成立敏捷学院，联合人力资源及各事业部从上至下进行全员成体系的敏捷培训、认证和教练实践，并组织各级领导力培训，使得敏捷文化逐渐形成并日益成熟也是项目组能够成功在IT项目运维领域转型成为敏捷组织的关键。具体来看，该项目取得了以下几项成果：

1  成本降低：

项目组移除了低效且重复的会议，为团队节省约20%的时间，此外，简化了不必要的流程和审批，使项目申请周期由87个工作日缩短至14个工作日，这大大提高了squad小分队的工作效率，降低不必要的时间成本。同时，为了充分发挥squad小分队的敏捷性，其被赋予了更多的能力和权力，极大地释放了小分队的生产力，而内部成员技能的多样性也使得整个团队能够产出更多有创造性的工作想法。

2  客户满意度提升

在新的组织模式下，客户可以根据业务需要来安排squad小分队工作内容的优先级，且小分队在收到客户请求之后可以立即投入工作，节省了临时组建团队的时间，客户能够随时看到小分队的工作进度并给出反馈，小分队也能够根据具体需求灵活地对工作进行调整。这些都带来了客户满意度的提升。具体来看，项目组主要从3个维度来收集有关客户满意度的数据：

1）通过全球CIO的问卷调查，用户可以进行匿名投票，对所有的IT服务进行评分。评分结果显示，目前，GCG（大中华区）的客户满意度在全球排名第一；

2）每次迭代结束后，项目组都会向PO及客户收集反馈信息，从这些反馈结果来看，这种squad小分队的模式受到了公司内的一致认可。不仅如此，这一模式还被作为范例在全球范围内进行推广；

3）项目组通过技术手段，对面向不同用户的画像收集到的近百项指标进行了分析。分析结果显示，超过70%的指标在客户满意度方面均有提升的趋势；

3  业务增长

Squad小分队对产品提供了端到端的服务，这极大地降低过去因工作在不同团队之间交接而产生的效率损耗，进而使得整体的业务吞吐量提升了20%-30%。不仅如此，由于小分队的工作模式更加灵活多变，能更快速地满足以往业务部门无法被满足的需求，提高了业务部门的竞争力，这间接促进了业务的增长。

4  质量提升

在新模式下，Squad小分队需要对端到端的产品和服务负责，所以更能站在客户的角度思考问题，准确切中客户需求，从而提高了产品或服务的质量。此外，项目组建立的大数据分析工具能够在第一时间检测系统故障，预测并提前处理这些故障，减少其对客户产生的影响。

持续完善

正如该项目负责人张先生所说，敏捷型组织并非固定的模式，即使在IBM内部，每个团队的敏捷工作方式都会有细微的差别。因此，为了使得团队能够一直处在适合自己的最佳敏捷状态，项目组也一直进行着持续完善的工作。其会持续关注公司关于IT的投资预算，并随时调整、定制项目的优先级，以便为业务提供更有价值、更高效的解决方案。此外，将持续优化对现有团队的绩效评估指标，并进一步优化现有流程，赋予squad小分队更多的职责权限，更大程度地激发团队活力。

具体到小分队的改善方向，张先生坦言，由于小分队的工作范畴较大，有些直接面对客户，有些则需要在整个工作架构层面做设计，加上项目组在组建小分队之初并没有对小分队原本的工作内容、性质进行大调整，所以，目前各小分队的能力及职责范围仍有所区分。未来，项目组希望每个小分队所具备的能力、负责的工作内容逐渐趋同，即小分队A与小分队B所负责的内容可以互相调换。为达到这个理想状态，项目组会逐渐把相对简单的项目在小组间转换，使之互相了解彼此的工作内容并逐渐熟悉。此外，根据成员的兴趣，项目组为其设计专门的培训计划，致力于将其培养为“T”型人才，即既有自己的专精领域，又有广泛的知识应对一般的问题。唯有如此，squad小分队才能达到最佳灵活状态，也能够最大程度地将其能量发挥出来。