近几年，敏捷转型成为了银行转型的标配，从起初的IT敏捷转型，到现在的战略转型为敏捷银行，敏捷在银行转型中的优先级和影响范围在持续提升与扩大。作为敏捷咨询顾问，看到这一现象既欢喜又担忧。欢喜的是越来越多的银行敢于迈出转型的一步，并且找到了相对正确的转型方向（敏捷转型）。担忧的是“敏捷”一词被炒得过热，业界标榜出太多的敏捷成功案例，导致银行开始盲目的遵循标准化的敏捷实践，敏捷转型渐渐地变成了一场形式主义运动，最终收获甚微。在银行转型落地中，我们选了较为普遍的两大维度：组织管理与创新，总结了其中的一些转型误区，同时也分享了改进建议，希望可以抛砖引玉，引发更多的讨论与思考。一. 只重视业务转型，不重视科技转型
银行转型的最终成效，体现在银行业绩（广义）的提升。因而，行内会把业绩提升作为转型中的目标，例如存款的提升、有效用户数的提升等，并建立一体化的组织架构，例如部落、事业部等，为组织下达业绩目标，组织中的全员都为业绩目标而努力。这个逻辑表面看似没有问题，但当全员承担业绩指标，重视管理能力的时候，就会忽视科技的重要性。行内科技人员倾向于走上管理岗位，去管理外包实施厂商，更多的科技产品交由外包实施厂商负责，如此以来，银行不断地失去会写代码的科技人员以及科技技术能力。随着转型的持续深入，业务开始抱怨产品研发的效率，抱怨没有完善的工具平台支撑，甚至线上生产故障频频发作。最终给出结论，业务转型快，科技转型慢，科技拖了整体转型的后腿。（现在甚至还有组织在整体转型策略上提出先管理转型再技术转型的思想…）银行科技能力的提升是整体转型的基石，科技能力提升需要长时间的持续投入。坦白地说，在银行内只要有足够的高层领导的支持，组织或业务转变都是相对迅速的，然而行内的科技能力提升，并不能短时间内做到，例如系统解耦、持续交付、工具平台的建设、研发能力的提升等，并且科技还要坚守规避技术风险及满足合规的要求，但科技能力的强弱直接影响研发速度，影响着组织对外的响应力。所以在整体转型过程中，需要重视科技转型，加大科技转型投入力度，甚至需要将科技转型提升到最高优先级，科技先于业务进行转型。银行的科技能力就像是汽车发动机的扭矩，不管车的外形多漂亮，扭矩低，就是跑不快。二. 只强调自组织，不重视充分赋能
企业在大张阔斧的划分完组织架构后，往往没有一套配合该组织架构运作的流程、方法，领导希望组织调整后的团队可以自组织运作。在团队中遇到技能短板，就强调T型人才 ，缺测试大家都是测试，缺运营大家都是运营。但是，换位思考到银行员工的角度，在转型前，大家一直以来的思想是合规合流程做好职责范围内的事情，一时之间这全都不对了，突然要切换成另外一种工作方式，其实是很难适应的。忽略这个转变难度，实际上导致的后果是：新团队成立后，团队仍然按照旧的思维惯性、旧的方式运作，有问题通过“私人关系”来解决；团队中各个角色不清晰自己的定位和个人发展，觉得自己什么事情都在做，对自己的个人成长感到迷茫；最终，导致团队运作尤其跨团队运作内耗严重。团队自组织与T型人才的前提是：团队已可以稳定运作，人员的本职工作已称职。在转型前期我们需要形成一套详细的运作标准与职责分工，来告诉新成立的团队，团队内外该如何协作，人员该如何分工，各自的职业发展通道是什么样子的。当然这个运作方式与职责分工不是预定义以标准化的，也不是一成不变的，我们需要在团队运作中持续总结出一套最适合行内的运作方法，且不断的更新。有了方法后团队内外的配合渐渐的默契，各种规则都已成为熟记于心的“潜规则”，最终形成自组织团队。团队中的人员在本职工作已做好的前提下，希望可以突破自己获得更多成长，从而尝试其它领域的专业技能，最终成为T型人才。在某银行转型落地中，我们将运作方法及角色职责形成多本手册，并按季度更新各个角色有对应的成熟度标准，牵引成长，并有明确的等级晋升通道
三. 积极建设内部工具平台，但却闭门造车
敏捷运作的实施，从需求、到代码、到运维都需要平台和工具的支撑。似乎所有内部工具平台的设计者，都怀揣着一个梦想，就是做出一套端到端的管理平台，把需求、进度、代码、BUG等等都管理起来。他们先设计总体的流程，再设计运作分类，再增加灵活性，再...最终系统3个月后上线，领导强推，团队感觉系统不好用，但由于是领导强推也没法说什么，开始形成运作两张皮，系统上记录一下，私下里用Excel等工具管理，甚至团队为了系统上的漂亮数据，开始选择性的操作系统，造成假繁荣的景象。这是极大的组织内耗。内部工具平台是服务于内部团队，辅助内部团队运作的。而过程量化数据，是为了持续驱动改进。首先需要明确内部工具平台的用户是谁。很明显，为了“梦想”的实现，我们默认了平台的用户是平台的设计者，他对于平台的设计已经有了自己的想法。但平台真正的用户是内部团队，需求和痛点都应该来源于内部团队。来自团队的需求，会有很清晰的需求优先级，平台设计者需了解真实需求痛点后再进行整体的平台规划及设计，并按照MVP的思想去交付，真正地帮助到团队。当然我们的最终目标，是希望通过内部平台拿到产品实施过程中的数据，这个数据不是考核，而是为了找到产品实施过程中的问题点，之后加以解决，从而提升产品的整体流动效率，做到量化数据驱动的持续改进，团队的效率持续提升。某银行使用Jira的配置调整就可进行产品的需求管理，以及实施进度管理。2周通过Jira的API接口做出数据量化报表体系四. 过度关注创新的业绩指标，但却忽视创新所需的土壤和空间
受到互联网公司产品的威胁，银行在转型过程中也希望可以打造出自己的创新产品甚至爆款产品。打造的方式往往是组织团队学习创新方法，例如强调以用户为中心、用户旅程等等。之后给团队一个创新任务，要求团队在半年内打造出1款创新产品，同时团队还要背负着原有的绩效KPI。接下来就是团队满是激情的去创造，结果次次汇报，次次受打击，“能对业绩产生什么提升？”，“这能体现出银行什么特点？”等等问题始终围绕在团队耳边。最终团队选择放弃自我创新，不去尝试说服领导，改成服从领导，领导想要什么，就做什么，不管好坏，最终创新成了领导的创新，团队做的都是应付领导的表面文章。创新的顶层设计决定创新的环境，是创新工作能够良性开展的大前提。创新的环境是，提供员工宽松的创新空间、允许试错的文化，形成创新自下而上的驱动，自上而下的支持。创新是一个概率学的东西，所以我们要的不是某一个团队或组织负责去做创新产品，而是发动全员提供创新点子，例如创新大赛、创新马拉松等。创新也不是短时间内就能够给银行带来真正的绩效的提升，更多的是生态布局、圈住用户，所以我们也要给创新足够的空间与支持，少干涉创新过程，不要在前期过度的强调利润，多鼓励创新，多支持创新。现在在银行中常见的做法是成立内部创新孵化器，通过全员举手收集点子，然后评选选出高潜点子，通过内部的独立孵化给与资源支持，孵化点子，当然过程中会有按照季度的退出机制，发现行不通就立刻转向或退出，快速试错。
创新孵化的运作示意
总结
现在越来越多的银行迈出了敏捷转型的第一步，但银行转型的顶层设计难，落地更难。在最重要的两个维度“组织管理和创新”方面，我们观察到以上的一些误区，我们的观点是：
- 银行科技能力的提升是整体转型的基石，科技能力提升需要长时间的持续投入，不可忽略科技转型；
- 团队自组织与T型人才的前提是：团队已可以稳定运作（有明确的运作方式），成员的本职工作已称职。转型过程中需要充分的引导与赋能，使得转型可以平滑过渡；
- 统一的内部工具平台是必要的，但不能闭门造车，平台的核心用户是内部团队，价值在于辅助内部团队的运作，平台的设计和建设需要以这些内部团队的需求为中心，进行迭代式的产品交付与验证；
- 创新需要以业务为导向，更需要有适合创新的土壤与环境——更宽松的创新空间、允许试错的文化，自下而上的驱动，自上而下的支持。
最后，我们作为银行转型落地的一员，希望可以有更多的同业沟通与讨论，大家共同为国内银行的转型尽自己的一份力量。
- 相关阅读 -
银行IT的敏捷转身
银行移动产品从团队敏捷走向产品敏捷
点击【阅读原文】可至洞见网站查看原文&绿色字体部分的相关链接。
本文版权属ThoughtWorks公司所有，如需转载请在后台留言联系。