当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

从增强现实到增强人类

《增强人类》美国增强现实专家海伦·帕帕扬尼斯(Helen Papagiannis)的新著作,系统地描述了增强现实及其各种模式的含义及应用分类的知识体系。海伦向我们展示了增强现实赋能人类的能力,我们需要扩展自身的思维和想象力,重新思考“增强”一词在未来对于人类的意义。ThoughtWorks肖然和王晓雷翻译了本书,此文是肖然为《增强人类》写的译序。

从增强现实到增强人类

翻译此书的过程中正好遇到父亲心脏出现问题,几经周折医生建议安装心脏起搏器。父亲心里很纠结,一台电子仪器植入体内或多或少让人感觉有些惶恐。于是利用此书安慰父亲到:你只是提前体验了未来,等翻译完毕一定让你看看更广阔的增强人类世界。

虽然只是一句安慰的话,但本书的确为我们展现了一个全新的世界,甚至定义了新一代结合智能技术的增强人类,这是在翻译之前始料未及的。翻译过程中不断查询作者引用的企业和产品,就像展开了一幅通向未来的画卷,经历了一次非常享受的想象力之旅。在另一位译者王晓雷的提议下,我们也在原书的基础上增加了很多的图像,试图传递我们在这个过程中得到的启发和脑洞。也许本书的再版就会脱离纸面,通过各种感官技术带给各位读者身临其境的感受。

本书的另外一个重要贡献如前言中指出,VR/AR技术本身已经日臻完善,但如何应用这些技术确是另外一个挑战。在这个科技时代我们经常会拿着各种新技术的“锤子”去找“钉子”,这种做法在科技时代之前带有很强的讽刺意味,经常会被导师用来教育那些知其然而不知其所以然的学生们。但随着第四次工业革命的到来,我们看到了类似AR这样的技术突破引领着人们对问题认知本身的改变。拿着锤子找钉子这样的做事方法被重新定义为用新技术去颠覆各行各业,这件事情在我们身边随时发生着,以至于谈起新技术每个人都会有自己的感慨。

对于VR/AR技术,很多人预测将随着5G网络时代的到来而爆发,这也是我们最初选择翻译本书的原动力。但怎么爆发以及在什么地方爆发确不可能有人给出准确的答案。就这个爆发的问题,本书作者给出了非常有意义的见解,书名也从增强“现实”变成了增强“人类”。这意味着我们的关注点应该从技术本身转移到我们人类自身,从我们自身的感受和体验出发去寻找增强的机会点。我们采用增强现实技术的目标也应该是为人类提供更好的生活和体验,从这点出发我们会发现一个很不一样的增强现实领域,超越了简单意义上的视屏叠加,而是能够调动我们人类听觉、味觉、触觉、甚至于情感的体验增强。

到这里,我们确实对作者关于增强体验设计是一门艺术的观点非常赞同。未来良好的增强人类应用很可能出自于艺术家们的手中,就像我们身边各类艺术作品一样,美化着我们的体验,成为我们生活的一部分。而艺术本身就是一种创作,最好的作品是出于生活却高于生活的,这也是我们在考虑现实增强技术应用时是所需要遵循的原则。从某种意义上讲,我们这样的技术人员应该尝试着向艺术家一样去贴近生活,让技术服务于我们的生活,并创造更好的生活。

最后,这也是一本充满正能量的科普读物,相信大家读完后会少一点对新技术的恐惧,多一分对未来生活的向往。技术本身没有正邪之分,作为创造者和应用者的我们决定了技术的走向。读完此书,我们更加坚定技术会增强我们人类的生活体验。而翻译结束时父亲也开始揶揄自己是增强人类了。

书籍内容概要

第1章:回顾从1997年开始的AR的经典定义,讲述了AR的今天和未来变化。

第2章:从艺术装置,到机器人和自动驾驶汽车,探讨计算机视觉如何为我们提供新的“眼睛”,增强人类视觉体验。

(ARKit的典型应用:无缝地在现实桌面上展示虚拟玩具车)

第3章:介绍触觉技术的研究和创新,以及使用触感进行沟通的新方法。

第4章:探讨了增强音频和“可听式”设备(佩戴在耳朵中的可穿戴技术),如何改变倾听周边环境声音的方式,甚至改变环境如何“听到”你的声音。

(Detour带你游览著名的卡斯特罗街道)

第5章:探讨数字嗅觉和数字味觉这个持续成长的研究、原型和产品设计领域,及如何增强我们共享和接收信息的方式,增强娱乐体验。

第6章:探讨如何通过AR来创造引人入胜的叙事体验。

第7章:探讨虚拟化身、智能代理、物品和材料如何成为活跃的情境变化因素:针对情境来学习、成长、预测和进化。

第8章:探讨了从电子纺织品到嵌入身体的技术,以及大脑控制接口等各种增强人类身体机能的方式。

(丝芙兰的虚拟艺术应用Modiface,查看自己上妆后的“妆容”)

第9章:归纳了10个AR体验分类,展望AR对人类更美好未来的影响。 谁应该读这本书?

“我特别欣赏海伦对艺术家(或被她称为‘惊喜创作者’)这一角色的洞察力和敏感度,这将会是下一波创新的火花。据我所知,迄今为止没有一个组织或社区曾经踏足过这片天地。增强现实不仅是工程师和计算机科学家的领域,也同样是作家和艺术家的地盘。体验才是我们能够记住,并终将改变我们的。希望技术(或者说类似于我的贡献)能够变得‘不可见’,为人类的创作腾出更大的空间。” AR/VR的祖父,汤姆弗内斯在为本书写的序中这样说。

无论是设计师、企业家、教育家、艺术家、商界领袖,还是开发者、工程师、技术爱好者,只要对AR充满好奇和兴奋,相信本书中的大量案例,会让你大开脑洞。


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

Share

数字化创新中的设计

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

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

创新是一个大家又爱又恨的事物,在这个不断涌现新生事物的数字化时代,大家都希望自己成为下一个“黑天鹅”的缔造者,都害怕自己成为被颠覆的“受害者”。而伟大的创新仿佛都要站到悬崖边才能发生,所谓混沌的边缘(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