微服务化小团队集群的组织和管理

随着微服务架构风格的流行,组织内部不可避免的产生了许多小规模团队,原来一个几十上百人的产品团队被拆分成了类似Amazon这样的2 pizza(6~10人)小团队。组织结构上也由之前的层级化职能团队设置变成了扁平的小团队集群。每个做这样调整的企业都希望借助小团队的灵活性在这个科技时代跟上市场变化和创新的脚步。

(组织的两种基本模式示意)

当然这样的组织方式本身就带来了一系列的挑战,技术实践方面Martin Fowler已经通过微服务的定义文章做了很形象的叙述,还用了“你必须长这么高”(You must be this tall!)来比喻在技术实践方面所需做出的投入。

在组织管理方面,越来越多的挑战被识别出来,把“自组织”当做银弹来回答这样集群小团队组织和管理中的问题是行业里存在的一个不好趋势。在最近和Matin Fowler的讨论中,我们达成共识的一点是:与其说微服务是一种技术架构,还不如说是一种企业组织架构

希望通过本文与大家一起研讨这样服务化小团队集群的组织和管理方法。

组织原则:对齐业务

科技时代带来的最大变化就是对变化本身的认知。在上一个时代,变化被认为是高成本甚至有害的,大家总是希望能够尽量减少变化,或者能够循序渐进地变化;而现在我们会认为变化是必然的,是会给我们带来新的市场机会的,甚至是会引发颠覆式创新的。

由于这样的认知变化,企业必须具备相应的灵活性,而扁平的小团队集群组织结构被不少企业(例如Google和韩都衣舍)证明是提供这种灵活性的有效组织方式。很多企业争相效仿,但不少会发现并没有得到之前追求的灵活性,反而做事情更为复杂了,以前一个接口部门变成了现在的多个团队。

作为咨询顾问,这两年经常接触到不少人抱怨划分成小团队后需求的实现成本增加很多,以前简单的业务需求现在要分解到很多“服务”团队才能完成。有的团队觉得这是技术问题 – 架构设计前瞻性不够;有的团队觉得是管理问题 – 没有跨团队的协调机制。而我往往喜欢从组织入手,让团队从业务需求出发,分析为什么那么多“集成”。

熟悉康威定律的同学可能已经理解我的用意了,以上团队出现的问题核心症结在于团队的组织结构和市场业务没有对应关系,大量的服务集成等同于把市场需求“翻译”适配到已有的组织结构。这样的痛苦在过去职能组织结构的时候就广泛存在,而错误的“服务化”只是把这种痛苦转换成了小团队之间的集成。

所以微服务化组织结构的核心原则是: 小团队的组织结构应该和市场业务对齐,并跟随市场业务变化而改变

稍微实例化一下以上的原则,比如最近一个客户的电商团队,100人左右规模。开始时候划分成了10人上下的小团队,每个团队负责几个服务,其中有几个“重要”服务,如customer(客户)和catalog(目录)。在一段时间里,几乎所有的需求都要经过这两个服务,工作量很大,团队实际上也根本不是十几人,而是几十人。团队告诉我:撑过这段高峰期模型就稳定了,以后就可以真正“微服务化”了(很多同学可能都有同样的幻想~)。

我用领域驱动设计的思想很快指出,就现在业务需求驱动出来的大量集成已经可以明确这些“重要”服务的划分是有问题的,新增加电子产品(比如点卡)的customer和之前的电商customer已经有不同的含义了,电子产品要求客户提供对应电子平台的账号和授权。按照上面的原则,不应该继续去扩充已有的customer服务,而应该重新分析新的业务模式下是否应该有新的服务(其中也包含新的customer模型)。

(不同的customer概念)

以上的例子在很多走向服务化组织结构的企业里比比皆是,而遇到问题时大家更容易从看似明确的技术或管理手段入手。这里希望读到此文的各位在遇到这样的挑战时别忘了康威定律。 管理原则:适应不确定性

《大教堂与集市》这本书中对比了两种不同的组织架构模式,很多特质也能够类比到单体架构和微服务架构之上。当微服务架构落地形成生态时(如Google),好比一个繁荣的集市,中央管理固然重要,但各个经营摊位却自主在为客户提供着琳琅满目的商品和服务。

作为一个企业,不太可能完全容忍集市一样的市场化,当然也有企业如海尔,把这种市场化更大程度上地引入到了内部。假设刚刚从过去职能层级组织结构转换到扁平小团队集群结构,这个时候管理者最大挑战就是如何还能够获取过去一样的“全面”信息。管理者往往会告诉我他们感觉到随时可能失控,因为每个团队都没有统一的开发方法和流程。

很不幸的是大多数从MBA课堂走出的企业管理者们都是管理“大教堂”建设的高手,却很难驾驭集市带来的“混乱”。然而我们的管理者们又都渴望着自己的企业能够有创新的环境。根据创新理论(Edge of Chaos),集市混乱产生创新的可能要远大于大教堂的整齐划一。那么在这个你不创新就被别人创新颠覆的时代,管理者就必须正视这个挑战。

管理的原则应该改变为: 放弃对掌控全局的虚幻追求,拥抱不确定性带来的挑战和机遇

同样实例化一下上面的原则,一个300多人的大产品经理与我谈他的困惑,自从转型成为扁平小团队结构后,他的会议比之前多了N倍,基本每天正常工作时间全部在开会。自己的产品方向和运营只能靠夜深人静的时候加班。他告诉我如果这就是所谓小团队要付出的代价,那么他觉得这事儿没法持久。

我首先肯定了他的观点,即如果作为产品经理都没有时间看产品方向和运营,那么模式上肯定是错了。进而询问最占用他时间的会议需要他做什么?很有意思的是他的答案是“我需要知道xxx信息才能保证计划的拉通”、“开会已经同步各个小团队最高效的方式了”… 这里表达出来的行为全部是希望掌控全局的急迫,和他嘴巴里说出的赋权团队、打造自组织文化大相径庭,当然知行合一本身就是困难的。于是我们花了很多时间来讨论为什么一定要有拉通的计划、为什么要中央同步各个小团队 … 这位管理者最后带着更多的困惑离开了那次讨论。

对比组织结构的调整,管理者思想和方法的转型确实任重道远。我往往给出的建议是从小处着手,比如放弃给每人安排任务,让大家自己来选择;又比如在团队之间冲突时,放弃作为管理者的“拍板权”,让团队通过快速实验来验证哪种方式更好。另一位大师级同事Jim Highsmith在八年前就总结出了适应性领导力(Adaptive Leadership),十年后的今天仍是少有管理者能够真正践行。

合作原则:简化集成关系

