从进化角度看规模化敏捷，上海银行4500+人实施案例——2023RSG大会演讲实录

点击蓝字 关注我们

导语

本文是吴穹博士与上海银行金融科技部项目管理部负责人王勤瑜在2023年上海RSG (Regional SCRUM Gathering) 大会上共同发表的演讲实录，以上海银行的规模化敏捷演进历程为轴，和大家分享最新的思考与实践。

上海银行敏捷历程

上海银行的规模化敏捷历程，大致可以分为三个阶段——“萌芽探索”、“试点成型”和“全面覆盖”。

1

萌芽探索

早在2015年，Agilean首次尝试在直销银行，引入了Scrum和Kanban的基本实践，但从结果上看，很快就回退了。

我们开始领悟到，敏捷如果仅仅是照本宣科，在开发环境做一些简单实践，通常很难持久。所以，除了改变团队的协同模式，配套的管理机制、流程制度和工具也需要随之改变，组织变革落地的可能性才会提高。

2

试点成型

2019年，Agilean和上海银行的再次合作，依旧选择了在直销银行和手机银行的研发团队着手试点。经过一年多的实践，试点团队的卓越表现，证明了试点的数字化研发管理模式是足以支撑规模化转型落地的，这里的成功经验也开始被评估，面向全行推广的计划开始成形。

3

全面覆盖

2021-2023期间，上海银行将“数字化手段支撑的规模化敏捷机制”全面覆盖IT和DT所有科技交付团队。在上海和苏州两个研发中心，成立36 个交付部落 ，267 个小队，实现了覆盖超4500人（含约1000行员）的规模化敏捷。

浅谈数字化

Agilean很认同Wikipedia对于数字化转型的定义“Digital transformation is the process of adoption and implementation of digital technology by an organization in order to create new or modify existing products, services and operations by the means of translating business processes into a digital format.”（数字化转型是一个组织采用和实施数字技术的过程，目的是通过将业务流程转换为数字化的形式来创新或优化现有的产品、服务和运营。）

在读到“In order to create new or modify existing products, services and operations”，大家可能会产生疑问，真实情况下好像每个组织的日常工作，其实都是在循环往复的创造或改造，强化自己的业务模式吧？如果说数字化转型就是在做新的业务模式，难道企业原本没有在日夜兼程的思考，去创新业务模式吗？所以，这并不是本质，本质是什么呢？本质是，第一，应用数字科技；第二，流程变革， 我们实现的一定要是组织上的变化。

数字化要做什么？

在数字化转型之前，管理者依赖的只有一些 “管理者的直觉和经验”，去做决策，并没有太多客观的数据作为依据，这就是原本的组织现状。

随着数字化转型的推进，管理者要从原本依赖直觉、经验的决策习惯转变到依赖数据的方式，也就是说，组织要在管理和决策的中间，引入更多的数据。当然，转变并不代表完全的取代，管理者的直觉和经验依然是重要的参考因素，完全利用数字决策模型来取代管理者在长时间的实践里培养起来的直觉与积累下来的经验，也是不可行的。组织要做的是用数据来强化管理者原本积累的经验。

所以，Agilean认为数字化带来的一个很大的变化，就是用数据来支撑管理，应用数据来提高生产力。

此外，为了更好应用数据， 组织需要快速演进自己的组织架构，以此来优化生产关系，最终更好地消化数字化转型为组织带来的生产力上的变化。

生产关系变革案例

上世纪八十年代我国农业做了一个管理转型，称为家庭联产承包责任制（1978年改革开放以来，随着家庭联产承包责任制的兴起，极大地提高了农民生产积极性，进而促进了农业生产效率的提高。这是辉煌的10年，也可以说是“三农”10年的“黄金期”），解决了人民的吃饭问题。

这一过程中，我们的生产力本质上没有发生变化，牛、犁、化肥等重要的生产资料都没有太大的增幅，但国家做了一件事，就是开始让农户耕种的粮食很大程度上归农户所有，可能只需要交一些农业税，剩下的东西都归你。

所以，我们认为在生产力的提升以外，生产关系的变革也非常重要。

所以， 当我们谈论数字化转型时，一方面是要通过应用数据来提升管理决策水平和生产力。另一方面，也通过将组织变革往敏捷化牵引，因为敏捷化的组织是数字化转型的重要支撑。

最后，不要忘记目标，Agilean希望让业务模式能更丰满，成本能更优化。以此为基础实现的数字化转型，就能让组织开始进化，就能实质上提升帮助组织探索新的商业模式，优化成本结构。

科技的问题就是“慢”？

