从王安石变法看“规模化敏捷”

[摘要]

当前敏捷在大型组织中的规模化落地,某种程度上很像历史上的变法。回顾王安石变法的历史,它为什么会失败?对比敏捷的规模化实施,探讨“规模化敏捷”到底可不可取?以史为鉴,我们应该怎么做?


最近在阅读《罗辑思维》全集时,看到一章很有意思的内容,详细分析历史上的变法,其中王安石变法部分让我不断联想起规模化敏捷的实施。两相对比分析,有诸多启发。

一、历史回顾:王安石变法

大事记

王安石变法为什么会失败?

回顾王安石变法过程,会发现其初心很好,实施策略看似做得特别成功:

  • 变法初心:王安石改革之前,司马光问王安石怎么改革?王安石说他有一个方法叫“民不加赋而国用饶”。王安石认为,北宋国家贫苦的症结,不在于开支过多,而在于生产过少;农民之所以贫苦和不能从事生产,一方面是由于官僚富豪兼并了大量土地,另一方面是由于政府把繁重的徭役加在农民身上。因此,最好的理财富国之路,是依靠天下所有的劳动力去开发自然资源,是积极开源而不是消极节流。即不增加赋税,激发社会活力而让国家变得富强。
  • 实施策略:
    • 先定义蓝图:上《本朝百年无事札子》,谈改革之蓝图;
    • 获得高层支持:北宋皇帝宋神宗,本来久慕王安石之名,其变法之道得到了他的绝对支持,他常常跟周围的人说,他跟王安石就是一个人;
    • 清除反对力量:王安石在获得高层的绝对支持后,对变革有异见的大臣比如欧阳修、司马光进行清除,扫清障碍;
    • 全面推广:在蓝图获准、清除变法异己之后,快节奏地全面推广。

然而,结果却失败了。为什么呢?浅析一下,原因可能是:

1. 目标与执行上的不匹配

历史上的变法,可以分为两类:追求效率的“效率型变法”和追求活力的“活力型变法”。

  • “效率型变法”:效率优先、集中财富但不制造资源和财富增量。简单来说,就是围绕单一目标展开,国家要达到这个目标,不惜一切代价集中所有资源都要实现,比如商鞅变法,春秋时代层层分封的财富分配体系被商鞅全部拆掉,他把国家的每一个老百姓、每一粒粮食都镶嵌在国家这个战争机器上,所以秦国变得非常富强。
  • “活力型变法”:激发活力、制造财富和资源增量。这种变法会同时考虑多个目标比如朝廷财源比较丰沛、老百姓安居乐业、市场繁荣稳定、军队能够有战斗力、政府高效廉洁等;在实施时不是调整存量分配,而是想法设法制造财富和资源增量。比如1933年到1941年期间,由美国第32任总统富兰克林·罗斯福发起的罗斯福新政,他围绕经济、农业与工业、社会保障以及政策制度等几个大的维度展开,后人用核心3R来总结,即救济(Relief)、复兴(Recovery)和改革(Reform),也称三R新政。最终,美国经济复苏,政治制度上建立了以总统为中心的三权分立格局,人民生活得到极大改善。

王安石变法,初心上是“追求活力”、有多重目标的,但实施上却采取了“效率优先”的方法,核心是依靠权力把效率推进下去。“效率型变法”要想成功,有一个天然的前提,就是先有蓝图,然后集中快速施工。对一个单目标系统,预先设定一个“正确的”蓝图尚且挑战重重,如果是针对一个多目标系统,几乎是不可能的。这种目标与执行策略上的不匹配,成为失败的原因之一。

2. 低估了制度成本

其实王安石的变法,从制度设计角度是非常好的,比如青苗法的初衷就很好:给老百姓提供低息贷款,避免去借高利贷,以保护和赈济民户。但问题出在制度的实施是表面上附和但内心未必接纳的各级官吏来推进的。最后变成什么了呢?那就是领导意志。比如当时有一个小官叫做邓绾,为了巴结神宗,当听到神宗称赞王安石为“当今之古人”后,瞬间明白领导意思,就神乎其神地夸王安石变法各种好,虽然他不一定懂新法但却得到了重用。这些变法的落地执行者,为了达到目标或超额完成目标,强制摊派老百姓贷款。最后,实际结果适得其反,不仅没有降低老百姓的压力,反而变成了一种变相的赋税。所以,良好的蓝图在实施过程中遇到了制度成本——执行变法的人,没有理解其真实意图,只是围绕既定KPI开展工作,结果自然不好

3. 忽视长期、可持续的变革力量

任何一种变革都不可能一次性成功,新法也可能会失败。如果失败了,那些反对派一定会站出来攻击王安石。所有效率型改革,只要失去高层支持,无论是主动的还是被动的,出路只有一条,那就是失败。宋神宗一死,继位的高太后一上台就把王安石搞下台,新法完全没有了机会,退出历史舞台!王安石阵营在变法期间,并没有能够培养出持续推动变革的力量,比如王安石卸任时推荐了他信任的吕惠卿继任,这个人不但没有继承变法大志,反而落井下石,跟邓绾一起诬陷王安石叛乱。因此,后面即使没有高太后和司马光,变法也难以为继。

二、敏捷的规模化落地与变法实施

敏捷(Agile)是2001年由17位资深软件领域专家们一起发起的针对软件开发工作价值观的倡议。作为一种软件开发理念,与之伴随出现了很多实践框架和方法,如Scrum、Kanban和XP。而这些方法目前已经逐步成为了我们软件开发的实施标准,类似持续集成(Continuous Integration)这种10年前被大家认为是“极限”的方法,现在也已经成了开发团队的一个标配。但在很多大型组织里,敏捷的大规模应用仍然是一个非常有挑战性的任务。软件自身的多样性和这个行业的高速发展,造成了敏捷方法落地的种种挑战。

1. 敏捷的规模化落地,本质是个多目标系统

敏捷的初心,即面向市场和商业模式变化如何提升业务响应力,为用户带来真正有价值、高质量的产品。在整个组织里落地敏捷是一个多目标系统工程,目标至少包含发布高质量、满足用户需求的产品,打造有创造力的文化,建立高响应力的团队等。这带来的第一个挑战就是“蓝图的设定”。没有人可以预先为这个多目标系统设定清晰而正确的蓝图。

