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

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

牵手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

DDD的终极大招——By Experience

以DDD思想和微服务架构为代表的新的架构时代正在逐步形成,不同方法和工具的涌现让人激动不已,同时这个过程也让人感觉到些许的不安,因为没有一套方法和一套架构能够打遍天下,我们能明确告诉所有组织和团队的,也只是架构设计上应该“响应变化胜过遵循计划”!具体到采用哪一种架构设计思想和方法,仿佛都需要增加一个定语“这取决于……”。

以去年的“明星”方法Event Storming(ES)为例,今年已经开始被不少人所批判。内行已经开始调侃这就是“糊墙”(不明就里的同学可以感受下图中的ES现场)。而实际上ES创始人Alberto是一位很低调的实践者,仍然在不停地磨练着他发明的这套方法。一年里我也接到了无数类似“我们是xxx领域,有xxx系统,ES感觉好像用不上?”的问题。我的答案往往是:“没事儿,你们先试试,找到具体困难点,咱们再看为啥不好用。”

(一个ES现场,“糊”满各色纸贴的建模过程。)

我相信得到这个答案的部分团队可能真的去尝试了ES,但鲜有人再将他们遇到的具体困难反馈给我 —— 也许ES实践本身就是困难,而不是他们要解决的业务问题。但我的出发点却并非推广ES,而是让团队能够获取“经验”!这点上还是小有成就的,去年我可能还是中国区“糊墙”最多的人,今年很多人都远胜过我了。

不管是在DDD原著,还是后续不少专家的书籍中,都明示或暗示架构设计最后的终极大招还是By Experience ——靠经验吃饭。从战略角度的subdomain(子问题域的划分)到战术建模层面Entity、VO的选择,最终的决策很可能不是完全“理性”,经验这个“感性”的东西发挥着很大的作用。

对于一个顾问和教练来说这是绝望的答案,因为我们每次面对的是希望学习,但没有经验的团队,“靠经验吃饭”等于告诉团队这东西没套路、靠感悟。这就迫使我们转换视角,从教大家DDD方法,转换到帮助大家获取DDD经验。下面就让我们来看看怎么有效解决DDD经验获取这个问题。

问题、问题、问题

DDD作为一种架构方法,最大的突破应该说是非常明确地区分出了问题域和解决方案域。而认知问题这件事情绝对不是技术人员擅长的,从我们学习编程起,我们就被如设计模式(Design Pattern)这样的解决方案所包围。想当年我自己最得意的事情也是refactor to pattern,也是把解决方案当成了“终极问题”来追求。

这往往是一个痛苦的蜕变,需要有人在你身边不停念叨“你说的问题是什么?”。你必须要做到心平气和,即使你认为对方是故意挑衅,有时候挑战更能促进思考上的突破。比如我经历过下面的一段经典对话:

甲:我认为这个子问题域是客户账户管理的问题。

乙:我觉得你已经在说解决方案了。

甲:客户账户管理是问题,我并没有提怎么管理啊!

乙:谁说一定要管理客户?!我还是觉得你说的是解决方案!

甲:(受不了你了… … )不管理客户我们做这个系统干啥?

乙:我就是这个意思啊,为啥要做这个系统?我们解决了什么业务问题?

甲:这么说的话那把业务找过来,看他们怎么说。

乙:行,反正DDD里说领域专家很重要,业务来了再讨论。

某种意义上这两位技术人员的争论是卓有成效的,最终的发现是业务问题其实并不清楚,远没有达到可以进入解决方案建模讨论的时候。

跨领域合作

当然上面的对话还有另外一个有意思的核心观点,即由于问题和解决方案在整个建模过程中是不停深入和迭代的,所以我们必须鼓励,甚至要求从业务到技术跨领域的人员参与和协作。

这点是我为什么仍然认为ES是一个好方法的基础,当然与我相对的观点是,如果有了真正的领域专家,搞那么复杂的协作有必要吗?ES通过对事件(event)的利用,提供了一套业务和技术能够共同理解的协作机制。在我的辅导过程中,很容易让两边的同学都理解如何上手。

(ES的运作机制,很有效的利用了Domain Event;注意这里的event是业务事件,而非技术实现。我的同事伍斌在自己的简书中详细记录ES的采用过程,欢迎大家查阅。)

