服务设计的难点

[摘要]

真正优秀的服务期待建立一个有生命力的环境,在环境之中,客户绝对不是服务的中心,而是服务的一部分。正因如此,服务设计存在着系统化思考、难以复制、行业差异性大的挑战,成为一个综合的商业问题,而不再仅仅是设计问题。


服务设计突然成为热点,让人有点意外。通常情况下,一个设计概念在国内的流行都会有一个充满美学意义的象征,无论是拟物化和扁平化,还是响应式与穿戴式,至少它们要看起来是美。然而,服务设计大量的讨论,是完全基于设计过程、思维方式、甚至设计哲学,也从来没有谁从端到端去剖析一个真正基于实践的服务设计过程,与美似乎没什么关系。

我乐观地认为这是一件值得高兴的事情——这可能意味着大家对思维方式和设计过程开始产生兴趣。但事实上,服务设计的难点超乎想象,在我看来它完全是一种设计理念,更是设计界对真实世界一厢情愿的总结,暂时还不足以成为影响服务产业的力量。

在此,我想谈谈服务设计本身的难点。

服务设计的逻辑

2011年我接触过一个客户,客户希望某个App是简单到只有一个按钮,按下之后就可以得到你所需要的所有信息,他认为大道至简以及真正的科技是让你感觉不到科技。在肯定了他超前的思维之后,我还是表达出来我们不是乔布斯的遗憾。

很有趣,这就是我们一直以来的思维模式,我们喜欢相信未来有一个世界,可以通过最简单的方式获得我们所有想要的东西,“一站式”的幻想深深植于许多人心中,但事实上,世界的发展似乎不是这样。

越来越多智能设备所带来的“碎片式接口”用另外一种方式让我们“永不掉线”,越来越多的传统服务因为技术的出现反而更加有生命力,充满魅力——纽约Chealsa Market的自制糕店会使用Square配搭手机进行移动支付;Safeway超市的收银条会把你所购买的商品按照类别进行分类方便查找;小小拉面馆也会通过短信的方式进行叫号。

(图1: Chealsa Market的自制糕店会使用Square配搭手机进行移动支付)

最朴素的服务设计的逻辑,是如何利用新的技术或设计,去解决服务触点(Touchpoint)的问题和增加新的服务触点,使得传统的服务体验产生新的魅力。

去客户中心化

设计经历着从功能为中心到用户为中心,再从用户为中心到客户为中心的演变过程,背后承载的设计理念是:

  • 功能设计:以准确输入和准确输出为成功衡量标准;
  • 交互设计:在功能完成基础上,加入对用户输入与输出的效能和效率的考量;
  • 体验设计:考虑还未发生交互之前,端到端的完整客户体验,去用户化。

而服务设计风潮之下的是“去客户中心化”,真正优秀的服务期待建立一个有生命力的环境,在环境之中,有物理设施、理念、规则、前后台的服务提供者以及客户——在这里,客户绝对不是服务的中心,而是服务的一部分。如果我们留意,生活中的大部分服务场景都是服从规则优先于个体体验的,特别在公共服务场景中,而且无论如何优化,目的也只是将规则讲解得更透明、设计得更公平,而非关注每个被服务者的个体需求。

人们之所以认为“人人都可以是产品经理”,是因为产品是可以从客户角度出发的设计,骂几句微博产品逻辑给自己的产品天赋加加分,然后转身成为产品经理也许可能,但是依靠强大的服务挑剔能力成为服务设计师,基本不可能,因为服务绝对不只是为客户需求准备的。

在服务设计里,你要管理的是整个环境中的:

  1. 设施
  2. 理念
  3. 规则
  4. 前台服务者(们)
  5. 后台服务者(们)
  6. 客户(们)

以及更重要的是:他们之间的关系。

系统化思考

服务设计的第一大难度,是线性思维。这才是最大的阻碍,因为从任何一个角度出发,都可能让这个服务设计失败。不像在设计一个终端产品时,从用户目标的角度考虑,所有的交互行为都只存在于他和他最熟悉的手机,你要做的只是让信息流更加通畅,让他更快更舒服地完成交互过程。

而服务设计的网状关系使得你需要考虑更多在传统体验设计中不必重点考虑的东西,例如:

  • 如何让设施表达理念?
  • 如何设置理念让客户和服务者们遵守规则?
  • 如何让前台服务者与客户更好地互动?
  • 如何让后台服务者与前台服务者更好地互动?
  • 如何让客户与设施更好地互动?
  • 如何让客户之间产生互动?

当然在传统体验设计中,我们也需要考虑这些东西,但解决方案往往都是基于人与信息的,是标准化和流程化的,而在服务设计中,这样的关系通常都有人直接参与,不确定性更大,可管理性也更弱。

因此,解决一个服务体验的问题,需要更多的系统性思考。例如,“购物车经常被人推出超市的问题”,你需要思考多个方面:

  1. 设施:如何让购物车不被人推出超市?
  2. 理念:如何依然保持超市友善的形象?
  3. 规则:如何让客户了解规则并接受规则?
  4. 前台服务者:如何减少服务者的参与?
  5. 客户:如何减少客户的麻烦?

Trader Joe’s超市用了一种很有趣的方式,并考虑了多个方面的感受:在超市出口处的地毯上安装一个感应器,当购物车尝试通过地毯时,它会自动锁死一个轮子,同时用卡通形象在门口告诉大家不要把购物车推出门外,有趣的是,它并不发出警告。这个方案在多个方面给出了它的回答:

  1. 设施:用感应装置阻止购物车被推出超市外;
  2. 理念:用卡通形象的方式表现这个信息;
  3. 规则:执行了规则但是也不报警,并只锁死一个轮子;
  4. 前台服务者:不需要去管理购物车;
  5. 客户:从收银到门口的一段距离依然也可以使用购物车,大部分时候也感受不到“不准把购物车推出去”的信息干扰和不信任,甚至在破坏规则时候也非常低调,不让周边的人察觉避免尴尬。