最近几年在国际银行届比较知名的数字化转型成功案例非BBVA(西班牙对外银行Banco Bilbao Vizcaya Argentaria)莫属。作为一家拥有6520亿欧元资产的全球银行集团,2007年应对全球金融危机时,BBVA开启其创新旅程,对集团进行数字化革新。尽管拥有上层认可及远见蓝图,BBVA的数字化转型之旅也并非按部就班的沿着蓝图前行,其转型过程大致经历了三个阶段:IT内部创新、扩大团队与银行业务发展重点的创新、数字银行分支匹配敏捷项目管理。一路上尝试不同的结构和方法,通过实验不断调整,最终成为数字化转型的成功典范。

2. 敏捷的规模化落地,是追求活力而不是追求效率

正如前文所述,敏捷的规模化落地,其核心还是围绕敏捷的核心价值观和原则展开,只不过参与的产品更多、人员更多而已。它追求的不是单一目标 —— 规模化,而是价值、质量与其他约束条件的调和所带来的多方优化结果。

笔者曾经参与过一家大型外资银行的敏捷转型辅导,其高管层的目标就是在一年内针对其全球六七万人的IT团队实施敏捷转型,所有部门,包括PMO以及外部教练都要围绕这一目标展开。大部分时间花在了制定各种对团队进行评估的模型上,而团队级别的敏捷实践深入辅导不足,团队对于敏捷理解程度有限。一年之后,形式上虽然绝大部分都参与过敏捷培训,或者敏捷教练辅导,但是对于产品质量和价值的提升非常有限。当这种疾风扫落叶的培训活动结束后,能够保留下来真真正正实施敏捷的团队已经屈指可数,大部分又回到了过去的开发方式。

上面两点,决定了敏捷的规模化落地,如果采用“王安石变法式”的实施方式,必然会失败。

三、规模化敏捷框架与王安石变法

当前大量组织级的敏捷转型需求,催生出了如SAFe、LeSS这样的“规模化敏捷”框架。如果详细研究SAFe的实施过程可以看到,它有完整的白皮书、官网,市面上有各种培训和认证,特别是SAF4.5已经给出了4个经典配置以及10个步骤的实施路线图,看似为组织给出了一个“清晰而正确”的蓝图。

SAFe的蓝图和实施路线图看似很完美,但在落地过程中会遇到诸多挑战,一如一开始看起来很美的“王安石变法”。

1. 追求活力的多目标,实施时变形为单一目标

在实施SAFe的时候,容易想到在组织内部去寻找宋神宗这样的人,这并没有错。但是,根据组织心理学家William Schneider提出的组织文化理论:其中,95%的商业组织都属于控制型文化,这种组织文化强调的是上传下达,领导意志。

(文化四象限)

因此,如果在组织内部发起变革,很容易变成目标问题。也就是王安石遇到宋神宗之后面临的挑战。本来是一个追求活力的变革,最后实施时变成了效率型方式。

2. 因为制度成本,忘记真实意图,仅仅围绕效率指标

前面讲到王安石变法过程中的制度成本问题,在规模化敏捷实施时也普遍存在。无论组织是自我变革,还是请外部教练,很容易变成在领导意志下围绕一个“蓝图”按部就班地展开。而且为了考核规模化的进展,就会设立规模化的指标,比如组织内部百分之多少的团队纳入规模化敏捷运作框架等。再加上出发点就是错误的,失之毫厘谬以千里,离变革成功就越来越远。不难想象,跟王安石变法类似,在实施过程中为了追求规模化的效率指标,往往忽视内功修炼。

笔者刚经历的一个实际案例,某家全球性企业正在实施SAFe,总部请了一名资深的SAFe教练,飞到该公司各个地区负责实施和辅导。当我们作为一线敏捷教练后续进入对中国区团队实施辅导时,某个团队Scrum Master(SM)有一天问我,Sprint长度是不是必须两周?因为他们团队之前一直是三周一个Sprint。我当时很奇怪,问他为什么这么问?他回答说来自Global的教练说了,Sprint必须两周,要不然就不对。我当时听到觉得很震惊,竟然僵化到如此程度!作为一线的SM有此疑惑竟然得不到有说服力的答疑,那么执行过程中僵化就在所难免。

3. 忽视人才和生机型文化,一旦推进不力,一夜回到解放前

当变革推进不力时,反对派的反扑就来了,一夜回到解放前的实际案例不胜枚举。再加上大公司的组织结构重组(re-org)是经常的事,如果支持者不在其位,那么围绕其建立的变革实施人员的动力就会大打折扣。前面提到的大型外资银行的例子,之所以敏捷转型实施一年多以后就没有继续,其中一个很大的原因是全球的高管团队进行了更换,新上任的CXO们并没有认为敏捷转型有价值,所以放弃了之前转型带来的初步成果。更重要的是,在过去一年多的转型过程中,大部分精力并没有放到转型人才的持续培养上,所以当高管团队决定不再投资外部教练,内部的转型力量也没有跟上,变革也就不了了之。

所以,SAFe的蓝图和实施路线图看似很完美,但如同“王安石变法”,注定难以成功。

四、敏捷的规模化落地,如何破?

敏捷的规模化落地,本质是个Complex问题(Cynefin模型)。规模化敏捷框架的最大问题是将一个Complex领域的问题当成Complicated或者Simple领域问题来处理。一个多目标问题,其实是没有Good或Best practices的,唯一有指导意义的是一些价值观和基本原则。对待Complex领域问题,要采取探索-感知-响应模式,快速探索,感知问题的存在,采取行动响应,然后及时调整,对应问题的实践在这个过程中则会涌现出来,而不应该按照一个框架蓝图就开始配置实施。

比如前面提到的BBVA的案例:

  1. 远大愿景:基于对行业趋势的判断,BBVA清楚地认识到,客户的地位在提升,监管的要求趋严,新技术的涌现让银行业面临着前所未有的竞争。BBVA开始以增强与客户的关系作为愿景的转型之路,战略目标定位为成为“数字化时代最好的银行”。而且,基于此愿景制定了6大优先级战略引领集团转型,涵盖了客户体验新标准、驱动数字销售、新商业模式等。所以可见,他们要平衡的是一个多目标系统,既包含用户也包含技术与商业模式等。
  2. 快速行动:BBVA采用实验与学习的方法,将员工、高校研究机构、创新机构、BBVA创新中心、BBVA创业公司比赛、Innova黑客马拉松挑战赛、BBVABeta测试器、BBVA风投以及收购和合作伙伴融入整个创新生态圈,通过各种方式将最新成果快速应用于为客户创造价值,为企业创造收入。
  3. 及时调整:BBVA认为企业应先设立其创新计划并随时准备根据变化对其进行调整,而非盲目的执着于最初计划。比如BBVA的创新项目选择非常灵活,设立指导委员会并根据优先级选择项目,灵活的预算编制以及敏捷的实施,在实施过程中学习,及时调整并探索。

