业技融合 - 大型银行的敏捷转型之路

白凡

分享：邓骏
编辑：白凡

大家下午好，我的表演时间到了，首先欢迎各位来到我们今天下午DevOps金融专场，金融是一个特殊的行业，我们做DevOps的实施和改进其实有很多的特点，那大家展位上走过来，大家会发现这一条路是比较曲折的，那我们金融行业的DevOps实施也要走一段曲折的路。我还留意到今天大会组织方在选择金融专场的讲座，几位讲师的主题其实也是蛮花心思的。我看到讲师的主题有包括来自银行的分享，也有证券的，有国内的银行，也有跨国的银行，有大型的银行，也有中小型的机构，也有谈DevOps的实施，也有谈精益和敏捷的转型，我相信今天下午的分享会会是一个很有意思的一个分享，希望大家能有共鸣，能促发更多的这种思考，我们下来有更多的讨论。

我自我介绍一下，我名字是邓骏，我来自汇丰银行，我是汇丰银行的敏捷教练。我今天分享的主题是“业绩融合-大型银行的敏捷转型之路”。简单讲就是讲我们在敏捷转型的过程中怎么将业务部门和我们科技部门更好地融合在一起，我为什么讲这一个主题呢，因为这是我们转型中遇到的比较大的难点。

1. 难点与根源

在过去的时间里。相对来讲我们做敏捷转型的时候，我相信很多的行业碰到这样的问题，通常科技部门走在变革的前沿，业务部门很多的时候都是入局慢，有很多原因，而且咱们参与度也不够。我们看端到端的价值流效率的时候，因为业务方参与不充分而导致端到端的效率其实是低下的，就是IT做得更好太快了，其实这和我们用户的期望值还是有差距，因为端到端的效率太低了。

说到敏捷，大家第一反应是猎豹，我相信敏捷的组织天生有这种柔性，有这种灵活性，能够容易应对改变，在这一个错综复杂的商业环境中有更高的响应度和更高的效益。对于我们银行业来说有时候我们自己自嘲我们是大象，虽然我们很努力地奔走，但是步履还是艰难，因为很多原因。特别是传统大型的银行，有很多问题，比如说体系、题量问题、文化问题，都会造成我们在敏捷这一条路步伐沉重，当然我们也一直探索怎样的路更适合我们，我们相信我们未来会插上理想的翅膀走得更快。

关于难点的话，过往大会同仁已经有很多总结，我在这里总结我们部门碰到的一些棘手问题，我们需要解决的问题。
首先是大家面对变化的心态的问题是什么，我们银行历史悠久，我们看有两个石头的狮子，我们都叫狮子行，有石狮子在门口，有150年了，同事们的仪式里面会觉得150年的银行什么都经历过，我世界大战都经历过，金融危机也经历过，为什么我要变，大家对变革还是有一定的保留态度。

另外一点大家知道我们金融业重监管的行业，所以这里我们不得要重视稳定性和安全的问题，IT在以前的架构里面IT是我们的中心这也是影响我们做变革的一个驱动力的问题。第四点也是我今天想讲的重点，就是业务部门认为你们做敏捷，做DevOps是你们的事，跟我们业务有什么关系，对不对。这会造成他们参与到整个转型的积极性不高，也无法更好融入转型里面去。

我们分析一下形态，为什么他们会不愿意参与转型呢，我从业务的高层到底层，大家看一下。高层通常都是什么，因为高层通常都是给我们科技部门的高层去忽悠的，我们一起搞DevOps，搞敏捷的转型吧。他们说好啊，但是他们心里有疑虑，到底这一个给我们带来什么呢，所以表现出来就是说好吧，你们干吧，我全力支持，仅仅是口头支持，落不到实处。对于中层来说是两头为难，中层老板叫我们搞敏捷，搞点DevOps。我还是照顾业务的业绩，下面的同事也会说这种变化对我们现有的东西带来一些冲击，所以两头为难。

对于下面的同事来说，我平时业务很忙了，还要配合科技部门做调整和转型就是火上浇油。通常我碰到一些情况是什么，在转型初期的，我到业务部门去说，经理跑过来说我们部门已经90%敏捷了，那边的哪位过来说，我们没有那么乐观，我们75%敏捷。我说你们很厉害，做业务就是不一样，这一个度量很厉害的，我说你们怎么做到，好吧，90%的人怎么说，他说我们早上90%人都站15分钟，我们一分钟不多，一分钟不烧了，我们已经很敏捷了。那75%怎么来的，他说我们项目75%用了这一个这个工具了，我们已经很敏捷了。我很无奈，我说你们这是伪敏捷的。为什么他们有这样的心态，就是为了上头有一个交代，这个事我完了，我做到敏捷了，你们不要烦我了。其实他们没有真正参与变革中，业务部门没有从变革收获到收益。