在解决任何一个服务体验的问题时,服务设计需要我们对多个维度进行系统性思考,最终才能产出一个多方都能满意的方案,而这是传统以客户为中心、任务流的思考方式所不具备的。

设计只是10%

当人的因素出现在一个系统中,并且集中在一个真实的现实环境中时,设计(或技术)能解决的问题就变得极为有限。体验设计时代带来的习惯,可能使得设计师高估设计的作用,当大部分设计师谈论的重点依然是高光或阴影的角度、按下按钮不同的状态表示、表单标签是否应该右对齐时,在服务设计中大量关于人的观察、商业的考虑、员工素质的讨论、行业特色的经验、文化差异的识别等等,就会被忽略。

服务设计可以作为设计公司(Design Agency)中一个独立存在的服务吗?这点我深表怀疑。互联网产品的设计,也许可以通过设计外包的形式将产品概念和设计部分交由设计公司,再由技术交付团队进行交付;但服务设计的实施,需要整个客户在“提供服务的过程中”进行实施,它所面对的不确定性更大。再加上大量的工作存在于沟通、流程、人事、客户服务等等,那种留下500MB的设计方案就离开的设计模式,在我看来完全没有可实施性。

复制的难度

更大的难度是缺少最佳实践,或者是无法体会到最佳实践。不像产品设计,优秀产品只需要5分钟就可以下载并安装到手机当中,来进行研究学习;而要真正感受服务细节体验,你必须有丰富的经历,就像之前谈到Trader Joe’s的购物车,你需要去很多次才可能有机会体会到那么细致的服务设计。哪怕是基于移动互联网的Uber一类O2O应用,你也只有亲自体验,才能体会到整个服务体验的精致,而手里那个简单的App,只是其中很少的一部分。

而就算我们已经有机会接触到了那么多的最佳服务体验,尝试将同样的实践复制到一个新的客户上下文中,几乎是不可能的,因为你所面对差异的复杂度是远远超过线上体验的。

缺少直接体验的最佳实践,客户情境的截然不同,对于习惯于逛Dribbble找灵感、下载最新应用做参考的我们该如何是好?

行业的难度

交互或产品设计中基础的信息逻辑,即使跨了行业也都非常类似,因其本质还是基于数理逻辑的计算机软件。而服务体验的行业性则非常强,单零售体验中大型商场、购物中心、专卖店、连锁超市、便利超市都有着完全不同的服务形态,而跨行业更是千差万别,例如政府机构、博物馆、交通设施、酒店等等。

在这个背景下,服务设计师需要形成更完整的设计方法论和独特的设计实践,驱动真正的业务专家一起完成服务体验的设计。这也是为什么目前看到的关于服务设计的内容,绝大部分是关于设计方法论的。

给服务创新实践者的建议

服务设计存在着系统化思考、难以复制、行业差异性大的挑战,成为一个综合的商业问题,而不再仅仅是设计问题。对于想要利用服务设计,进行服务创新的实践者,我有以下建议:

  1. 培养良好的设计思维。设计本身就在朝跨界(Multidisplinary)与融合的方向发展。不要把服务设计当成志向,而是把服务设计背后的设计思维作为志向,在实践中充分应用、不断培养提升大家的设计思维能力。
  2. 尝试各种服务,特别是极端情况下的特殊服务。例如超市的退货、失物招领、酒店换房等等,服务设计真正见功力的地方在于对异常的处理;有机会的话,去东南亚体会酒店、去美国体会零售、去日本体会公众服务,珍惜每一次体验机会,记录下每次接受服务的过程,并尝试用系统的角度去理解为什么这么做。
  3. 学会系统性思考。多了解政治经济领域的复杂问题,培养系统性思考的能力。了解台湾学生为何占领立法院、美国的医保和两党政治有何关联——在我看来,理解了这些就理解了国家作为一个系统运行的基础规律,思维就变得不再极端和狭隘,而更多学会用“上帝视角”来看问题。
  4. 对科技敏感。技术对于服务带来的意义是无穷的可能性,以及对现有解决方案破坏性的创新,认为自己只是创意家提供创意、或者艺术家只会写画、或者战略家只做顶层规划而科技是程序员的事情,这样成不了气候。
  5. 对商业模式敏感。考虑经营性、服务设计的特殊性,服务设计不是写写画画看看广告公司的案例就能完成,需要懂经济,对商业模式有足够的敏感度。

推荐阅读:

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

Share

重新定义客户旅程

[摘要]

以客户为中心创造价值,当前全新的商业环境下,领先的企业几乎都以此为战略核心。通过获取客户洞察、提升客户体验、创新商业模式,为组织带来核心竞争力和前所未有的商业价值。其中,客户旅程作为客户体验管理的一个重要思维和方法,正在进一步与企业持续迭代的实时战略相融合。客户旅程经历了哪些发展阶段,在当前的客户赋权时代,如何实践落地能够为企业创造更大的价值呢?


以客户为中心创造价值,当前全新的商业环境下,领先的企业几乎都以此为战略核心。通过获取客户洞察、提升客户体验、创新商业模式,为组织带来核心竞争力和前所未有的商业价值。其中,客户旅程作为客户体验管理的一个重要思维和方法,正在进一步与企业持续迭代的实时战略相融合。