所以,变革成功的哲学是要有一个远大的愿景 —— Think Big;赶紧行动,摸着石头感知河水的深浅、流速,找到可以过河的方案 —— Start Small;根据实验结果,持续学习并改进 —— Learn Fast。

总结

当我们要在一家企业推动敏捷时,首先它是一个活力型变革,多目标问题,而且是一个Complex领域问题,这不是靠套用一种 “规模化敏捷” 框架就能解决的。不要忘记敏捷的初衷,切忌把规模化本身当成目标。当我们忘记“蓝图”,把握“Think BIg, Start Small, Learn Fast”这样的基本原则,更容易找到适合特定企业、组织的敏捷实施方式,比如肖然在《忘记“规模化敏捷”》里所说的“建立持续改进的内部力量、系统思考整个开发过程,以及为创新建立安全试错环境”等。


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

Share

敏捷变革过程中ETC面临的六个陷阱

敏捷从2001年被首次提出到现在已经历经了17个年头,作为一种新的思潮和软件开发方法早已跨越了鸿沟(如图1所示),并团结了大部分实用主义者,陆续掀起了不可逆的全行业敏捷精益转型。

如果你的公司或者组织正在进行或者已经经历了敏捷转型,那么作为组织变革者的你,一定在转型初期,组建了类似于“变革委员会”(或者“敏捷工作组”、“敏捷小组”、“变革小组”、“敏捷组委会”等)的团队。而在这个行业中应运而生的关键角色之一 —— 敏捷顾问/敏捷教练,入驻客户现场以后,提的第一个建议很有可能也是成立这样的团队。

图1 技术采纳生命周期 – 跨越鸿沟 Geoffrey A.Moore《公司进化论》2006

其实这种类型的团队有一个专业的名词 —— ETC,全称为Enterprise Transition Community(企业转型社区),是由 Mike Cohn首次提出,并在《SUCCEEDING WITH AGILE: SOFTWARE DEVELOPMENT USING SCRUM》中做了详细的介绍。

ETC的成员不超过12个,他们来自于参与Scrum转型的最高级别人员。

ETC的存在是为了营造一种文化、一个氛围 —— 那些对企业成功饱含热情的人尝试做出改变,而这些人的成功又会使更多的人产生更大的热情。ETC不是通过强行实施企业变革,而是通过指导实施变革的小组,为成功实施Scrum排除障碍,为变革创造活力与激情。

虽然ETC刚开始是Mike Cohn为Scrum设计的,但是在实际应用过程中早已不局限在Scrum转型了。同时,ETC也并不只是为企业级别所特有,也适用于更小的规模,比如说:一个BU,一个部门,或者一个产品团队(通常人数规模在100人以上或者人数少但是跨部门)。虽然每个咨询师或者每个组织有不同的称呼,但是几乎每个咨询师或者变革组织都会在转型前期成立这么一个团队,足见其重要性。为了统一语言,本文会使用ETC这个名称做进一步的深入分析。

先来说说我在咨询现场的做法。我一般会协同高层领导、组织变革者组建专门的改进跨职能团队,比如一个研发组织,包含业务、开发、测试、运维等部门负责人,成立ETC,选择改进的Product Owner和Scrum Master,人员控制在15人以内(有的组织非常大,波及人员范围较广,需要领导层酌情取舍)。

ETC按照Scrum方式运作,让变革者在战斗中学会战斗。团队有正式的启动仪式,迭代周期为一个月(或者两周,不建议更短,后续以一个月为例)。一个月一次改进计划会议,通过改进Workshop制定改进措施,并梳理优先级,责任到人,一周两次站会跟踪,每次半小时,针对改进项具体内容设置评审时间和形式,一个月一次回顾会议。

这是组织进行敏捷转型过程中一个非常重要的改进落地机制,是组织的改进引擎。令人欣喜的是,这几年下来,有很多客户,在咨询师撤场两三年后还能够继续按照当初的机制运作,“持续改进”已经植入了组织的DNA,始终有这么一支队伍持续不断地率领组织时刻反思勇往直前。

但是,更多的是运作不好的ETC。尤其是ETC运作初期变革者缺乏经验,非常容易陷入困境,接下来我们就深入了解一下ETC的六个陷阱和应对措施。

陷阱1:没有共同的目标,ETC名不副实

ETC的成员往往都是参与敏捷转型过程中的最高级别人员,是一个管理团队。而管理团队往往会有屁股思维;以研发场景为例,可能会有开发部门领导、测试部门领导,还有产品领导,项目经理等。

因为人员角色多,大家关注的内容就各有侧重,ETC的计划会、站会或者回顾会中如果偏向于部门或者项目,那么另外的人可能参与感就不是很强。更重要的是,分散的目标很有可能会造成互相推诿抱怨,效率低,改进不明显。

作为ETC的发起人或者变革者,第一个要解决的就是ETC成员目标不一致的问题,就像造船分配任务之前要唤起团队内心对广阔无限海洋的渴望一样,我们需要找到核心问题,让ETC成员意识到问题的严重性,树立紧迫感,渴望改变现状,然后引导大家共同制定改进目标。

这只是第一步,变革者需要不断的与ETC成员沟通问题和变革愿景,适当时候对目标升维或者降维,甚至通过求同存异的方式让大家达成共识。

陷阱2:知易行难,ETC成员没有以身作则导致转型也就是一阵风

有一次,开家长会的时候,幼儿园的老师让家长跟着做动作,老师一边把手放在眼睛上,一遍嘴里喊着“请把手放在下巴上”。很多家长不知所云,最后大部分家长都会比较纠结地把手从下巴转移到眼睛上,又有点犹豫,最终还是效仿老师把手放在了眼睛上。

这是一个很好的“知行合一”的小游戏,我们的孩子是这样,我们的团队也一样。他们并不会根据管理层说的调整自己的行为,而是根据管理层做的调整自己的行为。

