数字化创新中的设计

[摘要]数字化创新领域的核心在于设计,而设计的难点在于深入发掘用户的潜在需求,及更广泛的人员协作。在这个领域有什么方法和实践呢?

“创新不是由逻辑思维带来的,尽管最后的产物有赖于一个符合逻辑的结构。”—— 阿尔伯特·爱因斯坦

创新是一个大家又爱又恨的事物,在这个不断涌现新生事物的数字化时代,大家都希望自己成为下一个“黑天鹅”的缔造者,都害怕自己成为被颠覆的“受害者”。而伟大的创新仿佛都要站到悬崖边才能发生,所谓混沌的边缘(Edge of Chaos)是创新的摇篮。这个边缘却是我们大多数人都不会愿意身处的境地,这也就形成了创新的悖论。

数字化时代的另外一个特点是持续降低的创新成本,从一个想法到一个可以为用户所使用的产品的制造时间在被不停地压缩着。Google和Amazon这样在互联网时代诞生的企业,甚至将新功能的发布做到了一年好几千万次。整个产品的制造过程在新科技的推动下,变得越来越自动化和智能化,创新者最重要的核心能力变成了设计。现代用户已经不接受工程思维下可以工作的“样品”了,有“爆点”的MVP思维成为了产品设计者对用户的基本尊重,召开一个产品发布会如果没有“one more thing”压阵都会显得苍白无力。

在下文中我们就一起来看看数字化时代的创新设计带来的主要挑战及对应的策略实践。

以用户为中心的不确定性

数字化产品的设计有一个基本原则就是“以用户为中心”,与之相对的是传统的以产品(服务)为中心,自古就有“好酒不怕巷子深”。这个转变是数字化时代的一个显著标志,意味着服务模式从过去用户找服务的“PC”模式,转变到现在的服务跟着用户走的“移动”模式。从表面看不管哪个模式,咱们产品设计都得做到用户满意,但实质上这两种模式对“用户满意”的定义存在着很大的区别。

在PC模式下,用户带着自己明确的述求,如查询一个感兴趣的商店,找到一台可以提供这个服务的电脑,然后访问你提供的服务完成自己的查找。在这个过程中,作为服务设计者需要做的是让你的用户感受到服务的高效,比如根据用户提供的模糊信息就能够组合出可能的匹配,甚至根据历史数据智能补全查找。如何能够更加高效的完成用户的原始诉求,就是“用户满意”的定义。

当我们来到现在这个数字化时代,如果你仅仅关注上面的满意度,那么你很可能连生存都无法持续。每个用户的智能手机里,在每一个常用领域都会有好几个同质应用,能够满足用户的基本诉求。就拿“查找感兴趣的商店”这个常用需求来说,我们都可以轻松列举出一打应用。这个时候,好的产品经理都会去探究这个诉求背后的动机是什么,用户为什么想要找这样一个商店——是某人生日临近希望采购礼物,还是最近朋友圈的流行触动了购物神经?当今这个时代,消费者并不是一定要到商店里,才能体验自己想要的东西,虚拟现实已经能够让用户足不出户就完成对新事物的体验了。于是我们看到设计上更加端到端的思考,追溯用户产生这个诉求的源头,并抱着颠覆性的态度去挑战我们的惯性思维。

图:产出案例,ThoughtWorks通过更加场景化的Service Blueprint来分析针对特定用户的服务设计(点击查看清晰大图)

在这种思维模式下,用户无疑是幸福的——可能连用户自己都还没意识到的问题,设计者们都已经悄然解决了,而且还不断创造出新的生活便利,给用户带来惊喜。但对于我们设计者来说,实际上却是非常挑战的——面对的问题域从原来确定的服务范围变成了现在前后延伸的探索,面对着更多的不确定性。Slack这样的协同办公平台,却诞生于一个手游开发公司,这样的事件越来越多。当我们尝试着去深挖用户每个诉求背后的意图时,不同的设计者针对不同的用户可能产生截然不同的方案,于是在同一个领域里我们看到很多的细分和创新,即使在最常见的如短视屏分享领域,我们也看到了从美拍到抖音的不停演进。

这种“以用户为中心”带来的不确定性,虽然给设计者们带来了挑战,但对于我们这个时代来说,却是美好的——因为这样的不确定性,赋予了我们创新所需要的“边缘”。

发散思维应对不确定性

生在这个创新的时代,不确定性是我们必须学会去驾驭的,但我们从小到大的学校教育却很大程度上限制了我们的认知。从简单的数学计算到复杂的物理化学,我们一直在学习着各种确定性的定律,并尝试着在遇到问题时应用这些定律来解答。

然而,这个时代下的设计是不存在教科书式的定律的。即使乔布斯的设计理念,也并非是金科玉律,iPhone也没有能够坚持他的3.5in 屏幕大小,更不要说未来可折叠屏幕出现后会有完全不同的用户需求。显然,我们在学校建立的学习模式失效了。如何设计,并没有现成的解决方案可以供我们参考。

那么如何应对这样的不确定性,从而产生创新的设计呢?答案其实很简单,学会发散思维。这里的发散思维有以下几个特点:

  • 挑战问题本身:我们应该避免把 “用户说的 … ” 当成问题本身。用户对问题的描述常带有一定的随机性,在数字化这个虚拟世界里更带有很大的想象成分。所以好的设计师都会告诉你,用户其实并非很清楚他或者她真正想要什么。花时间来分析问题本身是必要的,针对一个错误的问题,设计再好的解决方案也只会让情况变得更糟。
  • 拥抱多种设计:在高度不确定性的情况下我们希望看到不同的设计,从而能够加深我们对问题本身的理解。在用户没有亲身体验的情况下,我们从用户那里得到的任何设计反馈,只能当作假设,而假设是需要被验证的。数字化场景下,得益于技术的持续进步,我们会看到针对一个用户需求的多种设计,往往都会被做成原型来进行真实的用户测试,通过测试收集反馈数据,来作为设计决策的依据。
  • 尝试协同设计:战胜问题不确定性的另外一个好办法,就是动用更多的大脑。我们都知道在形成一个有效的讨论时,集体智慧往往会达到1+1 > 2的效果。当然这里有两个先决条件:一是我们能够为每个人创造独立思考的空间,不至于每次都是屋子里“最聪明”的人完成所有决策;二是我们都能够抱着感激的心态,去看待每个人思考方式上的差异,认可这种差异是我们能够产生更大集体智慧的基础。这样的要求反过来也制约了我们每次讨论小组的规模,比如10个人以上时,你会发现很难满足要求——给每个人独立思考时间,太多的思考方式差异造成很难达成基本的共识,大家很快变得烦躁,整体时间被拉长,以至于造成浪费。如何协同本身是一个很值得深入讨论的话题,基于多年的实战经验,ThoughtWorks也把这样协同设计实践进行了提炼,包含在了现在很多企业和组织都采用的数字化产品能力框架中。

学会发散思维,能够帮助一个团队和组织去认知这个时代的不确定性,而正是这样的发散思考才会产生创新的想法和设计。这样的例子在我们身边已经变得常见了,一些产出的设计甚至会让我们感动,比如为乡村留守儿童设计的智能纽扣,为盲人设计的智能手杖。在这些设计中,如果设计团队没有花功夫去理解问题本身,不去持续发散可行设计并持续验证,是不可能最后找到这样创新的解决方案的。

没有唯一真理的用户体验

当我们通过发散思维找到可行解决方案后,就需要真正设计出用户可以使用的产品和功能了。假设我们对设计问题本身的认知是准确的,这个时候设计是否成功就取决于用户体验了。用户体验在互联网时代已经被提升到了最核心的位置,以至于类似腾讯这样的互联网公司的任何产品讨论,都需要围绕着用户体验展开。

谈到用户体验,仿佛人人都能谈出一些自己的观点,甚至原则,但体验本身却是非常主观的。举个例子,我们经常都需要将文件从手机传送到电脑上,这样的一个简单需求其实已经有很多的设计实现了——作为苹果手机和电脑用户,有不少人可能和我一样都喜欢“隔空投送”这个功能,使用习惯上类似于拷贝和粘贴。而我的家人却不喜欢这样的设计,感觉这个功能本身是“隐藏”的,每次都需要思考怎么找到这个功能,相比之下她们更喜欢微信的“文件传输助手”,每次只要在电脑上登录微信客户端,在手机端就会出现这样一个文件夹标识。