微服务下小团队集群的结构不可避免的需要更多的团队合作。一个运作良好的微服务生态圈背后是一个紧密协作的小团队网络,而团队之间的合作就是这个网络里无形的手。合作很多时候是团队和团队在运营过程中实时发生的,并非是预先设定或中央控制的,这个时候如何高效合作就成了一个很大的挑战。

在共同满足业务需求的过程中,大多数的合作是由于实现过程中服务之间的集成关系产生的。如前面讨论组织结构时的案例,很多组织在转型后反而集成多了,造成交流沟通成本持续增高,最后不得不安装很多会议和流程来“协调”这样的合作。结果当然是响应力越来越差,小团队名存实亡。

在团队合作方面DDD(领域驱动设计)原书中提出的(业务)限界上下文(Bounded Context)的关联关系可以借鉴。服务划分强调从业务视角出发,限界上下文提供了很好的划分指导,即可以根据限界上下文来设计相关的服务边界。由于每个服务对应一个小团队,那么实际上我们就建立了团队之间集成关系的模式。Eric Evans用了一个子章节描述了不同的基于领域模型耦合方式的关系模式(248页14.4),并零散地叙述了几个模式的演进场景,很多读者可能都不会特别关注那个章节。然而在微服务开始落地实施的时候,这些模式就变得十分重要了,因为这些模式本身也是团队之间的合作模式。

(限界上下文关系模式要求矩阵)

Eric Evans通过上面的矩阵总结告诉我们集成是高成本的,要尽量避免集成。同样道理在咱们团队合作的过程中,原则也是简化集成关系。在微服务架构下,显然右上角的“大泥球”(Single Bounded Context)和“共享内核”(Shared Kernel)是不推荐的;“独立自主”(Separate Ways)这种完全松耦合的关系是值得我们考虑的,但大多数情况下小颗粒度的服务之间还是会被不同的业务需求串联起来。

很多刚转型的企业会出现不少的“用户/供应商”(Customer/Suppier Teams)模式,主要是团队之间关系还是由更高层的领导在指挥,作为一个演进的合作关系应该更进一步向“开放主机服务”(Open Host Service)模式推进。现代的服务多是以API的形式更为规范的对外提供接口,所以其实在团队沟通方面的成本并非比领导中央决策高多少。

随着API规范的更进一步发展(如采用RESTful架构),很多时候服务团队之间只用做简单的翻译或遵从提供者的模型即可,耦合程度进一步下降,这个时候左下角的另外两种模式“防护层”(Anticorpution Layer)和“跟随者”(Conformist)就更为常见了。显然这两种模式集成关系更为简单,合作过程中调用服务的团队是不需要知道提供方的内部模型细节的,当然这个时候团队之间的信任关系也应该是相当高的。

服务化转型小结

采用微服务架构后自然会产生小团队扁平化组织结构,我们应该意识到在组织、管理、合作的原则及思维观念上都应该发生转变,忽略任何一个方面最终都会造成转型的失败。

  • 在组织结构上,团队划分要面向业务能力,持续提供市场价值。
  • 在企业管理上,管理者要拥抱不确定性,持续提升管理适应力。
  • 在团队合作上,考虑跨团队领域模型的耦合,持续简化集成关系。

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

Share

也谈“精益”

精益对大家来说都不陌生了,无论是最开始提取的丰田制造原型,还是后面延伸出来的物流供应链管理,再到近两年颇为流行的精益创业(Lean Startup),都在不停刷新着“精益”这个概念。最近也不乏把精益当成“热词”来包装的各种理论,以至于很多客户建议我另外给“精益企业”取个名字。我一般都会礼貌回答说:看看精益房子(见下图)吧,我们并没有发明什么新东西。

(图片来源于Six Lean Sigma – Learn | Teach | Impact )

当然,精益房子所表达的架构其实还蛮复杂的,也不是一两篇文章可以论证的,日本和美国管理学界也没有达成完全的一致。很多人的疑惑是咱们好歹是21世纪的新兴产业,肯定跟上个世纪的汽车制造业有不同吧?还用精益思想合适吗?这里我来谈谈自己的理解,抛砖引玉。

精益思想为什么适合于咱们这个行业,在我看来有以下两点:

  1. 追求快速价值交付的小批量生产模式
  2. 追求极致卓越的匠艺文化

追求快速价值交付的小批量生产模式

“这个谁都知道”、“这不等于白说吗”、“这个太虚,来点干货吧” …

这些都是每次抛出这句时会收到的反馈。然后我反问,“能给我讲一下你最近交付的一个功能挣了多少钱吗?”一般这个时候对方会回避我真诚的目光,嘴巴上说着“我们的系统很复杂,一个功能太小了…”。那么我们再来看看各个岗位的绩效考核吧?开发了多少条需求和测试出了多少bug,横比环比增长了多少都是报告中的常客。这里的“价值”被定义为了每个角色、每个人的阶段输出,类似富士康流水线上生产一个iPhone零部件的工人,至于最后是iPhone 6还是7于这个工人其实并没有太大关系,反正这批订单200万台,本周得搞定,做的越多个人收入自然会更多。

上面的例子告诉我们,并不是所有的生产模式都是追求“小批量”的,富士康在生产模式上是成功的,甚至是行业标杆。而丰田制造当年形成精益的生产模式,其核心是追求对市场变化的响应力,即用户一旦变了口味想开SUV,我的轿车生产团队及流水线能够很快调整开始生产SUV,并且我能够通过这种能力快速验证SUV的市场是不是真的。在这样的生产模式下,较之每个员工的资源利用率及输出,我们更关心的是“需求”是否能够在团队快速流动产出最后的产品,应运而生的是对生产批次小规模化及人员跨职能的要求。持续交付(Continuous Delivery)显然是咱们这个行业对这小批量生产模式的总结。

当然不用论证的是科技行业的市场是持续变化的,具有不确定性,所以逻辑上这种生产方式应该是必须的,即使是所谓的后台核心系统,其需求也不得不跟着所谓的前台用户需求变。很多人会说这个很自然啊,咱们拆了User Story做迭代不都是这样吗?那么有多少次大家会说“这几个User Story关联很紧,客户都要,我一起开发(测试)了,效率高一些”、“上线走流程麻烦死了,咱们还是一个月上线一次吧”、“所有都是Must Have,砍不下去了,PM上去磕客户了” …

当然我们不否认有的时候这些意见表达的可能是正确的选择,但显然,坚守这样的生产方式就需要在这些时刻去思考是否大家真的都运用了精益思想来指导自己日常的生产工作。

这个时候可能会有大牛又跳出来拍一砖:”看吧,还是管理的人不懂精益!”