变革过程中,有时候领导会觉得团队改进进展缓慢,很多情况下与领导的风格大有关系,“一句话需求”或者“说一套做一套”都是最直接的罪魁祸首。

举个简单的例子,如果作为部门经理或者项目经理的你,希望在研发团队运作中增加一个Story Kickoff的环节,就需要不愿其烦地与团队讲Kickoff怎么做,为什么要加这个环节,能解决我们什么问题,并且在实际运作过程中参与到具体的Kickoff活动并给予团队指导;当团队遇到问题的时候,帮助团队一起解决问题,并且鼓励团队。如果你只是吩咐了一句:“大家做吧”,然后就静待收割,99%的概率会失望。

再举个例子,敏捷理念中非常重要的一条是:管理者转身 —— 使用“使命式指挥”替代命令控制。一起参加培训的时候,你对“使命式指挥”赞不绝口,非常认同,并启发管理层全部要向“使命式指挥”看齐,但是培训过后的日常管理中,对管理层又是直接命令来控制去,这个时候,大多干部都会潜移默化地效仿并对他的团队也使用命令控制,而不是“使命式指挥”。

这个陷阱的应对措施最简单也最难:以身作则,知行合一,有的时候,有些根深蒂固的习惯非常难改,尤其是管理风格,但是要让团队知道你是意识到自己的问题并且在尝试改正的。

如果我们要改变,首先需要定义出我们期望的行为是什么,我们希望人与人之间有怎么样的行为方式,并教会员工这种方法。

陷阱3:事无巨细,ETC成员沦为微管理现行犯

如果原有领导班子是命令控制性风格,这几乎是ETC成员最容易犯的毛病之首,管理太细节,改进Backlog太细节。

三年前我就见过一个领导团队,7、8个部长就一个“测试场地到底有20平方还是40平方,能不能放下测试仪器”的事情吵了起来,而这样的领导者容易犯的第二个毛病就是:没有了解清楚就给方案。

关注的内容太过于细节,但是领导往往掌握不了所有的细节,这样的矛盾就会滋生出更多的矛盾,甚至造成给底层员工添乱的尴尬局面。

而ETC的一个重要职责是营造一种环境,在该环境中里,可以逐渐形成不 同的改进社区,这些改进社区在追求改善企业产品创建过程中,自发地形成和解散。

Mike Cohn《SUCCEEDING WITH AGILE: SOFTWARE DEVELOPMENT USING SCRUM》

ETC最大的目标是创造这么一个环境,让改进社区确认自己的目标,并自发地组织起来达成目标。

现在你是否发现,进入ETC其实并不意味着我们自己要做很多很多的任务,比ETC实际要完成的这些工作更重要的是,传递我们的转型愿景并激发别人的兴趣。

陷阱4:将信将疑,ETC成员期待他山之石可以攻玉

例如,作为事业群的最高领导者及ETC的PO,其实对整个转型过程呈观望状态,由于其他事业群的压力所迫,不得不跟风;虽然敏捷运作开始了,但是更多是谨慎前行,你希望团队要告诉你敏捷到底行不行。

这种场景,几乎都有一个同样的结局:失败。

经历过这种转型的咨询师或者变革者都会深有感触不堪回首。我在咨询现场,对领导层提的第一个要求就是:乐观并且坚定。管理层的乐观和坚定非常重要,强调多少遍都不为过。

因为,如果管理层将信将疑,团队会从各种互动中感觉到管理层的质疑,继而团队就会质疑,觉得转型没用,然后又会反过来影响管理层对转型的信心并加剧管理层的质疑,循环往复。最终以失败告终。

这里必须要提一下“文化变革的新旧途径”,约翰·舒克是丰田城的首位美籍员工,在经历了NUMMI公司的成功精益转型之后,他对沙因的文化变革模型进行了修改,他认为:

要改变文化,首先要去改变的不是人们的思考方式,而是行动方式,即他们怎么做事。

2015年,在沙因和约翰的模型基础上,为了让变革者能够更容易操作,我提出了如下观点: 对于管理层,我们要通过改变他们的思想改变他们的行为; 对于基层员工,我们要通过改变他们的行为来改变他们的思想。

随后的几年咨询生涯中,又经历了许多案例,何尝不明白“二分法”是最危险的思想,不管对于哪个群体,让其发生改变其实都需要思想和行为的相互佐证。但是,在大多数情况下,这样看似粗暴的划分其实并无大碍。尤其对于管理者而言,思维改变是前期最重要的一环,从古至今的无数变革案例几乎都昭示了一个不争的事实:领导者没有下定决心痛定思痛,变革的路就走不长远。

图2 文化变革的新旧途径

陷阱5:缺乏与基层团队的多渠道连接,ETC更像空中楼阁难以为继

就像陷阱3中提到的,ETC成员靠自己只能完成一点任务,取得一点成果,他们更需要依靠组织中的其他人完成实践落地而走向敏捷所需要的大部分工作。因此ETC如何发动群众,辐射群众,与更广大的团队形成一对多的继承和相互促进的关系就显得尤为重要。

改进社区、各角色技能CoP(Community of Practice,实践社区)都是不错的选择。切忌管理层在ETC各种指点江山发号指令,而忘记了团队疾苦,很多改进措施难以落地,团队叫苦连天,时间长了,不仅仅是变革像空中楼阁难以为继,更有甚者倒退回比之前都不如的境地。

场景一:某企业某事业部正在进行从上至下的敏捷转型,作为部门A的基层员工,根本不知道为什么要转型,每天的事情已经够多了,为什么还要多出这么多敏捷转型的讨论和会议?

场景二:经由一些天的头脑风暴和深思熟虑,在大领导的带领下,大家终于下定决心要对现状的短瀑布流程进行彻底变革,用敏捷核心实践来改善目前的产品质量。大家成立了ETC,并建立了改进Backlog,开始跟踪各种事项。作为中层管理干部,你很幸运参与了整个过程。不过你的团队经常对你飚出的一些新词以及那片花花绿绿的改进墙充满了疑惑和好奇,最开始你还解释一下,慢慢的时间长了,你也懒得一遍遍解释,他们也就熟视无睹了。

不管是Mike Cohn提到的ADAPT模型(如图3所示)还是Kotter教授在《 LEADING CHANGE》中提到的变革八部曲(如图4所示),都着重强调了一个“真理”:

每一个成功实施变革的组织都是在多个层次上进行这些活动

