一、富滇银行数字化转型背景
富滇数字化转型项目称为“滇峰计划”。2022 年 1 月 16 日，富滇银行 APP 6. 0 上线，为数字化转型项目打响了第一仗。
云南交通非常不发达，村民们到县里办事需要走几十公里的山路。银行APP 对于很多大城市来说，可能只是一个软件，但是对于云南的村民们来说，它意味着少走几十里的山路，做生意也更加方便。
“滇峰计划”不仅是一个APP，它也承载了富滇银行“1234”的战略，是富滇银行的一号工程。它不只是解决发展的问题，而是解决生存的问题。富滇银行数字化转型项目助力于实现从城市到乡村空间的大转移，实现业务线上化的大转型。
富滇银行数字化转型的总体架构以中台化的方式，帮助富滇银行构建敏态的能力，驱动业务数字化增长。总体架构的落地需要组织、业务、技术三位一体的变革，才能真正实现脱胎换骨的转型。
首先，组织要变革。第一，组织企业内部，比如业务和科技部门的部门壁垒导致协作效率低。第二，外部环境的变化导致客户的需求发生变化，组织需要能够更快速地响应变化。
敏捷组织就是很好的方向，能够将多兵种的员工联合在一起，加速创新。
如果说组织是数字化转型之魂，那么业务重构便是数字化转型之本。任何转型成功的判断依据在于业务结果是否达成。如果仅靠组织的变革，没有技术平台的支撑也无法实现加速。因此，富滇银行的数字化转型项目对银行 IT 架构进行了全分布式的改造，全面构建可承接海量高并发的业务流量，使用阿里云的滇峰云底座对原有底座进行了替换。
“滇峰计划”是富滇银行和阿里云共同打造的计划。自 2022 年 1 月 16 日 APP 上线以来，取得了不错的阶段性成果，新增用户同比增长 3 倍，月活同比增长 52%，全行利息收入来源与数字化的信贷业务占比达 12%，实时授信审批每秒 18 笔。
举个例子，在数字化转型项目期间，同事拜访了某村的村支书，该村种植 6000 多亩芒果树，此前贷款利率高、额度少、到账周期长。经常出现芒果成熟后，因资金未到位，化肥、施肥跟不上，导致虫害，极大影响了收成。而“滇峰计划”大幅改善了该村的情况。
阶段性成绩的背后是一个大团队的努力，包括行方上百人、阿里几十人，协同 7 家厂商近 500 人，经过 9 个月的时间，上线了滇峰云数据中台、业务中台、新版手机APP、智慧信贷等新项目。
面对如此庞大的组织，如何一步步打造敏捷组织？
二、打造敏捷组织
银行进行数据化转型，经常会实行敏态和稳态双态共存的模式，同时支撑稳定和多变的业务需求。2020 年，富滇银行完成了 2+4+ N 的项目，该项目是构建 IT 架构稳定的基石。按照瀑布的项目管理方式运作，团队也按照项目管理的方式进行管理，目的在于稳定支撑业务发展。
敏态采用敏捷的组织迭代等敏捷的方法落地，以快速响应市场的需求。
敏态业务具备如下特点：
- 产品创新快，交付周期越来越短。
- 需求变更非常频繁。
- 依赖运营。三分建设，七分运营，需要持续的运营来优化业务效果，降低成本。
- 科技融合高。类似于金融行业的属性，要满足于业务的连续性以及监管的要求，特别强调业务和科技的融合度。
基于以上敏态的业务特点，我们认为敏态业务需要组织敏捷。敏捷的组织已经在互联网得到验证，能够快速响应外部需求的变和快，得到业务结果。
敏捷的组织阵型该如何搭建？
上图为手机银行 APP 6. 0 协作主体的示意图，涉及三个大团队。
最上层是前端产品组，约有70-80人，主要任务为业务、开发和测试。中间层为业务中台组，是全新构建的中台，包含十多个中心，比如账户中心、用户中心、支付中心等，业务中台包括业务、开发、测试等角色共200人左右。第三层为稳态的后台组。
前端产品组包含三个角色。在 3 个角色中存在着明显的两个壁垒，称为部门墙，导致团队协作一个月之后依然互不认识，且任务驱动，协作效率非常低。
任务驱动的概念为，比如 a 和 b 共同执行某个需求，原本两人可以直接讨论需求落地的细节、技术方案等，但实际执行并非如此，而是 a 将问题告诉自己的领导， b 也将问题告诉自己的领导，两个领导讨论完后，给出方案。a 的领导给 a 下发任务，b 的领导也给 b 下发任务。过程中沟通效率极低，因此我们必须将这两堵墙拆除。
拆墙的背后会涉及到很多问题。比如 a 的领导持支持态度，因为他曾在其他项目中实践过敏捷组织，他认为只要将敏捷小团队建立好，很多事务性的管理工作便可以由 PO 和 SM 带着团队完成，可以大幅释放管理者的事务性工作。但 b 的领导并不支持，他认为将自己团队的同学分拆到几个敏捷小队后，有些公共性事务会难以安排。
最终 ，我们按照产品特性拆分为公共基础类、转账类以及理财类三个纵向小团队，每个小团队里面有如下几个角色：
- PO：对产品特性负责，比如决策产品需求的优先级、产品的解决方案。
- SM：推动敏捷小队按照迭代的方式落地，过程中会存在很多阻塞的问题， SM负责推动解决该类问题。
- 交付团队：核心生产力，所有需求都靠交付团队来交付。
敏捷小队具备以下几个特征：
- 跨职能的业务开发、测试融合的组织，共同服务于某产品。
- PO和SM共同带领团队，按照迭代的框架，逐步达到自组织的状态，使得职能 TR 管理的事务性工作大幅减少。
- 坐一起，稳定且沟通实现更高效。
- 理性和感性结合，做事的时候坚持理性，而团队建设是感性的。当出现理性解决不了的事情时，可以靠感性的情感补位。
敏捷小队运作一段时间以后，在团队内部闭环解决了很多问题，但新的问题也随之出现，即跨团队的问题。
比如端设计得很好，但在中台的业务组不可落地，尤其是涉及到稳态后台改造则更难落地。端和中台的需求没有有效拉通，双方之间节奏不对齐，会导致需求变形，大量的需求返工业务也无法从全链路的视角进行验收。
那么，如何解决这一堵墙？
这涉及到两个大部门之间的协作，我们的解决方案是邀请数字化转型项目的负责人参与进来，在银行的整条业务线上落地了上图组织。组织分为两层，最上层是业务的决策组，由各个角色的 1 号位组成，关键职责包括：
- 确定业务范围。
- 设计技术、工程等架构。
- 关键事项的决策，包括推进阻塞的问题。
下方为业务分析交付组。其职责为按业务方向组建跨职能和跨功能的团队，负责业务需求的分析以及交互。团队里不仅有端的业务分析人员，也有中台的业务分析人员，不仅有端的开发、测试代表，也有中台的开发、测试代表。只有这样，才能站在业务的角度实现闭环的组织。
该团队专注于业务需求交付的全局效率。因为它最终要交付业务需求，不仅与端以及中台相关，甚至还会与数据中台、稳态相关。因此，对于业务需求交付有影响的任何一方出现问题，都需由团队统一解决。
业务驱动的组织在企业银行落地以后，得到了几个明显的收益。业务需求的交付周期大幅缩短。需求的变更和返工大幅降低了。数字化转型的项目也按照该方式进行了组织的变革，成立以业务目标为导向、三横六纵（6条业务线）的业务产品组织。
组织包括业务岗、产品设计岗、研发岗、测试岗以及运营岗。每条业务产品组织有三位核心成员，分别是业务 1 号位、技术 1 号位和PM。技术的 1 号位不仅关注端和中台的技术问题，还需要关注业务需求。PM 也必须纵观全局，推动解决所有的组织问题。
敏捷的组织文化如何养成？
富滇银行敏捷文化的养成分为有三个核心步骤。
首先，文化标语，自上而下地将项目组的敏捷文化确定下来，共确定论语 16 条，敏捷标语 26 条，标语全部上墙，办公楼每个人可以触手可及，人人可见。
其次，文化渲染。敏捷咨询师基于理念、方法相关的课程，为员工进行大范围的宣导培训工作，并且在项目中进行文化渲染。如果发现合适的企业内部的敏捷教练，也会加以培养。
最后，工作习惯。带来一些新的词汇，比如工作坊、Showcase、以终为始、站会、拉通、对齐、尽早反馈、短平快沟通、复盘等。经历过数字化转型项目以后，上述词汇对于富滇银行的同事来说，从无到有、从有到变为了工作习惯。
为了实现创新创业的氛围，富滇银行数字化转型项目独立于富滇银行，另租了办公楼，采用开放的空间，提供了很多白板。然而，办公楼的10 多块白板一直无人使用。在项目推进的过程中，我们鼓励团队多用白板，因为白板能够带来极高的工作效率，而且容易让人聚焦，得到启发。
我们教会团队学会使用白板来复盘，项目组的成员一起讨论过程中的问题以及值得保留的优秀的做法；学会通过白板进行业务需求、流程和规则的讨论，将来自不同厂商背景的同事的思想和经验整合成共识；用户故事地图可以清晰地展示每一次迭代的内容。有了白板以后，任何地方都可以开会，不必再局限于会议室。
工作坊类似于头脑风暴。此前，银行的需求评审会非常重要，每次与会人员几十人，但真正给建议的不超过 3 位，且大多以领导为主，业务负责人和其他员工常为“到此一游”的状态。
需求评审会的核心在于解决两个问题：第一，需求本身的问题，比如需求里的业务流程是否有遗漏，业务规则是否满足监管要求，业务需求是否会涉及到稳态修改等；第二，需求的确认。其中需求本身的问题实际上并不需要通过大型评审会来解决，而是可以通过工作坊的形式来解决。
比如端和中台已经开始进入开发阶段，但是两者之间的需求完全没有澄清清楚。可以将大家召集在一起，通过白板的形式进行更好的可视化表达。
大型的项目都会有定期的进度汇报，汇报的主要载体多为PPT。但PPT往往经过一层一层的润色，很难真正反映出问题。因此，可能过了很久业务需求依然无法验收。
而 Showcase 可以打破业务和科技的部门壁垒，增强业务和科技同学的信任感；其次，企业银行项目的 Showcase 链路很长，但也正是因为链路长而复杂，使得我们可以在集成过程中发现链路中出现问题的环节，而不是到项目上线前的最后一个月所有问题集中爆发；同时，通过 Showcase 可及时发现需求变形，需求与分析阶段不一致的种种问题。
在第一个项目接近验收阶段时，业务老师认为无法看到业务流程的完整度，因此临时补写了业务场景的流程和验收用例。而按照以终为始的工作原则，我们可以在项目初期便对验收阶段的问题纳入考虑，比如业务老师未来会怎么验收，会按照什么样的业务场景验收，用户会按照什么样的操作步骤。
敏捷的组织如何协同？
组织的协作会按照不同的阶段来设计。
在平台建设期，主要采用迭代的方式。首先，在前端的产品组 3 个敏捷小队实践迭代模型。沉淀迭代的准入、准出标准，让项目群按照标准统一执行。项目群的迭代模型基于单团队的迭代之上，重点考虑跨团队之间的联合。比如联合的计划会、联调过程中各种阻塞的问题，均需要通过联调会推动解决。结束之后，将各个团队的关键代表一起开联合的回顾会。项目群的迭代落地需要 PMO 团队统一协同、督办踩点，解决各种冲突问题。
在平台的成熟期，主要关注业务结果，业务价值驱动的协同方法变得尤为重要。首先，将需求分为三层：
- 第一层为业务需求，最贴近于用户目标和业务目标，业务需求承载了业务价值，是业务方验收的对象。要实现业务需求，需要拆解产品或者系统上要实现的功能点。
- 第二层为产品需求层，敏捷小队需要重点关注，通过迭代的方式进行快速交付。
- 最后一层拆解技术任务。
什么是业务需求和产品需求？比如单笔转账、批量转账、预约转账都属于业务需求。以单笔转账为例，实现单笔转账需要拆解到产品需求，比如交互视觉体验的需求设计、检验账户的合法性、判断转账限额是否超限、判断转账记账的动作、判断消息如何发送。直至所有产品需求都实现，单笔转账的业务流程才能形成闭环。
定义需求的全流程。针对业务需求，从需求的提出、规划到最终的验收发布，流程该如何定义每个环节的准入准出标准？拆解了产品需求以后，如何快速排期、如何开发测试，工作流是怎么样的？
层与层之间要进行分层的协作和对齐，过程中要严格卡准入准出的条件，提升内建过程质量。
最后，针对需求的分解和分析，需要提供有效的方法帮助团队进行梳理，减少后续不必要的需求，比如返工等。
业务驱动的流程需要规范化。通过活动的定义、节奏的约定、负责人、输入输出、背后运用的方法以及工具链的支撑形成规范化，使项目群有规范可循。
如何驱动组织数字化持续改进？
前文提到的协作均由云效BizDevOps一站式工具沉淀落地。BizDevOps工具具有几个价值点：
- 它覆盖了研发周期全生命周期，是一个一站式的平台。
- 它统一了数据模型，打通了业、产、技核心的作业对象。
- 它支撑了业务需求的价值定义，业务需求传递到产品需求，有效服务于价值集体的创作。
- 数据有了沉淀，系统的效能洞察能够发现执行过程中的问题，评价每个团队的效能情况。
项目进行过程中，出现送测不及时、质量差、缺陷修复不及时等问题，QA 同学提出质量分模型，经过不断调优，最终确定与现状最贴近的模型。
质量分模型以质量标准为基础，基于云效对质量的流程遵从性和质量过程数据建模，对交付质量进行打分，涉及9个主要指标。
度量时不能只看一个指标，比如对按期送测的高要求会导致送测通过率低，我们必须综合考量一组相关联的指标。
另外，质量分只是解决某一个阶段问题的管理抓手，后续出现的问题需要通过其他手段比如效率分等方式来解决。
三、总结
富滇数字化转型项目从组织结构、敏捷协作、数据驱动改进、敏捷文化四个维度进行落地。从敏捷小队，到产品级，再到业务级，最终到企业级，持续地进行深化落实，持续地改进。真正做到以业务价值为核心，快速响应。
云效，产研数字化同行者
云效是阿里云企业级一站式研发协同平台，源于阿里巴巴多年先进的管理理念和工程实践，提供从“需求->开发->测试->发布->运维”端到端的协同服务和研发工具，支持公共云、专有云、混合云多种部署形态。连续2次获IDC产品能力第一评估，获信通院BizDevOps、DevOps平台双重认证，服务金融、制造、电商、零售、汽车、物流、互联网等行业数十万客户，上百万开发者。通过BizDevOps、持续交付等不同解决方案，助力企业实现研发敏捷和组织敏捷。