我们看一下为什么他会有这种表征呢。我们也做一些分析，有几个方面。
第一是方面关于转型，从上而下的目标不一致。那到底要做什么，转成什么样子大家不清楚。另外还有一点，就是组织架构没有条件，科技部门和业务部门这个部门强还是在那里，其实是一个大阻碍。你大象你要跳舞，你不做怎么能跳舞呢，对不对。
另外一点，担心既有利益的损失，因为转型的过程中会有一些角色会丢失的。比如说我们项目经理在角色架构中不是项目经理，他们会担忧我心里怕，对不对。我干了一辈子这一个东西，你让我尝试做其他东西我心里怕，所以人心里有抵触。另外一点是很重要的一点，就是说业务部门不相信科技部门，为什么？因为他不知道科技部门做什么，他不知道这里面发生了什么事情，究其原因是信息不透明的问题了。

2. 思路与方法

我们说看到有很多的问题，我们在我们的这一个变革过程中会有哪些新思路呢，我们用什么方法应对呢
我作一点分享。首先刚才提到从业务的高层到低层其实心态上存在问题，我们就有针对性采取措施，首先高层的知识是转型的关键的因素，所以我们是通过作业辅导，力争他们的支持。对于中层我们要发挥他们承上启下的功能。对于底层来说，更多是做好相应组织架构的调整，去理顺，让大家知道新的转型结构中职业发展是什么，你们的角色是什么，消除大家的疑虑。

我们证券服务部从2016年开始正式去做DevOps，做敏捷也走了两年多，我们一直在摸索，有什么办法可以更系统地解决我们转型中碰到的问题，特别是业务方参与不充分的问题，我们希望结构化系统的方法来应对这一些困难。
我这里有一个图，就是大概介绍。

第一，就是高层支持，虽然说很多的变革我们敏捷也好，很多事情我们都是从下而上去推，但是从上而下的这一个高层的支持我们认为非常非常重要的关键，在这一个顶端我们整个从业部门也好，科技部门也好，大家去认可，去遵循共同的价值观。还有对我们的目标，我们到底要做成什么样子，中间的部门是组织架构做到一次比较大的调整。还有对应支持的生态环境是怎么改善和培养起来的，去支持这一种架构的调整。往下就是这样，虽然说我们不强调标准化，但是希望部门可以有一个参考运行的模型，就是帮助团队了解从敏捷转型怎么做。

再往下有工作的工具，还有相应的培训作为整个转型的支撑。整个的过程我们鼓励团队不停地尝试，做一些试验。相对来说，回来之后呢，我们通过一些回顾，通过我们的度量体系给一些回馈，我们寻找进一步改进的空间是哪里，这是我们做敏捷转型的方法和方案。通过这一些东西去进一步引导改善吸引更多的业务方参与专性的过程中来。
我一点一点给大家说，从头开始讲。

业务高层怎么做，很多企业都碰到这个问题，很多时候高层是口头的支持，怎么让他落到实处去做呢，对转型做支持呢，我们部门的办法是这样的，我们是走出去，请进来。怎么说走出去呢，因为我们公司是跨国企业，我们总公司在英国伦敦，我们从前年开始就组织了业务高层到一些转型过程中比较成功的企业里面。比如说前年去了荷兰国际，荷兰国际集团大家都知道了，他们是业界做转型成功的公司，我们高层去现场看了，到底这个事情怎么做，做完对我们带来什么价值是什么；请进来是什么，因为我们总部是在伦敦的金融城，周围很多的跨国金融机构，我们请一些银行的DevOps的大牛过来给我们业务高层分享，通过这一些实实在在的案例来使到他们真正看到我们做这一个事情的价值在哪里，从而让他们去做支持。另外对高层我们有敏捷教练和一对一的辅导，帮助他做做策略，这是我们做的工作。

另外一点，就是说业务部门也好，我们科技部门也好，其实我们都很希望有一个共同认可的价值观，大家认为我们讲价值观是很虚的一个东西，其实不是这样想的，特别是大型的企业里面，大家价值观不一样，大家秤不一样的话，大家想的不一样，真的很难做，做乱的，对不对。我们这一个价值观是这样，如果大家熟悉敏捷宣言就熟悉了，写法差不多，右边的东西很重要，左边的是我们更看中的。我解释一下，第一点就是我们追求敏捷精神的核心，我们快速交付，快速回馈和快速去学习、尝试，快速去实现我们的价值，而不是我们去跟随一些所谓的教科书的做法。