这个问题是:大部分变革项目都是由许多小项目组成的,这些小项目同样也需要经过从紧迫感到融入文化这8个步骤(如图4所示),缺一不可。而这是很多变革者最容易忽视的问题之一,他们往往蓄了足够的势,在最高层级用各种手段打开了突破口,找到了同盟军,让关键者动起来了,然而忘记了在下一个层级持续蓄势,或者忘记了教会他们的ETC用同样的方法鼓动底层员工跟着动起来,这也是敏捷转型非常容易失败的一个最关键的因素。

而另一问题是:整个变革项目行至中途,一些小项目完成了,而有的小项目才刚刚开始。不同项目不同团队的状况不一样,需要我们分别对待。

针对这两个问题核心应对措施就是:变革者要不断识别团队或项目处在变革过程中的哪个步骤,在多个层次和层级上反复进行变革措施,并培养更多的变革者,在不同的范围内和层次间不厌其烦地重复变革步骤。

图3 ADAPT模型 Mike Coh

图4 John Kotter’s Change Model-8 Steps 来源:staff.napier.ac.uk

陷阱6:忽视推广和传递,最终臣服于企业重力

最近几年,越来越多的企业管理者终于明白,敏捷转型是在不同的层级上进行的,敏捷变革所取得的成效也与其所能够影响的范围有直接的关联。就像上述陷阱5所讲,如果在IT组织内部不能够持续影响并顾及到多层级效应,就很难做出大的改变取得可观的效果,转型很有可能半路夭折。如果前五个陷阱完美应对过来了,基本可以说转型成功了一半。

为什么是成功了一半呢?其实对于进行敏捷转型的企业组织,只要踏过前五个陷阱,都能够取得不错的成绩,但是还差最后一关,那就是突破IT,向组织内更大范围推广和传播。

“企业重力”是一个很有意思的说法,不同的书籍均有提到相似的概念。这也是沙因对企业文化的解读:

文化 —— 是一个群体在解决外部适应和内容整合的问题时所学到的一套被普遍认可和不言而喻的假设。这些假设在过去运作得足够好,被视为有效的,因而被作为理解、思考和感知这类问题的正确方式传授给这个群体的新成员。 —沙因 《企业文化生存指南》

曾经让这个群体成功的那些思考、感受和看待这个世界的方式就是企业重力,因此敏捷转型的影响必须推得足够远足够广,才不至于使整个转型因为“企业重力”而被拉回到原点。

最经典的例子就是IT部门内部的敏捷转型,如果不连同业务部门,甚至HR、财务、物业等部门,用不了一两年,就会发现改进乏力,这也是《精益企业》中所提倡的,我们要在更大的组织和范围内进行彻底全方位的精益转型,才能让我们在不确定的市场环境中更具有适应性。

也有很多敏捷顾问/敏捷教练或者企业转型者认为只要ETC旗帜一树,正常运作起来,就成功了大半,殊不知这才是刚刚开始,组织转型本身就是九死一生的博弈,Kotter教授也在《LEADING CHANGE》中一开篇就介绍了导致组织转型失败的8种常见错误。

而本文用敏捷转型过程中的ETC作为引子帮大家鉴别领导班子的风格会严重影响组织转型的进展,希望正在做组织转型的你能够在面对ETC团队的各种问题见招拆招。


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

Share

企业敏捷在于打破常规

摘要

于软件开发领域而言,敏捷已经被广泛认可为一个行之有效的应对快速交付和不确定性的指导方法,并有一系列相对成熟的模型和框架。而企业更为需要的企业敏捷和业务敏捷则仍在探索阶段。敏捷吸引软件开发工作者的原因,是它打破传统开发常规,用不同的思维找到更好的方法,取得更好的结果。同样的,如果要业务敏捷,就要探寻业务部门所需要突破的常规。本文将与诸君分享三类业务部门突破常规的故事。


在这个技术突飞猛进、环境瞬息万变的时代,能够快速响应变化并做出适当的调整,是关系到企业生死的基本能力。企业(enterprise)需要敏捷,业务(business)必须敏捷。但很不幸的是,现行的商业和管理理论和实践普遍相对落后,连彼得·德鲁克都曾感叹:“我们称之为管理的东西反而使人们做事更困难”,更不用说支持快速响应变化。请问各位,您所在组织的管理和运作模式是否支持快速实现客户需求,是否支持快速响应变化?有哪些规则妨碍你们的工作?要迈向更好的运作模式,首先必须打破那些不必要的常规。

探寻更有效的运作模式并非容易的事。幸运的是,软件群体已迎来新希望。交付周期缩短的压力下,软件团队已经成功的实践新的工作方式,我们将之统称为“敏捷软件开发”。敏捷团队能够高效有效地协作,产出客户满意的软件产品。敏捷团队惊人的效率和激情,对业务工作者是一种鼓舞。组织领导希望业务人员有同样的敏捷能力和效果。

但是,业务敏捷(business agility)并没有明确的定义。敏捷联盟(Agile Alliance)将业务敏捷定义为“业务能感知内部、外部的变化,并及时回应以便于为客户提供价值。业务敏捷不是一种具体方法,甚至不是一个整体框架,它是形容一个组织怎样在成长思维下运作,而这种思维很类似于敏捷软件开发群体形容的敏捷思维。”敏捷联盟进一步表示,没有固定的敏捷实践、角色、或者周期。因此,业务敏捷的组成可说是还处于探索阶段。因此,业务敏捷是什么,它的目标是什么,它的广度和深度是什么,还需要每一个组织自己去定义。目前,没有任何参考的模型,各组织需要自行探索,自己检验。

在敏捷软件开发方法体系,业界有不少通用的模型,比如Scrum、XP等,来指导敏捷开发的实施。以上模型以软件团队作为出发点。业务敏捷的出发点呢?它从哪里开始?业务部门的领域不同,需要的敏捷模式则不同。比方说:销售部门的敏捷可能就跟财务部的敏捷完全不同,采购部的敏捷和人力资源部的敏捷也应该不同。同样的,敏捷对于高层管理者和业务部门领导来说也有不同的意义和侧重点。

我们或许可以考虑让这些业务部门尝试成熟的Scrum框架,让这些部门有迭代运作的概念。这或许有用,但我觉得不能解决业务的根本问题。原因很简单,业务部门都有他们惯用的例行工作分配和跟踪机制。在这些例行会议当中,他们会讨论与跟踪问题,并商定改进措施。所以,如果跟业务人员只是谈论“一般”的敏捷迭代做法,持续改进,他们就可能会感觉“我们都知道,已经在做了,没什么新鲜的”。