当然如果真有经验丰富的领域专家,确实事情就简单了很多。业务问题的分解首先就变得非常流畅,ES的功效也就不那么明显了。然而我个人始终认为“团队共同的学习 胜于 建模本身的正确性”,即使专家也不能完全预见未来,所以团队能够有机会通过某种手段学习专家的知识,也是很有价值的一件事情。

从需求到代码

DDD最初吸引我的地方是能够从问题分析一直拉通到代码实现,这有别于很多其它的架构方法,总是在某个链条上产生脱节。所以DDD的经验获取也需要尝试让团队端到端的拉通体验。

然而事实上很多团队仍然在践行着脱节的实践,比如建模后产生的Entity仍然用传统的数据和行为分离的实现方式。这样的实践方式显然是有悖于DDD的初衷,如果不能让业务和系统模型实现绑定关系,很快就会走上各说各话的老路上去。

实践端到端也有一定的技巧,首先应该明确分层架构的原则和规范,比如是否有Application Service存在的必要,Interface的调用规则等等。在此基础上,需要明确守护Domain Model的纪律,时刻保证代码和建模的一致性。最后需要建立分层的测试机制,特别是对Domain层逻辑的守护。

和前两点相比,这真是一个需要全队刻意练习的过程,坚持信念是团队走过开始阵痛期的必要条件。

刻意“失败”

之前在辅导团队的时候,一个常见问题就是团队纠结于一个业务概念建模采用Entity,还是VO。经常会听到团队说:“从现在的需求来看,VO应该是完全够用了,但很显然接下来我们马上就需要有业务状态的变化,很可能VO就没法玩了。”

针对这样的问题,我往往会刻意引导团队从简单的VO建模入手,先不要考虑“未来”的需求,即使有时候这些需求已经相当明确。这样的刻意行为显然会造成团队在接下来的时间里改变模型,VO可能会被重新建模成Entity。短时间有可能是痛苦的,很多技术人员也会跳起来说,你这是“站着说话不腰疼”。

但DDD的核心就在于持续的演进,演进就意味着模型和实现的改变。这样的改变和上面我们刻意安排的“失败”其实是一致的。当我们通过这样的刻意练习获取了演进的经验后,业务和架构未来的变化对我们来说就真的可以by experience了。

写在最后

开篇我就提到了一个新的架构时代正在浮现,不同于之前的架构方法,没有一个组织和企业会在这个时代告诉你这就是做架构的正确方式。数字化时代的系统和应用在不停进化着,速度越来越快,想要找到进化过程中正确的元方法是非常困难的。

DDD的终极大招By Experience某种意义上是在持续探索,并要求大家接受在这个探索过程中的不确定性 —— 你的设计有可能在未来被证明是错误的。这可能是未来架构设计最大的挑战,我们必须能够让架构持续演进。

《演进式架构》已于今年问世,带给我们很多这些方面的思考,类比人类社会的演进,数字化世界的构建和发展应该有很多地方可以借鉴和学习。当然就这个问题而言,不管是DDD,还是Microservices,都只是我们探索架构演进的开始,我们还有很多的Experience需要获取!


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

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

当Subdomain遇见Bounded Context

《实现领域驱动设计》的作者Vernon根据过去几年DDD的实战经验又写了一本《领域驱动设计精粹》,日前已经在中国翻译出版。去年底出版社找到我时,读完英文原著最终还是放弃了翻译,推荐给了其他同事,并告诉他们出版后准备接受炮火洗礼。

不得不承认Vernon的新书在构建DDD落地体系方面较之上一本有了很大的进步,全书读起来很连贯,有一定实践基础的团队或个人均可直接上手书中很多的实践。并且通过一个案例完整叙述了从需求分析开始到最后的团队迭代开发。当然迭代运作过程中的工作量估计方式,在我看来过于简单粗暴,虽然强化了架构的最终代码落地,但却可能造成一系列的僵化。

本文主要针对Vernon一直以来对Subdomain和Bounded Context的一对一映射关系进行讨论。目标是让更多同学意识到这个方面的不同声音,从而能够加深对这两个概念存在意义的理解,并建立自己的判断。

区分问题和解决方案是个老大难问题

