更好就足够了吗?| 驱动变革

写在前面:

“出于技艺的追求,工程师常常会以开放的心态去尝试新的工具和做法。其中有些完全可以由我们自己掌控,比如使用哪种文本编辑器、采用什么样的控制台、是VIM还是Emacs风格快捷键等等。但更多的情况是,我们发现的“更好的方法”不仅会影响我们自己,还会影响到团队、部门甚至整个公司。如果我们坚信自己的选择并由衷地希望以更好的方式工作,那就必须能够说服其他人,让他们认可我们的做法,并在工作上作出改变。”

本文是徐昊所写的《驱动变革》第一篇,后续他还将从“职权不是决定因素”、“行为的改变”、“获取信任和确立愿景”以及“提升紧迫感”等几个角度分别阐述驱动变革的意义及方式。敬请期待。


作为工程师的我们为什么要学习驱动变革?为什么必须成为变革者?请先试想一下这两个场景:

• 你在代码库中发现非常多的重复代码,这些代码不仅功能趋同而且结构类似。在进行了简单的重构之后,你发现这些代码其实是一类公用组件,可以在很多业务场景下重复使用。这个时候,你准备把它提取成一个单独的共用项目或者叫基础模块,在消除掉这些重复的同时,改善代码结构并且让未来的功能开发更加简单有效。你希望其他人支持你的做法,并着手修改他们所负责的代码。

• 你所工作的小组正在为某企业客户开发一款调查问卷软件的升级版,采用的技术栈
是 .NET、ASP .NET MVC和SQL Server。随着项目的进行,你发现所有数据都可以由问卷实体进行聚合(aggregating)。如果使用关系型数据库,这种聚合关联关系复杂而且效率不高。而使用文档数据库(Document Database)不仅能简化开发,而且常用查询的执行效率会提高很多倍。你希望能由SQL Server切换到文档数据库——比如MongoDB。

这两个场景你应该觉得非常熟悉,这是工程师经常遇到的境况:由于非常了解手头所做的工作,通常会比组织中其他人更早、也更敏锐地发现更好工作方式。比如更好的编码方式、更恰当的编程语言和工具,还有更合理的工程实践等等。出于技艺的追求,我们会以更开放的心态去尝试新的工具和做法。其中有些完全可以由我们自己掌控,比如使用哪种文本编辑器、采用什么样的控制台、是VIM还是Emacs风格快捷键等等。但更多的情况是,我们发现的“更好的方法”不仅会影响我们自己,还会影响到团队、部门甚至整个公司。如果我们坚信自己的选择并由衷地希望以更好的方式工作,那就必须能够说服其他人,让他们认可我们的做法,并在工作上作出改变。

作为工程师,通常我们对这个问题最直接的反应是以结果说话。相信只要有更先进的技术、更好的结果、更多的产出,那么我们所期待的变化就会自然而然地发生。然而实际情况恰恰不是这样的,我们容易低估变革的难度和阻力,而高估技术因素在变革中的影响力。比如上面所说的两个场景: 第一个是重构代码并调整项目结构,第二个是更换技术栈中的组件。看起来都是收益明确的“技术决定”,但这些决定带来的变化可能是非常深远的,阻力也可能完全来自意想不到的地方。

架构与组织结构改变

首先来看第一个例子——重构代码并调整项目结构。这里的盲点是Conway法则——组织结构是软件架构的倒影,阻力来自因为架构变化带来的组织结构变化。

你所重构出来的公共模块会在很多业务场景下重复使用,假使让所有使用了这些模块的小组共同维护这些组件,就会带来非常大的沟通成本。无论是API的变化还是特性的取舍,都没有办法在某个小组内单独决定,因为它现在已经是共用模块了。最简单的情况是由某个人——很可能就是你——来协调对公共模块的修改。那么在不久的将来,如果公共模块的需求足够多,实际上就会出现一个独立的公共模块小组或团队。这是由技术决策带来的团队结构和人力分配的调整。如果不能把这个因素纳入考量,重构就可能会失败。

你可能会想这真的会发生吗?重构一下代码结构能有这么大的影响吗?这当然不是编造的,我来讲个现实中发生的案例。

曾经有一个团队,他们采用的技术栈是 .NET。最开始的架构也很简单,前端采用
ASP.NET MVC,后端使用Entity Framework进行存储。然而这个系统的领域模型比较复杂,有很多小的细力度对象。使用Entity Framework进行持久化的时候,类型映射的代码非常复杂,但这些对象引用关系相对比较简单。这时候有个技术非常不错的小伙子,为了解决底层的持久化问题,开始寻找不同的解决方案。于是他边写功能代码边自己做了一套不同于Entity Framework的持久化框架,通过SQL Server的XML字段和 .NET对象序列化完成所有持久化的操作。

他做完演示之后,大家都觉得很不错,于是就开始着手重构其他代码。这时候麻烦来了,他做框架的时候,是根据他所熟悉的业务进行的抽象,有很多没有考虑到的地方。不过他手很快,白天提的需求晚上就能改好,后来慢慢发现由于整组人都在用这个东西,别人又没他了解的多,不如让他专门来做这个框架。渐渐他就不做其他的需求而是专门来做框架,于是他自己就成了一个小团队。

这就是因重构而产生团队结构变化的例子。这个案例之所以能够成功,除了他个人的一些做法之外,主要是因为这个团队负责整个软件的交付,责任结构比较简单,内部分工的变化对整体交付没有影响。如果不是这样的结构,又不事先考虑组织变革的成本,那么架构重构基本上就会失败。

很多年前,我在Java社区认识一个朋友,他所在的公司在国内某行业做定制软件开发。这家公司的团队是按业务模块进行划分的,每个小组负责一个模块的交付。我这位朋友算是想法比较活泼的,他希望能够抽取与业务相关的公共组件,从而在现有的项目中提炼出产品和行业解决方案。他在他负责的小组内做了尝试,并取得了一定成功。

他的领导让他征求其他团队的意见,看看是否有推广的前途。然而在这个过程中,他受到项目其他模块团队的质疑:如果公共模块出了问题谁来负责?当他回答说,“我可以用业余时间尽量帮助大家”的时候,最终实施结果也就可想而知了。没有人愿意把交付的成败依靠在某个人的业余时间投入上,而领导又没有足够的动力改变整个团队的结构,那么这个方案也就不了了之了。

核心组件与技能要求

再看第二个例子——更换技术栈中的组件。这里的盲点是协作部门的技能变更。

你所作出的技术决定是正确的。针对这种聚合关系的对象结构,无论从数据存储的效率、查询的效率还是开发的效率来说,文档数据库都会是更好的选择。但是开发仅仅是整个软件生命周期中的一环,除了开发之外还有运维支撑,比如监控、备份、数据恢复、故障诊断等方面,也是非常重要的。特别是对于已经运营了一段时间的软件产品来说,就更是这样了。

在这个例子里,因为是后续升级而不是全新系统,那么客户已经围绕SQL Server建立了完整的运维体系。那么如果把数据库换成MongoDB,就需要围绕MongoDB建立新的运营方式,那么运维团队就需要新的技能和工具才能继续运营这个产品。这是因技术决策而为协作部门带来新的技能要求,如果不能把这个因素纳入考量,就会影响软件的最终投产。

同样为了告诉你这样的事情真的会发生,我举个例子。

最近有个团队,在帮助某客户研发医疗管理系统。该系统是个有多年历史的遗留系统。由于设计的早,架构上有很多不尽合理的地方。在这次的研发中,客户希望可以撷取业内较好的工程实践,以支撑未来的架构演化。这个团队采用了micro-service的方式架构整个应用,把独立的模块分解成独立的服务。部署上为了更好的弹性,抛弃了原有系统的应用程序服务器模型,而是采用内嵌Web容器的方式。