敏捷吸引软件开发工作者的原因,是它打破传统开发常规,用不同的思维找到更好的方法,取得更好的结果。敏捷宣言中的四个价值观:

个体和互动 高于 流程和工具

工作的软件 高于 详尽的文档

客户合作 高于 合同谈判

响应变化 高于 遵循计划

右边就是常规,左边就是崭新的思维模式。同样的,如果要业务敏捷,就要探寻业务部门所需要突破的常规。

敏捷宣言也提出“我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观。”同样的,我将分享我的一些个人在业务敏捷经验和体会,供大家讨论,我把这些经历分为三类:

  1. 业务与IT的敏捷(Business and IT Agility)
  2. 客户参与的敏捷(Customer Engagement Agility)
  3. 业务自身的敏捷(Business Agility in Itself)

这三类经历都在说明,业务人员如何跳出他们存在的心态和思维,找到突破。

业务与IT的敏捷

谈到业务敏捷,很自然的就谈到业务部门和IT部门的合作。下面的场景相信大家都不陌生:业务和IT双方并不和谐,各自维护自己的利益,互相对抗。业务压需求,IT抵抗需求。其实,从企业整体目标的角度考虑,他们应该是相互合作的合作伙伴关系,没有高下之分。

这是很多企业里常见的做法:业务方希望以最低价格完成目标,所以跟许多供应商合作,让他们之间互相竞争价格。这些供应商,有些做开发,有些做所谓的“独立测试”,他们互相竞争报价。在极端情况下,一个业务部门有十几个供应商,分别负责开发、测试、用户体验等等不同的工作。在这种讨价还价,随时停止供应商服务的情况下,供应商怎么可能有热情和忠诚?有些业务部门不仅仅对供应商这样,甚至对公司内部IT的同事也一样。IT服务质量难免受损。

业务与IT的敏捷协作基础是互相尊重,互惠互利。我分享两段个人经历:

第一个经历是我2014年的一个大型敏捷转型项目,包括供应商大概有好几千员工,该业务在一年后扩张至约万人。当时我们提供IT组织敏捷转型方案,并且辅导团队落地实施。正好我辅导的某个团队,业务代表和IT代表水火不容,一开口就吵,几乎不说话,关系很尴尬。业务代表希望将70个左右的需求都要现实,但是IT方面抱怨说需求不明确,做不到。IT代表问我,到底他们哪一方合理,这让我左右为难,倾向哪一方都有损失。这时,我便问业务代表是否真的希望每一个想法(Idea)都实现,以及每一个想法当前的进展情况。如我所料,那些想法的进度并不相同,有些想法就是想法,业务代表只是想与IT代表共同讨论。说到这里,IT代表才平下心情。我们便建立一个想法看板(Idea Kanban),附有清晰的标准定义和具体的排序规则。这形成业务方和IT双方的合作基础。这个运作方式受组织的认可,并且变成了其他业务团队的参考模型。

第二个经历更是难以忘记。业务代表想创造一个B2B电子商务平台,向欧洲和香港市场发展,有大量的业务需求。IT方面正手忙脚乱地实施落地,工作量特别大,不少加班情况。为了满足业务需求,IT部门有并行的版本开发。这意味着业务方必须参与验收测试(UAT),而同时也需要投入准备德国和香港的演示和销售工作,所以工作量也很繁重。总而言之,业务和IT双方都被压得喘不过气。其实,对我来说,解决办法很明显:就是要聚焦,不要把精力分散。为了让香港客户演示的成功,应该把大部分精力集中在这里,不必要并行版本开发,反而应该舍弃一些已经计划发布的工作。我参加他们业务和IT的协作会议,并指出我的想法。业务方很果断的舍弃一个版本,并同意专注于演示的准备。取消一个并行版本之后,业务和IT突然感觉轻松多了,特别开心。为了纪念这次的决定,业务代表还提议在敏捷宣言前合影留念!

客户参与的敏捷

说到客户参与,我想把本文的重点放在线上和线下的“人为渠道”(human channel)方面。在目前提倡数字化背景下,组织提倡自动化和智能化,希望通过技术手段,更好的为客户服务。客户通过这些自动化智能化的渠道办理业务,不需要业务人员的参与,减少业务人员和客户通过移动或其他方式进行沟通。虽然,这将让客户更方便,但是在某种情况下,会失去跟客户人与人之间的接触机会。数字化和业务敏捷存在的意义就是让业务给客户更人性化的服务,如果要人性化,怎么能够完全没有人为的参与呢?所以,在本文当中,我分享两个相关经历。

在某家金融科技公司,客服人员每人每天有350次通话指标。其实,通话次数和通话质量是两回事。我便问他们是否有建立一些有意义的关系,解决他们的问题。这些一线客服人员便滔滔不绝的讲述他们与客户接触的感人故事:一名客户问客服夜间上哪里买药,另一名客户询问哪里能找到托儿服务、等等。很明显,这些都是超出客服的工作范围。在他们分享经验时,我能感觉到他们的热情,他们助人为快乐之本的心态。我相信他们的客户也会特别感激。在这分享中,客服人员理解他们的意义不是为了达到冷冰冰的通话次数目标,而是有同理心的帮助客户。客服人员不是接电话或拨电话的机器,他们是一群具有影响力的大使,帮助组织建立人脉,建立口碑。当业务意识到这一点,就会有更强大、更有创新力的服务。如果你想要客服更人性化,你必须关注他们,鼓励他们呈现人性化的一面。这是敏捷的基础——以客户为中心,以人为本。

这个故事是我在某家银行的经历。作为一个每月领取人民币薪资的新加坡人,还要把工资汇到新加坡,这手续其实很麻烦。在银行风险政策的要求下,每次境外汇款都要亲自跑支行两趟去办理手续,对我这样一个差旅频繁的人来说,这是个很大的问题。不过与支行经理商量之后,商定一个稍微简单的办法,将两次亲自现场办理手续减为一次。支行的王经理不仅满足我作为客户时间上的要求,在自己的工作上取得成就,更交了新朋友。这是个体现出一线人员寻找流程创新和突破的很好例子。

一线员工不是推销产品、提供信息的渠道。他们是真正能够与客户立建关系的大使,所以他们应该赋予更多权利。但是,不少企业往往对他们就像对待机器一般,完全没有决策权,完全百分百的遵循过时和不完备的流程制度。以上两个案例体现了一线的突破。这就是所需要的业务敏捷。