客户旅程(Customer Journey)是指客户首次接触直至下单并享受产品或服务期间与企业互动的全过程。它并不是一个新兴的概念,咨询公司早在很多年前就将客户旅程的梳理和优化作为打造最佳客户体验的重要工具,通过“以客户为中心”的客户体验改造和重塑,优化与客户的交互方式,持续为客户提供高价值服务;在设计领域,设计师将客户旅程作为设计思维的重要维度,客户旅程地图成为服务设计的常用工具之一,通过基于旅程的拆解,分析客户全流程接触点的体验和支撑旅程的利益关系,创新各个环节客户的体验。

关键不是产品,而是帮助客户达成愿景

随着用户行为和市场趋势的变化,ThoughtWorks将客户旅程的演进分为三个阶段(见图1):

  • 基于全流程客户关键接触点的优化;
  • 基于跨渠道全流程客户体验的优化;
  • 基于客户价值驱动的客户体验重塑。

(图1:客户旅程的三个发展阶段)

客户旅程1.0:全流程客户关键接触点优化

早期的客户体验管理通常从客户全流程中的「关键接触点」开始,通过基于运营数据和客户调研的分析,探索出客户在体验中的“痛点”,并将这些痛点进行优先级排序,优先改造那些影响关键业务环节的体验。同时,还需要在客户旅程中创造一个或多个客户“尖叫点”,以带来更好的客户体验,创造口碑传播的元素。

当共享租车早期投入市场时,用户的核心痛点之一是“车主拒单率高,租客被拒体验不佳”,这时你的优化策略可以是:通过有效的运营手段,在车主端为客户提供基于成单率的激励措施,在租客端进行基于车主接单率的优先级排序,并在客户被拒时给予适度优惠券补偿,甚至“免费升舱”到更高级别的车辆。如此在“拒单率高”这个核心痛点上满足并超越客户的预期,同时提升了车主和租客之间的供给效率。

这是早期的客户体验管理思维,专注于“单个”客户接触点的改造,而非“整个”客户旅程的体验。如果你的企业还只是停留在这里,那么可能已经“过时”了。

客户旅程2.0:跨渠道全流程客户体验

随着智能手机的普及和移动终端的快速发展,企业与客户的接触点进一步增加,并呈现碎片化趋势,客户开始期待在任何时间、任何地点实现线上和线下无缝融合的产品和服务体验。此时的客户体验将围绕连接“人-设备-服务”三者之间展开,无论从线上到线下,还是从线下到线上,客户的旅程可以从任何数字渠道或传统渠道中的任一环节进入到场景中,并获得相关的产品和服务。

在ThoughtWorks服务的多家零售、汽车、金融等行业的领先企业中,数字化转型早已成为企业发展的核心战略之一,它们纷纷开始进行多元化的数字化渠道布局,并关注数字化渠道与传统渠道的互联互通,利用设计思维打造线上线下无缝融合的跨渠道体验。如果你的企业也在做着类似的事,那么至少你跟上了这一波“数字化浪潮”。

客户旅程3.0:客户价值驱动的体验重塑

当我们看到阿里巴巴、腾讯等互联网巨头,通过持续的核心能力布局与战略投资并购,逐步连接和渗透各个垂直行业的同时,也真正尝到了生态系统布局带来的红利。这时许多传统企业开始重新思考未来企业将带给客户什么样的价值。

在“以产品为中心”的时代,我们聚焦于为客户提供基础的产品和服务,客户也满足于获得必备的产品。而随着市场逐渐由供给侧导向需求侧,我们迎来了“以客户为中心”的时代,此时的客户体验管理从聚焦于关键客户接触点,到聚焦于跨渠道全流程客户体验的优化。在这个演进的趋势中,客户不仅日渐“习惯于”获得最佳客户体验,被赋权的客户还将满足且超越客户预期视作“理所应当”,客户再也不会主动探索某个品牌、某个产品,取而代之的是客户在自己的生活场景中“被触达”或“被吸引”。(见图2)

(图2:客户行为驱动下的客户体验管理演进)

在这一客户行为驱动的变化下,企业无法再像从前一样仅从提供产品的角度思考问题,而是需要重新定义客户的「愿景」。例如对于银行而言,购车的客户对银行的需求仅局限于车贷,但是客户的愿景可能是“拥有人生中的第一辆梦想车”,这时银行可以基于为客户这个“梦想”的价值,在购买车、驾驶车、装饰车、分享车、置换车等多个客户旅程进行布局,并创新为客户提供服务的方式,将一整套的金融方案有效嵌入到“车生活”的客户场景中去。如果你的企业已经开始酝酿这样的「体验重塑」,那么未来有可能成就真正的“颠覆式创新”。

打造无缝融合的跨渠道全流程客户体验

案例1:汽车企业的“获客旅程”改造案例

(图3:汽车企业的“获客旅程”改造案例)

在与某德系车企的合作中,ThoughtWorks通过对购车客户的旅程进行梳理和创新,成功实现了跨渠道的客户引流、决策、购买、交付、留存和传播。通过该车企的营销活动,客户可以便捷的在手机APP、在线商场、4S店等多个渠道选择钟爱的车型,通过VR看车对车的内部外部进行深入了解,客户还可以在线完成试驾预约,进行车辆的个性化定制,并在4S店进行购买提车。(见图3)

案例2:银行进行“端到端的客户旅程优化”案例

英国的劳埃德银行于2014年启动数字化转型项目,该项目历时三年,以打造“最佳客户体验”为核心。他们通过与咨询公司合作,共同梳理了30个关键客户旅程,通过评估由“新客户”和“企业抵押贷款”两个旅程起步做试点,并先后进行了10个核心旅程的梳理和优化。同时,劳埃德银行还构建了基于客户价值的运营体系,通过组织跨职能团队、建立客户旅程实验室、使用专有预算和重建KPI等一系列举措,推动数字化转型的实践。

案例3:零售服装企业的“跨渠道旅程整合”案例