那么技术人员真的理解了“小批量”的含义吗?在你的内心深处有理解包括TDD这样的基础技术实践是在践行精益“小批量”的价值观吗?用测试来描述一个业务小场景,然后加以实现,这种小步前进的方式正是个人对精益思想的日常修炼!每个“小批次”业务场景实现后,都要严格重构,追求代码的极致简洁,这又是我们接下来谈的对”匠艺“的卓越追求。那么环顾四方、环顾行业,有多少工程师能够坚持TDD呢?当开发进度紧张成为压力的时候,有多少人是选择第一个放弃TDD,将“小批量”原则第一个放到裤兜里的呢?!

追求极致卓越的生产匠艺

回到富士康流水线上,一个杀马特造型的青年在熟练地完成着iPhone屏幕的组装,他下意识地拿着工具钳咯噔一下,熟练地把一个屏幕扣入了iPhone的背壳,时间不到10秒钟,然后他开始重复循环。他的眼神好像有点游离,嘴角不时露出微笑,脑子里在回忆着昨晚和兄弟们撸串时的高谈阔论。他到岗1个月,第一天就学会了这道工艺,除了有一次把屏幕扣反了,这一个月还没出过啥问题。最近谈恋爱花钱不少,他每天都工作10个小时,虽然辛苦但想到和女友的甜蜜时光还是觉得值。

上面对等的场景是一个蓬头的程序员,对象(OO)也搞了5年了,这次遇上了函数(FP)项目,于是“WTF”成了口头禅,有时候在pair时忍不住说了还得道歉。最近code review出来问题很多,功能是没问题了,但老是想着修改变量值。每天盯着屏幕的眼睛有几根血丝,脑子里不时闪过无数马匹从Monad身上压过去,都上项目一个月了,最近几个User Story还是被QA揪出不少问题。虽然“心”苦,这段时间还是觉得很充实的,回家地铁成了最好的思考地儿,有时候突然开悟,回家兴奋着也想来个session,当然结果一般都是家人2次元的眼神。每每这个时候都希望第二天快点开始,能够去把代码重构了,实践一把自己在地铁上的灵感。

上面的两个场景很普通,在这两个行业里可能比比皆是。经常我们会开玩笑说一个卖体力,一个卖脑力。但其实本质的不同是生产者采用的生产方式的不同:在流水线上的杀马特少年需要的是严格遵循制造工艺的每一道工序,通过不停的重复形成机体的记忆;而程序员需要的是认清自己认知的局限性,通过不停的学习形成更好的解决方案。好的流水线生产者能够通过认真练习、快速形成机体的记忆,使自己产出的效率和成功率都能够达到一个高水平。好的程序员能够通过刻意练习形成大脑的思维体系,从而能够持续提升自己面临新问题时的响应力。由于丰田当时的“特殊”市场环境,迫使其表面看是一个偏重于前者的流水线,但实际却走出了一条持续学习和提高的文化之路,收获了对市场需求变化的高响应力。

所以有人会说:“对嘛!管理层都想着用熟练工,所以没法有精益的文化了!”

咱们还是小处着手,刚才谈了TDD,现在谈谈pair。曾经作为一名PM,我也为两个人结对指着代码论道半天非常恼火,虽然内心万马奔腾,但对“匠艺”的认可还是阻止了我去拆散这对pair,毕竟我清楚两人确实是在讨论重构而非其它琐事。当然事实证明这对pair现在都是业界有名的敏捷和架构专家了,好歹也算是对我当年苦难的回报。

再次环顾四方、环顾行业,有多少工程师能够坚持pair,甚至code review?有多少人希望能够在功能已经实现的代码之上持续追求卓越,而不是想着我自己干实现快一点好交差。至少这么多年的咨询生涯所见者有限,令人惭愧的是code review成了咨询需要去说服团队的日常工作之一。如果都没有分享和交流,甚至是争论,又哪里来的真正意义上对极致卓越的追求呢?

小结

上面两点可能只是整个精益思想落地层面的两个具体方面,但就我个人的体会而言,要做到已经非常困难了!即使在ThoughtWorks这样对敏捷高度认可和实践的团队里,要坚持做也可谓是一件艰苦卓绝的事情。什么事情喊口号容易,持之以恒的一万小时是每个希望成为精益践行者必须经历的磨练。“着眼长远”这一精益的另一基本原则送给还在坚持的同学们。


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

Share

超越SAFE,创新需要EDGE

EDGE(边缘)和SAFE(安全)这两个短语在字面上给人的感觉是截然不同的。在没有具体上下文时,我相信大部分的人会选择“安全”,“边缘”总是给人摇摇欲坠的紧张感。然而人类的很多突破正源自于这些反直觉的思考,让大家能够踏出自己的舒适区。

在这个科技时代,人人都期待创新和颠覆,都希望自己成为引领时代的创新者或颠覆者。然而创新却又是那么琢磨不定,没有显然的规律可循。

我们无从预见人类未来的创新是什么形式的,但从历史的经验教训中,我们可以学会一个朴实的道理:作为企业的领导者,要想在科技时代引领自己的组织迎接时代的挑战,就需要让自己站在创新的边缘,而不是让自己和组织蜷缩在看似安全的舒适区里。

1-grave

今天的舒适区就是明天的“英雄冢”!

创新:混沌的边缘(Edge of Chaos)

这两年有很多关于创新理论(Theory of Innovation)的研究,大家都希望找到最适合创新发生的土壤。根据斯诺登教授(Dave Snowden@Cognitive Edge)的Cynefin框架对问题认知的分类(见下图),普遍理解这样的土壤存在于简单(Simple)和混沌(Chaotic)的边缘,是一个峭壁,驾驭不好可能就掉进混乱(Disorder)的深渊。

在认知理论中,大家往往首先考虑遇到的问题属性是复杂(Complex)还是繁杂(Complicated),目的也是为了降低陷入混乱的风险。但这种认知问题的通用模式并不代表着我们在考虑创新时应该远离那个峭壁去寻求SAFE之所。恰恰相反,不到EDGE边缘就不会取得创新和突破。

2-cynefin

Cynefin问题认知框架

很多创新,比如风靡一时的自拍杆,在今天看来是一个很简单的解决方案,但为什么在其发明之前很多人却没有想到,而是凑合着利用已有的定时快门功能呢?自拍杆的发明是否遵循了一定的流程呢?

如果我们仔细思考,会发现即使是这样的微创新也存在很大的“随机性”,即我们很难说遵循一定的流程就能产生某种创新。但当创新产生后,我们往往会觉得豁然开朗,某些问题的解决方案顿时变得简单了。这个例子应该能够让大家体会到“创新为什么存在于混沌的边缘”。

当自拍成为了一个主流需求,有人开始思考简单的定时快门是否是最佳的解决方案,很快有人会发现如果能够用竿子撑起手机就能够解决自拍时经常找不到地方放手机的问题,第一代自拍杆就这么诞生了!继而会有人发现定时设定还是挺麻烦的,于是利用蓝牙来触发快门的功能也就应运而生了。那么是不是现在的自拍杆就是最佳的解决方案了呢?不一定,谁知道小型无人机会不会是更方便的下一代“自拍杆”呢?能随时自动跟着你,自动侦测到你的各种姿态。

