挑战者银行的逻辑

[摘要]

自2009年始,欧美银行业出现了大量的挑战者银行(Challenger Bank)。它们改变了消费者对银行的认知和交互行为,并撬动传统银行机构进行数字转型,挑战者是如何发起挑战?被挑战者又是如何应对?当传统银行优势消弭,未来的银行路在何方?


2009年,30岁的澳大利亚青年Josh Reich在给投资人第一份提案的首页上写道「银行靠着让客户更糊涂挣钱」,而后他以「Simple」为名建立了堪称第一家的纯数字银行;次年,64岁美国人Vernon Hill在伦敦开张了Metro Bank 。上一次有店面的零售银行(High Street Bank)在英国开张还要追溯到100年前。这位靠连锁快餐店发家的美国大亨,面对媒体反复提到:「我们是一家零售商,只是恰好做银行而已」。这两位离经叛道者开启了挑战者银行(Challenger Bank)的序幕,越来越多数字和金融行业的从业者开始思考或行动,如何挑战甚至颠覆这个千年的古老行业。

(上一次有店面银行的开张要追溯到100年前,MetroBank是100年来的第一家)

银行的传统优势被撬动

挑战者撬动的正是,传统银行业的三大优势,它们是:

  1. 政策保护带来的行业准入门槛;
  2. 坐拥庞大的金融市场供需数据带来的信息不对称优势;
  3. 极低的客户流失率带来的极高获客成本。

首先,欧洲货币一体化的进程触发了对欧洲金融体系的重新塑造,从PSD1到PSD2再到「开放银行」的政策布局,显示着欧洲一体化的设计者对欧洲金融业僵化体制改造的决心,加上民粹主义抬头加深大众对于金融精英阶层的天然敌意,欧洲银行业经历着一个极具变化性的政策环境。

其次,专享客户数据、就能为客户提供独一无二的金融解决方案,这一银行长久以来的经营逻辑,正在被10年来崛起的互联网巨头以及获其背书的数字颠覆者打破,数据和人工智能的发展使得不需要全面的独享数据也可以提供精准的金融解决方案;同时,传统依靠信息垄断获得独享利润,在消费者中还落得一个「作恶」的名头。

最后,传统银行的极高客户粘性,其根本在于集中的服务提供者、繁琐的过程、传统的信任观念,极高的替代成本也推高了获客成本,对大银行而言,一个新客户的获客成本可能在1500至2500美元间,较高获客成本也为银行业获得了天然的门槛。而随着服务提供者的增多,更加便捷的过程、信任观念的改变使得新入市场的服务商可以通过更低廉的价格获客,再加上新互联网时代的病毒式营销方式,依靠高获客成本守住行业利润将会越来越难。

因此,当政策不再成为保护者反而成为塑造者、依靠信息不对称获利既难以实现也不道德的情况下,获客成本可能大幅下降,银行业可能面临前所未有的变化。

在这一背景下,近十年的时间里,银行业在国际范围内发生了一系列有趣的变化:

挑战者银行崛起

在Josh Reich之后,特别是2009年以后的英国,出现了大量挑战者银行。

欧洲传统银行成本收入比(Cost-to-income Ratio)维持在64%,因复杂度更低的IT系统、更加简单的产品组合(相对的合规要求降低)、和更低租金,使得一个纯数字的小型挑战者银行的成本收入比可能达到48.5%,这也成为挑战者银行创业者的基本逻辑——尽可能低降低业务的复杂度,以换取更低的IT和运营成本

考虑到传统银行业极高的获客成本,挑战者银行通常从对金融需求更短期和及时、更容易接受新服务的年轻消费者开始,并选择更加频繁、门槛更低的金融场景,例如:短期借贷款、信用卡、日常支出管理、支付、小额存款等。

针对这些轻量级的金融场景,挑战者银行们更是利用病毒营销,在短时间内积累大量的客户,然后依此从监管者手中获得更全面的银行业务执照。在法规允许的范围内,开辟更多挑战现状的金融产品,要么承担更大的运营风险,要么提供更高额的客户回报,本质都是用较低的运营成本换取客户量

当业务模式和客户量趋于稳定,挑战者银行通常面临两个选择,其一为被传统大银行收购,成为其数字战略的重要部分;其二为获得金融机构或互联网巨头的注资,开始独立的国际化进程,期待演进成全新的银行业态,保持颠覆者成色。

