以用户为中心的软件开发

问题

今天这个时代迭代开发已经成为常识,甚至政治正确。随便谁就能给你扯两句mvp。敏捷也从一个开发的,名词变成了管理名词。迭代,测试,反馈,名词满天飞。

人人都在说这些术语,仿佛他们真的就懂怎么做软件了。起码,觉得自己真的懂怎么创新了。然而经不起细聊,一旦深入下去聊一个mvp,聊聊他的迭代计划。就会发现露馅了张嘴闭嘴,谈的都是功能。这个迭代要交付几个功能,这个mvp多了什么功能?他的竞争对手都有哪些功能?却很少听到用户人人都在喊,以用户为中心。口号喊得震天响,但你看他们的行为模式,他们的语言,并没有用户的身影。

我时常觉得这个事情不太对劲。但是也没有想到更好的方法。敏捷中使用的故事卡比功能的视角要好一点。因为在故事卡里,你要写下用户的价值。但是,我一直也不知道这个价值是从哪儿来的。是先开枪后画靶子我们想做某个功能了,所以硬按一些价值的。还是真的存在的,价值的单位应该是什么呢?没有单位的东西就无法管理。无法管理,也就无法优化。我们交付的价值是越来越多吗?还是交付的不如以前了?用什么来判断?

回答不了这些问题,不管输赢都是有点不明不白的。这些问题的核心问题就是价值的单位应该是什么?怎么算一个价值?直到我看了,我们公司设计团队的一个框架MERLIN。又在《创新的窘境》,作者的新书《与运气竞争》里,看到了理论依据。这个问题在我这里才算是告一段落。我明白了,以用户为中心的软件开发大概应该怎么做。

方法核心

如果我们想以用户为中心进行软件开发,那么知行要合一,我们的分析方法应该是围绕着用户展开的。

这个方向倒是不新鲜,我们在inception的时候做用需求分析时我们的方法就是围绕着用户展开的。一个典型的分析过程,如下图所示:

​ 我们会在上面画一条轴,标示出用户旅途。这是用户在使用软件的时候的,他的一个全过程。然后在对应的时间点上,标记出,我们的功能。这样我们的功能就不是平白出来的。每一个都联系了用户价值。在ThoughtWorks,我们可能标记的是用户故事,相对于功能,用户故事,首先就是要写出价值。

但是这个图还是不够给力。首先,从用户旅途上的点,到功能的映射简直是个magic move。并不能很好的传递为什么是这样的一个功能,而不是别的功能?毕竟实现一个用户的价值方法有很多。后续在执行的过程当中,难免会僵化行事。 其次,上面的旅途,还可以再抽象和封装。简言之,旅途本身也应该是有抽象层次的。一个旅途上的一个点,可能也是一段新的旅途。

一个更系统的做法是这样的,首先做服务设计:

​ 系统化的分析用户的行为,过程中与企业有哪些触点,在这些触点上用户“雇佣”企业的产品到底是来做什么的,也就是动机。

然后将这些点再进一步细化,采用故事的模式:

​ 图上的一行会讲一个故事,就像电影分镜或者漫画一样,来表达用户使用的故事,真正的故事,而不是用户故事那种东西,我们叫这个东西故事板。 在故事板上,我们描绘了一个故事,这个故事里,用户获得了一种体验。一个故事对应一个体验。在基本需求都已经得到满足的今天,体验是新的最有价值的事情,以体验为中心才是以用户为中心。故事板恰好给了我们一个非常符合人类认知习惯的方式来描述什么是一个体验。也就回答了开头的问题,什么是价值的单位。

​ ​当我们定义出了价值的单位,就可以从这一单位的价值里面映射出故事卡,来进行开发过程的管理。

​ ​这里就是我们的重点,我们将来交付的软件、交付的服务、我们交付的一个MVP本质上是交付给了用户一组体验。MVP的迭代则应该是更多的体验或某些旧体验的升级(也就是同一个动机,换了一个故事来满足)。

这就是以用户为中心的软件开发的核心。最终我们把用户的价值很好的表达了出来,并且找到了用户体验的基本单位——故事板,由于故事板也可以转化为用户故事,结合早已经存在的敏捷开发方法,也就可以对体验的交付进行度量和管理。达到真正的以用户为中心进行软件开发。


更多精彩洞见,请关注微信公众号:思特沃克

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

银行业如何建立科技生态圈

上周好几个同事和朋友转给了我一篇《麦肯锡重磅报告:银行业如何超越互联网巨头建立生态圈?》。话题很时髦,读后却印象寥寥,好像说的都对,然则没有什么观点是真正触及问题深度的。于是把这两年自己跟各家银行合作过程中形成的“执念”记录下来,抛砖引玉。

牵手BATJ,是合作还是心猿意马?