所以创新本身是一个非连续性的混沌问题,人类目前还不能流程化、批量化的去复制创新,如自拍杆的例子创新是持续演进、没有终点的。作为一个组织,我们应该做的就是培育并保持这样的土壤,容忍一定程度的混沌去孵化创新。

再举个简单的例子,实现一个业务需求的时候,我们很多管理者希望的是从接口到数据库字段都能够“完美”的预先定义,写好规范文档然后交给码农去堆代码实现,大家都按照说明书工作;而另外一种小众做法是管理者给程序开发团队明确业务价值及需要解决的业务问题,让开发团队自己去决定最佳实现方式。

显然第一种方式更安全,但团队却决然没有做出创新的可能;而按照第二种方式运作的团队往往会产生很多创意的设计。有人会质疑这样做的风险和回报是否成比例,毕竟没有谁能够保证在某一段时间里按照第二种做法来做的团队一定能产出创新。

但不要忘记创新的本质是颠覆性的,伴随着科技的进步,试错成本持续下降,不能够驾驭创新带来的不确定性就只能坐等被别人的创新所颠覆,这是本世纪对组织管理者提出的最大挑战:

让组织既有足够的混沌来孵化创新,又能保持足够的简单来稳定基本的秩序。

结果胜于输出(Outcome over Output)

下面是我们经常会见到的两个典型场景:

  • 场景一:“通过团队这段时间艰苦卓绝的奋斗,我们成功达成了不可完成的使命,交付了100个功能点,交付效率提升了50%!”
  • 场景二:“我们上线了部分设计的用户体验,得到的反馈不是特别理想,好评度只有10%,我们准备重新定位用户群体。”

在大多数企业里,我相信第一个场景在各级汇报材料中比比皆是,第二个场景可能出现后就要被问责,大家会下意识的认为做产品设计的同学不负责任,而第一个场景下的团队最差也是“没有功劳也有苦劳”。这里的“苦劳”就是(努力的)输出,“功劳”就是(有价值的)结果,所以这句俗话就成了:没有(有价值的)结果也有(努力的)输出,等于“输出胜于结果”。这样的设置对既有组织机构下的每个人来说都是SAFE的。

但上面推导出来的结论可能大家都觉得是不能接受的,花了功夫做没有价值的事情怎么能够说得过去呢?

回想一下你或者你团队的年度述职报告,上面难道不是充斥着和场景一类似的描述吗?很多人会说开始时我们也不清楚是否有价值,而且市场变化决定了没有人能够100%确定产品功能交付后价值就一定兑现。

甚至很少有团队能够在设计功能的时候做出价值的估算。我们这里说的价值并非是“X功能实现后每天会有Y人次使用”,而是“X功能实现后每天会为公司在Z工作上节省15%的劳动力投入”或者“X功能将带给已有客户群体额外15%的经济收益”,简言之,这样的价值才是我们说的结果。

很可怕的是即使在这个所谓的高科技时代,当我们走近不同企业和组织,仍然可以看到帕金森定律在起作用:大家都很忙,每天有做不完的事情,每件事情都有输出,来再多的人还是这样忙碌,但却看不到转化出来的经济收益。

如果每个人都把自己的工作输出当成最后的结果,那么这样的现象是不会有一丝丝缓解的,“部门墙”、“各种会”、“大企业病”等等也会接踵而至。时下很多企业说”我们一直在做精益”,然而却忘记了精益的本质是价值驱动、结果导向。

价值驱动的决策系统(Value Driven Decision)

相信组织里的每个人都不会反对价值驱动和结果导向,但实际工作中却是知易行难。我们先来分析一下几个主要原因:

问题一:结构僵化

每个组织都有自身的结构,画出一个树状图的清晰架构在上个世纪是很时髦的,画不出来说明缺乏管理。采用这样的管理哲学必然导致结构僵化,这在当代已经成为大家的共识。然而有意思的是很多企业反僵化的手段就是不停的组织变革,采用不同的“先进”管理框架,然后针对泊来的框架“先僵化再优化”。

于是有意思的事情发生了,企业结构从一个僵化转移到另一个僵化,开始一般大家都热情高涨,“我们要变化,要站在时代的边缘去!” 然后是瞬间一落千丈,感觉新框架新结构又搞出了一套新的官僚机制。

4-bureaucrat

反僵化不是让大家把组织结构从原来的树状图转义成三层结构图,而是让整个组织具备在混沌环境下的运作能力,学会去感知环境时代的变化,然后快速做出反馈。这就是自组织的核心实质,也是为什么每个现代管理框架都要提”去中心化”的原因。正确的决策(决定创新的命运)可能发生在任何一个层级。

问题二:缺乏授权

现在,企业的管理者们并不缺乏主动授权的意识,但缺乏如何有效授权的方法。很多管理者的困惑在于授出的“权”最后还是回到了自己手上,所有的决策还是由几个人拍板,授权带来的只是效率的牺牲。

问题的症结在授权的方式上,很多管理者觉得给了“权”就要把“责”一并转嫁了,天下没有免费的午餐,所以如果授权张三可以决策产品是否发布,那么发布上线出了问题就要张三述职。这样看似公平的权责明确其实在“被授权者”看来更多是责任的转嫁,抵触心理可想而知。同时这样的授权方式下其实又创造了一个新的“中心”,根本没有促进自组织的形成。

举个典型的例子,很多团队的站会被我戏谑为“小组长汇报会”,所有人都向着小组长发言,甚至发言顺序都是小组长点名。每遇到这样的情况我都会首先“禁言”小组长,然后站会就混乱了,大家着急了,有意思的是也只有这个时候大家才开始思考共同的纪律应该是什么了!

这就是自组织的发生,即使在这么小的集体活动中也能体现出来。所以授权就是要让团队能够自发去找到决策机制,信任团队的协作,容忍站在外部看内部的混沌。

问题三:目标割裂

平衡积分卡这样的机制,在企业战略实施过程中应该已经是标准套件了,看似科学的分层分解机制从企业战略一直分解到执行层面的战术,很多企业的战略地图挂起来真的能让人欢心鼓舞好一阵子。但大部分企业实际的情况就是分解清楚了,图画漂亮了,仅此而已。

5-kanban

各级管理者抱怨下级执行层面不给力,年初的战略只有年底绩效考评的时候才会拿出来对标,当然往往都还是能“对上”。就这样年复一年消磨,直到颠覆者出现了,企业在抱怨声中衰落甚至解体。