在全渠道时代,客户可以在任一环节便利的切换到最舒服的渠道和触点来继续服务。ThoughWorks在与美国某知名连锁服装品牌的合作中,帮助其实现在手机APP、线下门店、移动终端等多个渠道的旅程整合,使客户在整个服务过程中得到的信息是互联的且一致的。(见图4)

(图4:零售服装企业的“跨渠道旅程整合”案例)

客户旅程2.0案例带来的启示

在企业的客户体验管理中,客户旅程2.0阶段仍然是当前的重点,这将直接影响到客户的满意度,甚至是业务的增长。在这一阶段,我们需要关注:

  • 持续理解客户和客户不断变化的需求:被赋权的客户将加速客户行为的变化,因此,企业必须具备快速适应客户变化的能力,深入实践客户研究,持续优化和迭代客户的旅程。
  • 为客户提供无缝融合的跨渠道全流程客户体验:企业需要更关注如何获取端到端的客户生命周期价值,将多个数字渠道与传统渠道打通,通过全渠道客户旅程的梳理,为客户提供无缝融合的客户体验。
  • 构建基于客户旅程实践的一整套运营体系:通过组织跨职能团队、建立客户旅程实验室、重新设计KPI等一些列举措,推动客户旅程的优化得以在企业中卓有成效的落地。

客户价值驱动的体验重塑和颠覆式创新

案例1:车企从“汽车销售旅程优化”到“重新定义车生活解决方案”

如前文中提到的汽车企业在客户旅程2.0阶段的旅程改造,这一阶段的核心是围绕新车销售的选车、试驾、订车和提车等环节进行的。然而,随着车企的转型,其商业模式正在发生变化,我们看到大部分车企都开始逐步向基于核心业务的产业链上下游去延伸,或基于汽车行业生态,布局汽车内容、汽车电商、汽车金融、汽车共享等一系列车生活相关的业务。(见图5)

(图5:汽车行业生态图)

随着车企业务复杂性的提升,企业与客户建立连接的渠道和触点不断增加,并延伸到生态价值链的各个环节,此时的客户体验管理如果仅围绕单一产品或服务进行客户旅程的优化,显然割裂了客户的整体品牌体验。因此,在汽车销售和车生活之间,我们需要重新定义客户的愿景,以获取端到端的客户生命周期价值为核心,通过多个客户旅程的整合,为客户提供基于「客户愿景出发」的一站式全场景车生活解决方案。

案例2:Uber从“客户打车流程再造”到“布局客户出行和生活方式”

Uber的诞生全面颠覆了客户的打车旅程,它从客户的痛点出发,用手机APP寻车告别了人们路边招手的尴尬和低效,用透明的价格缓解了人们行程中不停看计价器的不安,用实时定位增加了出行旅程的透明度,用无现金支付提升了出行的便利性,并通过评价反馈机制有效提升了客户的服务体验。这样的客户旅程再造满足并超越了客户的用车预期,创新了客户的出行体验。

然而,Uber并没有停留在客户旅程2.0阶段的设计。Uber开始从生态系统的角度重新思考客户的出行旅程,不仅与客户的出行、还与客户的生活方式建立更多连接。为此,Uber布局了UberEats外卖,还与Yelp、Snapchat、Pandora等平台进行战略合作,为客户提供基于位置的动态集成生活服务。Uber通过布局客户出行和生活方式,增加了客户旅程的丰富触点,创新了与客户的连接方式,让客户的出行生活变得更加便利和愉悦。

案例3:盒马鲜生从“客户消费旅程优化”到“客户价值驱动的商业模式创新”

在服务设计中,典型的客户消费旅程可以分为认知、到达、准备、购买、体验、物流、售后七个消费阶段。盒马鲜生从客户旅程2.0的角度为客户带来了无缝融合的跨渠道客户体验,它关注客户线上线下的体验融合性,将线上线下并行发展,在一些线下的关键接触点上充分利用线上工具进行辅助,并在体验细节上围绕产品、场景、情感等维度进行了创新。

作为新零售的典范,盒马从创立之初就开始同步从客户旅程3.0的角度思考为客户提供价值的理念和方式。盒马基于客户价值去决定不同渠道的投入,集中力量打造核心产品,并将“人-商品-数字工具-金钱”串联起来,创新客户的旅程和触点体验,让数字产品承担起线下购物中的助手,甚至智能导购的角色,颠覆了传统商超客户的购物体验。这一创新也为盒马实现了普通商场3倍的坪效,其用户转化率高达35%,用户粘性和线上转化率均远高于传统电商。

客户旅程3.0案例带来的启示

在“以客户为中心”的时代,客户旅程3.0思维将成为企业进行规模化创新的必备能力,助力企业将自身的服务有效连接到客户的生态价值链上。在这一阶段,我们需要关注:

  • 客户愿景出发:企业需要通过大量的客户调研,理解客户的目标,重新定义客户的愿景,然后从这个愿景出发去思考为客户提供服务的方式,将与这个愿景相关的旅程都整合进来,绘制出价值驱动的全新的客户旅程地图。
  • 客户价值驱动:在进行客户旅程的设计时,企业需要始终思考一些问题,比如我们正在做的这件事对客户有没有价值;对于客户而言,我们提供的服务旅程是否具备“必不可少”的价值;为了帮助客户达成愿景,我们为客户提供价值的方式和理念是否“足够吸引”客户。
  • 创新客户体验:企业需要创新和颠覆满足客户愿景、连接客户生态的旅程,并关注与客户的情感连接,“被惯坏”的客户习惯于满足并被超越预期,企业必须具备精益创新、持续迭代的能力,为客户持续不断的带来极致的客户体验。
  • 连接客户生态:今天,被赋权的客户再也不会主动发现企业所提供的产品或服务,企业必须将自身的业务旅程与客户的生态系统相连接,创造更多接触点,创新更多连接方式。