在国家的美好期待和祝福下,四大行从去年开始正式牵手互联网巨头。作为科技侧的顾问,这本身是一个利好消息,业务终于得向科技看了,老大难的协作问题终于有希望提上战略议事日程了,毕竟业务和科技总得融合吧!

当然时至今日,这个利好消息并没有变现,拿得出手的合作案例一个没有。问各大行的科技人员,充满了对互联网巨头们的失望;再问BATJ的前同事们,纷纷表示国企搞不定,流程长规矩多。究其原因,如果简单用银行需要从“霸气的主导者”,转变成“聪明的参与者”来形容未免就太过于草率了。

不可否认银行和互联网巨头有着巨大的文化差异,银行业的强风险管控和互联网的快速试错,驱动出了两种业态。是什么让国家都觉得这两种业态需要合作呢?答案显然是数字化。未来的金融服务必然需要依靠数字化技术和渠道,而互联网企业拥有更强大的数字化能力。中国移动支付被这几家互联网巨头雄霸就是最好的案例。

然而看似合理的联姻背后却是两种业态的碰撞。这几家互联网巨头已经各自演变成了平台企业,某种程度上的领域寡头,比如腾讯的社交、京东和阿里的电商、百度的搜索。平台战略是一种经典的商业模式,成为寡头是保证盈利的核心策略之一,比如现在的滴滴。在这个数字化时代,这些巨头们都在想什么呢?答案也是比较明确的,希望自己成为一家科技企业,好像Google和Facebook,能够利用强大的技术力量进入(甚至于创造)新的领域,因为老平台总有一天会被新平台取代。阿里旗下的金融服务公司蚂蚁金服,拥有高达60%以上的科技人员就可见一斑。

自然在这两个业态联姻时,这几家互联网巨头最希望的是合作银行用他们的科技平台,比如云和技术中台。所以自然的结果就是今天一家银行宣布采用阿里云,明天另外一家银行决定腾讯云来试点。然而除了去IOE和国家要求的银行IT系统上云,采用这些巨头的科技平台真的对银行有帮助吗?银行业的安全及监管规则对互联网企业来说很多是完全陌生的,也自然不会存在于这些科技平台中,采用平台带来的风险谁来买单呢?

反观银行方面,最希望合作的是互联网巨头们的流量,能够利用客群资源进行业务的拓展和创新。但作为垄断寡头的BATJ会把流量倒灌给银行?会锁定一家或几家银行合作?这本身就是违背平台战略的问题,自然答案是不会。于是这样的合作从最开始就已经是心猿意马了。

也许现在对这种泰坦级合作下结论还为时尚早,但有一点是肯定的,双方都不会在合作中得到自己最想要的东西

独立科技公司,是破釜沉舟还是文化转型?

以建行和民生为代表的国有和股份制大行纷纷开始独立旗下IT力量,成立科技公司,一时间搞得银行业暗潮涌动,有实力的银行纷纷启动FinTech和数字化转型。多家银行拿出的预算都是按照自身年收入的百分之几计算,一副破釜沉舟的架势。

收集各大银行独立科技公司的初衷超出了我的能力范围,但就我自己的观察,其中一个核心问题就是解决科技生存的文化土壤。当数字化渠道成为银行服务的主流渠道时,原有的IT作为一个成本中心是不可能支撑业务发展需求的。这个矛盾也不是简单将行里的愿景写成“科技引领”就会发生变化的。毫不夸张的说,业务和科技的协作问题已经是银行高级管理者们最头疼的问题。

5年前提出的去IOE对银行IT的影响不大,大量的业务仍然依靠稳定的IBM大型机,数据库也照样是Oracle。短短5年,银行的业务发生了翻天覆地的变化,当然这一点不意外,中国经济超高速增长的大环境下,金融业务必然更快成长。时下去IOE已经不会写在谁的年度目标里了,成为了自然而然的事情。和5年前的差别在于,之前的去IOE并没有客观的业务诉求,而现在不去IOE,可能就支撑不了未来业务了。这实际上也带来了文化上的巨大转变,传统的银行IT职责是使用和运维IOE系统及应用,目标是保持系统的健壮性和稳定运行。而后IOE时代的银行IT必须扩充自身的科技实力,这意味着学习新的技术和培养更强的自研能力。

从银行IT到金融科技,这不应该是一场破釜沉舟的战役,而应该是一次银行组织的文化转型。

不管转型的手段是什么,成立独立科技公司,亦或是增强科技人员占比,都不应该仅仅聚焦于银行的IT部门和团队,银行领导者和业务团队如果不深度参与到这次转型过程中来,文化是不会改变的,而科技和业务不但不会融合,反而会形成更大的鸿沟。这一点上,国内已经有几家银行走在了业务科技融合的正确道路上,展开了广泛的科技赋能。

客户为中心,是时代口号还是业务创新?