我们身边这样的例子比比皆是,有兴趣的读者可以问问身边同事和朋友们对摩拜和ofo两种单车设计的体验,你会发现很多非常有意思的独特观点。这说明在用户体验上,我们是找不到客观真理的,当一部分人嘲讽苹果AirPods是断了线的耳机时,在另一部分人中却成为了时尚。坏的设计或许是容易共识的,但好的设计却仁者见仁、智者见智。评判用户体验的好坏,由此也变成了一件相当难以达成共识的事情。

对于设计师来说,不仅仅是设计问题和挑战的识别,还需要一个具体的设计方案来落地交付给用户。用户不可能为了解决一个问题同时上两套解决方案,让用户同时戴上两幅耳机无论如何都是最差的体验。如果用户体验是主观的,那么,是不是就无法做出更好用户体验的设计呢?

收敛思维聚焦用户体验

在具体设计选择时,我们必须想办法让团队就用户体验达成共识,这显然是一个漏斗收敛过程,重要的是建立筛选的原则和方法。我时常举的一个经典案例,是2007年的第一代iPhone。它缺乏了对于我来说最基本的短信群发和文字拷贝功能,直接造成的后果就是我在新春发拜年短信时根本无法使用。就这样的设计选择,到底是明智之举,还是瑕疵失误,是我最爱问大家的问题。

显然,乔布斯是经过了缜密思考的,毕竟iPhone作为一个跨时代的产品是颠覆性的。那么是什么原则让他第一次发布时放弃了这两个对于我来说很重要的功能呢?答案其实非常明显:用户! 2007年第一代iPhone不是为我、或者说中国用户设计的,针对的北美用户当时少有像我们这样依赖于短信交流的,对他们来说手机更多是用来打电话的。

所以在我们具体设计选择时一定要认准核心用户,明确目标群体的诉求,从而能够更有针对性地设计用户体验。设计上最难的就是取舍,而取舍里最难的就是选择用户。这里的一个核心原则是不要贪多。很多团队分析核心用户时,想方设法纳入更多可能的用户群体,这实际上是在“自欺欺人”——因为良好的用户体验一定是非常有针对性的——别忘了,在这个数字化时代,我们的服务是围绕每个用户个体的。

当我们锁定核心用户后,需要更仔细的分析用户可能的使用场景,找到核心用户的核心使用场景,这同样是一个收敛过滤的过程。比如前文提到的AirPods,如果是为了运动场景设计的,可能就不会是现在这样无绳设计了。用户的使用场景决定了他们的体验和感受,在嘈杂环境里听音乐和在会议室里打电话,需要的良好体验是截然不同的,从而驱动出来的设计也会是不同的。

在收敛思维下,我们应该学会以下的思考方式:

  • 价值驱动:不论用户、还是使用场景的取舍都是一个非常困难的决策过程,在我们协同设计的要求下,团队(甚至包含用户)达成共识是这个过程最重要的产出。由于个体的思考方式差异,大家看待问题的视角不同,想要形成共识就必须遵守一定的设计原则,而这样的原则提炼本身是困难的。我们能够确定的最重要的原则是整个收敛选取的过程都应该从用户价值出发,在选取核心用户时明确哪类用户会得到较大收益,同理哪些使用场景会给用户提供最大的价值。
  • MVP设计:作为精益思想的应用,《精益创业》中的MVP很好的表达了以用户为中心的产品规划方法。MVP的核心实质是从工程思维到用户思维的转变,如下图所示,在追求快速用户反馈的“小”产品规划中,每次都能够思考那个让用户感受极致愉悦的“one more thing”。产品设计同样应该采用这样的方式,纠结于基本功能的“完备”而忘记了真正的客户价值,是我们在收敛过程中最大的敌人。

(错误的MVP模式【左图】;正确的MVP模式【右图】)

学会收敛思维能够帮助一个团队和组织去驾驭设计过程中的不确定性,把有限的精力和时间集中到最高的客户价值点上。数字化时代的创新,必须关注用户体验,小到已经普遍的“点赞”,大到刚开始流行的“刷脸”,所有能够为用户所喜爱的设计都需要经过严格的筛选和验证。而数字化技术的进步给了我们越来越多的设计可选项,如何有效收敛就成为了一个关键设计能力。

(图:ThoughtWorks从快速低保真原型,到中保真线框,到高保真视觉及可执行MVP的完整实践示例,整个过程以天为单位进行快速迭代。)

设计思维驱动创新设计

我们大脑左半球是指挥逻辑推理和语言表达的,右半球却具有空间、形象的思维功能。理论研究及实践都证明,在创造性思维中起重要作用的思维形式大都是非逻辑性思维,主要由人的右脑控制。

在我们的发散过程中需要很多右脑的能量,而在收敛过程中左脑的逻辑推理发挥着重要作用。当然这并不是说我们的整个设计过程分成了前面的右脑发散部分,和后面的左脑收敛部分。实际上在我们的每一个设计环节和实践过程中发散和收敛是快速交替进行的,比如我们在定义核心用户的时候,首先是采用发散的思维找到可能的用户分类,然后才是从价值及其它维度去收敛核心的用户群。下图是ThoughtWorks在实践过程中的4D模型总结,已经为很多团队和组织在实际产品设计过程中所采用。

(ThoughtWorks设计思维4D模型)

从创新设计角度看,我们采用的发散收敛方法实际是把设计思维(Design Thinking)付诸于实践。设计思维现在已经广泛应用于创新这个具有高度不确定性的领域,而在数字化领域,我们更是将这样的基于解决用户客观问题的思维方式作为我们设计的基础,从而能够在用户、业务和科技三者之间达成平衡,不仅让创新发芽,而且能发展成为规模化业务。

数字化创新领域的核心在于设计,而设计的难点在于洞察用户,及更广泛的、跨领域的协作。我们相信创新设计这个领域,将产生更多的方法和实践,让我们共同前进!


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

Share

数字化转型改变了什么?

[摘要]

在人人都在呐喊数字化转型的当下,我们有必要明确什么是数字化企业,数字化企业具有什么样的关键特征,打造数字化企业的关键支柱是什么。

数字化是时下炙手可热的话题,这两年可能没有哪家企业不在战略规划里提到数字化的。但数字化的具体定义,各行各业却是百花齐放,唯一能达成共识的,就是狠命上IT系统。很多人认为,数字化转型是一定要搞出比竞争对手更完备的IT平台。虽然,这有利于IT行业的蓬勃发展,但这样的视角也是危险的,几乎一开始就设定了一个失败的方向。

在总结了这两年的相关咨询经验后,我们希望提炼一个数字化企业模型来帮助大家理解数字化转型的真正含义,并且能够了解转型背后的商业动机。为了便于理解,我们努力让模型保持精简,尽量保证每个模块都能够指导管理理念上的转变。本文中我们也就这个模型和大家一起来分享对数字化转型的一些认知。

数字化企业是什么样的?

既然是转型,那么我们就需要理解TO-BE的模式是什么样子的,这样才能够指导转型的方向,逐步建立一致的愿景。而这个愿景在抽象层面上是高度统一的,就是“客户中心”。在市场经济环境下以客户为中心已经提了几十年了,依稀记得儿时一些前卫的商家打出“客户就是上帝”的标语来吸引买家。但数字化时代赋予了客户中心非常不同的含义,客户为中心不再是简单地收集客户反馈,持续提升自身服务;而是更加全面地发掘客户深层次的需求,创造性地拓展服务领域和服务方式,完成与客户的共同成长。

(数字化企业模型)

客户在这个数字化时代是幸福的,因为商业市场的权利转移已经成为了事实。服务的“PC时代”,即每个客户如果想得到数字化服务首先是要找到一台能够上网的电脑,已经一去不复返了。取而代之的是任何客户可以拿出自己随身的智能手机(甚至于穿戴设备),获取各种各样的服务,同质服务的竞争已经围绕着每一个客户展开,甚至各个服务商都喊出了争夺客户注意力时间窗(moment)的口号。对于提供服务的企业来说最重要的就是能够抓住客户瞬息万变的需求,如果能够在此基础上创新便成为了企业的核心竞争力。这样的竞争力在战略上我们称之为“实时战略”。对比经典的战略理论,我们追求的目标既不是低成本,也不是市场份额,而是针对用户市场的响应力。前两者某种意义上是高响应力企业必然会获取的优势。