写在最后

企业能否将客户旅程有效映射到企业的生态战略布局上,将成为未来企业进行客户体验管理的成败关键。推动客户旅程在大型企业的落地,并逐步形成客户旅程思维和规模化创新,企业需要在内部构建客户旅程DNA。基于ThoughtWorks的实践经验,我们建议:

  • 以客户为中心打造持续创新的高响应力组织:通过组建跨职能团队,成立专门的客户旅程实验室,并调整KPI考核机制,以适应企业转型的需求,这将是创新的客户旅程得以在企业中快速实践的前提。
  • 培养将客户旅程连接至生态系统的思维和文化:为更加适应市场的变化性,企业不仅需要培养客户旅程思维,还需要将客户旅程有效连接至企业的生态系统中,与企业持续迭代的实时战略相匹配。同时,企业需要不断对内、对外分享客户旅程的实践成果,为员工创造客户旅程思维和创新文化的真实感。
  • 以精益的方式导入客户旅程:旅程的导入需要遵循精益的原则,以MVP的方式导入到部门中,形成实施、反馈、修正的闭环。企业的数字化转型通常涉及几十个甚至上百个客户旅程,企业可以从中选择出2-3个核心的旅程进行试点优化,在实践中不断总结经验,并培养和赋能更多的团队参与到客户旅程的创新中。

相关推荐:


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

Share

顾问、老师及教练

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

解决问题的顾问

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

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

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

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

推动改进的教练

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

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

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

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

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

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

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

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

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

传授技艺的老师

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

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

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

不同的胜任力要求

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

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

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

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

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

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

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

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

不同的工作模式

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

(图:角色的工作模式)

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

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

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

不同的成功标准

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

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

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

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

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

相同的专业历练

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

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

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

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

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

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


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

Share

服务蓝图再思考

服务蓝图(Service Blueprint)是服务设计中重要的实践之一,本文将回到这一实践的本源,重新思考其核心逻辑在新的消费环境中是否需要演进。

溯源

服务蓝图(Service Blueprint)这一名词可追溯1984年1月哈佛商业评论中G. Lynn Shostack的文章《Designing Services That Deliver》,此文首次将对服务的设计分为以下几个过程:

  1. 定义流程
  2. 区分出服务失败点
  3. 引入时间效能
  4. 分析盈利模型

(一个擦鞋店的服务设计)

此外,Shostack还建议了执行这个蓝图的几个要点,其中包括:

  1. 客户可见和不可见的部分,用可视线(Line of Visibility)进行分隔;
  2. 强调统一制式的物品(Tangible Evidence)对服务承诺的正向影响,例如航空公司整齐划一的制服、物品或用具;
  3. 强调人对于整个服务体验的影响。

由于欧美国家时薪制度的标准化,标准服务流程中的时间估算,可以计算出一项服务的成本和盈利模型,因此服务蓝图有着强烈的标准化、工业化、系统化、商业化和控制化的基本属性。

Shostack在本章的最后也指出,服务蓝图的作用可归纳为:帮助服务提供商节省服务时间、提高服务效率、以及高视角完成对服务流程的管理。不得不忽略的是这一理论的出现,正处于美国进入服务业时代的1980年代中期,企业迫切需要一种对服务进行有效规划和管理的手段。

延续

服务蓝图偏流程和系统效率的特点延续到近几年服务设计的兴起。在服务设计中,服务蓝图被认为是客户体验地图(Customer Journey Map)的延伸,在传统客户体验地图的基础上添加了客户触点、跨部门的前中台服务人员行为、后台系统流程支持等元素。

(图片来自:http://suo.im/22QugV)

许多元素,例如中后台的交互、可视线、物理实物、服务时间等都被保留,其本质并没有脱离G. Lynn Shostack最初的概念——系统、任务、流程、和效率依然是服务蓝图的主题词。

全新上下文

如果我们回到Shostack所处的时代,服务有如下特点:

  1. 客户有固定的场所与服务商进行互动,如银行、酒店或是机舱;
  2. 为了追求效率和成本考虑,相同事务的客户有着统一的服务流程,而随着时间的推移,服务本身是趋向于统一化、稳定化的和简化的;
  3. 时间即服务成本、客户也期待更快速的服务,因此用更短时间完成服务,是客户和服务商的共同诉求。

当我们走完21世纪的第一个十五年,服务对于我们而言,有着惊人的变化:

  1. 客户不在固定场地与服务商互动,同一场地可能跟多个服务商互动;
  2. 客户追求多元化、定制化、个性化的服务流程,服务需要不断创新,而不是趋于稳定和一成不变;
  3. 客户体验开始替代完成任务,短时间完成服务不再成为唯一诉求,反而成为服务商的机会。

策略的变化

在传统上下文中,服务提升的策略有以下几种:

  1. 标准化流程,包括流水线化以降低服务人员培训成本、独立或外包某一核心模块、细化的指标进行精细管理;
  2. 管理关键事件,对客户等待、抱怨、投诉等典型事件进行集中处理;
  3. 减少和简化触点,并缩短触点交互的时间,即减少关键事件和非标准化流程出现的几率;
  4. 提高客户参与度,增加客户主动参与服务的比重,以降低服务人员的成本,例如便利的自助服务;
  5. 对客户进行分组,用几个分割的、相对简单的子系统代替一个相对复杂的统一系统,例如银行的对公和对私业务;
  6. 将复杂过程集中处理,减少客户在一个流程中走动的时间,例如多个窗口的转移;
  7. 增加信息透明和流动减少服务的失败和返工。

在新的上下文中,这些策略可能发生变化、或者被赋予了新的意义。

  1. 服务人员被赋予了更多决策权,以在标准化流程的同时针对客户的个性化需要提供服务;
  2. 移动社交网络赋予客户更大的能力,对于客户投诉需要全新的管理策略;
  3. 增加触点或增加触点交互的丰富度,以提高触点体验的沉浸度,而非一味减少或简化;
  4. 提高客户参与度的目的不再是降低服务成本,而是满足客户的特殊体验需要;
  5. 尽可能提供一站式的服务体验,而不是分割客户;
  6. 降低客户对复杂过程的感知,尽可能取消窗口,而不是缩小窗口间的距离;
  7. 由于单个客户获取信息能力的大幅提高,增加信息透明和流动成为服务商不得不做的事情。

服务蓝图实践

一项设计实践是否需要演进,取决于:1)其所在上下文是否发生变化;2)其是否鼓励新的设计策略。从这个角度来看,服务蓝图实践传统逻辑所在上下文发生巨大变化、其所鼓励的设计策略(简化、稳定化、标准化、专业化等)也发生巨大变化,我们应该重新审视服务蓝图实践本身是否符合现代服务体验设计的需要。