问题和解决方案总是像一对难以分辨的孪生兄弟,一个人看到的哥哥可能就是另一个人认为的弟弟。好像程序员在开发Story时,Story成了我们要解决的问题,具体的代码实现成了解决方案;但当BA在分析同样一个Story时,问题就成了对应的业务需求,Story只是分析出的解决方案的描述。

当然这个区分有时候可能并没有那么重要,Story到底是一个问题,还是一个解决方案,其实我们在迭代过程中并不是很关心。但有时候不做问题和解决方案的区分确是十分危险的,甚至会造成整个产品的失败。这样的例子当然是一抓一大把的,比如我经常提及的为税务审计人员提供屏幕上多记录的翻页功能,就是我职业生涯中记忆最深刻的一次失误,想当然地采用了“通用”解决方案。

Eric Evan在构建DDD的体系时显然是思考了问题和解决方案这两个维度的,我相信这个过程也是十分痛苦的,以至于最后呈现在书里的实践并没有做非常明确地划分。对于后面的实践者,包括我们自己,都存在着不一样的解读。我们曾经讨论过一个DDD实践的象限划分,但由于这样的划分太过主观,结果是一组很长的邮件讨论。

象限如下图所示,这是一个如同“PHP是世界上最好语言”般的讨论,建议大家慎入,以免上火。

(从问题/解决方案和战略/战术 维度分析DDD元模型的元素)

这样的象限分类确实有点简单粗暴,但Subdomain和Bounded Context却是Eric明确定义的两个核心模型概念。Subdomain是对问题域的分解,而Bounded Context是对解决方案域的分解。这两个核心概念构建起了DDD处理真实世界复杂度的根基。

建模过程中很多同学其实是忽略Subdomain的,反正目标是Bounded Context。当问题相对简单时,Subdomain的划分确实给人感觉是自寻烦恼,划出Bounded Context后反过来推Subdomain视乎更容易上手。读《领域驱动设计精粹》时你会发现相似的逻辑,配合书中敏捷项目管理工具的案例(问题也挺简单)还是挺好用的。

那么为什么我们还要关注Subdomain,还要去区分什么Core Domain、Support Domain和Generic Domain呢?是否和Story一样,留给业务和BA就好,程序员还是应该抓紧搞完Bounded Context,然后开写微服务比较务实呢?

区分Subdomain的必要性

在帮助一个长期合作伙伴构建大规模DDD应用时,我写了一个“xx阶xx步”的体系。也成了很多咱们同事体系性学习DDD的开始。

一年半以后这个团队组织了所有的技术专家和主管让我又讲了一次这个体系。这次我花了一天时间让大家体会问题和解决方案的区别,加入了Subdomain的概念。参加团建时,我问了几个专家和主管他们怎么看之前的设计,得到更多是务实的“赞赏”。其实我并不在意具体落地时的裁剪,但希望白纸黑字时应该明确原委,这也是我为什么拒绝了《领域驱动设计精要》翻译的原因。

我经常用电商的案例让大家快速认识到Subdomain划分的重要性。大浪淘沙之后我们发现淘宝和京东依然是霸主。当年马爸爸嘲笑强哥构建人肉物流网的寓言也并没有发生,反而很多人爱上了京东自有物流的速度。当然站在马爸爸当年对电商问题的认知角度,自建物流是可笑的,毕竟他要解决的核心问题是如何让琳琅满目的中小供应商能够直接对接千千万万的用户,让用户能够更容易的发现适合的商品。

所以从一开始淘宝和京东定义的Core Subdomain就是不一样的,正是问题认知的区别让两家都活了下来,并且活得很好。我们可以看到在线物品展示,吸引消费者方面淘宝一直在引领;而行业里如果你有机会接触电商领域,会发现京东物流系统还是蛮厉害的。

这是我们多年后的今天看到的结果呈现,但其实真正决定命运和格局的确是多年前两家电商对自身核心问题的理解。这个认知驱动出了两家完全不同的成功电商。