近几年呈现出一个趋势——大型组织的科技团队规模在快速增长。在这个背景下，Agilean与包含上海银行在内的这些大型组织接触中，我们洞察到不同角色对于彼此间的协作有着视角不一的负面评价。

基本所有的业务方都会提到“科技交付好慢”、“系统不好用”；研发侧总说“业务不讲武德，需求说改就改”；而另一些相关方也提出：好像有的团队会很忙，但也有些团队会周期性的忙闲，存在一些结构性的忙闲不均的问题；而在管理层则感觉到，尽管组织规模已经扩张到了几千、上万，甚至几万人，交付好像也并没有变快，甚至好像更慢了。

这时候，管理层就开始思考如何破局，因为一味提高资源填充无法治本，组织的业务量对成本的承受是有阈值的。一些细节繁杂的系统问题开始浮出水面，并且无法被简单地解决。

解决思路：建立“生态”帮助自主进化

通常情况下，组织在识别到复杂系统问题时，会采用所谓“计划经济”式的解决方法。比如形成一个部门，让这帮大脑来思考，将结论在组织内流程中改一改、发布、指挥执行。最终在经历了痛苦的推广和沉淀以后，在后评估报告中发现好像没有解决问题，或者没有解决根本问题。

那么如何弥补呢？可以参考后来的“市场经济”对于计划经济的补充，允许市场内的“主体”自管理其生产过程与结果，主体之间互相交易与竞争，形成一个“生态”。这对于研发管理也有参考意义，这就是为什么，Agilean希望将研发团队演变成一个生态型组织，独立的主体们持续交互，促进其自主持续地优化与进步。

在这个生态型组织内，首先要建立面向业务的组织，即，在这个大组织内建立多个的小组，每个小组有自己独立的目标、度量和运作方式，通过小组间的互相协作来解决管理问题。同时，搭建匹配组织的角色体系，这是对于生态组织架构的设计。针对构建的组织，组织需要为其定义产生数据的方式，即，要设计能让组织主体间的协同行为能够产生数据的端到端管理信息架构。

完成这些顶层设计后，组织就可以开始“迭代”。因为组织需要可持续地快速演进，所以，我们希望组织能够有一个稳定的迭代节奏，能够持续交付当期优先级最高的需求。

自此，有了组织、数据、迭代，就可以逐步沉淀，形成度量体系，并基于度量反馈建立回顾机制。

总的来说，将8个要点集成4个大方面——构建组织、数据基建、节奏迭代和度量驱动，以形成一个能稳定、自主、持续进化的组织来达成战略目标。

本质上来说，“卓越的组织是类似的”，不管目标是什么，是研发效能提升、数字化、降本增效... ...只要是组织想做的事都可以，因为要做的工作不会变，都是需要建组织、明确角色分工、建立协同的方式、产生稳定的交付节奏、能开启反馈改进的闭环。在这个基础上，Agilean认为，组织也需要引入数字化技术，通过统一标准的平台来支撑这个框架下包含的组织、协同、节奏、回顾、数据等内容，确保这个“生态”真正的落地生根。

上海银行的演进案例

Agilean与上海银行的合作，是从如下“八个支撑”切入，基于知微这一数字化协作平台底座，在项目周期内超预期达成了研发效能提升的目标。

1.组织：构建对齐业务的自主改进单元

银行业组织搭建与演进历程，深受科学管理框架下的职能式组织架构的影响。以工作方法和技能作为分工依据，独立设置管理机构，如开发一部、测试一部等。而在职能部内，常按系统分工，渠道在这能灵活调配资源，也能够有效使用技能，提高特定工序的效率。然而，当组织规模扩大到一定程度的时，以往小规模团队环境下不被定义为严重的问题会暴露出来。

完成一个需求，会经过多个职责、多种角色和多个系统。在这样高度耦合的协作网络内容易招致高昂的沟通成本。需求的分发澄清、资源的协调，涉及系统范围的界定等等待定要素，都在“这应该找谁？”、“可能涉及xx部门”、“我不知道，我要问下我科长”、“这事需要跟上级协调一下”... ...的复杂协调中消耗了时间。倘若决策领导本身时间有限，或所需关键资源本就疲于多个项目，那么组织的效率就更显著被拉低了。

另一方面，职能型部门也像一个个独立的“筒仓”，筒间体量大，相关性弱。容易出现“各自为营”的局面。例如，当时效慢、缺陷多等问题被分析指出后，在复盘中开发部往往会归因在上游需求晚到、加塞、缺乏澄清、说变就变或下游测试不充分。测试部则会认为开发不规律提测，或者开发质量不佳是主要的阻碍。当责任被附加边界，自然难以协作，更无法整体思考如何改进。