在我们的实践中,该实践的真正意义有两点:

  1. 用一种概括性的手段,梳理服务体验的诸多要素,初步建立上下文,寻找到设计的突破口,即建立问题或机会假设(Hypothesis),基于此进入深入的设计研究;
  2. 通过系统化的分析,寻找内部系统的边界、集成、和信息流动,帮助我们建立服务背后信息系统的初步上下文。

注意,此二点都不是完整的设计实践,而是建立上下文(Context Building)的实践,从这个意义上来说,服务蓝图,已经不是一张蓝图,帮助我们在长时间内固化服务方式和流程,而只是理解上下文、寻找设计突破口的工具。

服务蓝图在新的上下文中,即不是规划工具、更不是设计工具、而只是帮助设计师建立上下文的沟通工具。

写在最后

我们今天所知的任何一项设计实践,都并非新鲜之物,它们都有其最初的上下文、目的和基本逻辑——当上下文和目的在新环境下发生变化,其基本逻辑也必然需要发生转变。

服务从标准化工业流程朝着个性化发展、客户议价能力有着巨大提升、服务地点和品牌边界日趋模糊和灵活,这些上下文使得一个固化的蓝图(Blueprint)失去曾经的意义,那么服务蓝图作为设计实践的一种,我们对它的认识也需要更新——它只是帮助设计师建立上下文的沟通工具,即无法设计服务、也难以指导规划。


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

Share

浅谈微服务基建的逻辑

这篇文章主要目的是面向初接触微服务的朋友简单介绍微服务基础建设所需要的各个模块以及缘由。

起点

首先,我们得有一个“服务”。根据定义,我们可以把每个服务实例都视作一个黑盒。这个盒子有着明确的输入点和输出点,并且(理想情况下)仅通过这些输入和输出点和外界产生关联。每个服务实例会拥有专属的网络地址、独立的计算资源,并且独立部署。客户端通过访问服务实例的地址来调用服务 API。不同服务也可以相互调用。

配置管理器:统一管理配置

在微服务体系中,每个服务都独立部署和运行,团队可以根据需要自行选择增加和减少计算资源。一个服务可能会跑多个实例,每个服务实例都会需要做配置。为了方便统一调整配置,我们可以把配置中心化,每个服务实例都去找配置管理器(Configuration Manager)拿配置。当配置更新的时候,我们也可以让服务实例再去拿新的配置。

服务名册:解耦主机地址

这也引出了一个问题:网络地址(比如 IP)很容易因为扩容、维护而变动,调用者难以实时获知可用的地址。

鉴于此,我们可以把网络地址抽象成不容易变动的概念,比如给每个服务一个固定的名字。互联网使用 DNS 来解决这个问题,对应到微服务基建里面就是服务名册(Service Registry)。

每个服务实例在运行期间,都会以心跳的形式向服务名册发送注册信息,包括服务的 ID 、访问地址以及健康状况。这样,需要访问服务的时候,客户端就可以先问服务名册拿可用的实例地址,然后再访问实例来调用服务。除了更好地定位实例地址,服务名册还可以在某些实例下线、维护或升级的时候把其临时从名册中去掉,让服务不断线。

服务之间的调用也是如此,先找名册拿网络地址,再进行调用。

API 网关:入口和路由

找名册要地址,然后调用服务 API,这些是每个客户端都会去做的琐事,我们完全可以把这些事情抽象、集中,把服务的 API 整合到一个大的中心点,然后把要地址和调用服务 API 这样的细节封装起来,所有客户端都只跟这个中心点对话,不再直接访问单个服务。

从结构上看,这个中心点把整个架构划分成了内外两部分,内部是所有的服务,客户端则在外部,中心点站在中间。它作为内外的唯一通道,被顺理成章地命名作“API 网关”(API Gateway),有时候也被称做“边缘服务”(Edge Service)。

API 网关作为唯一出入口,又占据了最前沿的有利位置,所以有时还会承载别的公共功能,比如我们马上会提到的鉴权。

鉴权服务:身份和权限问题

顺着这个架构继续开发,我们会遇到新的问题:不方便的鉴权。

鉴权(Auth)包括了两个部分:身份认证(Authentication)和权限验证(Authorization)。身份认证关心的是“你是谁”,权限验证关心的是“你能不能做某件事”。

身份和权限都是高度中心化的概念。

对于一个系统来说,用户的身份必须是统一的。不能说这个用户在做这个事情的时候是张三,做那个事情的时候是李四。此外,用户的认证状态也应该是统一的。不能说用户访问这个服务的时候是已登录认证,访问另一个服务时又是未登录状态。所以,只能有一个身份认证方。