下面一点，我们最终是有价值的结构而不是产出，这一点我们花很多的时间做改变，为什么？因为在原来我们的团队里面，各个团队的经理层更多是关注我这个团队的资源利用，就是证明我们的人员都在干活，我们最终东西凑不成我们用户想要有价值的东西，所以我们做了很多的培训和辅导，就是怎么转变观念。
另外一点就是实践多与形式主义，回到刚才的笑话，我们在这里站了15分钟，我们用敏捷的，这是形式主义，在我们部门里面杜绝的一种东西。另外一点就是我们拥抱多样化而不是标准化，这一点在我们转型的初期，我去业务部门经常问，你告诉我最佳时间是什么，标准流程是什么，我说很遗憾，这一个事情没有最佳实践，为什么？因为敏捷只是讲一些原则和精神，至于实践的话，你要结合你自己的团队和项目实际情况调整，没有一个标准是标准的。所以我们花了很多的时间去给同事去，包括业务部门也好，IT部门做洗脑。最后一点，这里大家熟悉了，我就不讲了。这一个价值观只要有机会，我们会在所有开会、培训和工作坊里面讲，希望大家把这个称摆平，大家用共同的价值观去面对，什么是对的，什么是这一个企业倡导的。

目标对齐。目标对齐这一点，我加一个小小的故事，可能有的朋友听过了。就是上个世纪六十年代苏联和美国竞争的时候，当时做登月的计划，有一天肯尼迪总统去了美国宇航局，看到一个清洁工说你在忙什么，清洁工叫杰克，你在忙什么啊，清洁工一边拖地一边说，总统啊，我正在帮怎么把我们的人送上月球，一个清洁工说的话。我觉得这个例子我们团队里不同地去讲，一个凝聚力很强的企业怎么把这一个目标做到极致。

这一点的话，就是我们首先有点改变，就是去年开始，我们个人的绩效评估，我们经理层做了一次调整，去年开始我们个人的绩效评估是有一定的比例，是要把团队的成效作为个人绩效评估的一部分，这样尽量杜绝个人主义，大家关注端到端的交付，通过这个东西促使我们团队和同事去关注团队的成效。
还有组织架构的调整，这是我们部门一个表达变化，就是什么呢，通常一个大的平台，通常都是比较大的，我们需要很多同事参与，我们通常组建很多跨专业团队，在我们这里叫POD。

通常一个应用平台们需要几个POD支持的。那么在每个POD里面我们组成就是将我们原来业务部门的加入进去，他们更多承担业务分析，就是我们叫特性的负责人。因为POD是负责应用平台的某些特性，或者特性企业，所以我们叫特性的负责人，一次同时还有我们IT团队的同事，你可以看到通过组织的调整，我们业务部门的同事顺其自然在我们的团队里面作为团队的一部分。另外业务部门的产品管理，我们变革管理和业务的运营也是很紧密地去跟我们交付的团队在一起的。通过这个调整后使得业务方的参与顺理成章了。

然后我还多加一点分享，就是什么呢，就是讲生态，生态系统，这也是我们今年在部门里面转型的一个重的工作重点，就是每一个跨专业团队，相对来讲他只能交付一小部分的功能，而且交付过程中是有依赖性的，很难做的没有依赖性。比如说一个应用平台，他几个POD团队一起工作的时候，我们做了一些相应的对齐，让他们定期在一起解决依赖性的问题，去分享实践的问题，包括工程的实践和流程实践的经验，互相形成支柱。另外我们有产品线的级别，甚至业务线级别都会有考虑怎么完善这个机制，包括架构，包括基础设施的支持，包括产品服务的管理，包括我们风控，还有考虑到如何配合我们做人事的招聘和培训，包括财务的计划，使得我们POD团队交付的时候有足够的支持，而不是说我一个POD团队十个人可以做完所有的事情，你必须依赖整体的生态环境，去支持你实现更好的交付，的确生态系统是我们今年工作的一个重点。