战略目标分解有错吗?答案是没错,但错在分解的方式上!企业的战略目标被一次性分解到了各个部门各个团队,假设这些部门和团队都是努力负责、能力强的,都能达成自己的小目标,那为什么企业的战略目标往往成了空中楼阁呢?

这里大家忘记了不确定性,在我们制定战略的时候是无法排除接下来执行过程中的不确定性的,而这些不确定性意味着我们需要在执行的过程中不停调整,上面的分解方式显然是不支持这样的调整的,各个部门和团队领到了各自的小目标,越努力可能离企业真正希望获得的收益就越远,这里缺乏的就是响应变化的机制。

那么怎么才能建立响应变化的机制呢?答案其实很简单,抗击不确定性的法宝就是建立短周期的反馈闭环,要短周期就要求目标“小而精”。所以分解的方式不是按照企业现有的组织架构去“解码”,而是应该定义出战略目标下的MVP。

针对上面三大问题,ThoughtWorks抽象了一个决策系统(见下图)。这个系统首先是一个闭环,能够持续提供反馈并修正方向。在此基础上建立起来对愿景(Vison)和目标(Goal)的分解机制,并充分认识到每个机会点(Bet)的不确定性,通过尽量小的尝试(Thin Slice)来不断调整投资组合,保证对外界变化的快速响应。

7-edge

EDGE决策系统

精益的生态圈(Lean Ecosystem)

“大型企业如何进行大规模组织级创新”是一个世界范围的热议话题,如果说在一个小团队构建并维持一定的混沌来孕育创新是相对确定的,那么在一个千人万人的大型组织里怎么构建这样的混沌而不掉落到混乱状态就是一个非常不确定的问题。

目前来看,很多企业正在尝试着化整为零的小团队策略,希望通过这样的自组织小团队来平衡创新所需要的混沌和大组织治理所需要的简单。在此之上我们也看到了很多管理理论和框架的产生,都会用“规模化”来形容,其危险性在于从过去的职能部门僵化移步到新的小团队僵化,所以本质上并没有带来创新所需要的组织环境,每个小团队仍然可以SAFE的过日子。

更进一步看,规模化的方向不应该强调从三两个小团队运作到几十几百个小团队运作,而应该是企业各个职能部门的卷入,从扩大(Scale Up)变为扩广(Scale Out)。只有这样才能够在组织里真正意义的建立起创新的支撑环境。试想如果一个团队希望能够引入虚拟现实技术,而采购部门说设备没有事前预算等明年吧,在这样的环境下扩大是没有任何意义的。

近期的一些成功企业,如海尔和小米其实也在实践着这种扩广的精益生态圈打造,正如要做出一道创意的菜品首先需要各类调味品齐全一样,当一个企业形成了精益的生态圈、能够不停丰富自己的调味品种类时,某一时刻就会有新式的菜肴产生,同时生态圈意味着这种创新会持续自发产生,组织持续能够在创新的EDGE上跳舞,也只有这个时候创新才会成为常态。

8-edge

ThoughtWorks在科技时代精益企业背景下提出的“价值驱动决策”框架并用“EDGE”命名,主要针对如何在市场高速变化时保证投资有效性。针对EDGE的具体实践将在近期有系列的发布,敬请期待!

EDGE有6大主要的核心原则,见下图。

9-edge-frame

EDGE框架及核心原则


你想看到的洞见,都在这里

wechat

Share

你以为是微服务或Docker?其实是组织架构!

It’s Microservices …It’s docker …It’s organization structure

微服务和容器毫无争议的成为了这个时代的主旋律,大家争先恐后地让自己的团队和企业去尝试这样的旋律,但往往发现曲高和寡,难以在整个组织内形成共鸣。在本文中,我们尝试揭开微服务和容器技术背后映射出的组织结构的变迁,以及组织结构对落地微服务和容器化架构所带来的反向制约,最后用INVEST原则来看看支撑这样松耦合架构的组织结构应有的特质。希望能够帮助迷茫中的企业和组织重新思考自己的微服务之路。

Microservices(微服务)和docker(容器)成了近一年来软件行业的新宠,每次参加相关活动总会感到康威老先生站在背后邪邪地笑着:“我早告诉你们了”。

尽管Martin Fowler在“定义”微服务时十分小心的警告了大家所要付出的代价,但好像微服务的优点太过于吸引人,以至于大部分软件开发组织和企业都把微服务这种架构方式作为了未来的必选,大家都觉得我就是那个高个子(I’m that tall!)。

1-be-tall

(Martin Fowler对伴随微服务架构的高工程实践能力的比喻。)

随着容器技术到达生产应用的临界点,这种化学效应好像一触即发,我们仿佛看到了未来一个不一样的软件微服务大集市在逐步展开!

在这个集市里会有淘宝这样的平台,为中小服务卖家搭起一个在线商城,买家可以根据自己的需要搜索及购买琳琅满目、各式各样的服务,在线或是二进制、代码质量及自动化覆盖率等指标成为同类服务评级的重要标准。

杀手级的服务如区块链或者量子加密可能成为皇冠销量服务。最后掀起一大波程序猿开微服务店的热潮~ 很期待那是怎样的卖家秀和买家秀啊!

这种几乎接近于科幻的描述可能只适合作为微信上的谈资,但微服务和容器技术的流行却并非偶然。康威老先生用自己的定律揭示了一个更深刻的道理:

这不是一次技术架构或者基础设施的革命,而是为了保持组织灵活性的必由之路。

换句话说,软件开发组织或企业开始意识到一切的管理和技术实践都必须为保持尽可能高的组织灵活性服务。一定会有人问为啥要保持“尽可能高”的灵活性呢?铁打的营盘流水的兵、稳定的规章制度不也缔造出了历史上那么多成功的组织和企业吗?

论尽可能高的组织灵活性

所以我在前面加了定语“软件开发”,当然现在我们有一个更广泛的提法:科技企业。通常我们认为产品或服务的技术含量比较高,具有核心竞争力,能不断推出适销对路的新产品,不断开拓市场的企业为科技企业。

在我们所处的软件时代,大量的科技企业都跟软件沾上了边。但历史上我们可以回想大生产时代炼钢也曾是高科技,信息时代发邮件也是高科技。前两波的“科技企业”给我们的印象可不是灵活的:几大钢铁巨擘让人联想到的应该是当年国家呼唤生产力全民建设的宏伟场景;信息时代佼佼者如Microsoft和IBM让人联想到的应该是动辄千人的大型工业软件开发队伍,一个部署都得来一个专家队伍。那么为啥现在咱们的科技企业必须灵活,而且必须尽可能高呢?

2-steel

这里我们再次使用康威老先生的定律来做推论,康威定律说

“一个产品或系统的设计(架构)受到其生产组织自身交流沟通结构的制约”,