在开发了一段时间之后,有医院方的人员来参加成果展示。这时候,负责这个系统运营的IT部门表达了强烈的不满。原因是,他们的运营人员主要通过应用程序服务器的控制台管理所有应用程序。而一旦变成多进程的micro-service后,原有运维工作就需要依赖linux平台上的日志、进程管理监控工具才能完成。他们的运维人员完全没有这方面的经验。当时的结果是,micro-service仅在测试环境中使用,而生产系统必须采用应用服务器的模式。

这是好的、先进的技术因为没有预估好协作部门的技能水平而失败的例子。当然,考虑到这个问题而把一些相对激进的好技术推行成功的故事也是有的。

在Ruby还不是很流行的时候,有个团队想在项目中使用Ruby Watir作自动化功能测试。而客户的情况是:他们已经花了大价钱购买了HP的Quality Center和QuickTest Pro。这两个都是商业软件,都需要高昂的版权费用。这两个软件分别由业务人员和QA团队使用,业务人员使用Quality Center来记录需求和测试案例,自动化功能测试主要由QA团队完成。QA团队主要采用录制脚本结合VB Script的方式来编写测试,测试全部由QuickTest Pro执行。

力主使用Ruby Watir的是研发团队,因为当时ruby很新潮同时Watir的执行效率比QuickTest Pro要好很多,但QA团队并没有表现出对Ruby的热衷。这时候团队里的工程师研究了QuickTest Pro的编码风格。发现QuickTest Pro中测试主要依赖三个部分:Object Repository用于表示页面元素和常量、Data Sheet用于记录测试数据、VB Script用于实现测试步骤。于是他们使用Ruby做了一套框架:PageObjet用于表示页面元素和常量、Fixture用于记录测试数据、定制的领域专用语言(DSL)用于实现测试步骤,同时整合Quality Center以统计测试报告。这个框架让QA团队感觉到工作方式其实没有什么太大变化,基本都能与QuickTest Pro中的概念一一对应,并且不会影响Quality Center的使用。就同意尝试
使用它。大约四周之后,整个测试部门就开始了由QuickTest Pro到Ruby Watir的迁移,QuickTest Pro就完全废止不用了。所以只要方法正确,这种看似不可能的变化——抛弃已经采购的商业软件转而使用开源软件和不知名的小语种——也是可以顺利完成的。

我还可以列举出非常多的例子,看起来都是好的技术决策,然而最终左右这些决策成功与否的并不全是技术因素。我想你已经大概明白我的意思了:仅有更好方案是不够的。更先进的技术、更好的结果、更多的产出,并不能让我们所期待的变化自然而然地发生。哪怕只是某些技术上的改进,单单是个体的变化已经不够了。那么如果我们不希望年复一年地工作在腐烂的代码库上,使用陈旧的技术栈、落后的工具、过时的工程实践,我们必须学会驱动变革,成为卓有成效的变革者。


更多精彩洞见,请关注微信公众号:ThoughtWorks洞见

Share

以客户为中心,构建银行商业生态

[摘要]

金融脱媒的影响,正在从小额高频消费市场的长尾客户,蔓延至银行最为关注的高净值客户。面临重重挑战,当下的银行亟需进行数字化转型,「商业生态战略」成为许多银行转型的关键破局点。如何以客户为中心,构建银行商业生态呢?

  1. 重新认知创新,洞察数字化时代的商业逻辑
    • 1.1. 互联网企业的商业创新逻辑
    • 1.2 传统企业的商业创新逻辑
  2. 重塑客户体验,拥抱客户旅程3.0时代
    • 2.1 客户赋权时代的银行客户体验管理
    • 2.2 劳埃德银行和招商银行的客户旅程实践
  3. 重构商业生态,升维思考银行转型战略
    • 3.1 银行内部生态
    • 3.2 银行客户生态
    • 3.3 合作伙伴生态

写在最后


中国的传统银行正在面临着前所未有的挑战,支付场景的争夺战从生活消费场景延续到了交通出行领域,竞争进一步白热化。金融脱媒的影响,正在从小额高频消费市场的长尾客户,蔓延至银行最为关注的高净值客户。面临重重挑战,当下的银行亟需进行数字化转型,「商业生态战略」成为许多银行转型的关键破局点。

1. 重新认知创新,洞察数字化时代的商业逻辑

说起创新,一种大规模的商业模式转型和一个小的想法同属于创新。我们在过往的银行咨询实践中观察到,诸多银行虽然已经意识到创新的重要性,并通过一些创新机制的建立或举办创新大赛等活动,推动银行内部进行创新。但其中大部分的创新仅停留于“想点子”的维度,无法真正推动银行规模化可持续的进行创新实践。

在今天,互联网巨头和金融科技企业通过以客户为中心创造价值,依托提供更便捷、更低门槛、更丰富的体验吸引客户使用其金融服务,这也给传统银行带来了巨大的冲击。数字化转型已经成为传统银行转型的唯一出路,而数字化转型的核心竞争力,就是企业的规模化、可持续的创新能力。商业模式创新将帮助银行转变原有的业务流程,推动业务模式的转型,提高银行、客户或合作伙伴的商业价值。

那么,如何理解数字化时代的商业模式创新呢?我们可以探索一下互联网企业与传统企业的创新逻辑。

(图1:商互联网企业 vs 传统企业的商业模式创新)

1.1 互联网企业的商业创新逻辑

无论是BAT还是各类垂直领域的互联网平台,其商业模式创新通常包括以下三个圈层:

第一圈层,获取流量并直接变现。互联网平台早期通常以获客为核心目标,以腾讯为例,其最核心的产品即是QQ和微信,借助两大社交产品汇聚了大量用户群,腾讯可以通过平台广告售卖直接获得收益。

第二圈层,通过经营流量,实现增值业务变现。凭借核心产品带来的用户流量,腾讯逐步布局了腾讯新闻、视频、音乐、游戏、地图、浏览器等产品,这些产品大大增加了用户的使用时长,不仅增强了用户的粘性,还为腾讯带来了多元化的广告库存。同时,通过不同产品会员体系的搭建,把控头部高价值用户,进一步提升了平台价值和会员增值收入。

第三圈层,依托流量扩展生态场景,实现全生态价值链的可持续变现。腾讯在近几年大力推广“互联网+”业务,通过战略合作与投资并购,将其业务渗透到用户生活方式的各个领域,不断连接“人-设备-服务”,其商业变现也包括了生态布局红利、合作佣金分成、数据价值等丰富的模式。在商业模式创新的同时,腾讯通过“连接一切”,进一步发挥了生态价值链的协同效应,为自己建立了更强的竞争壁垒和可持续的商业变现能力。

1.2 传统企业的商业创新逻辑

随着互联网浪潮的兴起,银行或各类传统企业纷纷开始进行数字化转型,其商业模式也在创新实践中发生着变化,但与互联网企业有着类似的三个圈层:

第一圈层,依靠核心业务直接变现。作为最原始的商业模式,银行依靠金融服务直接获得收益,车企依靠汽车销售直接获得收益,商超依靠商品售卖直接获得收益。核心业务通常为传统企业带来50%以上的销售收入,是传统企业营收的重要保障。

第二圈层,围绕核心业务布局产业链上下游来变现。当企业的核心业务达到一定市场渗透率后,企业通常会开始布局产业链上下游,以寻求新的利益增长点。这时,零售银行开始将储蓄业务延伸至保险、理财、贷款等金融服务,而汽车厂商则开始布局汽车维修、保养、二手车等后市场服务。