在上海银行的第一步，是构建对齐业务的研发自主改进单元。这个构筑方案主要是在现有的实体组织架构（部门、科室...）下，建立面向业务的虚拟组织，把服务同一个业务板块的研发人员都集成在一起，甚至可以物理上集中办公。

虚拟组织的构建，让这些人有了共同的组织目标，可以作为一个活跃的集体来思考如何能更好地服务业务。从组织形态的角度解释，虚拟组织是在原本“纵向”的职能部门里，“横向”拉齐了完成一个需求所涉及的各种角色。此外，充分授权该虚拟组织，搭配对应的考核评价，允许其进行自主规划与管理。

在上海银行，我们在项目初期合作划分了面对10个业务板块的23个部落，并关联了200+个小队。当然，组织架构划分难免有妥协，但面对变革，我们的目标应该是接纳不完美，尽早的构建虚拟架构，将资源都圈起来后，在组织运营中慢慢演进。

人是组织的重要资源，针对特定兵种，采用行会机制进行技能型管理，拉动专业能力的长期建设。至此，行会与部落两个交织的虚拟组织就建立起来了，叠加实际的实体部门，我们就能构筑一个多维的、分层的、反映真实、面向业务交付的组织结构管理体系。

2.角色：梳理匹配组织的角色体系

角色职责边界的模糊是大型组织中的常态。在Agilean与银行业的一些企业的接触中，最常听到的角色是项目经理，但是在项目经理这个角色下，有的人在负责需求分析，有人在编码，有人在做架构，有的甚至在复合做多种工作。

所以，当组织圈定了资源，就可以把资源匹配到对应的角色，形成角色体系。在这个体系内管理者能清晰地、真实地了解其所辖的团队成员各自在做什么任务，清晰每个人的职责范围与成长路线。而职责范围的清晰将降低工作中的打扰，提升整体的研发效能。此外，清晰的角色体系，也会为组织带来更多潜在的好处，譬如可以观察组织的资源配比，为研究组织阵型的优化与资源效率的提升奠定了基础。

3.需求体系+价值流：形成端到端的管理信息架构

研发数字化的下一步基建工作，是想清楚“事”，也是定义产生数据的方式。进一步讲，是形成标准的需求体系和对应端到端透明的价值流，以此来保证组织主体间的协同行为能够产生真实的数据。当然，这项工作同时也是在尝试以数字化的形式还原组织内研发工作现场，在工具上透明业务需求从提出，拆分，一层层流动到最终投产的过程，并统一、规范这个过程中所涉及的术语，结合角色定义好谁会在什么阶段参与进来，以此减弱协作摩擦，提升沟通效率，改善组织中常见的多系统、多层级、多团队的复杂协作现状。当然，这些价值流在不同的组织或团队都会有一定的差异性。无论如何，我们的价值链设计需要因地制宜，也需要基本统一，让组织建立一致的术语。

在上海银行的案例里采用初版设计如下图：

内部的项目管理平台工具负责需求的审批，在关键节点做强管控，而对于派发到系统、拆分到团队、更新状态、报工等等是通过知微完成。如此安排能够让组织轻松的看到需求的主辅办情况、进展与风险，规避了人为过程管理对团队的打扰。需求方和管理方不需要为了获取进展信息而反复“追”问，也不再因不知道负责人是谁而被“踢皮球”。

总之，我们希望通过在线透明状态，积累过程数据，甚至可以向业务、领导层开放，将整个研发过程送进一个“透明厨房”，这种支持随时打开，看到“需求到底在哪？”、“有无阻碍？”的方式也将帮助业务解决研发“黑盒”的问题。

4.优选：建立帮助聚焦的需求优选机制

第五项支撑是稳定的月版优选机制，这是目前Agilean咨询团队接触到的大多数银行组织都希望采纳的版本管理模式， 这将从降低“拥堵”的角度支撑业产研协同优化。

举个例子，对于需求方而言，总会认为自己需求的优先级都是最高的，但其对于研发团队所对接的需求方个数和它本身的“容量”是缺乏概念的。所以，在业务普遍强势的情况下，研发团队会处于一个“拥堵”的状态。因为需求方不知道科技有多少人，每个月能干多少活，那么需求就无法规划。倘若科技说不能做到本周或当月上线，问题往往就升级到领导。

所以，在组织清楚科技的可用资源后（比如有20个人，那团队每个月容量就差不多20*22=440人天），下一步就可以开始建立全行的版本迭代日历，确定每个月版的计划排期、联调等时间，建立一个基本节奏，降低组织间的沟通成本。