换句话说如果你有一个前端展现团队、一个后端服务团队和一个数据库团队,那么我们可以肯定,搞出来的系统会分前后台和数据库的设计。这本身是一个悲观的定律,所以前面的团队发现新需求来了必须沟通三次,前后台团队关心新需求对自身架构的影响,数据库设计关心对现有数据结构的冲击,最后总是会在各方的争执中得到一个别扭的解决方案。

很多团队早已经习惯了这样的痛苦,数字化时代的变化频率将这样的痛苦逐渐推向了顶峰。举例感受一下:达到100亿产值,首钢用了71年,联想用了13年,这个时代的小米用了仅仅3年!而今年的小米已经不是站在浪潮之巅的科技新贵了。

所以康威老先生说:

如果要保持产品的持续竞争力,就要保持组织的灵活性。

曾经有人跟我争辩说:“我们做的是数字化时代的后台系统,不直接面对市场,需求很稳定,搞那么灵活成本反而高。”于是我指着他们有着千万行代码的系统说:“你们至少有30%代码是冗余的,这就是组织缺乏灵活性的另外一个恶果。”

3-code

这里我们先收缩范围到软件开发,非常有意思的是在咱们这个行业里,针对同一份需求,没有两个开发人员实现出来的代码是一样的(也许Hello World例外)。甚至,当我发现两个程序员使用的变量命名一样的时候我会怀疑他们抄袭了。这说明软件开发从需求提出到写代码实际都是在做设计,不同的人设计出来的东西就会不同,像大家的签名一样。

设计甚至延续到了后面的软件测试和部署,同样的应用在不同的网络拓扑结构下表现可能是完全不一样的。那些追求稳定的组织希望尽早结束设计这个高度不确定性的活动,从而能够通过标准化来提高效率。

即使在敏捷开发主流化的今天,很多团队仍然是架构师“画图”,码农堆砌代码。所以这样的组织很快发现自己深陷二进制的泥潭,进退维谷。我经常跟这样的团队讲:你们缺乏“代码的响应力”。而响应力对组织的要求就是灵活,能够从前到后驾驭设计活动带来的不确定性。

小结一下:数字化时代的市场变化是迅猛的,康威老先生已经告诉我们,处在这样时代背景下的科技企业保持组织灵活性是十分重要的。而软件(广义讲新科技领域)本身由于强设计而带来的不确定性又加重了对组织灵活性的诉求。

于是在这个时代我们看到了如Google、海尔这样已然成功的企业开始大刀阔斧地改革自己的组织结构,这种对灵活性的极致追求成就了这些组织持续保持市场领先水平的核心竞争力。毫无疑问,微服务架构的优点也正反向映射出了组织结构的灵活性,而容器技术的运用降低了这种松散集市结构的运营成本,就如同淘宝平台的出现给千千万卖家和买家搭建了一个基础的交易平台。

弹性伸缩的容器化计算资源加上松耦合的微服务架构必然会吸引追求组织灵活性的企业去打败康威定律,保持组织活力。

 

组织结构的INVEST原则

前面咱们辩证了数字化时代科技企业保持组织灵活性的必要,那么灵活的组织结构应该满足什么原则呢?下面我们就借用敏捷开发中赫赫有名的需求管理原则INVEST来剖析一下怎样的组织结构才能够真正落地微服务架构和容器技术带来的灵活性优势,或者从另外一个角度看支撑微服务架构的运用。

5-organization-structure

(两种组织结构对比示意)

独立的:Independent

按照微服务架构的团队应该对外提供一种或多种服务,服务和服务之间应该是松耦合的,所以背后的团队也应该是相对独立的。遵循康威定律,如果一个大型组织没有能够划分出服务导向的相对独立团队,那么最后对外提供的产品或系统的内部结构也不可能是简单的服务组装,而会是我们常说的“意大利面”,内部结构纠缠不清以至于最后响应市场新需求越来越慢。 便于沟通的:Negotiable

“小“服务团队的结构必然造成整个组织的集市化、社区化。如果没有建立良好的团队间的沟通机制,很难想象这样的组织里会有任何的产出。Amazon被认为是一个微服务架构运用的成功典范,其2pizza团队的原则成为了业内的标杆。

但这样服务导向小团队集合的底层是长期磨合形成的良好团队间沟通机制,甚至当我们问到Amazon各个团队如何发现其它服务或要求其它团队协助完成需求时,团队都说不出具体的流程机制,一切都变得很自然,全然像我们走进自己熟悉的超市一样,能够很自然的找到日常所需。

有价值的:Valuable

毫无疑问,每个团队必然是面向价值交付的。敏捷开发方法的提出其实很早就指出了传统方式下按照功能部门划分的瀑布交付模式的原罪,即每个功能部门都不对最终的价值交付负责(Output over Outcome,输出大于结果)。这样的组织结构必然造成对市场变化响应的滞后。

值得一提的是面向价值交付的团队往往也是跨职能的,按照微服务的架构,团队需要负责服务从需求到部署运营的全生命周期(Outcome over Output,结果大于输出)。这也是为什么在基础的工程交付平台及实践上团队必须是一个“高个子”。

可估计的:Estimable

这样的服务团队交付周期应该是很短且可以准确估计的,上线应该是家常便饭,而不是过去短则数月、长则一年的大爆炸模式。持续交付在这样的组织里应该是标准实践,让软件系统时刻处于可发布状态是团队的共同责任。从Amazon和Netfliex这样的现代科技企业身上我们已经看到了这样组织结构下逐步形成的工程能力优势,并最终转换成了业务服务上的巨大成功。

短小:Small

前面提到了Amazon的2pizza团队,人数10人以内,经典的敏捷管理框架Scrum也建议5~9人的团队,可见小团队成为组织灵活性的一个必要条件。中国俗语有“船小好调头”朴实地揭示了小的灵活性,但为什么不再小一点呢?比如两个人结对一个团队。

显然大家很容易发现软件开发本身的复杂性决定了要端到端交付价值两个人的团队是搞不定的。从整个组织的健壮性来讲,过小的团队也会增加企业形成单点依赖的风险。虽然没有正式确认,但我们交流中发现Amazon这样的微服务组织里其实也是存在服务冗余的,这样的重复保证了组织在切割成小团队后风险得到适当的规避。

可测试的:Testable

在面对市场情况高度不确定性时,我们应该直面试错这件事情。传统职能型的大组织结构往往是不能容错的,错误的代价就是整个企业走偏了方向,或者一个部门在企业里失去了话语权。

在灵活性高的组织里我们却应该是能够很容易进行这样的“测试”,企业更能够利用这样的结构进行动态的投资组合管理,像Google著名的7:2:1投资比例,最后的一成就是利用组织的灵活性进行创新的测试。测试的结果往往是失败的,但正是这样的不断测试创造了Google历史上很多著名的“黑天鹅”。