大型国有行和股份制银行确实在获取客户的能力方面非常羡慕互联网企业。按照现代资本论的说法,资本的增长包含一个纯人口部分和一个纯经济部分。从这个角度出发,如果能够为一种服务获取更多的“人口” —— 客户,那么增长是自然而然的。

互联网时代在客户管理方面有很多的创新,总结出了不少的分析模型,例如大家比较熟悉的海盗模型 —— AAARRR,据说海盗是这么发声吓唬人的。但其实这些模型存在的目的是帮助大家建立科学的认知方法,套用模型很容易买珠还椟,只记住了这些方法框架,反而忘了真正的客户。比如当我走进银行网点办理开卡业务时,柜员会根据提示发现我有可能正在装修,礼貌询问我是否需要低息装修贷款。这个场景用这些经典框架分析可能是非常正确的,在整个服务流程中嵌入了贷款金融服务。但实际上之所以我来到网点的原因是银行为了满足监管要求不能只通过网络给我开卡,所以我——作为客户——来到网点唯一希望就是快速办理,这个过程中任何的“植入”都会让我反感。

我们很容易喊着客户为中心的口号,做着伤害客户体验的设计。而真正的客户为中心往往需要银行跳出现有的服务模式,从客户的真实述求出发去重新设计业务。

“趣分期”是趣店的前身,由于其目标客户是大学生,所以纳斯达克上市后赶快弱化了其小型借贷公司的身份,成了一家电商。但我们却可以从这个案例中,分析一下为什么各大银行都在做的校园银行没有如此成绩。网上公开的数据显示趣店的大学生客户有3000万,月活2000万以上,这个数字相信足以让各大银行汗颜。

同样是校园信贷服务,我们看到的差异点在于谁真正把客户放到了中心,校园里的客户就是学生,而学生们不是希望贷款,他们希望的是自己拥有一部iPhone,或是能够拥有一台随身笔记本。贷款只是帮助他们达成自己心愿的一种手段(向父母撒娇也许是另外一种)。思维观念的不同自然造就了新兴业务模式的出现,而新业务模式的成功会给缔造者带来高额的回报。

最近在澳洲一家金融机构的数字化转型过程中出现过同样的场景。其中一个目标是帮助这家金融机构推销更多的住房贷款,大家拿出了现在的市场数据和客群分析,也考虑了简化贷款流程,然而一位资深顾问的问题彻底改变了大家的认知,“我们是在讨论提高住房贷款销售,还是在分析如何帮助我们的客户拥有一个美好的家?”这个问题让大家意识到,我们并没有认真去了解客户,我们还是在以自己的服务为中心。

高盛成立零售银行Marcus,直指颠覆传统个人银行业务的当下,各大银行急需的是业务的创新,并且时刻思考客户那个“美好的家”,而不是“住房贷款”。

固本清源,从业务出发建立科技生态

科技能力的建设固然是有很多种方式的,比如时至今日我可能才基本理解为什么华为领袖任正非提出的“用西方的砖修中国的长城”策略。科技能力的建设在当下最挑战的是需要为自己的企业打造一个科技生态圈,每当我看到西班牙BBVA在过去3年打造的科技生态(下图)的时候,都感觉到咱们中国的银行还有相当长的能力建设之路。

https://www.finextra.com/newsarticle/31811/can-banks-be-a-threat-to-big-tech

不仅仅是银行业,在电信运营商领域,最近两年荷兰起家的KPN给我们深刻演义了科技的力量,他们在2个月内完成了跟微信的对接,其直接结果是目前卖给中国游客的预付费SIM卡比自己本国经营的还多。而其它的欧洲运营商,由于不具备这样的科技能力,只能眼睁睁看着业务机会流失。

从科技视角出发,互联网实际只是一个数字化渠道了。在不远的未来,当IoT设备普及,我们会有更多的数字化渠道。针对银行现在的挑战,我们认为以下关注点是当务之急:

  • 从客户视角简化端到端数字化体验
  • 从提升响应力出发打造跨职能团队
  • 从平台思考规划数字化能力,建立能力平台
  • 从业务创新思考合作生态(渠道)


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

Share

敏捷变革过程中ETC面临的六个陷阱

敏捷从2001年被首次提出到现在已经历经了17个年头,作为一种新的思潮和软件开发方法早已跨越了鸿沟(如图1所示),并团结了大部分实用主义者,陆续掀起了不可逆的全行业敏捷精益转型。

如果你的公司或者组织正在进行或者已经经历了敏捷转型,那么作为组织变革者的你,一定在转型初期,组建了类似于“变革委员会”(或者“敏捷工作组”、“敏捷小组”、“变革小组”、“敏捷组委会”等)的团队。而在这个行业中应运而生的关键角色之一 —— 敏捷顾问/敏捷教练,入驻客户现场以后,提的第一个建议很有可能也是成立这样的团队。

图1 技术采纳生命周期 – 跨越鸿沟 Geoffrey A.Moore《公司进化论》2006