建立这样的战略能力是一个企业自我颠覆的过程,当海尔的领头人张瑞敏开始出来分享“人单合一”的模式时,他们已经实践了超过10年。最大的难点就在整个组织治理思路上的巨大转变,从过去定岗定员的固定式组织结构,向灵活适应性的敏捷生态圈演进。一听到生态圈,很多人会比较反感,最近各大知名“生态圈”都出了问题。我们这里定义比较简单,不是啥化学反应,而是一个共享共同愿景的小团队集合体。这种形式下驾驭规模化的思路是愿景统一下的团队自治,在统一的企业愿景和灵活的小团队差异之间找到平衡。

这样的组织毫无疑问是生机型文化的代表,而这个科技时代又要求我们有追求技术卓越的组织特点。这里的“技术”不应该狭隘地局限于写写程序,或者摆弄两下电路板,而是更加全面的从用户体验到产品设计的匠艺追求,一言以蔽之为“止于至善”。为什么这个时代我们会如此强调这种追求卓越的匠艺精神呢?原因来自于我们这个时代的不确定性,这种不确定性很大程度是由科技的快速应用产生的,而如何应用及在什么地方应用很大程度上不可预期。为了适应这样的不确定性,我们需要能够在科技领域持续学习。学习本身并非是一件易事,更别谈持续,为了让组织能够建立持续学习的氛围,鼓励大家在技术上追求卓越就成了一种非常有效的方法。

总结我们本章节的问题:数字化企业是以客户中心为基础,以科技为引领,在统一愿景下建立了实时战略机制和敏捷生态的生机型组织。

下面我们就从这几个维度来看看数字化转型给企业带来的转变。

一切从用户出发

产品经理是时下最热门的岗位之一,锤子手机的创始人老罗经常说的口头禅就是“你们IT人做不好用户体验,那就让我来当产品经理吧”。老罗这句揶揄的话里存在一个很有意思的对比,谈到IT大家首先想到的肯定是一帮工程师们,然后的场景是在电脑上敲打着各种命令,最后说可以工作了,旁边的非IT人士们一脸茫然。而这些非IT人士们在现实生活中就是我们的用户,在iPod之前的那个时代我们设计的系统可能都需要厚厚的说明书,用户需要参加几天的使用培训。对比这个数字化时代,用户可能连一页“快速启动”都不愿意再看到,开箱即用成为一个数字化产品的标准体验。

显然期望产品经理都是乔布斯是不可能的,即使标榜追求匠艺的老罗领军的锤子手机在市场上也是褒贬不一。我们必须面对的一个现实就是数字化产品并非团队中某一个人决定所有细节的,这个时候避免工程思维里的“可以用了”就是一个非常挑战的任务。即使外形越来越漂亮的机顶盒,调节音量也始终是两个遥控器的事儿,经常家里会传来非IT人士的怒吼“为啥音量最大了还是听不见!”。

所以我们这里说的客户中心、从用户出发,要求产品团队、甚至整个组织的所有人都以此为自己工作的准则。从这点出发就不难理解刚开始的小米为什么要求每一个员工都泡论坛、聊用户、找需求了。当我的印度同事来华第一件事情是去采购小米手机的时候,人人都是产品经理这句话就彰显了其市场价值。

客户为中心是一件知易行难的事情,当你走入自己的产品团队要求大家每周有一天调研观察用户的时候,答案很可能是“我手上的功能很紧张,这周必须交付”,“产品经理上周去过了,刚收集了反馈回来”,“我们还没有上线,不知道确定用户” … 而实际运作过程中你又会发现业务和IT的部门墙,领导下达的关键任务等阻挡着你的前进。这一点的改变牵动着整个组织的转型,而万里长征的第一步就是改变现有以完成工作任务为导向的工程思维,转而关注用户价值创造的成效思维。已经有很多业内的具体实践沉淀了下来,但关键一步是如何打开组织每个成员的心扉。

小编注:ThoughtWorks在帮助全球企业进行数字化转型的过程中也积淀了一套自己的落地实践,我们最近也将通过创新管理公开课的方式在国内和大家交流。

战略上的快

战略往往是关系企业生死,是非常严肃的话题。这样的定位在过去很长一段时间把战略制定变成了一件神秘而繁杂的事情。一些大型企业的战略制定需要数月到半年的时间,然后分解执行又需要大半年,最后的结果是还没有开始执行既定战略,市场就已经改变了。

这样的情况在这个加速变化的时代给很多企业带来了困扰,跟上市场的节奏意味着没有时间收集和论证各方面的细节,而不通过细致的辩证又如何保证战略的正确性呢?这个悖论带来的直接结果就是高层战略制定者和一线战略执行者之间的脱节,企业成了实际意义上的走一步看一步,企业自身的愿景和目标成为了摆设。

这个悖论的核心实质在于对战略“正确性”的重新定义。如果我们从一个实验的角度去看待数字化时代的战略及投资,正确的含义就从简单的是否为企业带来了利润,变成了是否为组织注入了新的经验。世界著名的协作平台Slack就是由一家开发塔防游戏的公司在自身演进过程中“转型”得到的,而这家公司在认定了Slack这个成功经验之后,也已经放弃了自身过去的游戏开发主业。这样的例子在互联网企业中并非个案,成功的企业家和管理者懂得如何去认知这个时代的反馈,将反馈快速转换为组织经验,然后快速指导企业战略上的调整,从而产生很多意想不到的收益。

在这样的游戏规则下,我们的战略不是一种计划,而是一种构建。这个构建包含了我们对一系列“实验”的定义,及相应的投资。这些实验对比过去的计划时间更短、投资更少。好的实验一定是围绕客户价值创造展开,并且有明确数据度量的。在这个看似简单的转变下却是决策者战略认知的根本转型,这也是为什么ThoughtWorks开始关注这一类的领导者,并总结出胆识型领导者的原因。

进化型组织

进化论是我们已知最可信的人类演进认知,两个核心观点是:随机变异和适者生存。生物的基因变化是随机发生的,而“筛选”这些突变的条件就是看能够适应于当时的环境,适应者被保留了下来,而不适应者就被淘汰。最近传遍朋友圈的德国鳌虾就是发生在我们身边的神奇进化案例,几十年的时间就依靠变异出的自我复制能力征服了欧洲的水域。

第四次工业革命给我们带来“无限可能”的同时也带来了无法预知的未来,从一个较大的生态来看我们很难预期会有什么样的改变,以至于凯文·凯利这样的未来学家成了大家追捧的时代“占卜师”。而什么样的创新会最后改变我们的生活工作只能从趋势和大方向上去分析。这个时候我们的组织就需要更强的适应能力,我们形容具备这样高响应力的企业为敏捷组织

在这个维度上对很多企业最大的挑战是组织结构上灵活性的打造和组织愿景方向的统一。在过去几十年的改革开放过程中,中国很多大中型企业都逐步建立起了相对完善的组织机构和流程规章,稳定的架构为这些企业提供了业务运作上的主干保障。然而稳定也带来一定层度的僵化,逐渐失去了对市场变化的响应能力。如何在稳定和灵活之间找到平衡是现代组织管理者面临的最大挑战,银行就是时下面临这样压力的一个典型行业。

科技与创新

关于创新的认知是时下最重要的话题之一,过去的20年让我们见识到了什么是颠覆式创新,什么是“黑天鹅”。对于我们绝大多数人来讲,包括很多企业的决策者,创新是很难规划的。数字化时代的创新根基来源于科技的应用,而技术的应用已经打破了我们现有行业的划分。作为一个想在数字化时代发展的企业来说,势必需要在科技创新方面做出尝试,除了前面我们提到的在战略制定和组织结构上的转型之外,还需要在科技领域做些什么呢?

在前文解释数字化企业的框架时我们已经提到了技术卓越方面的要求,我们可以认为这是一个文化平台,要求组织围绕新科技建立持续探索和尝试的机制。这不是简单的每年搞两次黑客松,或者让员工去开源社区做点贡献,而是从组织文化层面建立对探索和创新的鼓励,并搭建一个赋能平台,让有意愿的员工有机会去应用新科技和新实践。

在论述新的战略方法时我们提到了快速实验,作为组织在科技方面的第二个平台就是数字化平台,这个平台能够较为全面的支撑实验的落地,以低成本的方式获取有效的实验结果。ThoughtWorks通过对多个行业的总结,提炼出了如下的指导框架,帮助大家理解数字化平台的目标和功能。值得注意的是这个平台的构建原则最核心的一条是:始终保持一个“活着”的平台,即从构建的第一天起就应该尝试着尽快推向用户,这个平台也必须实践客户为中心的核心原则!