业务自身的敏捷

业务敏捷的第三方面是业务自身的质量和管理方式。这跟客户、合作伙伴和IT没直接关系。这是业务自身的核心,通常与领导层有关。业务的决策和经营体现了领导者的意愿。领导做事的方式对业务敏捷有很大的影响,通常表现在细节上。

我在知识共享领域有一段有趣的经历。客户所在的业务有不同产品线,规模很大。领导层希望不同产品线分享知识,让员工互相学习,找到更好的解决方案。但是,业务的安全部门有责任保护机密。因此,两个部门产生了冲突——知识管理部希望分享,安全部门需要维护保密性。讨论之后,最终没有将知识分享的项目交给知识管理部,而交给安全部门负责,这样他们就需要改变保密政策。这显然了创造共同视野的好方法。

在另一个组织中,不同额度的采购需要不同的级别的审批权限,这在某种程度上是有道理的,但却给带来巨大的问题。一个项目当中所需采购工作,就需要获得不同级别的批准。较小的采购交给较低管理层的批准,而较大的采购则交给更高管理层的批准。结果,经理们看到的是完全不同的采购,而不是一个项目的所有主要采购。经过一次改善活动之后,让每个项目都由一个单独的人来批准重大的采购,而采购业务的合作使他可以批准指定项目相关的所有其他采购。这大大简化了审批过程,将审批周期从最多21天缩短到最多3天。

最后一个例子是一家有很多个不同子公司的业务,每一个子公司经营的业务都不同,成熟度也不同。于是,我们合作设计了一个共同的绩效框架,用于管理不同子公司。这个框架基于麦肯锡的三维度、基于业务驱动变量,它们适用于B2B、B2C和混合商业模型。过去,他们集中于金融指标,经过共同的努力,他们得到了更好的领先指标,能够追踪客户和商业伙伴的成长。为总公司和子公司之间提高了急需的可见性,优于以往不透明的方式。

敏捷即打破常规

如果你已经尝试过敏捷,你可能会在开始的几星期或者几个月内感到很新颖。但是,如果在这期间没有任何突破,没有任何思维的创新,没有打破常规,团队就很容易回到老样子。团队们可能说他们有Scrum活动,有一系列的“敏捷”仪式,但是,我的经验告诉我,如果只有表面上行动,没有根本上的改变,这是很难持续的。若要真正的敏捷,就必须更上一层楼,就必须有思维的突破和创新。敏捷软件开发如此,业务敏捷也如此。

各位业务敏捷实施者,你们有哪些最关键限制因素?这些因素背后的原则和政策是什么?你可以做出哪些改变?你可以克服这个限制吗?要付出什么代价?如果你袖手旁观,后果会怎样? 我们追求的是管理层面的突破。这些突破,往往就是一个简单的决定,就向打开一扇门那么简单。但是打开门后,海阔天空。

今天,你有没有尝试打破常规?欢迎分享。


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

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

亲历者说:敏捷?我被洗脑了吗?

几年之前我还是个野生程序员的时候,对“敏捷”这个词是有些抗拒的。那时候,要么是没有想法、懒得去理会,要么就是主观上拒绝:

肯定又是些无所事事的人弄出来的无聊概念,帮他们自己刷存在感的东西!

敏捷,就是那些咨询公司弄出来给别人洗脑的嘛,那些理念太空,根本无法落地!

那些一大堆概念都是些什么鬼?条条框框太多了,运作起来太麻烦了!

不用敏捷,我们现在不也挺好的吗?敏捷跟我有什么关系?

但后来我却选择加入了 ThoughtWorks,这个传说中的敏捷大本营,一方面因为很多出名的书都是 ThoughtWorks 的人出的,另一方面也想亲入虎穴一探究竟。而如今,历经敏捷项目的洗礼,我已经成为专职的一线咨询师,为众多大型企业提供敏捷转型过程中的技术指导。

他们

在一些朋友看来,我自从换了工作,就开始在群里转发一些敏捷相关的文章,发表一些感言。在转发这些内容的时候,我经常用到的叙事口吻是“他们”。

他们的代码真的写了好多测试。

有时候要开一整天的会,我真不知道他们是怎么撑下来的!

感觉跟着他们一起做测试驱动开发好像没那么难。

这段时间里,我让自己成为一个“警惕的观察者”。不管是主观上的警觉,还是故意在外人面前将自己打造成这样的一个形象。深怕在我还没有觉察到的时候就已经被敏捷洗脑了;同时也希望在曾经的好友面前以尽量理性、中立和客观(理中客)的形象示人:不过,这不妨碍在他们看来,我已经被洗脑了。

后来我了解到,这如同学习新知识过程“守破离”中“守”的阶段。“守”的过程既是获取新认知的过程,也是与过去的认知做比较和更新的过程。观察现象——对比质疑——私下学习——拨开疑云,大体就是这样的不段重复,在不断了解新实践的过程中,也同步去认识它、理解它。

渐渐地,一系列疑问得以解答,使得最终我接纳了敏捷开发思想,并认为它是适用于现代开发团队中的工作方法。

疑问

在过去我呆过的团队中,一直有两个无法解答的问题。那时作为技术经理,我经常被别人问到的问题,也是我自己无法用经验回答的问题。

  • 做完这个功能,你估计需要多少时间?
  • 为什么大家在办公室显得很安静、气氛有点压抑?

在成功学的洗脑课程中,有一句被强调最多的话:“失败一定有原因,而成功一定有方法!”那么,我们过去回答不了的上面这些问题,以及由它们导致的管理上的难题,其根本原因又是什么呢?获得管理上成功的方法又是什么呢?我带着这两个问题离开了之前深度参与的创业项目。与朋友分享了要探索新征程的想法之后,他真诚地邀请我加入他的创意,并希望由我来带领团队一起续写新的故事。我猛然间发现,其实虽然之前在团队里担任所谓技术经理的职位,但我真正给团队带来的帮助似乎更多的只是一个有经验的工程师给新手的指导。那时候,第三个疑问产生了:

  • 如何去做好一个团队带头人?应该安排团队成员每天做什么?

这些疑问不得到解答,我就如同掉下井底的青蛙,虽然能听见外面世界的声音,却只能看到井口大小的世界。

答疑