很多同学会说这玩意儿是商业模式,也轮不到我们搞研发的参与。我们拿到的都是既定问题了,再识别Subdomain也没啥意义了。这个论断有两方面问题:

  • 作为产品和服务的实现者,如果都不参与和关注问题本身的划分及核心子问题的认知,那么你很可能在浪费自己的时间,开发出未来被边缘化,甚至淘汰的系统。这不是危言耸听,在我的最近咨询过程中已经鉴证了很多次,比如在这个移动优先的时代去强化PC应用的技术架构。
  • 其次在这个软件应用空前发展的时代,始终抱着所有模块都必须是“自研”,所有代码都必须自己写的思想,毫无疑问只能成为“小作坊”。构建现代的复杂系统已经逐步成为一个生态工程,随着数字化服务的普及,识别哪些领域应该直接外购使用也成为了开发团队的重要能力,构建一个典型的移动应用应该没有人再会去重头写一个二维码扫描模块,而是学会从市场上选择适合的软件包。

那么什么地方应该建,什么地方应该买,应该如何决定呢?这时候我们会发现Subdomain的划分就非常有指导意义了。类似二维码扫描这样的Generic领域显然应该是外购的,而当年京东对电商的理解来看物流系统是要自建的。同样道理还有上次DDD China大会来分享的盒马生鲜,半年时间已经重写了三次核心ERP系统。不去思考问题划分的同学们会觉得盒马疯了,ERP在外部看来是多么成熟的软件包啊~ 但事实上盒马生鲜的本质就在如何解决生鲜食品的高效配送上,也可以说是一家特殊的物流公司。

小结一下,即使区分问题和解决方案很抽象,划分子问题很烧脑,我们还是必须认识到分析问题本身的重要性和必要性。借用雷布斯的成名句“不要用战术上的勤奋掩盖战略上的懒惰”!

Subdomain和Bounded Context的对应关系?

探讨了Subdomain的必要性,自然我们需要分析和解决方案这边Bounded Context分解的关系。第一次看Eric构建的DDD模型脑图(如下)时,我一直认为少画了Subdomain和Bounded Context的对应关系。最早采用DDD时,个人认知是一个Subdomain下应该有多个Bounded Context,即当我们分析出了一个子问题后在针对建模的解决方案进行分解,成为多个Bounded Context。所以Subdomain:Bounded Context应该是1:N的关系。

(Eric构建的DDD模型脑图)

然而Vernon一直以来的实践方式隐含着1:1的对应关系。这样的对应关系并非没有道理,如果咱们从一个Bounded Context出发,我们会发现每个Bounded Context必然应该是“解决”部分问题的,而这个部分问题是否就应该是一个Subdomain呢?

当我们拿着这个差异去跟Event Storming的发明者Alberto Brandolini讨论时,发现对方委婉地表达了N:N的理解。简而言之没有直接的对应关系。当然这种理解隐含了一个Bounded Context是可以服务于多个Subdomain子问题的。比如“产品展示”Bounded Context的模型可能服务于产品销售和产品评论两个Subdomain子问题。

这三个对应关系的理解暴露出了大家对问题和解决方案这个老大难问题的纠结~ 当然最简单的是能够建立一对一的映射,作为解决方案高手的程序员们显然是非常喜欢这个模式的。以至于很多用DDD建模的程序员直接就跳过Subdomain搞起了Bounded Context。当然这也是我坚决反对这样简单化映射关系的重要原因。

出于对方法实操性的考虑,我仍然认为一对多的映射是最优的选择。诚然在我们的现实世界里,问题和解决方案是没有必然对应关系的,他山之石可以攻玉也是古来有之的。但软件设计本身就是一个问题抽象的过程,这个抽象一定会选取一个视角,也就会放弃部分信息。在这样的认知下,其实我并不介意在不同子问题的解决方案里存在一定的重复。

所以,如果让我来站队Subdomain和Bounded Context的对应关系,我仍然会选择一对多。在准确性和易用性之间寻求一个平衡,并保证大家能够更多的关注问题本身。

坚持持续认知问题

Subdomain和Bounded Context的讨论随着DDD实践的深入会进一步被大家所讨论,不论大家是否能够共识,这样的讨论都是有好处的。作为软件开发的从业者,在面对这个越来越多不确定性的数字化时代,认知问题本身将越来越重要。

Subdomain和Bounded Context在实际认知过程中一定也是相辅相成,逐步清晰的两个概念。Bounded Context建立一定是针对Subdomain的;而Subdomain的划分又会通过Bounded Context的模型得到持续地验证。


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

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