打破康威定律

最近很多以精益(LEAN)为关键字的理论框架在咱们这个领域冒了出来,也包括我前期撰文提到的精益企业(Lean Enterprise),于是有朋友揶揄说又开始炒概念了。我却很严肃地澄清正是不希望炒概念,所以才回到了上个世纪就论证和发展起来的理念:精益。

6-lean

来源于丰田制造的精益总结出了很多的原则和实践,但有意无意中丰田完成了自身组织持续灵活性打造这项超越同期其它企业的伟业。其结果就是在响应需求多样化时展现出的更强适应能力。

如果用我们前面的INVEST原则来看待精益组织,你会很快找到对应的原则和实践,即使在传统的工业流水线上,丰田也在形成一个个的小团队(cell,单元生产),也在通过员工的多技能培养来完成小团队内部的“跨职能”。其持续改进(Kaizen)的核心思想有力保证了团队面向价值的工作方式和良好的跨团队沟通文化。

某种意义上讲精益在康威定律定义之前就打破了康威定律!

微服务和容器技术无疑是这个时代工程架构方面支撑组织灵活性的重要一步,然而我们不能忘记一个组织是五脏俱全的,如精益企业提到的,组织的财务审计、人力资源、采购合规等功能如何有效的“微服务”化和如何能够合力构建一个弹性的“容器”支撑平台仍然需要诸君努力!

Share

从敏捷转型到精益企业

数字化大时代下传统企业面临着种种挑战:效率永远跟不上市场业务需求,质量总是修修补补过日子,协同在部门墙面前无从谈起。很多企业结识了「敏捷」,开始尝试用敏捷组织转型来应对这些问题。2008年我在国内接到了第一个敏捷转型项目,一转眼八年过去了。尽管在这个领域里,持续交付(Continuous Delivery)开发自运维(DevOps)规模化敏捷框架等一系列新概念如雨后春笋般冒出来,但敏捷宣言没变,敏捷核心实践没变,敏捷咨询好像也没有太大变化。最近在研讨和推广「精益企业」的时候,「精益企业和敏捷的关系」这个问题突然让我有机会反思这八年不同组织里「敏捷」到底发生了什么样的变化:显然目标没变,都是组织敏捷转型,解决的问题也都是上述这些挑战,那么这个领域里什么变了呢?

要回答这个问题首先要澄清对时下流行的「规模化敏捷」这个提法的理解。由于一些框架的提出,如SAFeLeSS等,「规模化」成为了这两年敏捷转型领域里的热点(也被大家看成了敏捷转型领域的发展)。但我尝试过在一个组织里询问不同角色对规模化的期望,结果是大相径庭的。比如在一个典型千人规模的IT组织里交付团队认为「规模化敏捷」应该标志着绝大部分团队已经采用了迭代开发的模式,而业务人员却认为这样的「规模化」对他们没有意义,「规模化敏捷」的实施应该是让团队具备在开发过程中快速响应市场变化的能力。所以「规模化」的提法是模糊的,咱们需要更实例化地来看组织敏捷转型这些年的演进历程。

更深入的敏捷实践

2008年请我去做敏捷教练的组织是一个传统行业的线上服务平台IT团队。这个组织拿出了一个网络平台组来实施敏捷开发。于是我们从Scrum入手,建立了两个全功能团队,把以前部门割裂的需求分析、开发、测试拉到了一起。由于组织领导者的高度关注和试点「特区」运作的模式,这两个团队很快按照迭代的模式运作了起来。

三个迭代后这两个团队都能够自发的组织各种关键会议,如迭代启动、回顾会议等,大家的交流沟通也日趋默契。如果身临其境,你会觉得这个团队很敏捷,但外部看来问题还是挺严重:迭代计划的需求基本上完不成,测试普遍滞后,用户故事(User Story)普遍达不到完成(DoD, Definition of Done)标准。

当然现在看来问题很明确,稍微有经验的读者都会说他们需要加强技术实践了。在后期,团队敏捷教练的时间主要都投入到了如持续集成、自动化测试这样的技术实践辅导里。作为程序员出身的我当时并没有从组织转型的角度思考,只是在解决现实问题罢了。如果你想提升用户故事的交付效率,显然必须考虑工程技术方面的问题。

2009年我又作为教练加入了一家大型通讯设备厂商的敏捷转型。面对复杂的组织结构和百人的开发团队,我自己有些迷茫了。经常会被一些部门领导问得不知所措,怎么把Scrum这种小团队模式在百人的团队里实施成了一个难题。回想起来,如何应对当时组织里的各种约束条件,比如绩效考核怎么搞、预算怎么做,这些企业转型后必须面对的问题,我当时并没有答案。

但有意思的是,在我参加的几个试点团队里,由于我们同步推进了不少技术实践(如重构、TDD),得到了出乎意料的认可。经典的案例是在一个项目上通过代码重构减少了三分之一的代码量而实现了同样的功能,并且代码结构变得清晰简洁。现在可能这样的案例或成果已经随处可见了,但大家可以想想在2009年,大多数企业度量程序员效率还是依靠单位时间代码行产量的环境下,这会带来什么样的冲击。

在之后的咨询生涯里,每个企业我都会要求管理和技术实践同步进行。成功的敏捷转型团队几乎都可以看到技术实践的持续进步。2013年当我接触到敏捷流畅度模型(见下图)时,图中第一颗星所要求的团队文化转变需要引入管理框架完成,如Scrum和Kanban;通往第二颗星所要求的团队能力转变,却必须依靠技术实践的落地。所以技术实践的引入是组织敏捷转型演进过程中的重要一步,让敏捷实践更加深入。此时,我茅塞顿开。
Agile Inflency Model