概括来说,以下逻辑支撑着以欧洲为主的挑战者银行们崛起和演进:

  1. 以纯数字银行开始,以获得更低的运营成本;
  2. 专注年轻客群,以信息集成者或中间人的身份快速获得客户;
  3. 通过积累的客户量,从监管者手中获得银行业务执照;
  4. 用低运营成本交换更高回报的金融产品大规模获得客户;
  5. 逐渐建立稳定的金融业务,开始选择性并入传统大银行、或考虑多市场拓展。

2014年2月,数字银行领域的明星Simple以1.17亿美元的价格加入欧洲银行巨头BBVA,这间成立于2009年的纯数字银行在成立仅仅五年后选择加入已经有150年历史的BBVA,既显示出大部分以Simple为代表的挑战者对规模化的无奈,也揭示出传统银行业不甘被颠覆的决心。

事实上,直到2016年底,BBVA在美国的业务Compass才完成了与Simple系统的整合——经过近三年后,BBVA在北美的Simple客户才可以真正并入其业务系统中。而保证其能够顺利完成Simple和Compass的系统集成的基础来自于2016年初开始的对OpenAPI平台的投入。

(过去10多年来,在欧美,从单纯的银行线上渠道,到无数挑战者银行以颠覆的姿态出现)

传统银行的数字转型

挑战者银行并未对传统银行业产生系统性的颠覆,但其对消费者行为的重新塑造确实触发了传统银行大规模的重构,其转型策略有如下三个阶段:

  1. 抱持开放的心态,持续不断进行遗留系统改造,建设中台能力,培育金融基础设施的建设能力;
  2. 对金融生态的基础设施进行投资,通过合作网络降低获客成本,同时倒逼核心银行系统演进;
  3. 孵化全新的业务组合和渠道,并开始寻找新的商业模式。

以BBVA数字转型的进程为例,「开放」从数字转型的一开始就成为其核心关键字,2016年2月,BBVA宣布上线其在后来有深远意义的Open API平台,为互联网金融创业公司提供API接口,最初开放的四个中台能力接口包括:

  1. PayStates:聚合BBVA卡支付信息方便第三方数据分析或商业情报;
  2. Connect:为第三方应用授权访问BBVA服务;
  3. Accounts:为第三方应用授权访问BBVA账户信息;
  4. Card:为电商网站绑定BBVA支付方式。

(BBVA的API市场,为金融创新者提供身份验证、转账、存款账户、以及多卡管理的标准能力)

在OpenAPI平台建设的同时,BBVA继续投资技术基础设施,例如:2016年5月,BBVA宣布与Red Hat合作,在IaaS(Infrastructure-as-a-Service )、PaaS(Platform-as-a-Service)、以及云管理平台等领域进行深入合作;10月,BBVA宣布与Amazon Web Services合作,以获得处理每天5亿4200万笔交易的云计算能力。

更加现代和健壮的基础设施,使得BBVA能够更容易接入外部合作伙伴或内部的独立业务,形成规模效应的同时减低运营成本——2016年11月,BBVA与CRM领域巨头Salesforce合作,在西班牙完美实现全手机开户;同时西班牙银行业务系统的现代化帮助其完成北美Compass业务和Simple的整合。

以云和数据技术为依托的基础设施,也使得BBVA有能力引入完成收购或整合更多的解决方案或产品,甚至孵化出全新的业务模式。

2016年底,BBVA继续向英国移动银行Atom追加投资,结合自有数据和开放能力,成为在2018年前具备交付开放银行能力的欧洲少数金融机构之一。

其旗下的投资机构Propel Venture Partners管理着17家不同类型创业公司的股份,类型覆盖区块链、数字签名、保险、理财、员工福利等,为BBVA提供技术、客户体验、和解决方案的可能性。

(BBVA旗下投资管理平台所管理的解决方案)

在业务创新领域,BBVA已经开始探索将数据作为企业服务的新模式——2016年11月,「Commerce 360」上线,为中小型企业提供交易(来源于丰富的POS数据)分析能力。

(BBVA的企业交易信息分析业务)

2018年底,BBVA十个主要市场国家中的6个都以实现「数字化拐点」——超过50%的客户交互在数字渠道上完成,这间150年历史的西班牙银行正在有条不紊地进行其数字化演进。

银行的未来