其实这种类型的团队有一个专业的名词 —— ETC,全称为Enterprise Transition Community(企业转型社区),是由 Mike Cohn首次提出,并在《SUCCEEDING WITH AGILE: SOFTWARE DEVELOPMENT USING SCRUM》中做了详细的介绍。

ETC的成员不超过12个,他们来自于参与Scrum转型的最高级别人员。

ETC的存在是为了营造一种文化、一个氛围 —— 那些对企业成功饱含热情的人尝试做出改变,而这些人的成功又会使更多的人产生更大的热情。ETC不是通过强行实施企业变革,而是通过指导实施变革的小组,为成功实施Scrum排除障碍,为变革创造活力与激情。

虽然ETC刚开始是Mike Cohn为Scrum设计的,但是在实际应用过程中早已不局限在Scrum转型了。同时,ETC也并不只是为企业级别所特有,也适用于更小的规模,比如说:一个BU,一个部门,或者一个产品团队(通常人数规模在100人以上或者人数少但是跨部门)。虽然每个咨询师或者每个组织有不同的称呼,但是几乎每个咨询师或者变革组织都会在转型前期成立这么一个团队,足见其重要性。为了统一语言,本文会使用ETC这个名称做进一步的深入分析。

先来说说我在咨询现场的做法。我一般会协同高层领导、组织变革者组建专门的改进跨职能团队,比如一个研发组织,包含业务、开发、测试、运维等部门负责人,成立ETC,选择改进的Product Owner和Scrum Master,人员控制在15人以内(有的组织非常大,波及人员范围较广,需要领导层酌情取舍)。

ETC按照Scrum方式运作,让变革者在战斗中学会战斗。团队有正式的启动仪式,迭代周期为一个月(或者两周,不建议更短,后续以一个月为例)。一个月一次改进计划会议,通过改进Workshop制定改进措施,并梳理优先级,责任到人,一周两次站会跟踪,每次半小时,针对改进项具体内容设置评审时间和形式,一个月一次回顾会议。

这是组织进行敏捷转型过程中一个非常重要的改进落地机制,是组织的改进引擎。令人欣喜的是,这几年下来,有很多客户,在咨询师撤场两三年后还能够继续按照当初的机制运作,“持续改进”已经植入了组织的DNA,始终有这么一支队伍持续不断地率领组织时刻反思勇往直前。

但是,更多的是运作不好的ETC。尤其是ETC运作初期变革者缺乏经验,非常容易陷入困境,接下来我们就深入了解一下ETC的六个陷阱和应对措施。

陷阱1:没有共同的目标,ETC名不副实

ETC的成员往往都是参与敏捷转型过程中的最高级别人员,是一个管理团队。而管理团队往往会有屁股思维;以研发场景为例,可能会有开发部门领导、测试部门领导,还有产品领导,项目经理等。

因为人员角色多,大家关注的内容就各有侧重,ETC的计划会、站会或者回顾会中如果偏向于部门或者项目,那么另外的人可能参与感就不是很强。更重要的是,分散的目标很有可能会造成互相推诿抱怨,效率低,改进不明显。

作为ETC的发起人或者变革者,第一个要解决的就是ETC成员目标不一致的问题,就像造船分配任务之前要唤起团队内心对广阔无限海洋的渴望一样,我们需要找到核心问题,让ETC成员意识到问题的严重性,树立紧迫感,渴望改变现状,然后引导大家共同制定改进目标。

这只是第一步,变革者需要不断的与ETC成员沟通问题和变革愿景,适当时候对目标升维或者降维,甚至通过求同存异的方式让大家达成共识。

陷阱2:知易行难,ETC成员没有以身作则导致转型也就是一阵风

有一次,开家长会的时候,幼儿园的老师让家长跟着做动作,老师一边把手放在眼睛上,一遍嘴里喊着“请把手放在下巴上”。很多家长不知所云,最后大部分家长都会比较纠结地把手从下巴转移到眼睛上,又有点犹豫,最终还是效仿老师把手放在了眼睛上。

这是一个很好的“知行合一”的小游戏,我们的孩子是这样,我们的团队也一样。他们并不会根据管理层说的调整自己的行为,而是根据管理层做的调整自己的行为。

变革过程中,有时候领导会觉得团队改进进展缓慢,很多情况下与领导的风格大有关系,“一句话需求”或者“说一套做一套”都是最直接的罪魁祸首。

举个简单的例子,如果作为部门经理或者项目经理的你,希望在研发团队运作中增加一个Story Kickoff的环节,就需要不愿其烦地与团队讲Kickoff怎么做,为什么要加这个环节,能解决我们什么问题,并且在实际运作过程中参与到具体的Kickoff活动并给予团队指导;当团队遇到问题的时候,帮助团队一起解决问题,并且鼓励团队。如果你只是吩咐了一句:“大家做吧”,然后就静待收割,99%的概率会失望。