(ThoughtWorks 数字化平台战略总结及从各平台中获得领先优势的典型企业)

让体系化创新成为常态

第四次工业革命的时代,“变化是唯一的不变”成为了我们工作的基础。这个基础同样适用于我们的转型工作,这次转型的最大挑战就是无法描述一个确定的终点。对于和我一样理工科出身的从业者来说是需要持续的认知调整和适应的,正如这一波的人工智能应用已经和20年前的尝试有了非常本质的不同,大家不在寻求某个固定的算法(或者更好的算法),而是尝试在大量的数据里去应用不同的算法从而找到一些客观的规律,更有甚者这些规律本身也并不要求我们人类可以理解。

我经常揶揄和我同辈的顾问们会被拍死在数字化的沙滩上,我们身边的90后、00后们实际上已经展示出了对这个时代不确定性的适应性。他们展现出了更强的自我创新意愿和能力,而我们需要给予新一代的是更宏伟的愿景,和更灵活的支撑。只有通过这样的努力我们才能在未来的组织中凝聚充满创新思维和热情的生力军们,形成组织级的体系化创新能力,让创新成为新常态!

最后,希望我们能够通过这个框架和大家建立更多的交流,共同来揭开第四次工业革命的新篇章。

点击这里或者长按图片识别二维码报名“规模化创新管理课程”


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

Share

顾问、老师及教练

由于工作的原因,这些年接触了很多的公司和团队,大家对我的称呼也各不相同。有叫肖顾问的,有叫肖教练的,还有叫肖老师的。最近一直合作的一个企业举办了规模不小的教练大会,引起了我的一些反思,于是想撰文跟大家分享一下在教练、顾问和老师这三个头衔上的认知,不一定正确,权且写出来跟大家切磋。也希望能唤起正处于数字化转型时代企业对自身教练力量建设的关注。

解决问题的顾问

实际上我的工作多是顾问,邀请我的企业或团队一般都希望我能够带领他们解决某些“问题”。为什么问题要用引号呢?原因是很多企业和团队初始描述的要求其实不是问题,比如“我们没有单元测试,帮我们搞TDD吧”。作为顾问,我要做的第一步是发现真正的问题,当然这个过程中有很多技巧,并不是本文的重点,按下不表。

作为顾问的一个基本要求是很了解自己的行业,并且有不少的相关经验,比如企业请我去一般都是做软件产业相关的工作,决然不会请我去做投资管理顾问(显然我自己也错过了比特币)。原则上顾问工作是给出客户面临的客观问题和挑战(也包含组织及团队的赋能问题)的解决方案。

从纯粹意义上讲如果已经给出了详细可落地的解决方案,顾问的工作就完成了。可能由于我个人资历尚浅,解决方案即使得到认可也还是被要求必须负责落地执行(至少一个试点团队是必须的)。我也见过不少银发顾问给了一个PPT就能够赢得客户最终认可的。当然在软件行业可能这样的情况会越来越少。

所以顾问这个头衔在我的认知里就是一位能够帮助企业和团队发现自身问题根源,并设计解决方案的人。

推动改进的教练

为什么不少项目上也有人叫我肖教练呢?想想大抵是因为不仅仅给出了一个自认为合理的解决方案,并且需要带着核心人员实施。为了能够落地解决方案,一般我会要求客户团队成立教练组,和我一起来承担改进任务的执行和反馈调整。这个时候大家自然也开始叫我教练。

教练这个头衔比较有意思,一般客户方负责人都会问我咋选教练,经过这两年的揣摩,我个人比较认可两点:第一、主动交流沟通好的;第二、自我驱动推动能力强的。注意这里我并没有要求专业能力,比如需求管理改进并不一定是一位资深的BA来作为教练。

为什么这样要求呢?因为改进工作无疑是破旧立新的一个过程,无论是烟斗曲线还是U型理论实际都告诉我们这是一个先抑后扬的过程。即使咨询顾问给出的解决方案是百分百正确的,也可能因为下挫的过程中无人扶正而被团队所放弃。

(图:著名的改变烟斗曲线,每个改变都要经历一定时期的痛苦Frustration和挣扎Depression。而这个下挫的过程是最需要关注和扶正的。)

一些组织确实能够通过行政手段保证下挫的过程中也可以“削足适履”的落地,但确实极其少见,也不建议效仿。大多数组织都需要一帮专注改进方向、持续鼓励团队的教练。而且很多时候这些教练还需要专职专用,把推动团队改进、扫除改进障碍做为自己的工作目标。

有人会说“程序员激励师”就是教练了!如果你的改进目标是让几个开发人员自信心爆棚,多写两三个功能,确实也可以算。但改进工作其实是很严肃的,事关一个组织未来的存活,目标也是全组织共享的,涉及整个组织各个角色和部门。这个时候不是简单让几个员工“high”两天就能转型的。所以教练也是一个长期工作,需要卷起袖子和团队一起实干落地。

那如果没有相关的专业能力,怎么能够落地呢?不少同事和客户都知道我也经常调侃高谈类似打坐参禅的业内“教练”为“走心流”。原因当然不是我想用“你会写Scala吗?”这样的问题去怼人,而是教练的核心工作是去务实的影响一个正在改进道路上下挫的团队,让他们坚定信心和方向。在这点上不是教练个人的修为重要,而是如何影响团队重要。如果参禅打坐能够感染团队,提升士气,实际上也无妨。但咱们这个行业毕竟有很强的工程学基因,恐难完全从悟道的角度去解决问题。

然而这并不是说教练一定要是某个改进领域的技术专家,而应当是一个引导者:这个引导者能够帮助团队建立改进的共识,持续反思改进过程中的问题;同时又是一个催化者:像催化剂一样让团队能力得到放大。催化剂这个说法《人件》中早有论述,我认为应该是一个教练的终极目标!

比尔盖茨在自己的TED演讲上说“所有人都需要教练”,论述了包括老师在内的每个人都需要一面会说话的镜子,才能够持续提升。良好的教练可以根据团队或个体希望改善的具体领域提供可行的见解和发展机会。这个改进的过程中目标必须清楚,成功标准必须明确。 但不管是改进目标还是成功标准,都不是教练制定的,而是改进团队或个体在教练的引导下完成的。

传授技艺的老师

老师也许是我最早的一个工作头衔,大学勤工俭学的时候,助教是我最喜欢的一份工作,每次上完一堂辅导课总是感觉一天十分充实。然而经常的困扰是学生们提交上来的作业五花八门,看得哭笑不得的也不在少数。

从那个时候到现在我都还是比较相信“没有不愿学习的学生,只有不会授课的老师”。当然老师并非是越资深就越会授课,比如我敬爱的博导一辈子都不喜欢授课,反而每年给了我很多机会去体会怎样做一个好老师。一个好的老师能够把一个知识点用不同的形式演绎给学生,让整个课堂的氛围变得活跃,有时候甚至是学生们自己在推着课程一步步深入。

对于我的导师来说讲课是痛苦的,因为总是要求他年复一年重复类似傅里叶变化这样的公式,但对于好的老师来说,每年可能都会有新的角度来讲授看似死板的公式。某种意义上这是对技术知识点认知的一种深入,把认知本身做为了一种匠艺来追求。正是在这方面的兴趣,促成了教学上的热情,把认知的传递作为了工作的回报。当然这样的人其实并不多,也是非常难坚持的,如《中国合伙人》中的主角成东青把终身热情奉献给讲台的老师是值得尊敬的。

不同的胜任力要求

回想自己的工作,其实即使在一个项目上也可能随时切换角色,比如调研分析时我是一名顾问,试点项目上我是一个教练,规模推广时我成了一名老师。但既然分析,就希望能够看看这三个角色有啥不同。我首先想到的是各个角色在胜任力方面可能要求不同。

尝试着列举出了一系列胜任力,发现其实重叠的不少,附件中也有一个小调研(金数据表),很想听听大家的意见。为了找到不同,迫使自己用单一指标的方法来“区分”到底这三个头衔有什么不同,于是产生了下面针对每个角色我认为最重要的胜任力。(记住单一意味着我只给自己一个选项,类似“交流沟通”这样的共性能力都只能被“无情”地去除了。)

选择胜任力时我采用了Workitect公布出来的通用的胜任力字典。我的选择如下:

  • 顾问:概念思维(Conceptual Thinking)—— 从一个整体视角,一定抽象层面或理论高度来寻找有效的解决方案。
  • 教练:赋能他人(Empowering Others)—— 表达对团队取得成功能力的信心,特别是在挑战新的任务方面。 委托重大责任和权力,让团队自主决定如何实现目标并解决问题。
  • 老师:技术专业(Technical Expertise)—— 在技术领域的知识和技能的深度。