纵观欧美银行业过去10年的发展,前五年挑战者银行蓬勃兴起、后五年传统银行大规模转型,挑战者更多是催化剂而非颠覆者,我们最终迎来怎样一个银行的未来?

讨论银行未来的角度,是先假设一个极端的场景,当现有银行所有的竞争优势荡然无存,那么谁建立了全新的竞争优势,谁就建立了未来的银行。

如果监管者的目标是为了建立更加持续的金融体系,而非稳定现有金融体系,那么谁能够帮助监管者打造这一目标,谁就获得了新的竞争优势;

如果利润来自于与客户的金融共赢,而信息不对称不再可能获得利润,那么谁能够帮助客户在每一个金融场景下获得成功,谁就获得了新的竞争优势;

如果高获客成本变得极低,而银行难以依靠垄断客户获得利润,那么谁能不断发现新的价值点,通过规模效应和生态系统获益,谁就获得了新的竞争优势。

那么未来银行的佼佼者多半拥有以下特点:

  1. 她一定能够更快地响应政策的变化,甚至参与和引导监管者的决策
  2. 她一定不再主要从信息不对称中获得利润,而成为跨行业金融场景的服务提供商,从交易双方的金融成功中获利;
  3. 她一定坦然面对获客成本和客户忠诚的持续下降,不断建立新的价值链,在更广阔的金融生态中保持独特的竞争优势。
Share

十年来我所经历的技术碎片,你的呢?

时间回退十年,我还在职业中的第二家雇主——IBM CSDL。虽然不能完全记清楚每个工作的细节,但从现在看来,不管是当时的行业形态,还是工作环境,都跟十年后的今天不可同日而语。那时,微信恐怕都还在策划中吧(事实上2011年才推出),朋友同事间的沟通,更多是依靠那个叫MSN的聊天工具,自然如今它也没了踪影。

作为一直晃荡在这个行业的从业者,我也有趣地看到这十年来,我所接触的工具和技术上的变化,有见地的深层理解无从谈起,权当是对一些碎片的记忆吧。

工作协同的系统是企业内不可或缺的部分,Lotus Notes在十年前虽然已经进入陈暮晚年,但仍然是IBM以及它的客户组织所依赖的协同系统,邮件,存档,甚至一些复杂的自动化流程,都会基于那个沉重的文档数据库(自然不是后来出现NoSQL文档数据库)展开。

我清晰地记得,当时作为QA的我,每天都不得不打开数据库服务器位于加拿大的测试案例库,然后切换到另外的待测系统界面,运行测试,然后再把测试结果一一记录到数据库中,在此期间我有相当的视角,只能盯着保存中的沙漏,以及那个标记了远端服务器地址的图标,它对我来说是个陌生的异域名字,但仅此而已,唯一能做的就是长时间的等待,直到几十秒钟后,它告诉我保存成功。

在我进入ThoughtWorks时,已经是Google Suite的天下(事实上ThoughtWorks也曾经是使用Lotus Notes的,你能想象那些ThoughtWorker怎样在谩骂中忍受?),即使没有条件的公司,也会逐渐享受到一些本土化的系统产品的优待,如日中天的钉钉自不必说,企业QQ,企业微信,Worktile,Teambition,Slack这些工具或平台,都在尝试无缝的链接企业和员工之间的工作流程和信息连通,以期求在效率上和数据共享上达到前所未有的高度。

在我从QA转向Dev之后,另外两个技术在这十年间的变迁,对我来说印象同样深刻不已。

一是前端技术。如今虽然已经有了现象级甚至垄断的框架——Angular、Vue和React,但在十年前,我们明显看到的是前端技术方兴未艾,百家争鸣。借着AJAX概念的提出,智慧的开发者在短短几年内发明不同的工具框架,你追我赶,各领风骚。IBM是Dojo.js的Sponsor,jQuery则是社区的宠儿,后来微软加入对其官方的支持,ExtJs则是独立的一方存在,作为具有优雅而丰富的UI类库的代表。其他还有很多,ThoughtWorks早期员工陈金洲的Buffalo以及OPOA(One Page One Application)也是在那期间出现。

这些十年前的竞争者们,以新鲜的视角,把企业以及开发者的目标聚焦在前端这个领域,当然是应了中国互联网的发展。关注用户体验,尊重标准是那个时期时髦的关键词。而今现象级的框架,则更像是把开发的理念做了影响深远的革新,大幅度提升了开发者的体验。