第三圈层,布局生态场景,通过连接创造价值,实现全生态价值链的可持续变现。传统企业本可以在产业链上持续深耕,然而随着互联网企业纷纷将业务触角延伸至传统行业,行业边界逐步被打破,这对传统企业带来了巨大的市场冲击。例如支付宝和微信支付抢占了传统银行的零售支付入口,而天猫、京东、拼多多等电商平台也颠覆了传统零售的买卖模式。于是,在过去两年,我们看到大量的银行开始着手布局自己的商业生态圈,通过生态连接用户的食、住、行、游、购、娱等场景,在场景中满足用户的多元化需求,为用户提供最佳的服务体验,并将金融服务渗透在场景中,根据用户的需求提供个性化的金融解决方案。

由此我们不难看出,无论是互联网企业还是传统企业,其推动商业模式创新的本质,都是通过“连接”创造价值,从而实现“全生态价值链”的可持续变现。银行随着生态场景的布局,创新的价值将在实践中逐步显现,未来银行的每个场景都将是一款数字化产品,其互联网化的经营客户的方式和全新的变现逻辑,都将改变传统银行原有的商业模式。新模式也将在未来进一步优化银行的整体财务模型,使得生态创新业务占据总体收入更高的比例,从而以生态圈构建竞争壁垒,并实现业务的多元化增长。同时,通过在生态场景下收集、分析数据,由数据驱动金融服务和相关业务的增长,可以实现更好的客户经营,提升客户的体验和价值。

ThoughtWorks认为,今天的银行正在从传统银行过渡到「数字化银行」,而未来的银行将从数字化银行变成「数字化企业」。

2. 重塑客户体验,拥抱客户旅程3.0时代

不久前,我曾在《重新定义客户旅程》这篇文章中提出了「客户旅程3.0」的概念,其背后的演进逻辑,其实是随着市场经济的发展、新兴科技的驱动,产品与市场供给结构发生的迭代变化:从“产品时代”的供不应求,客户被动接受;到“客户时代”的市场激烈竞争,客户拥有更多选择的权利;再到“客户赋权时代”,客户开始沉浸于场景中,并习惯被超越预期。这倒逼着企业在全流程客户体验上进行持续创新,以满足今天“被惯坏”的客户。

(图2:客户体验管理演进)

2.1 客户赋权时代,银行的客户体验管理

在客户赋权时代,客户旅程3.0思维将成为银行进行规模化创新的必备能力,助力银行将自身的产品和服务有效连接到客户的生态价值链上。ThoughtWorks认为,银行需要从以下四个方面重新思考客户赋权时代的体验管理:

1. 客户愿景出发

银行需要基于大量的客户调研和数据分析,充分理解客户的期待,对客户的愿景进行重新定义。然后,从这个愿景出发去思考为客户提供服务的方式,将相关的旅程都整合进来,绘制出价值驱动的全新的客户旅程地图。例如对于购车的客户,他们对银行的需求仅局限于车贷,但是客户的愿景可能是“拥有人生中的第一辆车”,这时银行可以围绕客户这个“梦想”,在车辆的选择、购买、驾驶、装饰、置换等多个客户旅程进行布局,将个性化的金融方案嵌入到“车生活”的客户场景中去。

2. 客户价值驱动

银行在重新梳理客户旅程的过程中,需要不断思考:我们正在做的这件事,对客户有没有价值?站在客户的角度,银行提供的服务旅程是否“必不可少”?银行提供价值的方式和理念是否有“足够的吸引力”?银行能否持续为客户提供价值,对银行连接客户、维系客户忠诚度来说,举足轻重。

3. 创新客户体验

银行需要创新和颠覆满足客户愿景、连接客户生态的旅程,并关注与客户的情感连接。“被惯坏”的客户习惯于需求的即时满足,也期待时不时的惊喜出现。银行需要构建可持续创新的能力,才能为客户持续不断地带来极致体验。

4. 连接客户生态

客户不会主动发现银行所提供的产品或服务,银行需要将金融服务的旅程与客户的生活场景相连接,创造更多接触点,提供更多创新的连接方式。银行可以将金融服务有效映射到客户的生活旅程中,比如将金融服务切入到客户的生活场景或重大事件中,如买房、装修、结婚、生育、购车、教育、旅行等。这将成为银行进行客户体验管理、构建生态战略布局的关键。

(图3:客户赋权时代,银行的客户体验管理)

2.2 劳埃德银行和招商银行的客户旅程实践

英国劳埃德银行的客户旅程改造项目于2014年启动。在项目初期,劳埃德与咨询公司合作梳理了30个关键客户旅程,由“新客户”和“企业抵押贷款”两个旅程起步做试点,截止2018年初,先后进行了16个核心旅程的端到端改造。未来三年,劳埃德将继续加大客户旅程项目的投资,计划于2020年完成50条客户旅程的端到端改造。在实践中,劳埃德也构建了一套基于客户价值的运营体系,通过组织跨职能团队、建立客户旅程实验室、使用专有预算和重建KPI等一系列举措,推动数字化转型的实践。

招商银行也于2018年初提出了“打造最佳客户体验银行”的口号,从“客户旅程地图”开展端到端的流程梳理和优化,以客户的视角重新审视从最初接触招行、到购买服务、到获得售后服务的全过程,覆盖客户的全生命周期。招行将FinTech创新基金的很大一部分投资,用于客户体验项目上,提出树立真正的“用户导向”文化,以创造用户价值作为核心评估标准,而不是像过去单以短期的财务结果论成败。同时,招行以“内建平台、外拓场景、流量经营”的方式,将业务聚焦于场景和APP,构建开放的银行服务生态体系,实现流量的快速增长。

3 重构商业生态,升维思考银行转型战略

银行构建商业生态,通常会采用B2B2C的模式,围绕“金融服务+生态场景”来进行布局。例如,丹麦银行(Danske Bank)开发了住房生态圈Sunday平台,客户可以在该平台上查找房源、预约看房、申请按揭,平台还提供家具递送、搬家、宽带过户等房屋售后服务。 第一资本(Capital One)将汽车金融业务作为其在共享出行生态圈的布局,通过汽车导航应用软件,客户可以浏览1.2万家经销商的300多万辆车,进而简化其购买、贷款等繁杂流程。中国银联今年在交通场景布局的消息不断,从湖北省高速公路全线开通“银联无感支付”,到宁波地铁实现银联移动支付全覆盖、青岛地铁全线开通银联二维码乘车,再到全国百余县域公交开通银联移动支付,为百姓提供了便利的支付方式,为行业提供了高效的支付解决方案。

金融机构类似的生态布局探索屡见不鲜,但同时也遇到了新的挑战和困惑,比如:

  • 银行是否应该像BAT那样大而全的布局生态场景?
  • 面对丰富的场景,银行布局生态圈需要从哪里入手?
  • 银行需要怎样调整内部资源,以支持新场景的落地?
  • 如何实现银行的规模化可持续场景创新?

基于在生态布局领域的最佳实践,ThoughtWorks总结出“内部生态+客户生态+合作伙伴生态”的三维生态构建思路,可以帮助银行解决上述问题。

(图4:ThoughtWorks银行商业生态构建)

3.1 银行内部生态

每家银行都开始强调“以客户为中心”,围绕客户提供产品和服务,以满足客户个性化的需求。然而在创新与客户的数字连接旅程中,我们常常会面临资源协调效率低、跨部门协作壁垒、违背组织原有流程、重复开发造成资源浪费等问题。显然,如果没有一套完整的内部生态机制作为保障,创新的客户生态与合作伙伴生态,无法高效地在银行内部流转。因此,银行在构建商业生态之前,需要同步搭建可以支撑外部生态落地的内部机制,我们建议银行从以下三个方面入手:

1. 打造银行规模化可持续创新的能力,推进组织与文化转型

建立支持数字化创新的组织架构和人才机制,通过成立创新基金、举办创新大赛等形式,鼓励内部创新文化的培养。自上而下,银行通过重点生态领域的布局,实现从”总-分-支”行的创新战略落地;自下而上,银行通过来自客户一线员工的探索,从”支-分-总”行推广规模化可持续创新实践。以招商银行为例,其推动金融科技创新并非优先从技术本身出发,而是从金融科技的思维和文化入手。招行董事会明确提出“容忍失败,奖励成功”的创新文化,不仅成立了金融科技创新基金,规模为上年营业收入的1%,且不考虑短期的投入产出比;还通过举办小团队创新大赛,允许员工跨地区跨部门跨条线自由组合参赛。当创新文化与机制先行之后,创新项目在行内的落地也就成了顺理成章的事。

2. 构建基于客户价值的运营机制,实现效率的提升与成本的优化

银行需要基于客户价值,采用设计思维和新的交付流程,重新构建运营模式和组织架构。通过自主的跨职能团队,使用专有的预算和灵活的KPI体系,银行可以从客户的旅程出发,聚焦解决客户的痛点和问题,为客户创造价值。同时,通过缩短处理流程、增加自助服务、提高客户转化率等举措,银行可以进一步释放人力资源,提升客户的体验和忠诚度,实现企业效率与成本结构的最优化 。英国的劳埃德银行经过研究发现,75%的客户与银行的第一次业务连接希望通过面对面进行,60%的客户期待可以面对面的开展抵押贷款服务。因此劳埃德将人力资源集中在最有价值和最复杂的客户需求上,例如理财规划、购买保险、抵押贷款等;而针对简单的和物理位置无法满足的客户需求,劳埃德在去年推出了远程服务“Home To Hub”,客户可以在家中通过远程视频会议,获取专业顾问的建议。

3. 以资源池提升协同效率,实现数据、技术和业务资源的平台化与共享化

在数据资源方面,数据共享是构建内部生态的核心,通过获取不同业务系统及第三方平台的数据,将其存入数据湖集中存放和管理,为跨部门跨团队的数据创新和业务支撑提供基础;在技术资源方面,推动银行内的产品设计、技术资源、数据能力等组件化、标准化、平台化发展,以支持银行全渠道战略的快速变革和创新项目的落地, 避免重复开发与资源浪费;在业务资源方面,推进跨部门跨业务条线的协作协同,建立银行内部的业务资源池,将客户资源与流量、渠道分发与营销、各项业务能力、产业辐射资源、孵化创新空间等汇入资源池,以推动银行内部业务创新的发展。

(图5:银行内部生态构建)

3.2 银行客户生态

伴随着BAT的生态布局热潮,银行也开始意识到“金融+场景”的重要性,我们看到大量的银行信用卡客户端,正在成为金融与生活服务场景连接的核心“载体”。一些银行也尝试了类似互联网平台的“烧钱”模式,每年用上亿元的补贴费用吸引客户使用银行提供的生活服务。在客户旅程3.0时代,银行最终必然走向以打造端到端的客户体验为核心,建立融入生活场景的客户生态系统。而作为生态系统的后来者,银行不可能像腾讯、阿里一样同时发力多个场景,事实上这其中的每个场景,对于银行而言也是一笔不小的投入。因此,针对银行的客户生态场景布局,我们建议:

1. 优先拿下高频场景

曾几何时,银行一直在忽略小额高频支付市场,把业务重心放在高净值客户身上,直到支付宝和微信支付的颠覆式崛起。腾讯乘车码从2017年7月在广州首次上线之后,如今已覆盖到北京、深圳、上海、厦门等全国100多个城市,根据微信官方公布的报告显示,一分钟全国有2.5万人同时使用微信内的乘车码乘公交、地铁,并且在早高峰的2个半小时,使用乘车码的人数达到375万人次。显然,高频场景这场仗,银行必须要打,与客户生活场景相关的购物消费、餐饮娱乐、交通出行等高频服务,银行需要尽可能地广撒网、多覆盖。

2. 深耕高价值场景

这里的高价值场景既包括了大额消费场景,如出国留学、商务出差、旅游服务、境外医疗等,也包括了覆盖高净值客户的全服务场景,即银行最为重视的高端客群(如信用卡钻石卡、白金卡客户)场景服务。这类客户的打法通常是从场景向产业链上下游延伸,银行可以B2B2C的模式切入产业链全服务场景。以旅游行业为例,在B端,银行通过支付平台,向产业链上游建立线上采购平台,向下游拓展线上分销渠道,基于支付产生大量信用数据后,通过数据分析为上下游合作伙伴提供融资、理财等金融服务,从而对整条产业链产生影响;在C端,通过聚合支付和金融服务,银行可以依托线上渠道,为消费者提供与旅游相关的融资、保险、理财等服务。长期以来,银行都将客户运营的重点放在高净值客户身上,如今无论互联网巨头还是大型企业的自金融服务,都在积极抢夺银行在高端客户市场的优势。当前银行必须从顶层设计的角度,尽快明确战略性场景,通过产业链布局深耕场景,构建维系高价值客户的竞争壁垒。

3. 以“小额高频”带动“高端低频”场景

在银行生态布局实践中,我们发现大量银行困惑于场景布局的优先级。而我们从互联网巨头的生态打法中发现,它们通常优先以高频场景圈住客户,运营客户使其留存在平台,再向其推荐相对低频但高客单价的服务。我们认为,类似的做法在传统银行同样适用。企业布局客户生态场景,通常看中的是其中的数据流、业务流和资金流。银行通过高频场景触达海量客户,在场景中不断的收集数据,基于数据分析实现更好的客户经营,进而推动客户使用银行的高价值金融服务和生态业务,“资金流”在场景中水到渠成的沉淀下来。

(图6:银行客户生态构建)

3.3 合作伙伴生态

内部生态提升效率,客户生态连接场景,释放生态能量、构建行业壁垒则要靠合作伙伴生态了。以金融科技赋能合作伙伴,以生态战略联盟构建行业壁垒,将会成为未来银行可持续增长的核心竞争力。在构建合作伙伴生态方面,银行可以从以下几个方面着手布局:

1. 金融科技赋能商业生态

以大数据、区块链和人工智能等技术为基础,通过开放的API战略和技术云化,推动银行内部、银行的客户和银行的合作伙伴共建金融科技生态圈,实现真正的科技赋能。一方面,银行与业界领先的金融科技企业合作,构建核心技术优势,形成技术壁垒,同时通过金融云向银行内外输出在大数据、区块链等方面的能力,推动技术与数据能力的协作和赋能;另一方面,通过打造API生态圈,实现从银行到内部生态、客户生态和合作伙伴生态的开放共享,提升全场景的金融服务能力,释放巨大的商业价值。2017年5月,西班牙毕尔巴鄂比斯开银行(BBVA)的API市场对西班牙的客户正式开放,首轮开放的API共8个,其中6个基于银行零售端用户信息,1个基于企业信息,还有1个是零售端多渠道数据的整合。随后,BBVA对美国和墨西哥也相继开放了零售API,并计划陆续登陆其它国家。BBVA一系列在基础设施、平台化、数据方向的开放措施,帮助其构建了坚固的竞争壁垒。

2. “银行+银行”合作生态