欢迎大家通过链接的表格给出自己的选择!

(调查表二维码,欢迎告诉我们你的选择!)

从某种意义上讲,顾问是问题解决者,老师是知识的传授者,而教练则是改进的引导者。解决问题需要从整体出发,能够通过概念思维进行一定的抽象来找到有效解决方案。传授知识则需要对知识技术有系统理解,才能深入浅出地诠释一个专业方法。改进引导如前文所述更多是赋能被改进的团队,让团队建立起追求成功的信心。

按照这样的胜任力分析,我们可以进一步找到三个角色在工作模式和成功标准上的不同。

不同的工作模式

《精益企业》作者之一Barry在最近的一篇博文中指出了教练的重要性,他从客户(聘用方)和服务提供者(受聘方)在工作过程中的信息输入对比了这三个角色。我们在这里借用他的分析产生了下面的图示模型。

(图:角色的工作模式)

教练被放到了最左边,在教练的工作模式下,客户(团队)的输入占比是很大的。顾问被放到了最右边,在顾问的工作模式下,服务提供者(咨询顾问)的输入是绝大部分。这显然是成立的,在改进的上下文里,解决方案是由顾问独立设计和提出的,而具体的目标和标准则是团队共同决定的。

从信息输入角度我们可以看到这三个角色工作模式的差异。教练需要更多的团队交流沟通,启发大家产生更多的想法。顾问需要深入的自我洞察,从系统的信息收集中找到解决方案。而老师则需要持续的双向沟通,掌握学员们的学习状况,并作出相应的调整。

实际工作过程中,我们会看到好的顾问总是在侧面观察和系统分析,好的教练则奋斗在团队的一线,在实际工作中给团队提供反馈和启发,而好的老师能够让自己的授课充满互动,以检查学生们的认知。

不同的成功标准

按照咱们这里的定义,这三个角色的工作产出是比较明确的。但实际工作中往往很少有人能够真正思考清楚请的是老师还是顾问,所以出现文章开头我的三个称呼。就时下大家最关注的数字化转型这个话题来看,显然这三个角色都是缺一不可的。

企业在进行数字化转型的时候首先需要明确市场的趋势和技术的进展,这个时候聘请外部顾问来拓展认知,明确初步的转型路径是必要的。当转型的决策者们建立了一定信心后,老师和教练这两个角色就成为了推动改进工作的关键。转型实施过程中需要老师来给与正确的工作方法,需要教练持续深入的鼓励和反馈。

从上面的简单描述不难找到各个角色的成功标准:

  • 对于顾问来说,提供业界的洞察,找到适合于企业的转型方案是工作的目标。顾问工作的成功意味着帮助企业找到了从上至下共识的转型路径。(注意这个路径只是一个起点,而不是终点。所以这个阶段共识重于正确。)
  • 对于老师来说,打开团队的脑洞,带领团队学习新的工作方法和实践是目标。老师工作的成功意味着团队看到了新工作方式会给他们带来的优势,愿意尝试自己去实践。
  • 对于教练来说,鼓励团队改进,并提供有效反馈,持续纠偏是重点。教练工作的成功意味着团队持续向着转型的目标前进,并建立了持续改进的意识。

说到这里,也想给很多正在焦虑于如何开展转型工作的企业一点建议:转型本身就是一项复杂工作,选择合作伙伴的过程中应该保持开放,理解这三个角色需要发挥的作用。没有一个人可以是所有方面的专家。

相同的专业历练

以上谈了我认为的三点教练、顾问和老师的不同,尝试区分这三个头衔。当然很多时候这些称呼都在被混用着,那么它们之间有什么相通之处呢?

这样的头衔同时也存在于其它行业和领域,我们会发现在一个领域里,教练不一定是最好的技工,比如NBA禅师杰克逊是一名伟大的教练,但之前并非是一名如科比一样的篮球巨星;而在各个运动专项上,比如力量、速度,又都有专门的老师。这两年也有不少顾问通过历史数据的分析来告知球队存在的问题及可能的改进方案。这样的场景其实也可以类比到咱们IT行业。

显然教练和老师都有很强的相关领域背景和经验,老师还需要在这个领域的某个具体方向上有比较独到的见解。就上面的例子仿佛顾问不需要多强的领域背景和经验,看数据分析就可以了。但我们知道能够从数据中看出门道的顾问十有八九都是同领域出身,就好像某项体育赛事的解说员都会邀请该领域某某著名运动员。即使央视体育频道的名嘴,至少也是球迷出身,自己私底下的学习和分析可谓数十载。

对比体育等成熟产业,软件和数字化领域显然拥有更大的不确定性,甚至没有一个顾问能够告诉你确定的产业发展方向。从这点出发不管是顾问、教练还是老师都必须重视持续的专业历练,脱离专业很快就会被淘汰。在数字化产业里还没有拉格朗日方程这样的公式,认知的刷新往往是一日千里的,作为老师我也经常告诉大家去年的实践只能是今年的奠基石了。

正是由于强调持续的专业历练,所以数字化产业里好的顾问、老师和教练都是一将难求的。如何在辅导过程中保持不“拖媒”是每一个从事上述工作人员的挑战。所以我经常还是建议刚刚起步从事教练工作的同仁们不要离开一线,在解决客观工程问题的过程中保持团队赋能和自身专业历练的平衡。时刻坦诚自己不是所有方面的专家,在动手的过程中持续学习和成长是教练自身修炼的必经之路。

最后也借此文呼吁大家提高对教练能力的重视。第四次工业革命才刚刚开始,这个过程中的不确定性意味着任何组织都需要做好持续改进的准备,而这个过程中能够持续赋能团队的教练队伍将是一个企业持续生存和发展的基础。未来两三年我们会在领先企业身上看到这方面的突出能力,而这样的能力建设不是短期花钱能够外购的。


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

Share

银行IT的敏捷转身

[摘要]

中国银行业的数字化转型才刚刚拉开帷幕,作为转型重点的银行IT部门正在经历从开发模式到组织定位的巨大变革。本文从时下银行IT广泛的敏捷转型开始分析,揭示了中国银行业面临的数字化挑战,分享了应对挑战的一些共识,同时给出了中国银行数字化转型的大方向。

数字化挑战

过去的3年时间里,我作为敏捷转型顾问,合作频次最多的,就是全国大大小小的银行。银行业IT这一波的敏捷转型,很多人会归因为互联网金融的冲击,认为银行业IT被迫从原来的内部职能部门走上前台,迎战外部市场的挑战。也有不少银行从业人员,对此持有不同看法:类似P2P这样的互联网业务,对中国的银行业还谈不上任何的冲击。在我看来,真正冲击中国银行业的,是以下两个方面:

  • 服务渠道的变迁——渠道从过去实体的网点向数字化渠道转移。注意,这并不是说所有的服务都变成了移动APP,而是所有的服务都会用某种数字化的形式呈现,比如现在到工行建行网点办卡都是通过一台综合服务机;交行几年前开始试点网点机器人,而招行已经在刷脸取款。由于银行之前是没有数字化部门的,所以这些要求自然跟IT挂上了钩。
  • FinTech的冲击——技术突破正在改变业务形态。最近火过了头的加密货币(比特币)正是这样的技术案例,它可能对未来银行业务产生颠覆性影响。在欧美很多利用智能技术做征信的平台也快速崛起,替代了传统费时费力的背景调查。对比之前的传统银行科技,FinTech拥有非常大的不确定性,这给习惯于购买成熟软件产品的银行带来了不小的挑战。当然由于又是科技相关,所以这口锅自然也得IT背了。

以上两点带来的变化显而易见,所以,无论提不提敏捷,银行IT都得转型。建立在支撑基础业务、保证业务稳定运行之上的IT部门,不可能自然而然演进成为“以用户为中心,思考服务体验,并保持对业界先进技术洞察”的新型数字化IT部门。下面就结合我过去3年中,近10家银行的顾问经历,谈谈这个转型中的挑战和可能的应对之策。

稳与快

我们辅导过一家外资银行,一上来就要求全球范围实施DevOps,“全面”敏捷。作为顾问,感觉很爽,改进起来气贯长虹。半年之后,已经没有不做敏捷改进的项目了,就连基于小型机AS/400的系统也都走上了DevOps的持续发布之路。