同时，透明的版本规划也给了科技与业务基于容量规划上线时间的空间。此外，稳定的发版节奏也从某些方面缓解了需求方的上线焦虑，也开始考虑优选，让真正高优先的需求先排期。最后，形成一套组织适用的业技协同机制，实现双赢。

5.节奏：稳定的统一月版排期机制

在统一月版排期机制的思想对齐后，Agilean在上海银行敲定了几个版本规划指标，包括版本达成率、加塞率和下车率。通过指标来识别异常，推动改善版本管理。

在这里我们会主要观察加塞。从现实来说，业务加塞几乎是无法避免的，所以所谓迭代100%完成，将所有加塞都推到下个迭代来优选本质上极难实现，但组织能做到的，就是持续的观察，将影响因素逐步关闭，起到越来越规律的效果。

此外，版本达成率也不允许达到100%，因为假若100%的达成率和50%的加塞率同时出现，这只能证明团队的版本规划过于保守。

下车率，则是在关注撤版的问题，它往往关于质量风险，因为代码是有生命周期的，当周边的系统一直在变，早先提交并通过联调测试的代码对周边系统的适配程度就在逐步降低。

利用这三个指标来为组织提供信息，帮助组织的改进决策，这是一个实际的改进思路。

6.度量：建立指导性的研发效能度量指标体系

当安置好人、事、流之后，组织就可以通过搭建一个多快好赞的指标体系，来描述团队的效能。在这一个度量体系内，Agilean咨询团队建议的整体目标是将数据结果反馈给每个研发团队，让其了解自身，明细如何改进，让组织能够运转起来。

7.反馈：为多层级管理者搭建数据反馈机制

在度量体系搭建与数据积累的同时，Agilean咨询团队也搭建了多层级的研发管理大屏，并利用最基础的实践——站会，保证每个小队能在站会前更新卡片上的状态等数据，这就等同于每日频次的基本数据收集，实时积累，并根据管理层级的差异化需要，精选给到小队级、部落级、中心级和组织级的管理者不同结构的数据。

这不仅仅是将一堆数据可视化出来，而是应用“聚焦”的思路，根据组织内所发现问题的优先级，定期改变供数的重点，比如这段时间可以通过分段时效解决飞卡率的异常，下个周期则通过加塞率来治理排期严肃性等。

通过定期引导组织关注不同的数据，来逐个改进组织当前识别到的最大问题，以此来闭环一个持续反馈与迭代优化的组织进化过程。

8.一个底座：协作平台

整体来说，以上所有的支撑，上海银行和Agilean咨询团队都是基于协作平台来完成的。知微在中间作为一个组织协同的平台，在最上层对接了行内的审批流管理平台，将组织结构、需求体系和流动价值链管理起来，并在最下层形成一些度量数据。

至此，三层结构中，最上层管理审批；中间层是一个能灵活应对管理者的主要诉求的管理工具，保证协作与日常效能数据的更新；第三层则为单角色进行自己日常工作的平台（如CI/CD和测试管理平台等）的工具体系。

总的来说，推动大型组织的管理变革，像这次上海银行4000+人的组织，利用数字化技术是非常关键的，靠着人为巡检和探查，管理半径是有限的，而现在利用系统工具协作，用数据驱动变革，则有了更实际的效果。

9.成效总结

在完成了包括组织架构、角色体系、需求体系、排期机制和度量体系等支撑机制的建设之后，团队研发时效提升了26%，同时，也为管理层提供了数字化的度量观察体系，这样就可以开启改进。

当然，这个过程并不是一蹴而就的，根据经验预测可能至少需要花费3年左右的时间。这是因为数据从0-1的产生到1-100的沉淀，需要一个治理的过程，并不是当数据建设好后，就可用了。很多管理的数据，需要治理的程度比业务数据高，这是由于业务数据与资本相关，相对来讲会非常精确。而管理数据，就很容易失效。

这里有一个例子，当我们探查一些组织的交付时效时，发现开发时效仅需要1天就能上线了，沟通后发现，其实是系统内的强管控造成了数据假象，有一些类似不填表、不补交付件就不让上线的流程规定，所以团队就在上线前在管理系统里补填很多信息，导致了“管理系统挺好用”的假象，但是导出的数据都充满了“走后门”的异常。所以，在快速消费数据来驱动改进的同时，也不能省略过程在数据治理上的投入。

小结

最后分享一些对于组织级转型的心得：

分享

收藏

在看

点赞