银行间的合作目前国内还比较少,我们在海外看到一些尝试。在日本,阿里在多个城市大力推广Alipay,给日本本土银行带来了巨大的压力,包括日本瑞穗金融集团、邮储银行以及横滨银行、静冈银行、福冈银行等地方银行在内的约70家日本银行,去年联合推出了虚拟货币“J币”,为个人、企业提供移动支付和转账服务。在美国,免费、快捷的个人对个人支付服务Zelle,几乎覆盖了包括富国银行、摩根大通及美国银行在内的美国多数银行,这样的联手旨在与PayPal、Venmo及Square Cash等支付服务相抗衡。银行之间通过结成战略联盟,依托各自资源优势和客户沉淀,通过合作伙伴生态构建竞争壁垒,联合对抗互联网支付巨头的竞争,实现合作共赢,是国内金融机构下阶段可以探索的方向。

3. “银行+FinTech”合作生态

金融科技企业通常以技术驱动,善于运用创新概念,可以以更灵活的方式连接客户,这将助力银行扩展能力,为运营可扩展性提供支持,更好的提升客户体验,缩小传统银行提供的服务与客户实际需求之间的差距;而银行可以为金融科技企业降低服务门槛,提供受监管的产品和服务,帮助其培养客户信任,并通过金融科技企业的战略合作或投资并购,帮助其快速成长,实现合作共赢。以欧洲最新锐的数字银行Number26为例,业务亮点在于引入了最新的科技元素,但是其本身并没有银行牌照,于是通过与德国传统银行Wirecard合作,由Number26负责数字银行的平台运营,由Wirecard负责保管Number26客户的存款,合作双方基于客户存款产生的息差收入进行分润,最终实现合作共赢。

4. “银行+产业链”合作生态

银行以B2B2C的模式构建商业生态,其中的每个生态场景都涵盖了大量的产业链供应商合作伙伴。银行与B端供应商进行合作,共同为C端客户提供场景化服务,通过连接产业链上的大量B端,形成资源聚合平台,从而吸引更多维度的C端客户使用场景化服务。由此便产生了裂变效应,数据流、业务量与资金流在场景中自然沉淀,银行即可收获生态系统布局带来的红利,充分发挥合作伙伴生态的最大价值。以中国平安为例,在C端,平安以汽车保险为切入点布局汽车服务市场,通过战略投资汽车之家把控影响用户购车决策的“内容”和“线索”,依托平台战略打造“平安好车主App”,整合B端供应商资源,为车主提供优质的用车服务;在B端,平安通过经销商云平台、新车二网云平台等覆盖全国90%以上的服务提供商,与90多家整车厂、2万多家4S店深度合作,带来了汽车金融和融资租赁业务的飞速增长。

(图7:银行合作伙伴生态构建)

写在最后

在完成这篇文章之前,我曾参与过互联网巨头的生态场景布局,也作为咨询顾问服务于银行生态战略从顶层设计到落地实践的全过程。对于「生态」二字,从探索商业逻辑、推进生态规划时的“半信半疑”,到让战略落地、在实践中持续迭代方法论后的“深信不疑”。直到现在,我越来越坚信:“以客户为中心,构建商业生态”才是银行真正的未来。


参考资料:

Share

从王安石变法看“规模化敏捷”

[摘要]

当前敏捷在大型组织中的规模化落地,某种程度上很像历史上的变法。回顾王安石变法的历史,它为什么会失败?对比敏捷的规模化实施,探讨“规模化敏捷”到底可不可取?以史为鉴,我们应该怎么做?


最近在阅读《罗辑思维》全集时,看到一章很有意思的内容,详细分析历史上的变法,其中王安石变法部分让我不断联想起规模化敏捷的实施。两相对比分析,有诸多启发。

一、历史回顾:王安石变法

大事记

王安石变法为什么会失败?

回顾王安石变法过程,会发现其初心很好,实施策略看似做得特别成功:

  • 变法初心:王安石改革之前,司马光问王安石怎么改革?王安石说他有一个方法叫“民不加赋而国用饶”。王安石认为,北宋国家贫苦的症结,不在于开支过多,而在于生产过少;农民之所以贫苦和不能从事生产,一方面是由于官僚富豪兼并了大量土地,另一方面是由于政府把繁重的徭役加在农民身上。因此,最好的理财富国之路,是依靠天下所有的劳动力去开发自然资源,是积极开源而不是消极节流。即不增加赋税,激发社会活力而让国家变得富强。
  • 实施策略:
    • 先定义蓝图:上《本朝百年无事札子》,谈改革之蓝图;
    • 获得高层支持:北宋皇帝宋神宗,本来久慕王安石之名,其变法之道得到了他的绝对支持,他常常跟周围的人说,他跟王安石就是一个人;
    • 清除反对力量:王安石在获得高层的绝对支持后,对变革有异见的大臣比如欧阳修、司马光进行清除,扫清障碍;
    • 全面推广:在蓝图获准、清除变法异己之后,快节奏地全面推广。

然而,结果却失败了。为什么呢?浅析一下,原因可能是:

1. 目标与执行上的不匹配

历史上的变法,可以分为两类:追求效率的“效率型变法”和追求活力的“活力型变法”。

  • “效率型变法”:效率优先、集中财富但不制造资源和财富增量。简单来说,就是围绕单一目标展开,国家要达到这个目标,不惜一切代价集中所有资源都要实现,比如商鞅变法,春秋时代层层分封的财富分配体系被商鞅全部拆掉,他把国家的每一个老百姓、每一粒粮食都镶嵌在国家这个战争机器上,所以秦国变得非常富强。
  • “活力型变法”:激发活力、制造财富和资源增量。这种变法会同时考虑多个目标比如朝廷财源比较丰沛、老百姓安居乐业、市场繁荣稳定、军队能够有战斗力、政府高效廉洁等;在实施时不是调整存量分配,而是想法设法制造财富和资源增量。比如1933年到1941年期间,由美国第32任总统富兰克林·罗斯福发起的罗斯福新政,他围绕经济、农业与工业、社会保障以及政策制度等几个大的维度展开,后人用核心3R来总结,即救济(Relief)、复兴(Recovery)和改革(Reform),也称三R新政。最终,美国经济复苏,政治制度上建立了以总统为中心的三权分立格局,人民生活得到极大改善。

王安石变法,初心上是“追求活力”、有多重目标的,但实施上却采取了“效率优先”的方法,核心是依靠权力把效率推进下去。“效率型变法”要想成功,有一个天然的前提,就是先有蓝图,然后集中快速施工。对一个单目标系统,预先设定一个“正确的”蓝图尚且挑战重重,如果是针对一个多目标系统,几乎是不可能的。这种目标与执行策略上的不匹配,成为失败的原因之一。

2. 低估了制度成本

其实王安石的变法,从制度设计角度是非常好的,比如青苗法的初衷就很好:给老百姓提供低息贷款,避免去借高利贷,以保护和赈济民户。但问题出在制度的实施是表面上附和但内心未必接纳的各级官吏来推进的。最后变成什么了呢?那就是领导意志。比如当时有一个小官叫做邓绾,为了巴结神宗,当听到神宗称赞王安石为“当今之古人”后,瞬间明白领导意思,就神乎其神地夸王安石变法各种好,虽然他不一定懂新法但却得到了重用。这些变法的落地执行者,为了达到目标或超额完成目标,强制摊派老百姓贷款。最后,实际结果适得其反,不仅没有降低老百姓的压力,反而变成了一种变相的赋税。所以,良好的蓝图在实施过程中遇到了制度成本——执行变法的人,没有理解其真实意图,只是围绕既定KPI开展工作,结果自然不好

3. 忽视长期、可持续的变革力量