再举个例子,敏捷理念中非常重要的一条是:管理者转身 —— 使用“使命式指挥”替代命令控制。一起参加培训的时候,你对“使命式指挥”赞不绝口,非常认同,并启发管理层全部要向“使命式指挥”看齐,但是培训过后的日常管理中,对管理层又是直接命令来控制去,这个时候,大多干部都会潜移默化地效仿并对他的团队也使用命令控制,而不是“使命式指挥”。

这个陷阱的应对措施最简单也最难:以身作则,知行合一,有的时候,有些根深蒂固的习惯非常难改,尤其是管理风格,但是要让团队知道你是意识到自己的问题并且在尝试改正的。

如果我们要改变,首先需要定义出我们期望的行为是什么,我们希望人与人之间有怎么样的行为方式,并教会员工这种方法。

陷阱3:事无巨细,ETC成员沦为微管理现行犯

如果原有领导班子是命令控制性风格,这几乎是ETC成员最容易犯的毛病之首,管理太细节,改进Backlog太细节。

三年前我就见过一个领导团队,7、8个部长就一个“测试场地到底有20平方还是40平方,能不能放下测试仪器”的事情吵了起来,而这样的领导者容易犯的第二个毛病就是:没有了解清楚就给方案。

关注的内容太过于细节,但是领导往往掌握不了所有的细节,这样的矛盾就会滋生出更多的矛盾,甚至造成给底层员工添乱的尴尬局面。

而ETC的一个重要职责是营造一种环境,在该环境中里,可以逐渐形成不 同的改进社区,这些改进社区在追求改善企业产品创建过程中,自发地形成和解散。

Mike Cohn《SUCCEEDING WITH AGILE: SOFTWARE DEVELOPMENT USING SCRUM》

ETC最大的目标是创造这么一个环境,让改进社区确认自己的目标,并自发地组织起来达成目标。

现在你是否发现,进入ETC其实并不意味着我们自己要做很多很多的任务,比ETC实际要完成的这些工作更重要的是,传递我们的转型愿景并激发别人的兴趣。

陷阱4:将信将疑,ETC成员期待他山之石可以攻玉

例如,作为事业群的最高领导者及ETC的PO,其实对整个转型过程呈观望状态,由于其他事业群的压力所迫,不得不跟风;虽然敏捷运作开始了,但是更多是谨慎前行,你希望团队要告诉你敏捷到底行不行。

这种场景,几乎都有一个同样的结局:失败。

经历过这种转型的咨询师或者变革者都会深有感触不堪回首。我在咨询现场,对领导层提的第一个要求就是:乐观并且坚定。管理层的乐观和坚定非常重要,强调多少遍都不为过。

因为,如果管理层将信将疑,团队会从各种互动中感觉到管理层的质疑,继而团队就会质疑,觉得转型没用,然后又会反过来影响管理层对转型的信心并加剧管理层的质疑,循环往复。最终以失败告终。

这里必须要提一下“文化变革的新旧途径”,约翰·舒克是丰田城的首位美籍员工,在经历了NUMMI公司的成功精益转型之后,他对沙因的文化变革模型进行了修改,他认为:

要改变文化,首先要去改变的不是人们的思考方式,而是行动方式,即他们怎么做事。

2015年,在沙因和约翰的模型基础上,为了让变革者能够更容易操作,我提出了如下观点: 对于管理层,我们要通过改变他们的思想改变他们的行为; 对于基层员工,我们要通过改变他们的行为来改变他们的思想。

随后的几年咨询生涯中,又经历了许多案例,何尝不明白“二分法”是最危险的思想,不管对于哪个群体,让其发生改变其实都需要思想和行为的相互佐证。但是,在大多数情况下,这样看似粗暴的划分其实并无大碍。尤其对于管理者而言,思维改变是前期最重要的一环,从古至今的无数变革案例几乎都昭示了一个不争的事实:领导者没有下定决心痛定思痛,变革的路就走不长远。

图2 文化变革的新旧途径

陷阱5:缺乏与基层团队的多渠道连接,ETC更像空中楼阁难以为继

就像陷阱3中提到的,ETC成员靠自己只能完成一点任务,取得一点成果,他们更需要依靠组织中的其他人完成实践落地而走向敏捷所需要的大部分工作。因此ETC如何发动群众,辐射群众,与更广大的团队形成一对多的继承和相互促进的关系就显得尤为重要。

改进社区、各角色技能CoP(Community of Practice,实践社区)都是不错的选择。切忌管理层在ETC各种指点江山发号指令,而忘记了团队疾苦,很多改进措施难以落地,团队叫苦连天,时间长了,不仅仅是变革像空中楼阁难以为继,更有甚者倒退回比之前都不如的境地。

场景一:某企业某事业部正在进行从上至下的敏捷转型,作为部门A的基层员工,根本不知道为什么要转型,每天的事情已经够多了,为什么还要多出这么多敏捷转型的讨论和会议?