还有敏捷运营的模式。我们总结了两年了发现了模式，还是回到一句话，这不是标准，没有标准化在我们部门，这是一个参考，让他们落地的时候有一个指引。
首先需求从这一边过来，有很多需求的类型，比如说客户的变更，合规的要求，审计的要求，很多产品有自身产品的策略，进来之后我们由单一的有需求列表，之前是很乱，我们能做到透明的，让所有人能看到的一个列表。再下来是业务部门有产品管理的团队，他对齐产品管理的策略，那些功能和市场吻合，有一个优先级的排序。
然后是产品负责人做更详细的优先级排序，但是这里你可以看到我们还加了一点内容，就是产品决策团，这是什么东西呢，这是我们部门自由的一种做法，是什么呢，我们碰到一个问题，教科书说我们需要PO做决策，排优先级。但是我们发现我们需求来自不同的业务线，需求很复杂，我们很难找到业务领域的专家做这一个PO的决策。所以我们采取折中的方法，我们调去不同的产品线，他们的SME业务专家组成一个决策团。他们定期频密地跟根据大家达成公司的标准去做这一个排序的决策。我们很多团队已经做了，因为这一个PO不好选的问题，很实在。通过这一点，我们相信假以时日之后，我们有经验的积累之后我们的PO能成熟起来做排序。还有我们有特性的团队支持，他们负责交付某一些特性级。这一些团队我们有业务团队的同事，大家作为一个同一个团队去共同努力。大家看到图中业务部门和科技部门通过这一个模式很好地融合，有的部门墙就通过这种方式很好地消除掉了。

还有刚才提到一点，就是信用的问题，信息的问题，就是因为信息不透明的问题，互相不知道做什么。我都不知道你做什么怎么信你，不信你怎么合作，对不对。和很多的企业一样，我们也是推进这一种协同的平台，让大家有更好的分享渠道。另外是办公环境，我们是2016年开始重新做了办公室的装修，把所有的这一些办公室的隔板去掉了，去掉造成沟通不畅的因素，另外我们增加白板，我们的大电视，也是方便分享。因为我们调整组织架构，我们业务部门要和IT部门一起工作，我们把两方的同事放在一起。另外一点是我们公司特别困难的地方，我们是跨国企业，意味着我们是跨国团队，就我们叫披萨，意思是说一个团队十个人，我中午定两个披萨就可以吃饱了。但是这么小的团队，可能有产品的管理OP是来自英国的，我们业务分析来自香港，我们开发是中国，我们测试是印度的，可能每家有技术支持，所以一个团队十个人可以有时差的问题，如何解决呢？首先从设备角度讲，我们视频沟通是每个同时的标配，另外我们用一些工具做离线的沟通，另外我们远程交流互动怎么做得更好，我们做电子化的物理板，比如说伦敦两个工作方讨论的时候，可以在另一块板，我们这一边做一些讨论，另外一块板可以做同步的。我们也通过好设备方式去解决这一种跨地域的问题，去增加透明图。

还有培训，业务部门进来作为一个PO角色，或者是业务分析的角色，他们的技能提升也很必要，保证他们融入到这一个过程中。还有就是实践者社区COP，很多业务分析员来自业务部门，我们组织案例分析，拿一些案例分析去引导他们，去给他们分享，比如说用户故事怎么猜，用户故事怎么写，用户故事怎么组织，用户地图怎么应用，通过这一些让他们技能提升，让他们更好融入敏捷的环境里去。

度量体系这里也有相应的定义了。做这一点我们有一个好处，有一些东西你要说服业务部门的参与。你必须有一个反馈给他，我做了这个东西了之后，我的收益是什么东西，比如说业务的价值，我们通过交付价值，我们可以看到我们的团队，他交付的业务价值是不是有提升的趋势。还有能不能解决延迟成本的问题，通过数据说话让业务方详细改革能给这一个业务带来一些收益的。

另外我们推敏捷度画布，就是同三大维，人、实践、产品三个维度，让我们团队知道我们现在处于什么地方，下一步是什么，哪些地方可以改进，这一个东西我们去推，让他们自评。这里提一点，我们部门是严禁在部门之间拿这一个结果作比较的。因为这一个东西比较的时候有一种不好的攀比在这里，会扭曲我们设计的初衷了。

我们讲敏捷很多的时候没有一成不变的方法跟进，很多时间靠我们去尝试、摸索、谈探讨，到底什么是适合我们，我们部门叫DnA实验，这个DnA是什么意思，D就是DevOps，我们讲DevOps就是希望持续改进的思维和意识植入我们的血脉中，植入到每个同事的基因里去，让大家有勇气做试验。我待会儿会讲部门的案例，就是怎么做试验，获取一些好的收益。