任何一种变革都不可能一次性成功,新法也可能会失败。如果失败了,那些反对派一定会站出来攻击王安石。所有效率型改革,只要失去高层支持,无论是主动的还是被动的,出路只有一条,那就是失败。宋神宗一死,继位的高太后一上台就把王安石搞下台,新法完全没有了机会,退出历史舞台!王安石阵营在变法期间,并没有能够培养出持续推动变革的力量,比如王安石卸任时推荐了他信任的吕惠卿继任,这个人不但没有继承变法大志,反而落井下石,跟邓绾一起诬陷王安石叛乱。因此,后面即使没有高太后和司马光,变法也难以为继。

二、敏捷的规模化落地与变法实施

敏捷(Agile)是2001年由17位资深软件领域专家们一起发起的针对软件开发工作价值观的倡议。作为一种软件开发理念,与之伴随出现了很多实践框架和方法,如Scrum、Kanban和XP。而这些方法目前已经逐步成为了我们软件开发的实施标准,类似持续集成(Continuous Integration)这种10年前被大家认为是“极限”的方法,现在也已经成了开发团队的一个标配。但在很多大型组织里,敏捷的大规模应用仍然是一个非常有挑战性的任务。软件自身的多样性和这个行业的高速发展,造成了敏捷方法落地的种种挑战。

1. 敏捷的规模化落地,本质是个多目标系统

敏捷的初心,即面向市场和商业模式变化如何提升业务响应力,为用户带来真正有价值、高质量的产品。在整个组织里落地敏捷是一个多目标系统工程,目标至少包含发布高质量、满足用户需求的产品,打造有创造力的文化,建立高响应力的团队等。这带来的第一个挑战就是“蓝图的设定”。没有人可以预先为这个多目标系统设定清晰而正确的蓝图。

最近几年在国际银行届比较知名的数字化转型成功案例非BBVA(西班牙对外银行Banco Bilbao Vizcaya Argentaria)莫属。作为一家拥有6520亿欧元资产的全球银行集团,2007年应对全球金融危机时,BBVA开启其创新旅程,对集团进行数字化革新。尽管拥有上层认可及远见蓝图,BBVA的数字化转型之旅也并非按部就班的沿着蓝图前行,其转型过程大致经历了三个阶段:IT内部创新、扩大团队与银行业务发展重点的创新、数字银行分支匹配敏捷项目管理。一路上尝试不同的结构和方法,通过实验不断调整,最终成为数字化转型的成功典范。

2. 敏捷的规模化落地,是追求活力而不是追求效率

正如前文所述,敏捷的规模化落地,其核心还是围绕敏捷的核心价值观和原则展开,只不过参与的产品更多、人员更多而已。它追求的不是单一目标 —— 规模化,而是价值、质量与其他约束条件的调和所带来的多方优化结果。

笔者曾经参与过一家大型外资银行的敏捷转型辅导,其高管层的目标就是在一年内针对其全球六七万人的IT团队实施敏捷转型,所有部门,包括PMO以及外部教练都要围绕这一目标展开。大部分时间花在了制定各种对团队进行评估的模型上,而团队级别的敏捷实践深入辅导不足,团队对于敏捷理解程度有限。一年之后,形式上虽然绝大部分都参与过敏捷培训,或者敏捷教练辅导,但是对于产品质量和价值的提升非常有限。当这种疾风扫落叶的培训活动结束后,能够保留下来真真正正实施敏捷的团队已经屈指可数,大部分又回到了过去的开发方式。

上面两点,决定了敏捷的规模化落地,如果采用“王安石变法式”的实施方式,必然会失败。

三、规模化敏捷框架与王安石变法

当前大量组织级的敏捷转型需求,催生出了如SAFe、LeSS这样的“规模化敏捷”框架。如果详细研究SAFe的实施过程可以看到,它有完整的白皮书、官网,市面上有各种培训和认证,特别是SAF4.5已经给出了4个经典配置以及10个步骤的实施路线图,看似为组织给出了一个“清晰而正确”的蓝图。

SAFe的蓝图和实施路线图看似很完美,但在落地过程中会遇到诸多挑战,一如一开始看起来很美的“王安石变法”。

1. 追求活力的多目标,实施时变形为单一目标

在实施SAFe的时候,容易想到在组织内部去寻找宋神宗这样的人,这并没有错。但是,根据组织心理学家William Schneider提出的组织文化理论:其中,95%的商业组织都属于控制型文化,这种组织文化强调的是上传下达,领导意志。

(文化四象限)

因此,如果在组织内部发起变革,很容易变成目标问题。也就是王安石遇到宋神宗之后面临的挑战。本来是一个追求活力的变革,最后实施时变成了效率型方式。

2. 因为制度成本,忘记真实意图,仅仅围绕效率指标

前面讲到王安石变法过程中的制度成本问题,在规模化敏捷实施时也普遍存在。无论组织是自我变革,还是请外部教练,很容易变成在领导意志下围绕一个“蓝图”按部就班地展开。而且为了考核规模化的进展,就会设立规模化的指标,比如组织内部百分之多少的团队纳入规模化敏捷运作框架等。再加上出发点就是错误的,失之毫厘谬以千里,离变革成功就越来越远。不难想象,跟王安石变法类似,在实施过程中为了追求规模化的效率指标,往往忽视内功修炼。

笔者刚经历的一个实际案例,某家全球性企业正在实施SAFe,总部请了一名资深的SAFe教练,飞到该公司各个地区负责实施和辅导。当我们作为一线敏捷教练后续进入对中国区团队实施辅导时,某个团队Scrum Master(SM)有一天问我,Sprint长度是不是必须两周?因为他们团队之前一直是三周一个Sprint。我当时很奇怪,问他为什么这么问?他回答说来自Global的教练说了,Sprint必须两周,要不然就不对。我当时听到觉得很震惊,竟然僵化到如此程度!作为一线的SM有此疑惑竟然得不到有说服力的答疑,那么执行过程中僵化就在所难免。

3. 忽视人才和生机型文化,一旦推进不力,一夜回到解放前

当变革推进不力时,反对派的反扑就来了,一夜回到解放前的实际案例不胜枚举。再加上大公司的组织结构重组(re-org)是经常的事,如果支持者不在其位,那么围绕其建立的变革实施人员的动力就会大打折扣。前面提到的大型外资银行的例子,之所以敏捷转型实施一年多以后就没有继续,其中一个很大的原因是全球的高管团队进行了更换,新上任的CXO们并没有认为敏捷转型有价值,所以放弃了之前转型带来的初步成果。更重要的是,在过去一年多的转型过程中,大部分精力并没有放到转型人才的持续培养上,所以当高管团队决定不再投资外部教练,内部的转型力量也没有跟上,变革也就不了了之。

所以,SAFe的蓝图和实施路线图看似很完美,但如同“王安石变法”,注定难以成功。

四、敏捷的规模化落地,如何破?

敏捷的规模化落地,本质是个Complex问题(Cynefin模型)。规模化敏捷框架的最大问题是将一个Complex领域的问题当成Complicated或者Simple领域问题来处理。一个多目标问题,其实是没有Good或Best practices的,唯一有指导意义的是一些价值观和基本原则。对待Complex领域问题,要采取探索-感知-响应模式,快速探索,感知问题的存在,采取行动响应,然后及时调整,对应问题的实践在这个过程中则会涌现出来,而不应该按照一个框架蓝图就开始配置实施。