中国的银行业可就不是这样一个情况了。我和业内熟悉的几个人,经常开玩笑说“‘喝茶’就是悬在中国银行敏捷转型头上的‘达利摩斯之剑’”——高管们心里羡慕着互联网玩法的“小、快、灵”,脑子里却时刻担心着因生产事故被请去“喝茶”。转型需要经历烟斗曲线,当刚好处于曲线下挫点时,很可能因为一次事故而被全面叫停。一位银行科技高管曾经在内部会议上对我直言:“不要以为我不支持敏捷,正是因为我支持,所以才拉着你们跑慢一点”。

团队里有顾问找到我说不想做中国的银行了,太纠结,犹抱琵琶半遮面。于是我反问这位顾问,为什么中国的银行不能像外行一样一步到位呢?是因为太保守或者太官僚?一时问得对方语塞。其实,外行比起咱们可能更保守,生怕有一点负面消息,有的机构更庞大,更官僚。那么是什么原因,让我们中国的银行不敢“全面”敏捷呢?

就我目前认知,中国银行和外资银行有两点显著不同:一是中国银行集中精力办大事儿的构建方式;二是中国银行IT的历史定位。

如果我们对比中外银行的业务架构,会发现咱们的银行在业务设计上非常集中。这样的集中思路投射到IT系统建设上也是非常明显的:一般会考虑一套系统支持多条业务线。经典的例子是咱们的银行一般只有一套清算、核算平台,而外行每条业务线可能有自己的独立平台。集中建设的好处自然已经体现出来了,短时间我们就构建起来了一个相对完善的金融电子平台,但带来的问题就是系统非常复杂。

(图:中外行典型组织结构区别)

在敏捷转型过程中,有两个领域的复杂度是让我头疼的:电信和金融。大家可能想象不到,打通一次电话和完成一笔转账都要涉及近亿行代码!一条业务需求动辄要求修改十几个独立应用!咱们集中建设的银行系统显然不是随便就敢改的,早期即使在银行大型机系统上引入迭代开发都是很困难的。而这些系统往往又是银行的核心主干,任何小错误都可能造成致命的连锁反应。

在IT定位上,从国有五大行到各大股份制银行,基本都将IT归到了科技部下面统一管理。从组织结构上,可以看到IT的定位是一个共享的内部服务部门,或者说,是一个成本中心。最初的IT只是管理一些购买的商业软件和平台,并没有作为一个强自研能力的组织存在。银行IT的自有员工和外包人员比例,普遍都在1:6左右,一个主要的IT系统可能也就能投入两三个长期自有员工。到了现代,这个以科技为核心(Tech@Core)的时代,这样的人员配置显然已经捉襟见肘了。

以上两个因素,从技术架构和人员架构两个方面制约了敏捷的大规模推广。所以,银行想要“快”起来,往往不那么容易。各家银行的转型,都会选择相对新的技术领域,或和用户结合比较紧密的应用开始试点。而初期的转型目标,也会设定为“探索在现有约束条件下,如何进行敏捷模式落地”。最终,大多数银行都会走向“双模”:明确哪些系统和应用更看重业务表现的稳定性(采用瀑布模式),哪些更看重市场变化的响应速度(采用敏捷迭代模式)。

(图:源于Gartner总结的双模IT架构基本示意图)

理论上讲,“双模”只是一个过渡状态,这种方式也受到了不少专家的批评。“双模”可能会掩盖掉一些更深层次的问题,比如系统快不起来,根本原因其实是架构质量问题。从科技的发展趋势来看,确实止步于“双模”是不明智的,微服务化和平台化架构的逐步成熟会让以前稳定第一的系统也快起来。但就目前的约束来看,“双模”是已有成型建制银行IT的必经之路,其意义更多是在组织里植入管理不确定性的能力,从而构建对市场变化的快速响应能力。

效率与响应力

“唯快不破”是互联网服务发展的必备条件,而这个“快”其实是被很多管理者误解的。这个误解也造成了银行IT管理者们对“快”的提法有些许反感。这个误解的根源,在于对效率和响应力的混淆。

如果我们正确分析互联网成功服务的特质,就会发现他们根据市场变化推出和改变服务的速度特别快,而这个快很明确是在响应力上。举个日常生活中的例子,作为干洗店的客户,我们其实并不关心干洗店内部的效率问题(例如单位时间处理多少件衣服、干洗机的利用率等),我们关心的是干洗店能多好多快地把我们衣服洗好。

互联网时代给银行业带来的一个明显转变,就是从过去“以自身服务为中心”,到现在“以客户为中心”。从前在以自身服务为中心的时候,我们的管理方法及技术实践都是围绕效率来做的;到了这个时候,显然我们必须用客户的视角来思考问题,所以就需要更加关注响应力。当我们在追求效率的道路上走到一定程度,就有可能伤害响应力。比如为了干洗机的利用率,我们批量分类客户的同类型衣物放一个批次,显然这样的做法在订单达到一定数量的时候,会减缓每个客户的交货时间,让客户等待更久,伤害了对客户的响应力。

同理,这也是为什么在敏捷组织里,我们提倡少分角色、跨职能协作。当我们的分工过于细化时,对外部的变化响应能力就下降了。在传统银行IT系统里这样的情况是很普遍的,一个业务需求需要分解到十几个应用模块完成,而每个模块都只能由一个专人完成。

理解响应力的重要性并不难,但实践高响应力的管理却是相当困难的。银行业是一个重流程管理的行业,银行IT显然也继承了这样的基因。重流程标准化的管理方法,造成大家习惯性地进行自身局部效率的优化,实则增加了端到端的响应时间。我经常举一个发生在我们每天日常工作中的例子让大家意识到这个问题的严重性。

你是一位IT管理者,小王是一位认真负责的开发人员。一天他告诉你,现在项目A上他的工作进入尾声了,接下来只需要占用他一半的工作时间。这样的情况下,小王希望请示接下来的工作安排。在实际工作过程中,大家会赶快告诉小王启动项目B的工作,或者分配给他项目C的部分工作。假设小王启动了项目B的工作,很快他发现需要小李协助才能开展分析工作,而小李这个时候正在项目A上忙得不可开交。接下来有意思的事情就发生了,小王显然会要求小李配合,而这事儿如果真正发生了,显然就耽误了项目A的工期,那么项目A的完成时间就要推后了。小王和小李有可能找到你来请示工作优先级,然而,可怕地是,在你的意识里,会觉得这显然是“加加班”就能解决的问题!

于是,整个IT产业陷入了做不完的需求和越来越严重的内耗!

(图:小王工作安排示意,由于项目B的引入工作越来越多,成效却变少了)

实际上,如果我们认识到项目A的关键要素是快速推向市场,那么我们给小王的安排应该是让他继续专注于项目A,看看什么地方能够协助团队尽快完成项目。这个认知的转变是困难的:

  • 作为管理者,要放弃过去对人员利用率的执着,理解利用率和响应力不是正比关系,在一定阶段后甚至和效率也没有正比关系。
  • 作为员工,要放弃一个萝卜一个坑的工作模式,保持持续学习和跨职能工作的能力,把自己构建成一个T型人才。这个案例中,小王要能够帮助项目A的其它工作,就要求他具有开发之外的其它能力,比如测试。

在这样一个时代背景下,银行IT的敏捷转型,实际是基于以用户为中心的根本原则,加强整个组织的响应力。如果大家还在以“一个功能实现是不是更快了”来度量和牵引转型方向,那么请尽快调整到“面向市场和用户的端到端交付指标”上来。

业务与技术

懂业务是银行业人员晋升的关键因素。曾经在一次银行IT中层管理干部的培训上,我让大家举手表决是向业务方向发展,还是向技术方向发展,结果是全部都选择的业务方向。不可否认,银行业务的复杂度,要设计一套IT系统需要很强的业务理解。但数字化时代,技术成为了越来越重要的一个支柱,各银行组织如果不能快速构建技术人员的职业通道,必然很难在数字化上取得真正的收益。

我们从两个方面来看看中国银行业技术方面的挑战。

第一点是没有足够的技术封装。经常看到一个有意思的现象是,银行业务人员会看数据库,每一张数据库表就映射一张物理世界的报表。这样的设计结果往往是一张银行数据库表可能有好几百个字段。一段时间内,这样的设计是很流行的,因为沟通需求和最后验收都会相当顺畅,直接看数据库表就完成了技术和业务的交流。隐患就是,数据库根本就没有模型可言,修改任何的数据项都需要波及整个系统,所以大家就倾向于一开始就把所有的数据项全部列好,如果不确定就先留下一些空字段以备后续不时之需。