第二个就是虚拟化和云技术。我记得不到十年前,IBM还在实验室里尝试用虚拟化技术帮助创建大规模(性能)测试所需要的机器资源(事实上ThoughtWorks也做出过类似尝试),业界还在争论公有云的安全问题而更看好私有云,以及评价云服务提供商应该是IBM和微软更能胜出,是因为只有它们两家公司做到了从基础设施硬件,到操作系统,数据库,到应用软件一应俱全,更容易提供完备的SaaS,PaaS,XaaS。

而今天看来,结果怎样已经是不言自明,Amazon的AWS和IaaS一家独大了。当然更重要的是,Amazon做到了对开发人员体验的关注和尊重,开发体验远远胜过其他厂商。我们很容易看到,至少现在不尊重开发人员体验的第三方服务提供商的赢面没有那么大。

很难想象,这十年会是我所经历的。技术的剧烈变迁,一如时代的变迁,超出了大多数人的认知。很难讲清楚技术和时代之间谁影响了谁,但就十年而言,我们多少可以看出一些印记,以及理清一些脉络,比如固守技术投资的企业多半会逐渐失去市场竞争的态势,比如对外部技术跃迁的无视多少是体现了企业内臃肿的组织结构和随处可见的官僚气味,比如开发者体验这个毋庸置疑的已经既定的存在。

作为个人,我也很庆幸,在这十年间,即使不是亲身经历,也是耳闻目睹了这些技术上的变化,相比较新进入这个行业的人来说,我也许更能明白从历史纸背透过来的必然性,以及在面对又一新鲜炫目的技术变化时,以更快的速度理解它,以及它可能的命运。

就今天而言,即使在开发者的世界,分工的细致化已经势不可挡,全栈即便不是奢望,也需要时间的沉淀,当越来越多的人止步于好用,够用,会用,是不是就足以理解要解决的问题,并且可以完美的解决,我抱有怀疑。

当然,更进一步,我觉得永远都不会错的,就是每个开发者都不应该局限于用最新最酷口碑最好的技术来解决所有遇到的问题,满足于尝鲜和随波逐流,毕竟,问题才是最重要的。


亲临现场聆听Martin Fowler、Neal Ford、Rebecca Parsons等国际软件巨匠的十年回顾。现在购票可享最后五天七折优惠!

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

Share

从架构可视化入门到抽象坏味道

抽象的坏味道

上文说过,C4说穿了就是几个东西:关系-线、元素-方块和角色(角色不过是图形不同的方块)、关系表述-线上的文字、元素的描述-方块里的文字,虚线框(如前文所说,在C4里面虚线框的表达力被极大的限制了)。

这些东西一点都不新,我们自己随便找个白板,无非也是用这几个东西来表达架构,它的优点在于引进了一些分层,帮助我们理清思路、也有利于可视化给别人看。

换言之,C4不能帮你做好架构设计,但是它能暴露出你设计中的问题,以便于被自己或其他人纠正。

可视化的威力就在这里,但根据我的经验,即便你用上了C4也不见得就能表达清楚,不过好消息是,我们终于可以聊一些高级的表达问题了。

可视化之后,我们能看到自己的表达问题,大概的问题有两个:抽象层次和抽象粒度。这个是表达方面永恒的问题,也就是软件设计永恒的问题,没有万灵丹,但是用上了可视化手段之后还是有机会让生活更美好一点的。

这两个问题可能太抽象了,不容易意识到,那我们可以看图,从图上的具体表现来发现坏味道。一般会有几个迹象表明我们有可视化的坏味道:

  1. 一张图上过分密密麻麻的线
  2. 一张图上太过多元素(也就是方块)
  3. 一张图上太少的元素,比如角色特别少
  4. 每个图上文字表达不契合,有的太泛泛,有的太细节
  5. 无限制的画更多张图,基本上也就失去了使用图形化表达的意义

那么对应的手段就有:

合成更大的元素

当我们意识到有密密麻麻的线、太多的元素,闻到这个味道的时候,可以考虑是不是该把里面的一些元素合成更大的元素了。Component可以合成Container,Container可以合成System,这样就会分成更多的图,每张图就变得没那么多线和元素了。

紧接着会面临下一个问题:怎么合成一个更大的系统,Container是明确的,所以Component合成Container不是问题,问题是Container怎么合成一个系统,为什么是这些Container合成这个系统,而不是另外几个?或者多加几个、减几个?