比如前面提到的BBVA的案例:

  1. 远大愿景:基于对行业趋势的判断,BBVA清楚地认识到,客户的地位在提升,监管的要求趋严,新技术的涌现让银行业面临着前所未有的竞争。BBVA开始以增强与客户的关系作为愿景的转型之路,战略目标定位为成为“数字化时代最好的银行”。而且,基于此愿景制定了6大优先级战略引领集团转型,涵盖了客户体验新标准、驱动数字销售、新商业模式等。所以可见,他们要平衡的是一个多目标系统,既包含用户也包含技术与商业模式等。
  2. 快速行动:BBVA采用实验与学习的方法,将员工、高校研究机构、创新机构、BBVA创新中心、BBVA创业公司比赛、Innova黑客马拉松挑战赛、BBVABeta测试器、BBVA风投以及收购和合作伙伴融入整个创新生态圈,通过各种方式将最新成果快速应用于为客户创造价值,为企业创造收入。
  3. 及时调整:BBVA认为企业应先设立其创新计划并随时准备根据变化对其进行调整,而非盲目的执着于最初计划。比如BBVA的创新项目选择非常灵活,设立指导委员会并根据优先级选择项目,灵活的预算编制以及敏捷的实施,在实施过程中学习,及时调整并探索。

所以,变革成功的哲学是要有一个远大的愿景 —— Think Big;赶紧行动,摸着石头感知河水的深浅、流速,找到可以过河的方案 —— Start Small;根据实验结果,持续学习并改进 —— Learn Fast。

总结

当我们要在一家企业推动敏捷时,首先它是一个活力型变革,多目标问题,而且是一个Complex领域问题,这不是靠套用一种 “规模化敏捷” 框架就能解决的。不要忘记敏捷的初衷,切忌把规模化本身当成目标。当我们忘记“蓝图”,把握“Think BIg, Start Small, Learn Fast”这样的基本原则,更容易找到适合特定企业、组织的敏捷实施方式,比如肖然在《忘记“规模化敏捷”》里所说的“建立持续改进的内部力量、系统思考整个开发过程,以及为创新建立安全试错环境”等。


更多精彩商业洞见,请关注微信公众号:ThoughtWorks商业洞见

Share

忘记“规模化敏捷”

[摘要]

虽然敏捷软件开发理念已为业界普遍接受,但敏捷的大规模落地应用仍然是一个非常大的挑战。敏捷开发模式的标准化是规模化应用的一个重要前提,很多组织和企业都已经在开展这方面的工作。市场的需求也催生出了如SAFe、LeSS这样的“规模化敏捷”框架,但本质上,规模化敏捷是一个伪命题,这样的“标准化”并没有帮助我们解决落地时的两个核心问题:即面向市场和商业模式变化的业务科技合作,及云时代的企业科技架构。

当然如果你仍然认为敏捷的框架体系是最重要的,可能获取一个“敏捷国际认证”对你来说也是关键的,点击这里便可一键获取!

目录


  1. 敏捷走向生命周期的尽头
  2. 软件开发标准化的伤害
  3. 不忘敏捷初心
  4. 下一个“敏捷”长啥样?
  5. 敏捷的规模化落地

敏捷(Agile)是2001年由17位资深软件领域专家们一起发起的针对软件开发工作价值观的倡议。作为一种软件开发理念,与之伴随出现了很多实践框架和方法,如Scrum、Kanban和XP。而这些方法目前已经逐步成为了我们软件开发的事实标准,类似持续集成(Continuous Integration)这样10年前,被大家认为是“极限”的方法,现在也已经成了开发团队的一个标配。

值得一提的是很多开发组织里敏捷的大规模应用仍然是一个非常有挑战性的任务。软件自身的多样性和这个行业的高速发展,造成了敏捷方法落地的种种挑战。在过去10年时间里,我自己在这方面的咨询辅导工作或多或少跟适配团队和实践有关。相信在下一个10年,我们还需要持续去解决敏捷开发落地的问题。

市场的需求当然也催生出了一些所谓“规模化敏捷”框架,如SAFe和LeSS。很多需要解决敏捷大规模应用的组织,于是感觉有了框架和标准。也有很多企业,询问我支持什么样的规模化敏捷框架。

希望通过本文总结一下这两年来我持续表达的观点:规模化敏捷是一个伪命题!所谓伪命题就是不要为一个不存在的问题,去寻找一把看似精美的战斧——敏捷这把锤子,遇到组织级灭霸,可能不好使了。

敏捷正走向生命周期的尽头

说这句话的时候我自己也带着一些伤感, 这里并非是想哗众取宠地呐喊一句 “敏捷已死”。敏捷作为一种开发理念,已经成为了现代软件开发的基础。然而,软件开发作为接下来这个数字化时代的基建行业,仍然有很多超越当年敏捷所谈及的事务。从时下爆款的区块链,我们就可以看到完全不一样的“开发团队”——形象代言人和挖矿小分队,都成为了这个开发团队里必不可少的成员。

什么标志着敏捷走向了生命周期的尽头?为什么不是持续演进成为敏捷2.0呢?

咨询行业对理念和方法的生命周期是有着最快感知和反馈的(如下图所示)。一旦一个理念和方法成为了事实标准,那么咨询公司需要做的事情就是体系化总结,通过标准化来帮助目标企业更快落地。一个我们都知道的案例,就是华为在IBM的帮助下,在上个世纪成功规模化应用了IPD。但即使有了华为这样的成功案例,IPD在后续中国企业落地时也是普遍失败的,原因是下一代的方法显然已经显现出了更大的优势。IPD有着完整的流程、方法和实践定义,当年的敏捷相比之下是混乱之极的,但仍然不可阻挡一波拥抱敏捷精神的互联网企业快速崛起。

​ (图示:开发方法随着行业成熟度提升而经历的生命周期。一种方法的成熟某种意义上只是为下一次创新做准备。当突变发生时,新方法将超越现行的主流方法,形成新的生命周期。)

当下的敏捷是何其相似!各大咨询公司蜂拥而至,都开始了“敏捷咨询”,资深的敏捷专家们开始总结大而全的框架,生怕遗漏了任何一个时髦概念——“价值流”大家都谈就加一个,“DevOps”火就先放里面。当你艳羡框架的完整时,往往需要警惕这个框架的时代价值,别忘了你做敏捷的初衷是什么?

在这个问题上,我在ThoughtWorks曾经纠结了好多年,每次有“写框架、卖咨询”的冲动时,都先后被老马(Martin Fowler)和Jim Highsmith这样的敏捷宣言签署者给拍了回来。确实也要感谢他们,能够站在行业发展的角度Let Agile Go。

早在10年前,华为给我的命题是:用敏捷开发改造IPD。记得我们最后“成功”把大家痛恨的“软需”改造成了用户故事(User Story),并构建起来了一条嵌入式系统的持续集成流水线。虽然现在看来,那是多么简单的任务,但当时大家还是激动地出了一本“葵花宝典”,记录了整个改造过程。听到这个名字大家可能都会笑而不语,XXX之后的IPD还是IPD吗?

同样的事情可能马上就会发生。有一天,中国的BATJ们可能会说:用XXX改造敏捷。我相信这个XXX不会是敏捷2.0,而我不希望成为那个在汇报中必须听到“敏捷改造成功”的管理者(即使团队写了另外一本“葵花宝典”)。

软件开发标准化的伤害

之前总是会顾忌得罪圈子里的老伙伴们,好在很多敏捷圈子的老一代们都已经去了各大知名企业做管理者(侧面印证了敏捷方法的成熟),敏捷顾问又是一波新人,所以今天才写这篇文章。再则最近几次关于AI的研讨和培训,着实让我觉得不能成为敏捷的“遗老遗少”,所以除了自省也希望鞭策更多的人。