场景二:经由一些天的头脑风暴和深思熟虑,在大领导的带领下,大家终于下定决心要对现状的短瀑布流程进行彻底变革,用敏捷核心实践来改善目前的产品质量。大家成立了ETC,并建立了改进Backlog,开始跟踪各种事项。作为中层管理干部,你很幸运参与了整个过程。不过你的团队经常对你飚出的一些新词以及那片花花绿绿的改进墙充满了疑惑和好奇,最开始你还解释一下,慢慢的时间长了,你也懒得一遍遍解释,他们也就熟视无睹了。

不管是Mike Cohn提到的ADAPT模型(如图3所示)还是Kotter教授在《 LEADING CHANGE》中提到的变革八部曲(如图4所示),都着重强调了一个“真理”:

每一个成功实施变革的组织都是在多个层次上进行这些活动

这个问题是:大部分变革项目都是由许多小项目组成的,这些小项目同样也需要经过从紧迫感到融入文化这8个步骤(如图4所示),缺一不可。而这是很多变革者最容易忽视的问题之一,他们往往蓄了足够的势,在最高层级用各种手段打开了突破口,找到了同盟军,让关键者动起来了,然而忘记了在下一个层级持续蓄势,或者忘记了教会他们的ETC用同样的方法鼓动底层员工跟着动起来,这也是敏捷转型非常容易失败的一个最关键的因素。

而另一问题是:整个变革项目行至中途,一些小项目完成了,而有的小项目才刚刚开始。不同项目不同团队的状况不一样,需要我们分别对待。

针对这两个问题核心应对措施就是:变革者要不断识别团队或项目处在变革过程中的哪个步骤,在多个层次和层级上反复进行变革措施,并培养更多的变革者,在不同的范围内和层次间不厌其烦地重复变革步骤。

图3 ADAPT模型 Mike Coh

图4 John Kotter’s Change Model-8 Steps 来源:staff.napier.ac.uk

陷阱6:忽视推广和传递,最终臣服于企业重力

最近几年,越来越多的企业管理者终于明白,敏捷转型是在不同的层级上进行的,敏捷变革所取得的成效也与其所能够影响的范围有直接的关联。就像上述陷阱5所讲,如果在IT组织内部不能够持续影响并顾及到多层级效应,就很难做出大的改变取得可观的效果,转型很有可能半路夭折。如果前五个陷阱完美应对过来了,基本可以说转型成功了一半。

为什么是成功了一半呢?其实对于进行敏捷转型的企业组织,只要踏过前五个陷阱,都能够取得不错的成绩,但是还差最后一关,那就是突破IT,向组织内更大范围推广和传播。

“企业重力”是一个很有意思的说法,不同的书籍均有提到相似的概念。这也是沙因对企业文化的解读:

文化 —— 是一个群体在解决外部适应和内容整合的问题时所学到的一套被普遍认可和不言而喻的假设。这些假设在过去运作得足够好,被视为有效的,因而被作为理解、思考和感知这类问题的正确方式传授给这个群体的新成员。 —沙因 《企业文化生存指南》

曾经让这个群体成功的那些思考、感受和看待这个世界的方式就是企业重力,因此敏捷转型的影响必须推得足够远足够广,才不至于使整个转型因为“企业重力”而被拉回到原点。

最经典的例子就是IT部门内部的敏捷转型,如果不连同业务部门,甚至HR、财务、物业等部门,用不了一两年,就会发现改进乏力,这也是《精益企业》中所提倡的,我们要在更大的组织和范围内进行彻底全方位的精益转型,才能让我们在不确定的市场环境中更具有适应性。

也有很多敏捷顾问/敏捷教练或者企业转型者认为只要ETC旗帜一树,正常运作起来,就成功了大半,殊不知这才是刚刚开始,组织转型本身就是九死一生的博弈,Kotter教授也在《LEADING CHANGE》中一开篇就介绍了导致组织转型失败的8种常见错误。

而本文用敏捷转型过程中的ETC作为引子帮大家鉴别领导班子的风格会严重影响组织转型的进展,希望正在做组织转型的你能够在面对ETC团队的各种问题见招拆招。


更多精彩洞见,请关注微信公众号:思特沃克

Share

银行组织的敏捷落地

年初在一篇文章《银行IT的敏捷转身》中谈了银行IT普遍面临的敏捷转型问题,主要聚焦于这个数字化时代,银行IT从过去的成本中心,走向科技能力中心的困惑和挑战,文中我指出了敏捷转型绝对不是IT一个部门的事情。可喜的是在这半年的时间里,我们看到越来越多的银行从数字化战略的角度开始整体规划敏捷转型,把敏捷作为迈向数字化的一个坚实基础来抓。