这个问题没有标准答案,但是有一些其他的框架可以提供一些思考的维度。

比如可以结合akf扩展立方来思考。

(akf扩展立方)

X轴就比较容易,一方面从容器本身的描述来看设计上是不是支持横向复制的,另一方面则是看部署图。

Z轴相对难一些,只是比较偏技术。比如当技术上有性能瓶颈,则需要注意这一个维度,有时不得不搞出一些特殊的容器出来,有时已经存在这些容器了,他们可能单独属于一个系统(类似于大数据分析的系统),或者一个系统的某一个局部(这就是前面提到的虚线框表达力被限制的地方)。

Y轴给人的感觉是最容易操作的,但实际上却是最难做好的,Y轴的背后是业务,往往我们觉得就按业务切成多张图就好了。这种想法就表现出我们往往意识不到业务的真正难度,于是总在这里出问题。如果你能跨过这个心理障碍,决定去认真做一下,那么也有一些工具可以帮助我们做好。

(领域模型与架构设计)

最经典的工具组合就是求助于DDD,结合康威定律和步速,考虑维护的团队、使用的角色、变化的节奏,这块展开就复杂了,有机会再聊。

这里说一个最简单的做法:按照用户角色分。同一种角色,由于其在公司里的职能、职责都是已经被定好的,天然在系统上就有一种隔离性。比如招聘专员、会计、出纳,他们使用的系统肯定是不一样。

但说简单,其实也不简单。我见过一些图,上面的角色只有两个,内部用户和外部用户。而另一些图,细化到了个人的级别,或者把职级都放上去了。所以无论再简单的原则,最后都会掉进抽象的坑。

画一些共识图来忽略掉一些通用的元素

有时候合成了更大的元素,元素依然很多,线条依然很密。画多张图也不够切分的。这个时候我们可以求助于共识。

人与人交流,如果已经有一些共识存在就可以少废很多话,共识多到一定程度只需要确认一个眼神就完成交流了。所以毫无疑问,做好共识管理,可以大幅简化我们的架构图。

所以在我们做架构可视化的时候,经常会先画一个技术共识图,比如以一个能力建设的数字平台为例,我们就画了一个下面这样的技术共识图:

(技术共识图)

在后面画具体的图时,就可以省略掉一些共识的元素,像nginx和数据库就没有了,可以更关注在业务上,而不是技术上。

通过制定主题,限制文字的抽象层次

其实上面的技术共识图就是类似的做法,只是用于技术方面,如果用于业务方面,我们可以用一些抽象的名词或动词来代替一类业务,比如下图:

(数字平台系统景观图)

上图是一个系统景观图。当前这个主题是希望人们能一眼看清楚这个系统里面的相关角色都在使用什么系统,他们关注什么,职责是什么。至于具体学什么,怎么学的,都不是那么重要。所以我们就用学习一词代表了一系列的业务。

当主题确定的时候,很多纷杂的信息就没有了。一定要克制住自己试图在一张图上表达足够多信息的冲动。

只画重要的图,剩下的交流的时候再画

除了像上面说的,不要试图在一张图上给他足够的信息。同时也不要试图把所有的信息都表达出来。

绝大多数的图可能只在交流具体业务的时候才画,推荐使用动态图。

总结

即便有了C4这么,好用的可视化工具。我们依然会看到,自己会掉进抽象的坑。所以在使用的时候一定要注意坏味道,经常自查是不是犯了抽象层次和抽象力度的错,才能做好可视化。这件事上,没有谁能幸免,所以要时常自省,与诸君共勉。


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

Share

ThoughtWorks 专业服务的演进

在前面的一篇文章《ThoughtWorks的Professional Service (专业服务)模式是否面临颠覆?》,我们分析了ThoughtWorks的专业服务将面临的冲击。企业服务领域正面临着向高度标准化和高度定制化两极分化的趋势。基于云的平台和应用服务,不仅大幅减少了基础设施部署、维护和升级的工作量,还将大幅减少应用软件的升级、移植、转型遗留系统的工作,因此可标准化的服务将更多以SAAS的形式提供。另一方面,以数字化为名,技术驱动的商业变革,让高度定制的技术服务在企业的项目频谱上占据更高份额。这两个趋势所压榨的空间,就是原来属于传统的大型商业软件套件和低端IT服务的空间。ThoughtWorks最近几年的发展在某种程度上印证了后者。