企业里的很多管理者会说规模化敏捷框架至少给出了标准,让我们有章可循。很不幸的是这个“标准化”对目前的软件开发是有害的。标准化的基础在软件开发这个行业目前是不存在的,这个行业的基础知识积累还远不能支持有效的标准化,在未来很长一段时间软件开发都会是世界上最大的手工行业(可笑的现实~)。

谈标准化时我们必须跳出自身行业,看看别的成熟行业是怎么成功标准化的。程序员从心底是抵触“码农”这个可能未来的,所以暂且不说建筑行业。咱们看看临床医疗,算是一个标准化程度相当高的产业,但一个豪斯医生这样的天才也需要至少10年的培养,学习各个标准步骤;也没有人会写出《七天学会胆结石移除》或者《心脏起搏器的10种安装》这样的“速成”秘籍。从行业知识积累角度,临床已经是一个成熟的成年人,有着过去四五十代的知识积淀,尚且如此,何况软件开发仍然像个正在探索世界的小孩子,才经历了不超过四代人的知识积淀!

而显然,我们不应该以小孩子探索期得到的经验为依据,就开始进行行业范围大规模的标准化。CMM的失败在于软件学术业觉得软件开发就像算法论证一样,找到了nlog(n)的最佳算法就是普世的。但很可惜底层的运算环境,仍然会从单个冯诺依曼模型变成池化的云,再变成量子计算……

所以,让敏捷完成其历史使命,不要把敏捷标准化成另外一个CMM。软件开发行业需要下一个“敏捷”,下一个基于新知识积累的创新理念和方法!

不忘敏捷初心

当年的敏捷通过宣言的形式发表也是煞费苦心。在我们批判敏捷没有框架、没有标准的时候其实应该感谢17位参与者的克制和包容。我们很容易被自己十多年的经验所蒙蔽双眼,一边告诉别人要持续改进,一边却总认为自己这套是包治百病的。

他们的初心是值得学习的,我们每一代从业者都是在为这个行业的日益成熟积累经验。我经常拿开发和测试同事们开玩笑,“警告”他们未来不是成为“软件开发劳动力”,就是被AI所取代。但实际上软件开发的未来,包括职业的分工,都是一个未知数。持续学习的开放心态和着眼实践经验积累的学习方式,是软件开发在这个历史时代必须的。

另外一个值得提出的初心就是对软件开发“管理”的认知。由于软件开发并没有太多的先验知识,所以管理很多时候是会产生副作用;因为背后的标准并不具备普世性,随着生产工具的进步很快就成了畔脚石。用COBOL主机开发的方式去管理基于JavaScript的前端开发毫无疑问是偏执的。

这对我们的管理者提出了很高的要求,于是有一些企业高管开始要求全体管理者必须上手一线代码实践。当然这些做法都是不得已而为之,管理者的“初心”,是希望大家能深入理解这个年轻而高速发展的行业,直面缺乏标准化的现实,把自己日常的管理工作变成是去持续改进,做一个领导者,而不是所谓标准的监察者。

下一个“敏捷”长啥样?

那么,大家就会问下一个突破在哪里?未来的软件开发是什么样子的?很抱歉没有人可以准确预见发展的趋势,这个问题也可能不是大家目前最关心的。但既然写这个话题,我总还是要分享一些自己的思考,权且留作日后回顾的笑谈。

实际操作层面的标准化

随着老马即将出版的《重构第二版》,我们会发现实际代码层面的评判标准日益成熟。我们早已走过了代码能工作就是好的阶段,即使在过去最混乱的JavaScript领域(重构再版就是基于JavaScript的!)。在软件架构和代码结构方面,我们会逐步看到业界共识的质量标准。这两年基于GitHub等开源平台的兴盛为这个层面的标准化提供了契机。

当然这个层面的标准化也是最有可能被AI应用所颠覆的,毕竟全球最大的“手工业”必然会是AI技术应用最有利可图的行业之一。

行业层面的定制化

云已经是不争的软件开发基础设施,这样的水平切割已经形成了实际意义上的IaaS、PaaS和SaaS的分化。就我个人过去两年体验来说,各层软件在整个软件生命周期定义上还是存在明显差异的。比如构建一个IaaS层的基础服务,较之一个SaaS层的应用服务,在需求管理和发布上线领域就存在着显著不同。

在水平分层的基础上,我们越来越多地感受到了商业领域业务模式不同对软件开发的影响。前一段时间我写了一篇《银行业IT的敏捷转身》引起了行业的广泛关注,其原因就是金融行业在数字化时代越来越依赖软件,而从业人员发现他们的敏捷运用跟其它行业存在着很大不同。

这样的不同存在于方方面面,比如我经常挤兑同事吴雪峰的 “抛弃型演进式架构”,也许在区块链这样的投机领域就是一个真命题。

在一横一纵的行业化背景下,软件开发本身还需要很多的经验积累,短期标准化的必要性不大。对于一些更为传统的产业,在中国也面领着“互联网+”的冲击,存在更多不确定性,尝试着去标准化一个定制的“XXX行业的规模化敏捷”模式,也可能是弊大于利的。

敏捷的规模化落地

希望看到这里你理解了我为什么说 “规模化敏捷” 是一个伪命题。当大家在热议HBR关于敏捷的话题,认为敏捷就是真理的时候,需要理解我们现在的挑战是如何在一个大型开发组织里落地敏捷。而这个落地,不是靠套用一种 “规模化敏捷” 框架就能解决的。目前看,有这么三件事情是必须做的:

1. 建立持续改进的内部力量

这是软件开发组织最重要的管理举措(没有之一)。在行业缺乏足够先验知识积淀的今天,作为从业者我们能做的,就是让组织持续积累经验,并且具备从经验中学习和改善的能力。如果说我希望参与一项标准化工作,那就是行业里对教练的标准化“定义”,因为我希望帮助整个行业明确这个角色或团队在组织里存在的必要性及重要性。

2. 系统思考整个开发过程

软件开发不存在管理和技术的区分。由于立项、审计等多方面的传统制约因素,很多咨询公司人为地划分了所谓管理咨询和技术咨询,帮助刚开始合作的团队去理解如何落地敏捷。于是有了“只做管理”或“只关注技术”这样的说法。

事实上软件开发和很多工程制造业在这方面的差距是巨大的,即使Scrum这样的简单管理框架在落地时,也是受制于技术架构约束的;我们还没有办法让技术足够标准化,从而不约束管理。自从目睹了有人挥舞Kanban做“纯管理提升”产生的悲惨现场,再有任何团队说“这次只做管理”,我都坚决拒绝。

3. 为创新建立安全试错环境

面对未知最好的方式就是探索,而探索意味着大多数时候都是失败的,毕竟从失败中我们学习到更多知识。很多组织和企业说我们一直在做啊,我们每年都会有创新项目,投资一两个小团队去做。这个数字化时代,软件行业的创新应该是中国改革开放式的,即使不能用“雨后春笋”这样的形容词,也应该是全员参与的。已经有很多的案例告诉大家为什么隔离出来一两个小团队“专职”创新是不可行的了。规模化创新意味着创新不仅仅是IT的事情,是组织各个部门、各个角色共同的愿景;也意味着我们承认创新是一个不停试错的领域,从错误中我们提升成功的可能(让统计学发挥作用)。

所以虽然我反对“规模化敏捷”,但我却站队了“规模化创新”!

最后,让我们摆正心态,让敏捷成为软件开发历史进程中的一块儿重要垫脚石;让我们持续探索,为软件开发领域的知识累积添砖加瓦,并共同期待新一代创新理念和方法的诞生!


更多精彩洞见,请关注微信公众号:ThoughtWorks商业洞见

Share