权限稍微复杂一点。和身份不同,权限通常分成两种类别:功能权限和数据权限。这样的划分对应了现实世界中常见的权限模式:你的角色决定了你的职能,而职能范围通常由附加条件来限制。比如,你是一个法官,对案件有裁决权,但是你是 A 区的法官,只能判 A 区的案子。再比如,某个快餐门店的经理有权看员工的详细资料,但是只能看自己门店的员工资料。

两种权限都由全局的规则来确定,而不掌握在执行部门。比如,谁来判案,取决于法律,而不取决于法院。谁能查看谁的资料,也不由资料保管部门决定,而由规章制度决定。

在现实的情况中,组织可能会有专门的审核部门来验证权限,但对那些不是特别敏感的权限,企业会让各个部门自行验证。不过不管谁来执行验证,都必须拿着同一份规章制度,不能各说各话。这份制度必须由中心机构来统一制定、维护。也就是说,权限的管理也应该中心化。

明确鉴权中心化之后,我们就可以开发一个公用的鉴权服务,执行身份认证和权限验证。下一个问题是:谁来发起鉴权?

所有服务的调用都要求调用者明确自己的身份,所以自然身份认证越靠前越好。作为出入口的 API 网关自然是发起身份认证的不二之选。权限验证则稍微复杂,完全值得另起一文详述。此处我们暂时假定权限验证也由 API 网关来发起。

消息中介:异步和通知

开发继续进行,一切风平浪静,技术上暂时没有什么问题。不过,业务上有一个问题需要解决。

比如,我们做一个在线商城,要求在订单成功创建的一刻,仓库就要启动备货和发货的流程。问题是,订单和仓储是两个服务,不同团队在负责,而且从关注点来说,订单服务并不关心仓储相关的问题,所以订单服务不可能在创建订单的时候去主动通知仓储服务。仓储服务只能定时轮询订单服务,看看有没有新的订单。这不仅麻烦,而且实时性不够。

仔细想想,我们会发现这种需求很常见,信息的产生者并不知道(也不关心)谁会对信息产生兴趣。比如我们可能会有一个监控服务需要实时展示产品销量,有一个 BI 服务需要获取客户购买产品的信息来做分析,等等。既然这是一个常见需求,我们不妨把它模式化,形成一个机制:信息产生者把通知发出来,收到通知的人再确定是否需要采取行动。

这就意味着我们需要再引入一个中心化的公共服务:消息中介(Message Broker)。当某个事件发生的时候(比如用户激活成功、订单创建成功),服务可以朝消息队列发一条消息。而其他服务可以订阅这些消息,并针对这些消息做出反应。

比如,仓储服务可以订阅订单创建成功的消息。这样,订单成功创建后,订单服务将这个消息发到消息中介,消息中介通知仓储服务,仓储服务一看,就问订单服务要新的订单信息,最后,启动出库流程。

消息中介除了能广播事件之外,还能做异步调用。把同步的调用转化成异步的回调。针对调用时间长和不要求实时结果的调用,可以增加性能,提升体验。

前置后端:优化前端开发

走到这里,其实体系已经比较完备。现在的问题是,如何让微服务基建结构和研发团队常见的结构更好地对应起来。这要求我们从康威定律的角度来看待整个基建的设计。

在围绕用户和价值的软件研发流程中,我们常用用户历程和用户故事来捕捉和跟踪价值的实现。一个用户故事通常会包含一个有明确边界、明确验收标准和明确价值的业务步骤。

问题在于,支撑一个故事有前后两端的研发工作,二者是不同步的。前端由业务流程和设计来驱动,希望按顺序产出;后端则由业务资源和建模来驱动,希望按模块来产出。

比如说,前端常常会因为设计的原因调整自己需要的字段,而后端从建模的角度并没有这个需要,也没有动力频繁地去跟随前端的调整,使得前端不得不在不稳定的网络条件下传输多余的信息,占用了宝贵的网络带宽。

此外,前端呈现某个业务步骤的时候,有两种信息不属于当前必备信息,但常常需要和必要信息一起展示。一种是状态信息,比如当前的登录状态和用户名,短消息的数量等等。一种是垂直相关的信息,比如在展示文章的时候顺便展示一下相关的文章。

这就要求前端在调用主服务的同时还要再调用多个不同的服务。且不说这些服务有可能会有调用超时、出错的可能,仅仅是多出来一堆异步请求,就已经足够让前端效率降低一大截了。

在微服务体系下,这些问题更加严重,因为现在不仅仅是前后端的差别,不同服务还由不同团队负责。这些团队的诉求和日程不一,很难做到前端所需要的快速响应。

这些问题和麻烦可能会催生一个“缓冲带”,比如后端出专人来负责对接前端的需要,或者前端派驻一个人到后端来谈需求。按康威定律,这种沟通体系,久而久之,很容易以软件的形式沉淀下来,形成一个专属的中间层。

要调和前后端的不同步是不可能的,而这种中间层是自然催生的解决方案,可以保留。新的问题是,它的职责是什么?应该把它放在哪?应该由谁来维护?

分析下来,其责任有二。第一是解耦前后端的工作,降低相互的影响。前端需要的东西可以写在中间层里,让它频繁变化也没有关系。后端如果还没有准备好,前端也可以在这一层模拟假的数据,不至于被阻塞。第二则是提升前端的运行效率。前端可以把所需要的多个服务的东西统一汇总,一次拿完,免得发多个请求。

放置的位置则在 API 网关之内,让它可以享有 API 网关所带来的好处和保护。

最后是维护问题。按照“谁主张,谁举证”的原则,既然有了这个中间层,好处让前端得了,那么,理论上应该由前端来维护。

这样,一个主要为前端服务的中间层就定义好了。不同类型的前端(桌面、移动)可能会有不同的需要,为了避免中间层的碎片化,我们可以让各个中间层都特定的前端类型紧密耦合,比如桌面专用、移动专用。如此,每个中间层都像是某类型前端的专享后端,所以“前置后端”(Backend-for-Frontend,简称 BFF)也因此得名。