由于根本没有数据模型封装,看似业务上便于理解的设计,到后来也会因为冗余严重、耦合紧密而变得难于理解,或根本不可维护。只要是在基于如此架构上工作过的IT人员,就特别能理解,“为什么弄懂一个几千行的存储过程,需要花几天时间”。没有封装的结果,就是每个维护修改者都需要理解已有系统的所有复杂细节。这也是为什么我们在银行核心COBOL系统中,会看到大量的冗余代码——与其修改已有的程序,还不如忘记已实现的业务,为新增业务重新开发。

第二点是没有开放的技术生态。银行业经常把基于Java这样现代语言的开发称之为开放平台,与之对比的是传统基于大型机和小型机的封闭开发环境。最近还就开发效率问题和一个老牌银行技术人员进行过讨论。一个观点是,基于成熟封闭环境的开发一旦上手其实效率可以很高,对金融行业来说更加模式化,并且硬件保证了高性能和稳定性。于是我也花了不少时间,来研究这样环境下的开发模式,比如在绿色的传统命令界面上完全采用键盘操作,从代码管理到部署都是私有的平台和工具。

从我的角度来看,传统封闭开发环境有以下几个致命伤:

  • 技术设计的表现力不够,造成可维护性差。长期下来,系统修改十分困难,成本随时间爬升很快。
  • 不能够利用很多已有资源。从开源到云服务,实际上都是开放生态中的可用资源。开放技术的全球知识库早已超越了任何一家企业可以提供的技术服务。使用这些共享资源的门槛,就是需要加入到这样的开放生态中去,随着环境的发展而持续演进。
  • 难以支撑快速的市场和用户扩张,对基础资源抽象隔离不够。以云服务为例,某种意义上,云是对之前我们计算机硬件资源的封装,让其成为像日常生活中水电气一样的公用资源,它使得我们在数字世界扩张的时候可以不再受基础资源的限制。然而,在银行IT中,这样的基础资源和服务抽象很少。

很多银行已经意识到了上述的问题,在科技发展方向上,决定逐步将系统应用向开发技术平台迁移。但还存在很严重地照搬过去架构设计的倾向,如前述数据库设计问题仍然存在于新系统中。在敏捷转型过程中,会发现即使在开放平台上也很难实现端到端的业务价值交付,其中核心症结之一仍然在技术架构上。去年,我花了比较大的精力在领域驱动设计(DDD)的推广上,也是希望通过这个方法让银行IT组织认识到正确的架构设计思想。

未来的银行数字化部门应该在应用设计上达成业务和技术的架构绑定,而在人员任职上形成业务和技术的双通道。

文档与人

曾经一句玩笑话“人走文档留”,引起了我对银行IT人才观的深入思考。从较长一个时期看,IT人才观的转变可能是中国银行业的最大挑战。在前沿程序设计会议上,当我倾听一家外行科技VP讲函数式编程,看到两家美国银行收购硅谷技术公司的业界新闻的时候,就深刻地意识到,把“文档”当成IT资产的观念,将会严重阻碍中国银行的科技发展。

也许,在国家鼓励下的BATJ合作,可能给咱们的银行IT业带来深层次的冲击。从去年开始,这个冲击已经超越了我们经典意义上的敏捷转型,而是银行组织级的变革。在这个过程中,我认为我们要解决三个组织级的定位问题。

  • IT合作伙伴的战略定位——从现在的人员外包模式,到面向价值共享的战略合作模式。现行包人头的方式,是敏捷转型的障碍,在银行数字化转型过程中必须重视并解决。当IT和数字化成为银行业未来业务的重要支柱,合作伙伴的定位及合作方式就必须相应改变。
  • IT人员的能力定位——从现行的流程执行模式,到面向业务和技术创新的持续学习模式。随着智能技术在未来几十年的持续渗透,追求效率的金融领域会逐步用机器替代掉重复性工作中的人。这对IT的影响是更深远的,很快我们就会有机器来代替基础的程序员和测试人员,也不再需要管理这些基础人员的IT自有组织。但更为紧缺的是,具备持续学习能力、能够快速响应市场需求变化的数字化人才。
  • 数字化平台的支撑——从过去组织统一流程、检查规范模式,到平台化快速支撑模式。针对未来的不确定性,做细管理流程、强化检查节点的帮助其实是有限的,而提供快速的试验支撑,能够灵活快速地启动小规模多点尝试,则是成功的关键。

人才这个话题上,有一点是确定的:整个组织需要构建数字化人才的能力模型及持续培养体系。去年在国内,我也很欣喜地看到,若干家银行的高管们,开始过问大数据人才的招聘和留用问题,关心在现有体系下如何开辟新的渠道来灵活留用人才。

数字化未来

前面谈了目前银行业IT转型的挑战,最后让我们展望一下未来可能的方向。在前文中我已经多次提到了“数字化”。一个可以预见的未来就是数字化银行,其实《银行3.0》中已经描述了这样的现实,作者也已经开始讲“银行4.0”了。

应该澄清的一点是,数字化不等于IT系统,数字化能力不等于写计算机程序。IT系统仅仅是数字化的一个基础,数字化包含了以用户为中心的实时战略方法和高响应力的敏捷组织,在这样的组织里对技术卓越及创新生机文化的追求是大家的共同目标。

(图:数字化转型模型)

银行业IT的敏捷转型,显然必须服务于这个数字化未来。通过敏捷转型,我们需要把现行的IT部门变成未来数字化银行业务的支撑平台之一。而IT的敏捷转型最终目标应该明确为:

  • 提升端到端的市场响应能力,从而能够为科技引领创新提供能力支撑。
  • 探索科技和业务融合的新模式,从而能够为数字化业务提供模式支撑。

中国银行业的转型才刚刚拉开帷幕,敏捷转型的模式还需要更多的实践者出来分享和交流,谨以此文作为和大家交流的起点。


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

Share

DDD战术篇:领域模型的应用

领域驱动设计DDD在战术建模(后文简称建模,除非特别说明)上提供了一个元模型体系(如下图),通过这个元模型我们会对战略建模过程中识别出来的问题子域进行抽象,而通过抽象来指导最后的落地实现。

(DDD构建的元模型元素脑图)

这里我们谈的战术阶段实际就是这样一个抽象过程。这个抽象过程由于元模型的存在实际是一定程度模式化的。这样的好处是并非只能技术人员参与建模,业务人员经过一定的培训也是完全可以理解的。在带领不少团队实践建模的过程中,业务人员参与战术设计也是我要求的。

由于已经有不少书籍介绍DDD的元模型,这里我们就不再赘述,转而谈谈这个抽象过程中大家经常遇到的一些困惑。这些比较常见的问题可能是DDD元模型未来演进需要解决的,但我们仍然要注意业务问题和架构设计的多样性,不要过度规范,以至于过犹不及。

业务对象的抽象

通过对业务问题的子域划分,我们找到了一些关键的业务对象。在开始进行抽象前一个必须的步骤就是“讲故事”!

讲什么故事呢?关于这个子域解决的业务问题或者提供的业务能力的故事。既然是故事,就必须有清晰的业务场景和业务对象之间的交互。这件事情看起来是如此自然和简单,然则一个团队里能够站起来有条不紊陈述清楚的却没有几人。读到这里的读者不妨停下来试试,你是否能够把现在你所做的业务在两三分钟内场景化地描述出来?

这么做显然目的是让我们能够比较完整地思考我们所要提炼和抽象的业务对象有哪些。只有当我们能够“讲”清楚业务场景的时候,才应该开始抽象的步骤。对于一个业务对象,我们常见的抽象可以是“实体”(Entity)和“值对象”(Value Object)。

这两个抽象方式在定义上的区别是,实体需要给予一个唯一标识,而值对象不需要(可以通过属性集合标识)。当然另外一个经常引用的区别是,实体应该是有一个连续的生命周期的,比如我们在一个订单跟踪领域里抽象订单为一个实体,那么每个订单应该有一个唯一识别号,订单也应该有从下单创建到最后交货完成的生命周期。

显然,如果不增加其它约束条件,值对象的抽象是没有意义的,都用实体不就行了?但如果我们稍微思考一下一个实体的管理成本,比如需要保证生命周期中实体状态的一致性,那么我们就会发现值对象变得很简单很可爱。当一个对象在我们(抽象)的世界里不能改变的时候,一切都变得简单了,这个对象被创建后只能被引用,当没有引用时我们可以把它交给垃圾回收自动处理。