第一个例子我们建立一个跨专业的特性团队，大概两年前我们有这个团队，是我们第一个成立的团队，它是一个前端的系统。这是一个前端的系统。他从架构层面上是后端的系统有很强的特性。另外业务部门和IT部门之间是各自为政的，就是互相不管对方，有很强的这一种互相不负责任的现象存在，造成的结果是什么，我们一个很小、很小的系统改变，我们都需要一个季度来交付出去，在这一个团队里面，在两年前，这是非常麻烦的事情。那我们在这里做了一个实验，就是我们尝试建立一个跨专业的特性团队，他们只是专注某一些特性级。我们当时是把团队所有成员请过来，在广州，这一个团队由英国的同事做PO，香港的同事做BO，印度的同时做技术支持，把所有的人请过来，我们做价值流预设，我们一个小的改变都需要一个季度，每一个过程的步骤我们用一个便利贴把它贴出来，大家以为都很简单，当我们贴完了之后，我们很惊讶，我们是一个很大的会议室，从这一边贴这一边，全部贴完，差不多贴了十米，整个团队很惊讶，为什么？原来我们交付的流程这么繁琐和复杂。当业务部门和IT部门讨论的时候，大家意识到这个问题，大家讨论到底哪些地方我们可以去尝试，这才能得到整个团队的承诺。比如说探讨中我们看到有一些审批的步骤存在，其实是没有价值架构进去的，我们能不能去掉，这是一个实验。

比如说我们有一些测试有重复，比如说我们系统测试和某些用户测试，这一个测试案例有很多的重复，在重复做事情，那就是不重复的部门在做这个事情，那能不能合并起来，或者我们往前探讨这一个事情呢。还有工程的实践，我们可不可以去装。这也是整个团队做的，我们当时做了BTT, 也是一个很好的尝试，那这一个团队打通端到端后，我们做了半年后看，我们看成果还是有的，就是说整体端到断流程的效率提升三成左右，这一个交付频率一个季度去到三个礼拜左右。大家觉得三个礼拜算什么，对不对我们看互联网的企业，一天都可能发布几百个，对不对。但是这一个业务场景里面三个礼拜一次交付是一个不小的改变了，在半年的时间里面。从业务部门这一边给予了很大的赞赏，他看到业务部门和IT部门一起去努力，看到了变化，给业务带来收益。在全球我们作一个范例推广，我们今年做了15个工作坊，建立相应的跨专业的团队，通过不同的实验，我们寻求适合我们方法。

另外一个案例是我们设立了团队了之后，我们PO,我们的产品负责人给我们一个回馈是什么，他觉得很难排优先级，因为我们不同业务部门提过来的需求，大家说我这个需求重要，你赶紧给做啊，我优先级要高。他PO很痛苦，对不对，那怎么做呢。我们做了一个小实验，我们列了一个打分表，我们对每一个需求从不同的唯度去评估，到底这一个业务的价值点有什么。比如说举个例子说，我们的驱动是什么，如果是合规的问题，银行是要合规，他的打分会高，如果一般的客户需求会相对来讲低一点。还有这一个需求会影响多少地区，比如说我影响中国分数就低一点，我影响的是欧洲，可能这一个打分会高一点。还有对我们财务和运营的影响，我们要求每个需求提上来，你要有自带评估表，大家对这个有共识了之后，PO排优先级的时候会觉得容易很多。当然这是一个参考，当我们推的时候，我们产品管理部门会做相应的调整，我们在几个团队推广。收到回馈就是说这一个事情可以帮我们优先级排序至少提升一半以上的等待时间。

还有一点我们也作了改进，我们怎么改进反馈，因为敏捷更多是说快速地去尝试，快速去回馈，去找到提升的空间，迭代回顾大家都知道了。还有一点就是做端到端的流程审核，这一点我觉得值得讲，就是我们也有经验教训的，一开始我们容易做，就是IT部门容易做，做完了之后有很多跟进的部门需要业务部门配合，他们不认可的。因为都没有参与到这个事情，对不对。所以我们做端到端的流程审视的时候，我们业务部门和IT部门一起做，大家对改进有一个承诺，这是我们一个教训在这里。

3. 总结

我们讲了半个小时了。总结一下我们讲的内容。业务参与是很多转型企业碰到的难题，这是不可避免和回避的问题，怎么去引导业务更好地参与，这是影响我们转型成败的关键，解决要从各个方位，从思想，目标，组织架构的调整，生态支持的系统的调整，还有运行的模型，我们相对配套的基础设施都需要有一个系统的解决方法。
最后我们还是坚持没有什么标准化的东西，我们需要是团队根据自己的企业情况去摸索，去探讨什么才是更适合我们自己的。

好了，我们相信DevOps也好，敏捷也好，这一种转型其实是路漫漫，需要业务部门和IT部门、科技部门一起大家更好携手合作，才能够创造更好的这一种新的篇章，今天的演讲就是这样。