回路熔断器:提高容错度

现在,调试也方便了,我们又继续开发。一开始没有什么问题,但部署到预生产环境的时候,又一个问题出现了:整个体系的容错度很低。一个小错误容易被层层传递和放大,导致整个体系的崩溃。

我们都知道,编程最麻烦的就是远程调用。本地调用大部分时候结果是“成功”或“失败”,但远程调用则很可能是“无响应”。“无响应”有可能是正常的,对方可能稍后会给你结果,也可能是因为对方已经死了,没法给你响应。最坏的结果,就是门口挤满了人,大家都在等你给结果,而你也在等别人给结果,资源全部占用来等,什么也做不了。

不过,远程调用是无法避免的。在微服务体系中,这个问题被进一步放大。这是因为微服务的模块化以服务为单位,而每个服务独立部署和运维,使得服务之间的调用成了家常便饭。

在这种严峻的情况下,我们必须从架构上尽量提高整个服务体系的容错度,让个别服务的问题不至于影响到全局。

具体的做法,则是给远程调用加一个熔断阈值检查,当调用超时次数超过阈值时,就不再调用,直接返回错误。过一段时间之后,再把阈值恢复,尝试继续调用,重复前面的过程。这个机制就是回路熔断,而这个工具则是回路熔断器(Circuit Breaker)。

除了隔离已经出错的服务实例,熔断器还有一个重要的功能是提供备用方案。虽然我们把所有业务都拆成了服务,但服务有高低贵贱之分。有一些服务属于关键服务,一旦出问题,则整个流程无法继续,有一些则属于分支服务,即便错了,也不会影响大局。

比如说,购买商品的时候,常常会根据用户的习惯和当前正在购买的东西做一些推荐。负责推荐的服务出问题的话,大不了就不推荐了,不应该影响用户正常的购买流程。同理,如果是在线点餐的地址定位服务出问题了,我们也应该允许用户手动选择餐厅进行点餐——体验虽然不佳,但至少正常的流程仍然可以走完。基于这个考虑,熔断器应该为非必要的服务调用提供备用方案,尽量保证核心流程的顺畅。

有了回路熔断器,远程调用出错的问题就从一定程度上缓解了。结合回路熔断器和对熔断阈值变化的监控,开发者可以更容易地发现问题,并及时采取行动。

负载均衡器:提升服务弹性

要正式上线,我们还必须做好负载均衡(Load Balancing,下简称 LB),提升整个服务的弹性。要做负载均衡,从理论上有两种方式:

客户端负载均衡(Client-Side LB):由客户端来决定如何分散请求。 中间方负载均衡(Mid-Tier LB):由 DNS、网关等中间方来决定如何分散请求。

现在,服务名册中已经有了服务及其对应的实例地址列表,所以客户端的负载均衡最简便的方式就是把地址拉下来,然后依次或者随机选择可用的地址。中间方的负载均衡则选择面较多,从最外层的 DNS 到网关都可以不同程度地去按需要去做。

扩展基建

现在,微服务基建基本完成了。如果有需要,我们可以对这个基建进行扩展。在做扩展时,架构师应该注意区分哪些东西应该中心化,哪些东西应该由服务自行决定。 比如说,在本文提到的基建之中,(几乎是)强制完全中心化的模块有:

  • 配置管理
  • 服务名册
  • 消息队列

其中,配置管理和服务名册是所有服务都需要的基础设施,必然需要统一。消息队列和日志收集都是为了跨服务的操作和追踪,也必须中心化。

半中心化的模块则有:

  • 路由
  • 鉴权

路由和鉴权都必须统一,我们前面讨论过。不过,微服务可能会向外界暴露“自用”和“客用”等多套公共 API(比如快递公司内部使用的物流 API 和开放给第三方使用的物流 API),所以可能会有两个 API 网关,对应会有两套 API 目录和两套鉴权体系,所以,它们是“半中心化”。

这些都是中心化、半中心化的选择范例。每一次中心化的选择都可能会让整个架构变得死板,失去灵活性,所以,我们在设计和扩展基建的时候应该特别注意这个问题。

除了中心化的选择之外,架构发展的另一个关注点,是让业务保持“黑盒”。

我们把每个服务之间的关联抽取了出来,也把权限的定义和验证抽取了出来,每个服务变得简单而纯粹,成了“纯业务式服务”,等同于一个仅包含了业务规则的黑盒。这样,不管服务和模块再多,也没有影响。业务的重用性也很高。

总而言之,搭建好了微服务的必要设施之后,剩下的就要根据实际情况和项目经验来继续调整了。比如,我们可能会选择把很多功能合并到一层,以避免过度分层所带来的不必要的性能损失,或者对整个基建进行一些细节微调。只要把控好“中心-自理”和“业务-非业务”之间的关系,这个基础设施就能健康地发展。

微服务基建总结

总结此文,微服务的基建应该包括如下一些组件(按请求流中的出场顺序):

  • 配置管理:配置集中管理。
  • API 网关:对外的 API 总目录;API 依赖关系;发起鉴权。
  • 服务名册:服务的注册和发现。
  • 鉴权服务:提供鉴权服务:认证身份,验证功能权限。
  • 前置后端:按前端的需求拆解请求、调用服务,并汇总、转换结果。
  • 消息中介:全局通知机制;异步调用机制。
  • 回路熔断:隔离出问题的服务并等待其恢复;提供备用方案。
  • 负载均衡:避免服务过载。

需要说明的是,这些组件的组合形式,具体拆分形式,是否需要,都需要结合实际项目和团队的情况来调整。本文权作抛砖引玉,请读者知悉。

Share