图1. 敏捷流畅度模型(图片来源:http://www.agilefluency.org)

回想2012年后,作为咨询顾问的我,已经没有听到任何团队说只引入管理实践了。即使在一些非常传统的技术领域,如嵌入式设备(甚至是芯片开发)和大型机(Mainframe),敏捷提倡的技术实践也被不停地尝试。业界敏捷转型很成功的一家大型海外金融保险机构,先期也大刀阔斧地通过重构、自动化测试等技术手段简化了自己的整个大型机生态系统,成功把部分核心系统迁移到更为开放的技术平台上,大大降低了维护成本。

更大规模的敏捷推广

敏捷实践深入后的效果在一些团队中很明显,我还记得好几个团队告诉我效率提升在50%以上。但作为顾问,我面临的组织不可能是两三个由7到9人组成的开发小组,而是少则百人、多则上千人的大型组织。这时候就面临着真正意义上的「规模」问题了。

2012年之前我还是比较「幸运」的,无论是教练还是顾问,我都回避了这个「规模」问题,因为企业认为敏捷是一种新的尝试,所以一般都是试点,意味着我带着几个小团队就可以了。最后可能交付一些组织级的方案,当然其中不会涉及到组织结构、流程再造、绩效激励等小团队可以暂时「忽略」的问题。以至于2012年我觉得敏捷没啥好讲的了,每个企业都大同小异。

2013年在互联网金融繁荣的背景下,很多金融保险机构的IT组织开始进行敏捷转型。首先遇到的挑战就是严格的部门划分和职责定义。由于业务监管及合规性的强要求,金融保险机构的IT组织一般继承了业务这方面的特点,倾向于流程上的集中强管控,稳定是首要任务。很多组织都首先拿出了互联网相关的IT系统来做试点,但不同于之前试点的是,由于组织的集中管理结构,必然要求最后站在整个组织的角度来定义敏捷的实施和推广。另一方面我们也看到更多的复杂产品团队加入到敏捷转型的阵营中来,特别是一些大型嵌入式设备的研发团队,上千人的规模是比较普遍的。

图2. 典型金融保险IT组织结构

这样的背景下,前文提到的规模化敏捷框架(如SAFe)开始流行起来。敏捷提倡的「以价值为导向的高响应力小团队结构」,在这些大型组织里如何落地,成为了第一大挑战。作为咨询顾问,尽管这些框架有很多可取之处,但在组织的流程运作和管理方法上,还是需要考虑组织的特点加以定制。即使在宣称直接应用这些框架来实施转型的组织里,最后的实施结果与原框架的差异往往也是非常巨大的。

经历了两年这样的大规模敏捷转型后,我开始认识到这样的大型IT组织存在必然的「二元性」,如核心清算系统的开发模式,不可能和移动互联网应用的开发模式保持一致。只有承认这种二元性,才能在这样的组织里实现真正意义上的敏捷!得出这样看似明显的道理和论断,花了我们很长的时间。Gartner在2014年总结出了BiModal(双模)IT,基本描述清楚了这种二元结构存在的合理性。

gartner-bimodal-it

图3. Gartner BiModal(双模) IT(图片来源:https://juanjesusros.files.wordpress.com/2015/02/tabla-bimodal-it-gartner.jpg)

(注:BiModal在明确指出了复杂IT组织二元性的同时不免也过度简化了问题,比如两种模式应该如何协作、企业的创新如何开展等。笔者建议在采纳时根据组织的具体情况进行更为细致的分析。)

追求更大规模的敏捷推广仍然是现在大部分企业面临的变革性课题。随着敏捷开发模式在全球范围内的主流化,很多组织已经不希望再通过试点的方式来引入敏捷了,这个时候认识到IT复杂度带来的二元性就显得至关重要。这两年我们也看到了很多组织生搬硬套如SAFe这样的框架而形成了一套新的瀑布流程,不但没有获得敏捷提倡的高响应力,反而在动荡中牺牲了效率。

更广阔的精益组织

2015年,我作为咨询顾问加入到了一个千人的IT组织里开展敏捷转型咨询。借着前面更深入、更大规模推行敏捷的经验,我已经能够很快「按部就班」地和企业的转型推进者们一起制定出转型的节奏和目标。从试点到推广的效率也越来越高,内部改进人才的培养也有章可循。

但新的问题来了,团队开始反馈「立项太复杂了,不支持敏捷迭代」、「外包人员流动性太快了,无法深入敏捷实践」、「采购要求范围确定,敏捷模式下没法通过审计」、「敏捷技术能力要求太高,招不到合适人员」,这样林林总总的问题纷至沓来。

2015年初,我又幸运地接触到了前文提到的《精益企业》一书,发现原来这些挑战在各种组织中都普遍存在。跟几位作者交流后,发现大家的认知是一致的:敏捷转型绝不仅仅是研发团队的变革,而是涉及到一个企业的方方面面,是一项包括行政、财务、人力资源等部门的综合工程。由于过去十年大家对敏捷先入为主的观念(即敏捷是一种软件开发方法),《精益企业》作者们为了明确敏捷作为一种思想,对于一个企业来说绝不仅局限于IT,所以特别用了「精益」来加以区分。

在精益企业的架构(见下图)中,我们可以明确地看到,探索新商业模式和拓展已验证商业模式这两种不同业务形态的显式区分。通过企业运营、IT架构、目标制定和组织结构的精益化来打造一个高适应力、持续创新的高绩效组织。这毫无疑问将是企业敏捷转型的下一个必由之路:一种全新的生机勃勃的产品开发模式,在产品的探索期、拓展期和成熟期采用不同的工作方式,并顺利实现从一个阶段到另一个阶段的跨越。依托设计思维、实验性交付、精益看板、持续交付和持续改善等方法最大化产品所创造的用户和业务成效。图4. 精益企业架构(该模型根据《精益企业》书中对高适应力、持续创新组织的描述建立)

前文中提到的海外大型金融保险企业,在敏捷转型取得巨大成功后也开始对组织结构进行深层次的调整,先后围绕用户体验和创新技术成立单独运作单元,目的是能够更好地支撑探索型的创新商业模式。可以说没有这样的调整就不会有这个组织在移动、云及大数据等新兴技术领域的快速应用。整个企业也因此能够在用户体验和技术能力上持续创新。

总结

回顾组织敏捷转型这8年,从简单的小团队引入敏捷管理框架开始导入,敏捷转型经历了对技术实践的更深入尝试、对团队规模的更大范围采用、以及对整个组织的更广阔精益变革。随着IT行业的颠覆式发展,敏捷转型涉及的范围也在不断扩大,今日我们谈论「精益企业」时,已经把敏捷的思想运用到了企业运营的方方面面,对价值的追求也不再局限于高效的软件交付,而是持续创造市场价值。

展望未来,「科技即商业」正在逐步成为现实。全球著名的在线影业公司Netflix公开宣称自己是一家技术公司,经营电影视频只不过是他们利用自身技术创造社会价值的一种方式。传统企业,如通用电气(GE)布局数字化多年,形成了自己的数字化工业架构,具有自己的智能机器数字线、数字分析应用产品、以及工业互联网云平台等,转身成为世界上最大的“软件公司”之一。中国的新兴互联网企业也在纷纷效仿,在创新技术上进行了大规模投入。在这样的时代背景下,如何打造精益企业、拥抱技术变革必然成为企业市场成败的关键。标普S&P500中的企业平均寿命已经从上世纪六十年代的60多年逐年下降到现在的不足20年,创新技术正在以越来越快的速度颠覆着企业的市场环境,如果谁对技术即业务的未来还存在一丝一毫的犹豫,那么被挑战的不仅仅是企业的发展,而是企业的生存。所以当下的企业转型绝不再是简单的敏捷开发方法的导入,而是围绕企业经营环境的精益生态圈的建立!

 

 

 

 

Share