在经历了几家银行大刀阔斧的改革后,我希望能够把敏捷落地这个话题放到银行整个组织下来跟大家分享几点心得,借机提醒正在高歌猛进的组织不要忘了初心,也为正在规划转型的组织提供一些前车之鉴。 利用敏捷宣言的模式,我总结了四个方面:

  • 敏捷文化 over 敏捷开发
  • 实验探索 over 创新项目
  • 平台思维 over 微服务架构
  • 员工体验 over 开放办公

我们应该都意识到了排比句的右手边是这个数字化时代敏捷落地的一些核心领域,但我希望通过这样的对比,强调组织级敏捷落地中左手边领域的重要性。在下文中我将逐一展开这四个对比,帮助大家理解转型过程中的一些核心关注点。(点击此处或扫描二维码观看视频回放)

敏捷文化 over 敏捷开发

金融是一个强监管和强合规的行业,在中美贸易战和P2P暴雷遗患未除的当下,监管肯定是不会松绑的。某种意义上这是合理的,有多少客户能够接受自己在四大行买的现金理财产品出现了本金亏损(即使购买时风险已经告知)?如果这种情况出现在我父母身上,他们有可能就报警了。

这样的行业管理模式下必然驱动出统一、标准化的服务(产品)开发过程及方法,以及随之配套的企业文化。在面对不确定性市场时,这样的方法和文化的弊端被放大了,没有办法快速响应变化,更无法激发创新。这是大多数银行开始走向敏捷的原罪。

经过最近20年的演进,敏捷(软件)开发实际上已经有了一套比较体系化的方法。Scrum、Kanban及XP的实践都得到了广泛应用,在《ThoughtWorks的敏捷开发》一文中我也总结了这10多年来ThoughtWorks全球形成的敏捷开发方法的体系构建及关键实践。

那么银行作为一个组织的敏捷转型,是否就是要把过去的开发过程和方法,转变成上面提到的敏捷方法,并形成自己组织内部的统一实践呢?答案自然不是。我们要解决的原始问题是如何建立对市场变化的快速响应,并能够激发组织内部的创新。我们的目标并不是要用一套大一统的“敏捷方法”来取代过去的传统方法,我们需要的是组织文化上的敏捷性,能够持续学习和改善。

就中国的大多数银行来讲,这意味着可能有多种软件开发过程和方法,甚至于在一些传统核心应用里仍然使用瀑布过程作为流程主干。当然这里并不是预定解决方案就是“双模”,从银行自身业务发展出发,谁说不可以“三模”、“四模”呢?

经过四年多的实践,某大型国有银行软件开发中心就形成了三种敏捷开发模式(开发敏捷、全流程敏捷和端到端敏捷),为中后台团队、网络金融和互联网创新分别提供了实践的牵引。如果从教条主义出发这是值得批判的,为啥不全都是端到端敏捷?但从现实的行业和企业生存环境出发,这样的敏捷落地是务实的。四年时间里我见证了该组织员工敏捷认知上的持续进步,在强监管的约束下,通过多种模式创造了时代需要的组织灵活性。从这一点出发,这样的做法和大刀阔斧的组织变革同样值得尊敬。

我们需要拥抱变化和持续改进的敏捷文化,而不是所有产品整齐划一的“敏捷”开发模式。

实验探索 over 创新项目

由于FinTech的冲击,各大银行纷纷启动了创新机制,有的甚至成立了单独的创新中心。科技创新在银行业成了最为重要的企业战略话题,各家银行的网点里目前都已经摆满了全自助的柜员服务机,有的大堂里已经开始有服务机器人在主动迎宾。

创新同样是敏捷落地过程中一个不可避免的问题,甚至在不少银行成为发起敏捷转型的原动力。在一家致力于金融科技引领的大型股份制银行的转型过程中,敏捷开发模式成为了FinTech创新项目的必选项。但除了更“快”,大家似乎都没有找到创新和敏捷的必然联系,只是因为希望创新产品快速上市,所以认为必然是敏捷的。

在这家股份制银行的一次FinTech创新项目提案评审会议上,CIO的一个问题触动了我的思考。在各个创新团队争相汇报自己的创新产品取得的成果后,CIO停顿了几秒钟,说到:“我希望大家以后不要每次都出来讲自己的创新如何成功,取得了如何的成绩。我希望大家都讲讲自己在创新的过程中遇到了什么问题,通过用户实验验证了哪些错误的假设,并谈谈怎么改进的。”

是啊,既然是创新,那就是在实验,而实验失败应该是十之八九的事情吧。如果永远都是成功,可能如这位CIO接下来点评的:“大家都没有创新,只是在延续已有业务而已。”而接受实验失败,并把失败作为一次重要的学习机会,在目前银行业里仍然十分少见。没有这样的试错文化,可能下一个“支付宝”仍然不会出现在现有的银行体系里。

我们需要通过科学实验来验证业务想法,而不是制造一堆只能成功的“创新”项目。

平台思维 over 微服务架构