如果我们追求的是高度定制化的市场,并且希望占据战略价值的制高点,就需要在ThoughtWorks的深度和广度上持续扩展。说到战略价值,总会让人想起McKinsey的管理战略咨询和埃森哲的技术战略咨询。不过根据FORRESTER的报告,单纯的战略咨询工作正在减少。在这个不确定的世界里,企业缺乏耐心去启动一个长期、昂贵而结果难料、价值难测的大型项目。相反,通过长期愿景下的一系列短周期项目创造可预见的增量价值,会是更加常见的模式。

这个趋势正好跟ThoughtWorks一直秉持的敏捷理念一致。在软件交付和自身运营中多年的实践,让我们的各项服务都自带敏捷属性,在这个趋势中占据了先发优势。就好像黄博士正在推出的超越预算(Beyond Budgeting)相关服务,其背后思想跟精益非常一致,推动以财务为代表的运营适应VUCA(Volatile,Uncertain,Complex,Ambiguous)的环境。我们的设计师和咨询师们秉持这一理念,创建和演进出各种设计、业务和工程技术的方法。

除此之外,变革管理越来越重要。跨界的竞争对手,快速的技术和业务变化,给团队留下的改变时间很短。伴随着企业需要更多更快的引入、验证和发展新技术、新业务,非正式,随时发生增量组织变革占据了越来越多的比重。这要求咨询公司不仅仅能够转移技能,也能够转移胜任力,不仅仅设计组织和流程,还要注入和增强文化。这种变革是针对客户,也是针对我们自己的团队,考验着我们的学习能力和走出舒适区的勇气。

跟以往相比,战略咨询将越来越多地跟实施融合在一起。相对于协调两家各有所长的公司分别承担这两项工作,客户更愿意看到一个具有跨界能力的公司总体负责战略和实施。具体的工作任务则由这个战略合作伙伴根据优势选择自己或第三方服务团队提供。以前选择这个整合者的天平倾向于管理咨询公司,当前数字化的趋势则将更多的话语权交给了兼具技术和设计能力的组织。

ThoughtWorks已经定义了自己在战略层面的战场 – 技术驱动的商业变革。在当前这个时代背景下,我们会关注业务优化、消费者服务体验、产品创新和商业模式演进这些领域,寻求创造客户价值的机会。在2016年,传统汽车厂商面临着百度、乐视、特斯拉这些跨界者的挑战,同时,在传统汽车市场的格局中,由于车厂跟4S店之间的博弈关系,使得车厂无法有效获取和利用客户的全生命周期数据,因此在业务模式上受到严苛的约束。

过去几年的主动拓展已经使我们初步形成了价值主张、战略、能力、资产和服务五层布局。对外的表现是咨询、交付、DPES和产品/解决方案四个业务模式,并且开始逐渐积累一些轻量级资产。

在这个图里,我们在很多点上都还有着显著的薄弱环节。在上方战略层,我们很多时候缺乏能力快速切入客户上下文,勾勒完整图景。具体就表现在跟客户高层的对话中,无法跟随客户的思路和话题,提供有价值的意见,甚至问不出切到点上的问题。下方资产层的积累一直是ThoughtWorks的短板。

客户对服务的期望是更加敏捷。在高度定制化的同时,要求更快地响应,并支持持续的改变。在这种情况下,如果什么都从零开始,显然会很累。未来可重用资产在服务中将比现在占据更高的比重。组织需要不断算法化并演进其知识和能力,沉淀为资产。资产的形式可能是方法学和知识体系,或是轻量级、可灵活装配的软件组件,又可能是组件化的案例和实践文档。不过资产的建设也需要把握个尺度,我们强调轻量级和快速演进,目的是希望资产不会成为我们创新的包袱。

中间层是我们的各项能力,既是支撑我们价值主张和战略的基础,也是我们资产和服务竞争力的源泉。随着我们不断扩张高价值业务领域,能力的portfolio也在不断扩展。Tech Strategy2.0为我们提示了新能力的方向,但求新的同时,不能忽视我们一直追求的工程卓越,少了这项能力,其它都是无本之木。

