科技银行、智能银行、敏捷银行……近年来，「数字化转型」日益成为国内银行的战略方向。与国有行、股份行相比，城商行科技积累偏弱、人才资源相对不足，转型时遇到的阻力往往更大。破除障碍、快速成功的关键不在于照搬别家经验，而是因地制宜采用适合自己的方式，组织治理、流程体系、管理制度、软件工具、实地教辅、人员培养……多管齐下，在短时间内以最高效率进行转型。凝聚力来自于打胜仗，转型成功的信心来自于每个月在产能、交付速度、管理效率等方面的量化进步。
一、直面金融科技化的真实挑战
然而，移动互联网等技术在银行业的深入应用，也为股份行、互联网银行快速切入这些城市打开了方便之门。业务模式相对传统、科技实力不足，成为城商行在这场竞争中的短板。
通常情况下，城商行的科技建设以利用外部伙伴为主，行方人员和外部伙伴的比例高达 1:10 。虽然人力资源与股份行存在很大差距，但麻雀虽小五脏俱全，城商行的系统数量并不比股份行少。
针对上述痛点，行方从几方面采取措施：转型落地由董事长亲自关注；从某大行引入了一只能力过硬、经验丰富的科技高管团队，着力扩充行方科技人才；优化制度流程，找到我们深入参与辅导，并采取「管理经验+工具支撑」配合的快速导入方式，这些举措为科技敏捷成功落地奠定了坚实基础。
二、建立匹配业务的科技部落
科技敏捷第一步，从建立匹配业务的科技组织架构开始。
该行科技条线之前包括两个部门：IT规划部 和 科技中心。业务部门提需求给IT规划部，规划部将任务派发给科技中心完成。科技中心内部行员人数较少，往往一人负责多个系统，但业务需求普遍要跨系统协作，这造成了大量的任务交叉和拥堵。
久而久之，在业务部门看来，行员+外部伙伴已经将近 1000 人，需求却总是做得很慢。而科技同事面对的情况是，每个需求到自己手里时都十万火急，工作堆积成山，不断加班加点也很难做完。
针对上述问题，我们先建立了虚拟部落机制，这里有两个关键词：
- 「部落」。部落制是一种柔性网状的敏捷组织结构，是一个偏向于交付的矩阵型组织，包含 小队-部落-分会-行会 四种组织单元。日常管理在小队和部落，人员培养和绩效管理在分会和行会。
- 「虚拟」。之所以称为虚拟机制，是因为原有的 IT 规划部、科技中心等职能部门依然存在，它们对应部落制中的分会/行会。主要成员被分配进入部落，部落是在原有实体部门之上的虚拟组织。
建立部落制后，每个业务部门都有唯一对接的需求受理部落，负责方清晰，沟通线路变短，优先级排序流程简化，大幅缩短了过往占比最高的需求澄清时效。由于交付能力提升，业务价值可以更快验证，加强了科技团队的归属感和责任感。业务和科技之间的协作，开始变得高效顺畅。
如果把部落比作一支球队，里面包括前锋、中锋、后卫、守门员等各种角色，部落长通过合理配置准备每一场比赛。横向的职能部门就像技能教练，聚焦于培养人员的专业技能。「纵向的小队/部落」和「横向的分会/行会」，几方紧密协作，既要实现踢赢球的短期目标，也要兼顾长期的能力建设。
三、精心设计，1000 人划入六大部落
把行里千名科技人员分进部落，是个非常挑战的过程。划分时主要考虑以下两点：
- 该成员主要负责哪个系统
- 该系统主要支持哪个业务领域
注意「主要」这个词。由于很多行员同时负责不同业务领域的系统，而不少系统同时支持多个业务领域，这些历史问题不可能在短期内解决，需要采用逐步过渡的方式。
在划分部落时，有一条原则不能妥协：人员一定要专属，不可以跨部落，这样量化机制才可以顺畅运转。针对前面提到的过渡状态，部落间要逐步进行系统剥离，长期目标是 85% 的业务需求可以由其对应部落独自完成。
在过渡期间，需求在部落间拆分系统任务，部落要持续追踪任务拆分情况，不能因为短期有困难，就放任人员跨部落兼职，为后续的深入管理制造障碍。
合理的部落规模在 50-100 人之间，具体如何划分，由人数、系统、业务属性和关联关系等实际情况而定。比如，该行有近 300 个系统，系统之间存在众多复杂的依赖关系。我们根据条线和业务属性，划分出了六个部落：零售、互金、资管、公司、数据中台以及业务中台部落，每个业务部门都有对应的部落，负责衔接需求的输入和输出。
每个部落再划分成若干个小队，每个小队约 10 人规模。小队为跨职能团队（包括产品、开发、测试），能完成独立的需求交付，响应需求的变化。
小队可能负责一小块业务，比如「信用卡产品小队」；也可能负责几个系统，如「前端小队」或「后端小队」。前一种为「业务小队」，后一种为「系统小队」。业务小队是更理想的状态，但系统小队也是可以接受的。
在部落制运行初期，可能存在角色对自己的职责认知不清、职能与部落双头汇报、人员调动与补充时而混乱的状况。对此，我们量身定制了部落运行手册，包括部落日常事务管理、排期和回顾指南、各角色职责划分、部落与职能部门差别描述等内容，帮助人们了解细节，逐步理顺关系，完成转变。
四、建成端到端的需求管理体系
部落制开始运行后，我们明确了需求拆分体系，以加强对需求的计划和管理，提升针对变化的响应速度。我们采用「业务需求-系统任务-个人任务」三层需求体系，系统任务拆到 10 人天以内（单系统、可测试），个人任务拆到 1 人天左右。需求明确主办部落，系统任务明确主办部落和主办小队。
针对业务需求，从过往的全量承诺转为价值优选。在需求澄清过程中，相关同学与业务部门对齐需求的业务类别，分别为：P1（战略安监）、P2（业绩考核）、 P3（创新优化）、P4（其他）。
有了需求优选和粗略估计机制后，我们使用知微工具来透明规划容量信息，了解部落和小队的载荷情况，避免过载或空载。在每月中准备下个月的部落排期会，根据需求优先级与部落可用容量来制定排期计划。
除此之外，我们还为需求体系定义了明确状态，以及每个状态的完成标准。这样可以在团队间快速统一术语，达成共识，极大地降低沟通成本。
需求管理体系的另一个重要组成，是对相关指标的统计和分析。其中最重要的，是需求各阶段的时效数据，如澄清、排期、研发、交付时效等。通过分析各阶段的耗时分布，获知哪个阶段应该优先改进，分析问题成因，制定优化手段，跟进优化效果。
如上面的需求时效趋势图，可以看出超过50%的时长花在了需求澄清与排期阶段，研发并不是真正的瓶颈。
五、在小队级导入关键敏捷实践
配合部落制运行，我们导入了每日站会、迭代、代码评审等敏捷实践。
迭代计划会的重点在于会前准备。因为是全小队参会，过滤掉无关事项，让会议保持聚焦非常重要。小队长通过知微工具过滤出数据，了解小队当前迭代的可用容量和系统任务的优先级，选出下个迭代将投入研发的系统任务，提前与开发人员澄清并拆分好个人任务，选择好系统任务上的开发迭代字段，方便日后跟进。
会中，所有人员对齐迭代的系统任务，每个系统任务的计划开始与完成时间，以及 SIT 环境的提测时间。在制品（WIP）不能过高，有任何风险要提前暴露。通常迭代里排进小队容量的 80% ，留一定容量用作沟通。
在迭代过程中，每天用站会和知微看板来透明需求进度。所有成员在站会前更新好个人任务和系统任务进展，开会时围成环形站立，时间控制在 15 分钟以内。
在迭代末期，小队组织迭代回顾会。队长提前准备好度量数据，比如需求和系统任务研发时效、吞吐量、需求进度、受阻情况、缺陷情况、上个迭代的改进项完成情况等等。回顾会也是全员参加，在一小时内过一遍数据，展示当前迭代完成的需求。大家根据情况总结经验，形成改进项和优化方案，并产生具体行动项和相关跟进负责人。
回顾会是团队自我检视、提升协作的好时机，最好买些零食或者设计一些小游戏，营造轻松快乐的回顾环境。
六、「管理驾驶舱」为机制落地保驾护航
通过划分部落制、形成需求体系、导入站会和迭代等基层敏捷实践，该行初步建立了端到端敏捷交付流程。但是，机制建成不是最终目的，要寻找合适方式维护机制的运行和不断优化，确保组织逐渐从「不够敏捷」变成「足够敏捷」。这里有两个关键：
- 对整个机制进行建模，让每个组织成员都能看到机制如何运作，以及与自己有关的信息。
- 通过知微工具建立管理驾驶舱，让管理者实时了解机制运行情况，及时纠偏。
在银行数字化转型的过程中，知微是管理机制落地的「守护者」。从部落制建成伊始，通过知微对实际工作进行价值流梳理和建模，加上不同角度的可视化视图，为组织构造了数字化管理现场，帮助管理者获悉不同视角和维度的信息，从而实现双眼紧盯，进而把双手放开。下面列举几个「管理驾驶舱」功能：
业务需求看板
对需求进行精细化管理，可以直观看到每个需求的状态，是否受阻、子任务完成情况等等。
部落人力结构视图
查看行员与外部伙伴配比，分析各职能的人员配置是否合理，及时进行资源调配。
需求跨部落情况分布视图
重要的「方向盘」功能，查看本部落主办的需求分跨哪些部落，各相关系统任务的进展情况，「黄/蓝/绿」三色分别代表「待办/进行中/已完成」。
通过观察这些信息，管理者能快速获悉整体状况，了解完成进度，优先解决受阻碍项，这也是可视化的价值体现：
- 个人在一定时间、一定范围内获得的信息有限，可视化要尽量把每个信息的价值，都以一种合适的形式展示出来。
- 通过用多种的、合适的形式加工信息，帮助管理者快速抓到重点。
分管行领导分布视图
- 行领导「需求部落分布视图」，用于查看各分管行领导的需求分布情况。
- 行领导「需求状态分布视图」，用于查看各分管行领导关注的需求状态，可以按业务优先级过滤，也可以点击进度条查看明细，信息具体到部落、小队、负责人、工作估算、状态、受阻情况等。
月度规划视图统计
能看到研发人力投入在哪些需求中、需求当前完成情况等。可以通过主办部落过滤各个部落每月规划的需求，并随着业务优先级变化及时调整研发投入。
月中会开始准备下个月投入研发的需求，在与业务和关联系 统对齐后，相关信息会同步到知微中。
该行在敏捷转型半年后，效果逐渐浮现：
- 业务需求有明确的 P1-P4 优先级，通过排期会，每个业务需求都能指定到小队级的主办负责人。
- 建立「业务-部落-小队」端到端需求交付流程，明显改善成员身兼多职的情况，插队的需求越来越少。
- 从 excel 文档管理转至知微工具精细化管理，实时获取产量、时效等数据，并通过数据观察趋势持续向好。
下图为截至去年 12 月，在没有调整需求大小的情况下，该行科技产量（需求完成个数）以 15% 左右的幅度逐月递增。
从时效上看，这 4 个月业务需求上线速度出现了明显优化，交付时长减少了20%（交付速度提升了20%）。
以上，我们总结了城商行科技敏捷导入的四个重要举措：
- 运行虚拟部落制，扭转过于刚性的管理机制，形成敏捷银行所需的网状柔性治理体系。
- 建立端到端价值交付管理体系，打造高效的设计、决策、执行、反馈闭环，在迭代中不断优化。
- 从低到高导入关键敏捷实践，管理和工程能力提升并重。
- 使用数字化管理工具，打造量化统计能力，建立制度流程落地的持续守护机制。
下一步，我们将深化推动科技敏捷，比如导入版本规划机制，形成合理的发版节奏和维护方式，持续优化产能、速度、质量并用数据量化展示。同时，建立产品管理流程和能力，形成业务创新管理体系，引入 OKR 等敏捷绩效守护手段，打造全面拥抱数字化时代的敏捷银行。
本文是 Agilean 咨询团队帮助某城商行科技敏捷转型的案例分享，介绍如何以建设「柔性网状治理体系」为抓手，在半年内促成业务和技术紧密融合，取得了令人满意的落地效果。
作者简介：周麟，Agilean 高级顾问，专注于金融组织敏捷，为企业量身定制敏捷交付流程与管理体系，促进业务和科技协同交付价值，已为深圳农商行、长沙银行等多家银行交付敏捷部落制、研发过程管理的成功案例。
版权声明及安全提醒：本文转自网络平台Agilean，文章仅代表作者观点，不代表「金融文库」立场。相关版权归原作者所有，「金融文库」仅提供免费交流与学习，相关内容与材料请勿用于商业。我们感谢每一位原创作者的辛苦付出与创作，如本转载内容涉及版权及侵权问题，请及时联系我们客服处理（微信号：JRwenku8），谢谢！