随着高并发、分布式系统的普及,实际上我们在对业务对象抽象的第一步思考是能否用值对象。如果大家实现的技术架构采用函数范式的语言(类似Closure),那么首先考虑值对象抽象可能就是一个建模原则了。

对象抽象初步完成后,一定要再重复一次之前的故事来审视一下我们的建模。经历这个抽象过程后,参与讨论的每个人都应该发现自己更清晰业务的需求和需要提供的能力了。

聚合的封装

DDD元模型中一个核心概念叫“聚合”(Aggregate)。这个从建筑学来的名词非常形象,建筑学上我们翻译为“骨料”,是形成混凝土的重要元素,也是为什么混凝土如此坚固的基础。

(混凝土里的一种骨料)

同理,在DDD建模中,聚合也是我们构建领域模型的基础,并且每个聚合都是内聚性很高的组合。聚合本身完成了我们对骨干业务规则的封装,减小了我们实现过程中出错的可能。

以上面那个订单跟踪领域为例,假设我们允许一个订单下存在多个子订单,而每个子订单也是可以独立配送的,这种情况下我们抽象出“子订单”这个实体。显然订单和子订单存在业务逻辑上的一致性,没有订单的时候不应该创建子订单,更新子订单的时候应该同时“通知”所属的订单。这个时候如果采用把订单和子订单聚合起来的封装就很有必要了。

采用聚合抽象的结果就是访问每个子订单都需要从相关的订单入口(i.e., 订单为聚合根),存取时我们都是以这个聚合为基本单位,即包含了订单和订单下面的所有子订单。显然这样的好处是在订单跟踪这个领域模型里,订单作为一个聚合存在,我们只需要一次性梳理清楚订单和子订单的逻辑关系,就不需要在未来每次引用时都考虑这里面的业务规则了。

(订单跟踪领域的订单聚合)

在建模过程中,很多团队并没有努力思考聚合的存在。封装这个在技术实现领域的基本原则在建模时却很少被重视起来。开篇提到在战术建模过程中强调业务领域人员的参与也是为了解决这个问题,聚合的识别实际是针对业务规则的封装,当我们不理解业务规则的时候是无法做出是否封装的判断的。

一言以蔽之,识别聚合是认知潜在核心业务规则的过程,而定义出来的聚合是在大家共识基础上对核心业务规则的封装。

领域服务的定义

在最初的元模型定义里,领域服务让不少人纠结,一个经典的例子是在账户管理领域里对“转账”这个业务行为的抽象。由于转账本身是作用在至少两个账户上的,所以把转账作为一个账户的行为显然是不合适的。那么如果我们把转账名词化抽象成一个实体呢?感觉也是比较别扭,毕竟转账是依附于账户存在的。

这个时候DDD在元模型里提出了服务(Service)这个抽象,转账被抽象为一个服务感觉就顺畅多了。同样道理,在我们上面的订单跟踪领域里,如果跟踪的过程中需要进行短信的通知,一个比较好的建模就是抽象出一个“通知”服务来完成。

我经常会用静态方法来帮助技术人员理解服务的抽象(虽然服务并不一定用静态方法来实现)。服务本身就像一个静态方法一样,拥有一定的逻辑但不持有任何的信息,从整个领域来看也不存在不同“版本”的同一个服务。

一个经常困扰大家的问题是对Service这个词语的限定,有的分层架构设计里会出现领域服务(Domain Service)和应用服务(Applicaiton Service)。大多数时候应用服务在领域服务的上层,直接对外部提供接口。如果存在这样的分层,那么领域服务就不应该直接对外,而应该通过应用服务。

举个例子,前面的订单消息通知如果是一个领域服务,在完成订单状态变化时创建通知消息,而最后的通知以短信的方式发给设定的人群,这样就应该有一个相应的应用服务,包含了具体的业务场景处理逻辑。之后也可能有一个邮件通知的应用服务,同样调用了这个通知领域服务,但通过邮件渠道来完成最终的业务场景。

由于微服务架构的流行,每个子领域的粒度已经相当细了,很多时候已经没有这样的领域服务和应用服务的区分了。当然从简单性角度出发这是好事情。在整个建模过程中,服务的抽象往往是最不确定的,也是最值得大家反复斟酌的地方。

Repositories的使用

Repositories是一个非常容易被误解的抽象,很多人会直接联想到具体的数据存储。在初期采用DDD建模的时候,我经常刻意回避这个抽象,避免让大家陷入思考紊乱。

这个抽象概念实际可以追溯到Martin Fowler的Object Query模式。另外一个相关概念是DAO(Data Access Object),都是用来简化需要存储的数据和对应的业务对象之间的映射关系。不同的是Repositories针对更加粗颗粒度的抽象,在DDD这个方法里我们可以认为映射对象是我们的聚合。针对每个实体在实现时候也可能创造出对应的DAO(比如采用Hibernate这样的ORM框架),但显然在建模过程中不是我们需要关注的。

那么Repositories的抽象为什么是必要的呢?让我们再回到订单跟踪这个例子,通知订单状态发生变化的服务在发出通知前,需要定位到订单的信息(可能包括订单的相关干系人和子订单的信息)。通知作为一个服务是不应该持有具体订单信息的,这个时候我们就需要通过Repositories的抽象来建立对订单这个聚合的查询,即有一个订单的repo,而具体的查询逻辑应该在这个repo中。

这样的抽象在需要存储和查询值对象的时候也是必要的。假设我们分析订单查询这个领域,在这个领域里订单记录显然已经不允许修改了,自然的抽象方式就是值对象。同时一个查询的服务来持有具体的查询逻辑(比如按时间或用户)是合理的。外部应用直接调取了查询服务(接口)并给出规定的参数,我们就需要一个订单记录的repo来持有跟存储相关的查询逻辑。当然这并不是说有一个查询就一定有一个repo与之对应,如果查询的逻辑非常简单,未尝不可以让服务直接针对数据存储实现。记住我们抽象的目标是让建模更简单,抽象过程中应该保持灵活。

限界上下文的意义

经过最近10多年的演进,我们在如何支撑一个组织的规模化上达成了一些基本的共识。我们知道微服务架构(Microservices)能够帮助我们把成百上千的工程师们组织起来,而小团队的自组织性是至关重要的。我们也逐步就如何能够在技术和业务团队之间明确沟通“架构”这个难题上找到了DDD。那么DDD和微服务架构的关系是什么呢?很多人会提到限界上下文(Bounded Context)。

我曾经就这个话题专门撰文一篇(DDD&Microservices)。一个限界上下文封装了一个相对独立子领域的领域模型和服务。限界上下文地图描述了各个子领域之间的集成调用关系。这个定义某种意义上和我们的微服务划分不谋而合:以提供业务能力为导向的、自治的、独立部署单元。所以虽然我们不能百分百依据限界上下文划分服务,但限界上下文,或者说是DDD,绝对是我们设计微服务架构的重要方法之一。

如果我们再追溯到DDD的战略设计,我们会发现在问题域上,DDD通过子问题域(subdomain)的划分就已经进行了针对业务能力的分解,而限界上下文在解决方案域中完成了进一步分解。当然我们不能完全认为子问题域和限界上下文有严格意义上的一对一关系,但大多数情况下一个子问题域是会被设计成一个或多个限界上下文的。子域subdomain和限界上下文某种意义上是互相印证的,重点在区分问题域和解决方案域,这是落地DDD最困难的地方,也是判断一个架构师能力进阶的分水岭。

战术建模小结

DDD的建模元素比较简洁,本文中叙述的元模型应该是满足了大多数场景下的建模。毛主席曾经有一句名言“战略上要藐视敌人 战术上要重视敌人”,就架构设计来说我们没有敌人,业务需求是我们的朋友。所以在领域驱动的架构设计方面,咱们需要的是“战略上要重视朋友,战术上要简化建模”。希望这句话能够帮助正在实践DDD的团队重新思考自己在战略问题域的投入和重视程度,不要挥舞着战术模型的大锤到处寻找实际不存在的钉子。

在这里我们也希望通过第一届DDD China建立起一个架构设计人员的交流平台。期待更多的中国技术人员能够通过这个平台和世界一流架构大师们建立起沟通的渠道,不仅在战略层面,也在战术层面和所有人一起分享讨论关于DDD的一切。


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

Share