最近比较喜欢的文章是哈佛商业周刊里的一篇-《Old Habits Die Hard, But They Do Die》,其中提到,“达成长期稳健发展的公司案例都是能够在包括文化、关系、领导力、战略等稳定性因素和快速动员资源,市场探索实验等动态因素之间取得平衡”。专业服务公司的竞争力是其成员竞争力的综合体现。时代会变迁,我们只要能增强追求卓越、持续改进的文化,对自己的能力保持高的期望,我们就能与时俱进。文化和能力是组织新的基础设施。

MD心声:

我们这样的业务演进对我们的人才结构会带来什么新的要求?对文化会有什么影响?
相对于过去打着一个简单的敏捷标签,能力和服务的丰富反而让我们在市场和社区的识别度下降,如何破?

推荐阅读:

Share

从TechRadar看UI自动化测试的未来

2017年第17期和2018年19期技术雷达中,分别出现了两个新的工具——cypress,testcafe,之前只接触过webdriver框架的同学可能会有些陌生。而cypress已经在最新一期的技术雷达中进入了评估阶段,并在多个项目得到了应用,总体反馈利大于弊。

先来详细的介绍下cypress以及我所在项目使用中踩过的坑,关于testcafe会在另外一篇文章中介绍,testcafe主要是用来做UI的回归测试,以及多浏览器测试,cypress不足之处则是testcafe的长处。

框架理念

虽然我很鄙视这种行为,但也能够理解,毕竟身后有巨大开发团队在支持,各种开销,总得有收入来维持运转,所以它走了很多中国产品的营销策略,即免费使用,然后通过提供增值服务来赚取利益,也印证了一句话:服务即未来。

框架架构

让我们先来看看它没有公布的设计架构。

这是一张来自cypress 架构师画出的所谓架构图,其实等于什么都没说,但是我们还是能够通过蛛丝马迹,找到一些重要的信息点。electron 与termina,driver ,launcher 等玩过Puppeteer的人肯定知道 chrome headless 既可以在命令中直接执行脚本,又可以通过puppeteer调用chrome launcher在页面运行,显示测试运行过程。

然后我们看下 cypress的运行界面。

貌似就是一个chrome浏览器,没错就是经过二次开发后以electron封装出的工具。没猜错的话,它的底层应该是基于chrome remote-interface这个库,通过在其之上开发出专有的自动化api来控制浏览器。这意味着每个所支持的浏览器都需要一个新的driver。这个driver是什么,用chrome的话其实就是chrome headless。当然还有Firefox,尽管Firefox已经公布了headless模式 但是cypress目前还没有支持。

(chrome headless 架构图)

优点

我们了解了架构,再来说说这种架构之上有哪些优点,和webdriver区别又是什么。

最大的优点:快

我们之前使用基于webdriver的各种测试框架,被运行效率折磨的痛不欲生。在用上cypess之后,感受到要起飞的节奏,为什么? 之前我们说过cypress其实就是一个二次开发过的chrome,而且你所写的测试是在浏览器进程中运行的,这也意味Cypress测试直接访问真实的DOM元素,而不是像webdriver一样通过json wire protocol、通过proxy server 转换成各种浏览器driver所能识别的命令,这样来来回回会耗费很多时间,所以cypress设计之初就抛弃了 webdriver这种架构。

第二个优点:异步

Cypress is asynchronous and relies on timeouts to know when to stop waiting on an app to get into the expected state. Timeouts can be configured globally, or on a per-command basis.

这是来自官方的文档,所以我们不用再像webdriver那样去封装等待方法,cypress 所有的操作都已经自带了retry功能,直到到达设置的timeout。

第三个优点:只支持js

很多人会诧异,“什么?这也算优点?难道我不会js是我的错?其实cypress面向的主要对象是前端DEV与QA,cypress的底层与所使用工具都来源于前端,面向的测试也是基于前端,例如api,E2E等。

第四个优点:方便调试

前端工具很多都支持hotload,cypress也贴心的加入修改测试代码自动rerun测试的功能,并且支持代码debug,甚至可以在chrome dev tool中方便的调试,更甚每个步骤的操作都会清晰的在图像界面中展示,还有详尽的log信息在console界面打印,还不够的话,还支持录制回放功能,方便你查看整个流程。

其它优点

类似jquery 或者直接使用jquery是获取操作对象。