金融服务已经完全依赖于数字化渠道了,各家银行都意识到了IT系统的重要性,拼命加大科技方面的投入。由于很多互联网企业的示范作用,微服务化架构也进入了银行科技的愿景里,期待着云时代能够通过微服务构建灵活的系统架构,从而能够支撑新服务和产品的高效敏捷开发。

于是很多银行都开始拿出不同的应用进行微服务改造,希望通过试点建立自身微服务架构的能力,逐步让更多的应用“微服务化”。国内银行显然没有时间等着一个一个应用的试点,于是往往会挑选不同业务领域(如零售和对公)的应用同时进行改造。然而,完成微服务拆分后,根本没有人会跨业务的审视大家在服务层面是否有共性需求,我们希望的复用性自然也就不会发生。这些服务未来可能也仅仅是一个应用改造后的“模块”,而不是真正为多项业务持续使用的“活着”的服务。

在此基础上,不可避免的需要构建一套微服务开发框架,直接采用开源框架对于银行来说还是很难满足其监管要求的。在设计和开发这个框架的过程中,我们最常听到的就是如何能够把各种服务管理述求(从注册到安全)都植入到框架里。这是一个似曾相识的故事,结局可能是一个复杂难懂的框架,看似开发工作量(代码行数)少了,但却给开发人员带来了痛苦的体验,以至于一有机会大家都会想办法绕过框架。

这些问题的解决必须依赖于我们思想观念的转变,新的平台思维是我们需要去拥抱的。我们这谈的并非是阿里提出的中台,而是从过去软件应用框架平台到数字化能力平台的转变,这个转变带来了三个方面的显著变化:

平台的“客户”是我们的开发人员。这里的开发人员是广义的,比如在数据分析领域,未来的银行业务人员也是开发人员。这个能力平台必须要关注开发人员,即客户的体验!

平台是持续演进的“活体”。平台上每种能力都为不同的业务应用提供着支撑,并且是持续完善的。我们不会像过去应用框架开发一样集各种述求于一身,设计就需要大半年。

平台是自服务的。开发人员不需要读上百页的技术文档,或demo项目来理解怎么使用平台能力。感谢互联网,已经为我们做出了这样的表率。

我们需要一个能够持续积淀的数字化能力平台,而不是一堆各自为战的微服务。

员工体验 over 开放办公

我经常玩笑说组织转型有两个非常好的破旧立新的契机:一是组织结构的调整,二是办公室重新装修。后者毫无意外已经成为了银行组织敏捷转型过程中的常规武器,通过打造不一样的工作环境,来促进员工之间更多的沟通和交流。

在敏捷倡导的协作和信任模式下,大部分重新装修都会选择开放式办公环境,即每个员工不再有自己的小格子间,甚至不会有自己的固定工位。这样的好处自然是我们可以更方便地让一个团队的员工们坐到一起,形成更紧密的团队协作氛围。

多年的顾问工作让我习惯了“居无定所”,每次走到客户的开放办公环境自然感觉非常适应。但也有那么几次走入新装修的彩色环境时感觉莫名的不快,所谓的开放办公桌比之前的格子间更为拥挤了,桌上一个显示器挨着一个显示器。整个场地没有几个会议室,都摆满了长条桌,团队站会都显得非常局促。这让我想起了多年前一家创业企业负责人在参观了ThoughtWorks北京办公室后跟我说的一句玩笑话:“这样的开放布局不错,单位面积里能多坐不少人,还能时刻监视每个人!”搞得我忙解释,其实我们的人均员工空间是行业普遍水平的一倍多,并且也没有人会去监视别人。

(你听说的开放办公 vs 你经历的开放办公)

这样假借开放之名来“提高”场地利用率的情况现在也正在发生着。值得提醒有类似考虑的管理者,别忘了选择开放环境的初心。我们在给团队提供更紧密协作空间的同时,也需要考虑团队的私密空间,这要求不同团队之间有一定的空间隔离,也要求足够的会议室来支撑时常需要进行的小范围协作会议。开放空间的设计不是在大平桌上整齐地排列一台挨着一台的电脑和显示器,而是更加全面的思考团队沟通协作的需求,更多的可视化空间及移动办公设施。

而这一切都是为了更好的团队和员工体验,让大家能够在安全放松的环境下去思考和碰撞,从而能够激活整个组织,创建生机型文化。借用西方管理哲学里常用的一句话:只有愉快的员工,才会有愉快的客户!

我们需要一个能够让员工感到安全和放松的团队工作环境,而不是一个为了提升利用率而拥挤不堪的“开放”场地。

银行组织的敏捷落地正在发生着,文中四点显然无法涵盖转型工作的方方面面。如开篇讲到的,我希望在帮助银行数字化转型的过程中,持续把自己的经历和观察总结分享出来,促进我们的银行业在数字化的进程中变得更加开放,从而能够碰撞出真正的创新。

Share