平安业研一体 BizDevOps——降本增效与业务价值最大化实践

本文来自于平安专家在大会上的分享，介绍了平安科技的业研一体的协作机制和业务场景，专家认为，业研一体的模式逻辑上是从业务到技术双方的端到端的方法体系，它很好的解决了企业数字化的需求，把业务和技术放在一起能够碰撞出很多火花，产生了很多智慧的数字化方案，而且效果很好。

差不多一年多的时间，它已经在平安内部驱动 IT 精准化赋能整个业务，在团队实践过程中已经有了一些降本增效的体现。同时在整个集团里发布了业研一体的成熟度模型，它适用于金融的各个场景。这个程度模型并不只是用来评价的，而是一个实践模型，是能够指导团队怎么去做的。

如上图所展示，平安业研一体“1-3-N”实践方法体系是一个立体的体系，评估框架很明确的告诉你你现在在哪里，你应该去哪里，差距是什么。可以参照实践框架，根据场景选择相应的实践方法去落地。赋能框架具有很强的灵活性，可以告诉如何推进。

从实践框架本身来讲，如图所示，正如之前在推广的敏捷和 DevOps 理念一样，像数字底座、组织联动是提的比较多的，也是很多企业目前在做的领域。但是这个框架在企业里要想推动起来，得重点关注两个方向发展，一个是向业务端，另一个是向上推动，这样才能取得更大的成果，这里面很重要的一块叫价值管理，也可以理解为企业的经营管理，涉及到公司的投资预算，洞穿向上的战略预算和业务的价值，这才能准确的知道你的价值真的是不是符合企业的发展方向。

赋能框架这张图，它是帮助团队能够正确地理解，正确地找到方法，正确地落地，还要持续的放大效果的有效闭环。

技术赋能到底是怎么做的，专家在演讲中引用了集团内部进行抽样调研以后的一个结果为案例来详细的介绍。

这个评测的结果某种意义上反映了业技融合的一些水平，或者业研协同一体的水平。

很有趣的一点是，像人员与能力、组织结构、职能绩效等分值普遍都会偏低，特别是在金融行业，技术和业务相对比较分离。所以组织架构、职能与绩效、人员能力，相对是比较弱了。这也就意味着这是推动业研一体阻碍较大的部分。首先是得让技术和业务互相了解，知道技术的复杂度和专业性，也要了解业务的逻辑和场景。另外有好的技术要用到业务中，形成合力的，这是很重要的一方面。

分值比较高的一个叫价值实现，平安集团做敏捷、DevOps 做了很多年了，所以大家对价值的理解有很明确的理解，特别是对需求的优先级非常有概念，优先级高的交付速度就快，但是另一个陷进是高优先级不一定代表高价值，这也是挺有意思的一点。

上图是在整个调研中真正的业务评测的反馈，同样的一个问题，业务侧的反馈普遍偏低，研发侧普遍都比较高，即研发侧会认为自己做得还不错，而业务侧则觉得自己做得不咋地，这也是挺有趣的一个现象。

在价值管理领域里非常高的是价值实现，但是价值定义和价值分析这一块很低，因为研发团队或者业务执行团队不关心需求的优先级为什么这么高，他们只关心它是不是高，因为他们在价值分析这一层面基本上就很少做，甚至没做。他们关心的是结果，不追求这个价值的来源。

价值验证数值低也是有原因的，对业务来讲，IT 资源是有限的，但业务需求是很多的，这种供需矛盾的冲突始终存在，因此业务的需求就会往前挤，交付以后和研发没关系，所以研发也不会去检测价值高低，不关注效果。所以在价值管理里两头是出问题比较多的地方。

技术赋能这个领域比较有趣的现象是，工具对业务的支撑效果并不好，研发团队有大量的工具或者系统去支撑业务，但综合调研出来的结果发现，大家认为工具还是不够，这是什么呢？因为做工具的人是一种功能性思维，堆叠大量的功能。但业务是场景化思维，这就导致工具操作不太好用，体验也不大好。另外像工具平台里的研发管理工具还需要加强。

从各个评价因子里面可以看到一个很有趣的点，这条线上面的是属于 IT 技术方，下面这一侧属于业务方人员的评价，技术方出来的结果全是高的，研发的分减去业务的分，如果这个减的差越大，那么柱子就越高。如果研发的分数越高再减去业务分后得到的正数越大，那么它就在上面。如果是负数那么就在下面。就所谓业务的评分高，研发的评分低。科技侧的评价错误结果是比较高的，他们自认为在信息透明和业研协同上做得挺不错的，但实际上业务端并不认同技术方的流程标准。

上图是某个大型产品的业研一体的实践，其一就是价值成效的提升，领导从经营的视角想知道钱是不是都投到了该投的地方，是不是都做了些没用的需求，这些都是降本增效里面很重要的一个关注点。其二是优先级需求做之前有没有做评估，所以这里就做了闭环，先把价值管理闭环做起来。

其次在做的过程中，有一个叫经营价值数规划，其实就是解决投资和产品未来发展关系之间的评估做决定。第二步是全景地图，它要解决的是具体投什么，就要在产品侧的功能、模块等具体的方向，通过全景地图里面就可以看清楚整个业务的发展方向，和预算的投入以及产品的规划全串通起来，形成一个闭环。实际操作过程会有很多需求进来，所以根据不同的场景引入了需求 UN 级评估模型，可以根据投入成本等因子快速筛选出低价值的需求，基本上 80% 左右的需求是不需要的，可以快速的筛掉，业研协同的效率也提高了。

最后要对结果进行验证，这个案例里面是每个月会对相应的功能和需求投产以后的情况进行验证，每个规划的功能都有个验证周期，通常情况下是 3 - 6 个月来检视价值成效。这样的话一些高价值的需求占比就提上来了，也意味着原来一些低价值的投入就减少浪费了，协作的满意度也会提高，因为在资源有限的情况下大家都在过独木桥，如果高价值的需求被解决了就意味着业务的目标达成几率就提升了，所以业务方也满意。

- END -往期回顾
◆经济下行，拆分还是整合：单体和微服务的技术抉择
◆AI 裁员潮开始了：应用 GPT-4 不到一年，多邻国裁掉数千人
◆小红书可观测 Metrics 架构演进，如何实现数十倍性能提升？
◆快手 Kwai Agents 系统、模型、数据全部开源
◆互联网大厂“组团”宕机，都怪降本增“笑”？
◆领域驱动探索：开启架构现代化转型之路


技术交流，请加微信： jiagou6688 ，备注：Java，拉你进架构群