Cypress.$("ul li").map(function () {
    return Cypress
    .$(this)
    .text()
}

mock普通的http请求

cy.server()           // enable response stubbing
cy.route({
    method: 'GET',      // Route all GET requests
    url: '/users/*',    // that have a URL that matches '/users/*'
    response: []        // and force the response to be: []
})

以及上面提到的mock graphQL请求

beforeEach(() => {
    cy.server();
    cy.mockGraphql({
        schema,
        endpoint: '/gql'
    });
});

还提供了各种CI工具结合的接口,方便与不同CI集成。

不一一介绍,请看文档

缺点

上面吹了那么多好的地方,也该来黑一波了。

坑一:除了cy对象外的所有操作都是同步的

这就意味着类似以下代码你必须用promise封装,否则将会出现错误永远拿不到正确值,因为Cypress.$其实使用的是jquery对象,方法返回永远都是同步。

getElementsText(selector) {
    return Cypress.$(fxConfig[selector]).map(function () {
                return Cypress.$(this).text()
            })get()))
}

有没有方法解决?有 有 有!

使用cypress-promise这个库 如上述代码在返回最外层使用 promisify()方法,在使用ES7 promise语法 async await 就可以转换成为异步操作。

async getElementsText(selector) {
    return await promisify(Cypress.$(fxConfig[selector]).map(function () {
            return Cypress.$(this).text()
            }).get()))
}

坑二:并发测试

当我们的测试用例越来越多时,我们第一个想到是并发测试,但是这是cypress 收费服务。当你按照以下图做了配置时,高高兴兴的在云端运行时,发现根本没有用,因为你没交钱!

有没有方法解决?有 有 有!

  1. 利用concurrently这个库或者GNU命令起多个进程去执行不同测试文件,从而绕过cypress的限制。
  2. 测试设计层面,利用cucumber的tag 将测试分类,再利用CI 设计不同pipeline 来并发运行不同tag的测试,进而绕开收费限制。

坑三:当元素不存在或者没有找到时,测试会失败

这个坑貌似听起来很正确,但我们想一下这个场景:如果我们希望当某个元素不存在时,需要执行某个操作。但是因为以上默认的实现,没有找到元素,所以会直接报错。

或者某个元素刚开始没有出现,必须将页面滚动到底部,直到全部数据加载完后才出现,也会遇到问题。

有没有方法解决?有 有 有!

利用jquery 查找元素的length是否大于0,然后利用if或while循环进行判断

if (Cypress.$(".show-more-button").length > 0) {
    cy.get('.show-more-button a').click();
}
else{
    do something
}/

肯定有人问:为什么不直接cypress去查这个元素的length对不起 cypress没有这个方法。

坑四:不支持多浏览器测试

对,cypress首席执行官也说了,多浏览器测试也许在未来已经不需要了,因为微软已经放弃IE啦,好了世界都是chrome和webkit的了。

再来谈谈它的云服务

先看看界面吧。

类似继承了一个CI,但是刚才提到收费项目,并发测试,以及 bar chart分析。

再来看看到底怎么收费?

收费也不算高,这在国外也就一顿大餐,但是提供的服务还是有限,期望以后能够提供一些自动化测试结果分析以及预测的功能,或者结合ML,AI实现一部分的自动化混淆测试。

坑还很多,需要慢慢填,记得当初在上一次提及cypress工具后,很多人都说“坑很多慎入”,其实我觉得和webdriver最开始一样,坑也很多,只有不断有人去填坑,这个工具才会有更好的未来,与其慎入,不如来尝试下他的优点,何乐而不为。

未来预见

对于QA而言,JS势必会成为一门必须要掌握的语言。 由于我们大部分项目都是以前端为主,前端方面的知识储备能够帮助QA快速的融入团队技术架构,快速构建适用于项目的自动化架构。 自动化测试平台化离我们越来越近,Webdriver离我们越来越远,像cypress这种打着免费旗子的工具只会越来越多,那么谁提供的服务更好,性价比最高,就将在这场争夺中存活下来。 就像很多公司在做类似于AWS的产品,但市场中占绝对统治地位仍是AWS,还是那句话——服务即未来。

我们并不需要一个大而全的工具,我们需要的是一个能够帮助整个团队提升工作效率与体验的工具,那么目前来说cypress在E2E的测试上是成功的。 所以从现阶段看像webdriver这种效率低下且体验差的工具在软件开发历史长河中终将泯灭,但还是要感谢它在自动化领域做出的巨大贡献。


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

Share