加入新团队后不久,这些疑问就完全得到了解答。第一个要实现的需求就是一个“明星”功能,集成第三方系统的调查问卷。团队很快组织了需求计划会议,并细致地过了一遍第一期要完成的目标,实现这个目标要包含的业务范围,而具体又包含哪些步骤(用户故事)。

  • 目标:发出问卷链接,并将数据收回来。
  • 范围:选取模板、发送链接、收回数据、发送提醒邮件
  • 步骤:
    1.  管理员在外部系统中创建好模板(不需要开发)
    
    1. 用户可在 XX 页面中使用选项来选择问卷模板(系统自动将外部系统中的模板名字同步到本地系统)
    2. 用户可在 YY 页面中使用链接发送调查表单,客户收到包含链接的邮件
    3. 系统自动将外部系统中收到的数据同步到本地系统中以供使用
    4. 如果没收到提交数据,系统自动在7天后自动发出提醒邮件,客户再收到一封包含链接的邮件

接着开发人员和测试人员对还不够详尽的细节提出问题,讨论获得一致,一起对各个步骤大致估计所需时间。每个用户故事并不确定由谁来做,而是大家一起就其中的细节进行讨论,并就所需时间形成一致:有的人说需要 3 天,有的人觉得 2 天就够了。他们会叙述自己的想法,并最终达成共识。

这项活动,以及之后的迭代过程中,基于这个会议的开发过程解答了我第一个疑问。

他们有一个角色叫 BA,会写一个个的用户故事来描述需求,一两天就可以完成一个故事。明确的前提条件和验收标准(从哪里开始做,做到哪里为止),让开发工作变得有节奏感,需求不清楚的时候随时就这个需求的范围进行讨论。

相比于拿别的产品做个演示,甩一句“就照这个做”,然后就天天催进度、做出来之后又说不对劲的产品经理,有一个专门负责业务、随时可以叫过来讨论的 BA 让开发人员感到倍感轻松。

江湖上传言说敏捷不需要文档,原来是谬误。敏捷并没有说不需要文档,只是说认为团队成员之间的沟通协作比详尽的文档更重要。所以,用户故事仍然是会包含必要的描述内容的。要写清楚为什么要做这项功能,以及验收标准等。

团队一起估计时间的过程,不光可以消除特定人估计时的无助感,更重要的是它让所有人都了解用户故事的细节,在后续开发中谁都可以参与开发。

相对较小的用户故事,估计起来要比一整个功能(比如对整个调查问卷功能进行估计)估计起来靠谱得多。即使有特定的用户故事估计不准确,其影响范围也是可控的。

把所有故事的估计时间相加,即为整个功能所需要花费的时间。

估计只是帮助做计划的一种方法,在后续开发过程中,如果发现比当初估计的要复杂,或者简单,需要与 BA、PM 等角色一起更新这个估计值,从而帮助团队及时完善一开始制定的迭代计划(如果必要,可以加入一些,或者减去一些,或者修改一些)。

这样,我发现开发团队的时间原来是需要管理的,而管理时间这件事其实也需要花些心思才能做好。这时候,如果你问我某项功能需要多久做好?我会告诉你,让我来拆分一下功能,粗略估计就成为了可能。

而后面的其他疑问也很快得到了解答。关于团队气氛,如果一个团队里每个成员都在闷头做自己的工作,独自面对自己的交付压力和技术挑战,成员之间互相帮不上忙,他们的气氛一定不会太好。而如果所有人通力配合工作在相同的功能上,一起理解消化业务,一起解决技术问题,共同做技术决策,并分担解决缺陷(BUG)的责任和压力,那么团队的气氛怎么会不好呢?

最后一个问题,关于团队。

团队里大家的角色是如何分配的,规模又应该多大?团队之间应该如何配合?这就不难回答了。典型的业务功能团队,以及后来出现的微服务团队,都很好的诠释了团队结构和规模问题。有一个论述产品设计和组织结构关系的康威定律,值得我们深入思考。团队带头人?我突然反应过来,一定要有这个角色么?如果大家都能很好地运作了,那其实这个所谓带头人的作用是很淡化的,这也就是所谓的自组织团队了。如果一定要一个带头人,那他的职责一定是确保这样一种自组织的机制在团队中持续地运作下去。

所以,我被洗脑了吗?

也许你可以这样认为。

作者我现在是接受了敏捷思想的,其中还有一些工具和方法,我还在持续学习过程中。不过,“洗脑”这个词本身其实具有一定的预设立场,它是那些质疑者的说法。

那么,重新回到问题本身。敏捷是什么呢?它会将人们洗脑吗?

敏捷不是什么宗教,它只是一种生产软件的思路,一种倡议。它倡议,通过加强团队成员间的交流协作,尽快交付高质量、有价值的软件,让团队以良好的响应性来拥抱软件的变化。为了符合这种思路,它一般又会有一些典型的实践方式。我们可以说哪些实践是由敏捷方法所推荐的,因此是“敏捷的”;而哪些实践是不推荐的,因此是“不够敏捷的”。但不会说哪种是好的,哪种是不好的。

比如,敏捷的:

  • 自主提交代码,尽早集成
  • 自动化一切,包括环境初始化
  • 代码由团队共享,随时重构和优化

不敏捷的:

  • 逐次代码提交都需要他人审查并批准的管控
  • 手动部署生产环境
  • 不让他人修改自己编写的代码

但这些“不敏捷”的条目,基于团队具体情况,可能实际操作起来更可行,就可以根据目前的阶段去施行,并向着更敏捷的方向去持续改进。类似地还有,敏捷不会说团队一定要开站会,站会一定要在早上开等等……相反,如果要求团队一定要做某件事,其实它与敏捷思想是背道而弛的。我们应该遵循敏捷理念去对实践进行改良,以适应团队实际情况。

事实上,“敏捷”一词来源于英语 Agile,这一英文词汇也类似于中文中的形容词“敏捷”一词,其适应性相当广泛。人们往往用它来形容业务的灵活性,思路的开放性等。因此对于敏捷来说,并不存在什么洗脑不洗脑的说法。它只是一种风格,一种态度。只要你运用这种思路和风格去让团队协作越来越好,开发出来的软件的质量越来越好,那就是敏捷的。敏捷中典型的具体实践方法有 Scrum)、XP 和 Lean 等。此外,近年被广为谈论的 DevOps,也已经成为了敏捷软件方法的典型实践。


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

Share