能在1个小时内快速做出决定的项目,58%都获得了成功。如果花超过5个小时来做决定,成功率就几乎为零。决策拖延越久,代价就越高。Scrum的关键经验是,让最接近工作的人来做决定,速战速决。

你突然遇到一个问题——你刚刚发现了它。

它可以是任何情况。比如,你在建造东西时,意识到设计需要调整;或在计划工作时,遇到未曾预料到的情况,需要你立即做出反应。我应该马上做那件紧急的事情,还是把紧急的事情放一放,去做那些非常重要的、以后会非常有价值的事情?

这就像德怀特·艾森豪威尔著名的决策象限,根据重要性和紧迫性对事情进行排序:

假设你被困住了,你必须决定新遇到的棘手问题属于哪个象限。你需要与谁核实?要等委员会开会吗?是不是每个人的日程表都排得满满的,今天,或者明天,甚至后天,都没办法做出决定?如此延误的代价是什么?

决策延迟

斯坦迪什集团的创始人兼董事长吉姆·约翰逊几年前就开始对决策延迟问题产生兴趣。斯坦迪什集团通过访谈、分组座谈会和问卷调查等方式,对项目如何在全球运行进行初步研究。他们从1985年就开始在这么做,研究了数以万计的项目。他们定期发布问题报告,其中包含说明项目成功或失败原因的各种各样令人着迷的数据。全球采用Scrum的项目成功率如下图所示:

比较而言,敏捷项目的平均成功率为42%,而传统项目的平均成功率诶26%。

Scrum是大多数敏捷项目的实现方式。与传统项目相比,敏捷项目失败的可能性不到一半,但成功概率要高得多。这是切切实实、有据可查的数字。

但是我们要清楚:并不是每个敏捷项目都有很好的结果。吉姆和Scrum公司的同事一直在研究为什么有50%的敏捷项目仍然面临挑战、延迟、预算超支或让客户不满意等问题。

项目失败的根本原因是什么?是什么使Scrum项目比传统项目更有可能成功?几年前,吉姆在采访马萨诸塞州采购处处长时,突然想到了这个问题。

“处长给我讲了自己亲历的事情,”吉姆说,“那位处长以前在波士顿市政厅工作过。他谈到一种情况,当时有个项目,他们必须得到副市长的批准,才能推进这一项目。他们有60个承包商在等待副市长的批示,60个人在6个星期内都无法行动,做一个决定需要花6周时间。”

吉姆很是惊愕,认为这一定是一种反常现象。所以他开始给自己的研究加上一个问题:“你做决定的速度有多快?”对许多有问题的项目进行深入研究之后,吉姆意识到决策延迟并不是反常现象,而是普遍现象。在失败的项目中,人们总是当断不断。吉姆发现,真正不可思议的是,所涉及的决定多数时候并不特别复杂,也不特别困难,通常都是司空见惯的日常决策,但决定愣是做不出来。

自从就决策速度问题开始提问之后,吉姆一次又一次地碰到当断不断的问题,于是他便开始进行基准测试——实际测量人们在知道必须做出决定的情况下,需要多长时间才能做出决定。因为在任何项目中,都要做很多决定。

“结果如何呢?”吉姆说,“数据显示,对于一个项目而言,平均每花费1000美元,就要做一个决定。对于一个百万美元的项目,需要做出上千个决定。”决定拖延越久,代价就越高,成本呈现快速累加的趋势。这要归因于爱因斯坦广义相对论的奇妙推论:时间不仅和空间是同一回事,和金钱也是同一回事。因此,吉姆提出一个衡量标准,用来衡量从明确需要做出决定到做出决定需要多长时间,他称之为“决策延迟”标准,然后将其与项目成功的可能性进行比较。他研究了全球数百个项目,得出了什么结果?情况比你想象的还要糟。

2013-2017斯坦迪什集团

图表显示了数百个项目的最终结果。对于可以在1个小时内快速做出决定的项目,58%都获得了成功(按预算准时完成)。如果花超过5个小时来做决定,成功的概率就会直线下降:只有18%的项目能成功。5个小时不是很长的时间。

因为结论触目惊心,吉姆花了一年的时间才决定发表研究成果。慎重起见,在成果出版之前,他还到商学院和研讨会上做了演讲。

“听众的反应特别有趣,”吉姆回忆道,“一开始他们说,‘这不可能是真的。这不可能是根本原因。’然后他们考虑再三,改变了看法,对我说,‘你可能真正参透了其中的奥秘。’”

最关键的问题是:大部分决定都是简单琐碎的。但如果企业行事死板,等级森严,决策必须沿着审批链层层上报,然后再层层下发,那么决策过程就会耗时良久。

我们与一家大型全球汽车公司有过合作,他们使用的是一种通用的日式审批制度,叫作“禀议”(ringi[1])。其目的是就应该做出什么决定在管理层中达成共识。有人拿出提议后,该提议就会在决策链中的每个人中间流通;等每个人都同意,最后经过高层领导签字同意,决定就做出了。禀议制的理念是,你必须在幕后默默工作,以建立共识,为一项提案创造肥沃的土壤。日本人把这个叫作“根回し”(nemawashi[2]),字面的意思是“修根”,即准备移植树木时,围绕树根开挖。

让我讲一个故事,来说明禀议制这种运作方式如何令人沮丧。假设你在美国的一家汽车工厂工作,想花钱买点东西,比如为工厂添置一台新设备。尽管在年度预算中已经为新设备拨过款,但你还得提交一份书面“禀议”,也就是必须写一份详细的、有说服力的商业案例来说明为什么要花这笔钱,还必须包括所有的会计数据:要花多少钱,钱从哪里来,流向谁。再说一遍,同样要提交书面文件,然后还要提交环境评估报告,明确这台机器将使用多少电,可能会产生什么排放影响。所有这些都要写在纸上,这叠纸就是“禀议”。

然后,“禀议”必须得到批准。首先报送规划中心,一个工程师告诉我:“规划中心必须对‘禀议’进行审查,核实一大堆我们不明所以的东西。”审查后,规划中心要么将其打回,要求修改,要么予以批准。

一旦核准,就必须走签字程序,别忘了,整个流程都是以书面形式进行的。首先,需要由申请者的经理签署,然后由高级经理签署,然后是集团经理、总经理,可能副总裁也要签署。然后经理、高级经理、集团经理、总经理再度签字确认,分管规划中心副总裁也必须签字。由于是在制造厂工作,可能还得让负责安全生产的总经理签字。

就这还不算完。下一步,所有签过名的文件必须走财务流程,通过同样的审批链。如果新设备涉及信息技术部,信息系统总经理和分管副总裁的办公桌上也必须出现这些文件。如果决策足够重大,全套“禀议”文件可能还要呈送集团总部,再次经过层层审批。

与我交谈的那位工程师只是要做一个小的项目,花费在四五十万美元,却需要35位负责人用钢笔在同一张纸上弄出35个签字(这还不算极端,有时一份文件需要50人签名)。这需要4~5个月的时间,甚至可能需要更长的时间——长得多的时间。没办法,他们现在所做的是创建一种“禀议”前的“禀议”,以便提前得到一些钱,来启动汽车开发(请注意,这笔钱已经被列入预算)。

他们组建了一个团队,其任务是使整个过程实现最低限度的自动化。自然,他们使用的是Scrum。他们的目标是什么?摆脱繁文缛节。在无数的反馈回路中流转文件,可以说是非常缓慢的。他们还将使规划中心所做的一些检查实现自动化。

这将带来两个好处。第一,自动化将使过程清晰可见。现在的问题是,没有人知道文件传到了谁的办公桌上,所以也没有人掌握整个过程的进展情况。是差不多签完了,还是签了一半?是不是因为我们不知道的原因,被某人耽搁了?第二,照目前的情况看,如果你想复制一份几年前的“禀议”,因为你要做的事情与那份“禀议”请求做的事是一样的,你就必须找到提起“禀议”的人,并希望他们存有纸质副本,然后从那里复制。他们可能存有纸质副本,也可能没有。通过数字化,至少可以回头看看已经被批准的“禀议”并复制下来。

所有这些层面,所有这些审批链,往往导致错误的人最终做出特定的决定。有不同类型的决定:有些是技术上的,有些是业务上的,有些是人事上的。虽然有些决定很重要,但也有一些并不重要。不同类型的决定应该由不同类型的人做出,需要由最了解情况的人根据既定情境做出决定。

“Scrum之所以如此简洁,是因为可以将决策下放到团队层面,”吉姆说,“在Scrum中,只有两个决策者,产品负责人和团队。因此,需要由利益相关者或主管做出的决策较少。”

这是关键。只有真正拥有最多知识、最了解情况的人,才应该做决定。这样才能速战速决。如果做一个决定要花5个多小时,那么这几乎是一个肯定的信号,表明你必须把它送上审批链。

1个小时。这就是目标,就是做出决定需要的时间。等待委员会做出决定无异于与命运女神订立自杀协议。那么,该如何缩短决策时间呢?

衡量会议的成本

假定你需要做一个决定,所以你决定开个会。假设召集20个人参加会议,要花1个小时才能做出决定。你不妨扪心自问:做出这个决定要花多少钱?单单是时间成本,单单是这1小时所消耗的金钱。现在想想,你每周要参加多少毫无意义的会议。

我的一个朋友曾经在一所常春藤盟校工作。他告诉我,有时甚至直到走进会场时,他都不知道要开的是什么会。即使他知道开的是什么会,会议也一直没完没了地开下去。在此不妨做些数学运算。我们估算,每次会议大约花费1000美元。这位朋友每周至少要去开10~15次会,加起来要花费多少时间成本?

然而,真正的问题甚至更糟:在会议中做出的决定很可能被推翻。根据斯坦迪什的数据,有超过40%的会议决定被推翻。假设在会议上做出一个决定,假设离下次会议还有一周时间。在这一周内,开始执行第一个决定,但在下次会议上,每个人都改变了主意,做出一项新决定。所以,不仅是浪费了一周时间,现在还不得不撤销刚刚完成的工作。这就像挖一个坑,挖了再填,劳而无功。

根据斯坦迪什集团的研究,出现这种情况的原因有两个:一是参加会议的人,一是没有参加会议的人。实际上,会议室做出来的决定往往是由会议室里嗓门儿最大的人做出的。他们犹如推土机,强力推压别人,以得到他们想要的决定。会议结束后,人们各回各的办公室,心中愤愤不平:哼,回头再想想,我不同意这个决定。我要在下周的会议上提出来。

还有那些没有参加会议的人。他们也许应该参加,却没能参加。无论如何,他们都觉得自己应该参加会议。为什么不征求他们的意见?好吧,他们肯定会在下次会议上露面,让众人听取他们的意见。

吉姆·约翰逊说,倘若一个项目每天失败一点点,每延迟一天,项目失败的可能性就增加一分。一天一天,慢慢走向灾难。

决定做哪些决定

实施Scrum是为了发现拖累你的问题。Scrum能够揭露问题,把问题暴露于光天化日之下。当然,当问题在一个冲刺接着一个冲刺中不断出现,而团队也期望这些问题能够得到解决时,一些人就会开始说问题是Scrum造成的,并不在于问题本身。其实,问题始终是存在的。

问题在于,有各种各样的问题。而解决各种问题的办法并不在于那些坐在总部办公室中的管理层主管,而在于那些与客户直接接触的人——如果你愿意的话,也可以说解决问题的办法在于各个“节点”。通常,人们跻身管理层之后,地位升得越高,离第一线实际发生的事情就越远,同时也越相信自己对解决方案有最好的洞察力。

将决策层踢开的一个激进的例子是未来工业株式会社。未来工业株式会社生产电气安装设备——开关箱、电缆、导管之类的产品。与大多数日本公司不同的是,未来工业株式会社完全不搞“禀议”那一套,该公司的创始人是山田昭夫。山田长期担任公司首席执行官,直至2014年去世。山田认为“禀议制”极其荒唐,所以取缔了“禀议制”。他对员工们说,你认为怎么做最好,就怎么做;又说,让最接近工作的人来做。山田在其著作《员工最爱的幸福企业》中写道:“我是个傻瓜,不这么做,叫我怎能做出判断呢?”在他自己的公司里,他经常是看到某某员工的新名片后,才了解到日本某地新开了销售办事处。员工们自己决定创建新办事处时,就会找一座大楼,在里面租一块地方,雇用和发展新员工。山田写道,如果他不允许员工通过这种方式做出自己的决定,员工将不得不花费大量精力说服领导,领导就不得不去做完全不熟悉的事情。

然而,在大多数公司里,领导们坚持要了解一切,掌控一切,做出最后的决定,从而导致对情况了解最少的人做出种种决定。因为担心得不到足够的信息,领导们就要求得到更多的信息,因而耽误系统的运行。然后,领导又开始担心自己可能会犯错误,于是就召开委员会会议来分散决策权。

就我所知,一家大银行成立了一个风险委员会,成员有40多人。银行的任何提案都必须得到这个委员会的批准。委员会召开没完没了、扼杀灵魂的电话会议,一讨论就是好几个小时。等到真正做出决定时,已经搞不清是谁提出的主意,也搞不清一开始想解决什么问题了。如果结果证明这是一个坏主意,也没有人会被追究责任。该银行曾经做出过一些草率的决定,结果被政府罚款数千万美元。设立风险委员会是为了保护该银行,管理层真心不希望再度发生失误,所以把一干要人统统派到风险委员会,告诉监管机构:看,我们高层领导正在确保不再犯类似错误。然而,至此,风险委员会不仅阻止了做出糟糕的决定,而且完全阻止了做出任何决定,最终做出一个决定需要几个月时间。几十个人经过旷日持久的讨论,投入大量政治资本,最终做出一项决定,已经确保万无一失,它不可能是错误的决定。因为在这个问题上施加了如此多的行政智慧,出错是不可能的。可结果还是会出错。于是,他们得出结论:一定是那帮执行决定的讨厌鬼没有落实好。不幸的是,这种风险委员会在金融领域非常普遍。

最初定义非常简单的事项很快就会超出其初衷。委员会成员不是坏人,但他们建立决策控制系统为的是获得认同,这不仅会减缓事情的发展,而且几乎可以确保做出错误的决定。因为,几乎可以肯定的是,当他们终于做出决定的时候,时机已经错过。在做决定期间的几天或几周时间里,问题已经以某种方式得到解决。哪怕你选择不做决定,你还是做出了选择。

Scrum在这里行不通

我经常从Scrum怀疑论者那里听到一种论调:Scrum在这里行不通。我们做的事情太复杂,太不可预测,Scrum这样给予团队自主权的系统难以做到。我实在搞不明白他们为什么相信传统的项目管理方式可以处理他们独特的项目,搞不明白他们为什么对此深信不疑。我也搞不明白:为什么他们认为对于软件业来说,Scrum可能很好,但是他们的领域超级复杂,比搞软件要困难得多,所以Scrum不适用。

我经常教授对公众开放的课程。令人难以置信的是,来听课的人所从事的专业五花八门,从银行家、制造商、出版商、生物制药生产商,到研究人员、服务提供商、教育工作者和非营利组织工作者,形形色色,几乎无所不包。学生们的行业、专业知识和角色的多样性令人惊叹。

但是,如果你是怀疑论者中的一员,我想和你分享一个人的经验,他在一个(可能)比你试图完成的任务风险更高、变化更快、错误空间更小的领域中实现了Scrum。

几年前,美国海军指挥官乔恩·哈斯打电话给我,说不久前接手了一个代号为EODMU2的部队,即第二爆炸物处理机动中队,他想在部队中实施Scrum,想在地球上最苛刻的环境中,以更快的速度、更高的质量前进。

爆炸物处理中队是美国特种部队中最小的军种,人数只有数千。但他们必须能够在地球上任何环境下与任何其他部队一起合作,任务是摧毁一切可能爆炸的东西,使之失效,从地雷和炮弹,到简易爆炸装置。他们能够在陆地工作,也能够在水下工作,甚至可以使世界上最致命的武器,那些装有核、化学或生物载荷的武器,变得安全。他们也执行其他机密任务,恕我在此不便言明。

乔恩决定用Scrum来管理他指挥的这支三军中要求最为苛刻的部队。鉴于乔恩的工作性质,很少有人能采访到像乔恩这样的人。尽管如此,我还是向乔恩提了12个问题,关于Scrum和他的工作内容。他被允许通过电子邮件回答其中的9个问题。我不想把话塞进他的嘴里,所以我将分享一下从他那里收到的电子邮件。

乔恩的回应以如下免责声明开头:

以下内容仅代表作者本人的观点,不代表海军远征作战司令部、海军部、国防部和美国政府的观点。

问:你第一次听说Scrum是什么时候?

我第一次听说Scrum是在我准备当指挥官的时候。我联系了一些导师,整理出一份阅读清单,内容涵盖从领导力、管理手段到沟通技巧、情商等多个主题。正是通过这个过程,我找到了Scrum。看到Scrum后,我决心通过阅读《敏捷革命》来深入学习。大约两年前,我开始了学习敏捷性和Scrum的旅程。

问:是什么促使你在爆炸物处理中队实施Scrum的?

我们尽可能地去尝试,而不是做决定。做实验要具有一定的必要条件。首先,成本必须低,风险必须极低。实验在性质上也必须是暂时的,即使证明是不成功的,也必须是可逆的。最后,必须有可以监测的度量标准,以查看实验是否达到预期结果。

Scrum满足了所有这些需求。

开始Scrum不需要花钱;实施Scrum的风险很低;Scrum实验是暂时的,如果不成功,可以很容易掉转枪头;Scrum还包含了速率(Velocity)等指标来评估其有效性。通过度量每周的工作效率,可以跟踪每周的生产率,由此可知团队速率。

问:Scrum的结构是什么样的?你是怎么设置的?

我们规划了Scrum的结构,使之与Scrum的角色、活动和工具一致。Scrum主管由主任参谋担任,产品负责人由指挥官担任,而Scrum团队则由剩下的关键参谋人员构成。随着我们对司令部每个成员所支持的产品和服务的理解不断完善,小组的组成也随之发生调整。

问:产生了什么样的直接效果?

团队速率从每天提高4个点开始,稳步增长到每天提高50个点。其直接效果是改善沟通、优先顺序、成就任务。

问:影响最大的因素是什么?为什么?

影响最大的因素是确定所有活动的目标和议程。虽然许多活动反映了军事生活中的习惯行为,但我们缺乏通过实施Scrum所获得的目标和议程的清晰度。

时间定量(Timeboxing)也成为我们日常生活中必不可少的一部分。

时间定量和理解每个项目的目标对我们如此重要的原因是,我们可以在每次团队会面时,对照共同的、被充分理解的、深思熟虑的目标来衡量我们的效率。这使我们能够更加专注,进而促使我们能够完成更有意义的工作。

问:你能举个例子说明可以用Scrum做一些以前不能做的事情吗?

作为一名领导者,我能更加适应自己的行为对团队的影响。通过严格的冲刺回顾,我知道我的行为是如何影响团队幸福感的。

举个例子。在一个冲刺中,我督促团队完成一个特定的目标,这个目标与我们进入该冲刺时的优先事项不一致。在冲刺回顾会上,我征求团队的意见,并得到了我的行为是如何导致团队幸福感急剧下降的真实反馈。如果没有Scrum,团队就不会有向我提交反馈的机制,我也永远不会知道我行为的结果。

问:遇到了什么困难?你需要修改什么吗?

很难说服团队,让每个成员都相信所有的项目都需要进行冲刺。虽然人们广泛接受了每日立会,但有人对我们在会议上花费了大量时间进行待办事项清单改进和回顾表示不理解。逐渐地,随着团队开始理解这些事情的影响,比如拥有一个干净的、准备好的待办事项清单,或者在冲刺回顾会议上获得有关团队幸福感的数据反馈并征求团队持续改进的建议,团队对这些事情更加认可,更为接受。

问:在整个冲刺过程中,你是如何以及在哪里执行每一个项目的?

冲刺从星期一早上开始,我们在每周的协同化会议上会见所有的排。这使我们能够征求指挥部内所有小组的反馈。

在此之后,我们进入了制订冲刺计划阶段,将刚刚收到的信息纳入冲刺计划中。冲刺计划完成后,我们进入每日立会,讨论如何工作。这些都是在我们的会议室里完成的。

我们在同一个会议室使用团队展示板进行每日立会,指挥部中的任何人都可以看到这个展示板。周三下午,我们在团队展示板前开会,对待办事项进行优化梳理,包括讨论和确定要优先完成的工作。周五,我们召集全体水手,向他们介绍我们所完成的工作。这是我们的冲刺复查,下午,我们在团队展示板前集合团队进行冲刺回顾。

问:你离开后,Scrum还会继续吗?

未来不可预知,但是基础已经打好,基础设施已经存在,可以确保Scrum在我任期结束后继续存在。

现在,回想一下刚刚读到的内容。去掉偶尔提到的军职和水手等内容,把注意力集中在要点上。这不是一个军事案例,这是Scrum在复杂、困难和不可预测环境中工作的一个例子。

哈斯指挥官和他的队伍向来技艺精湛,积极上进。作为特种部队,他们可以说是毋庸置疑的佼佼者中的佼佼者。然而,实施Scrum之后,哈斯和他的团队发现,在18个月的时间里,生产率从每天提高4个点增长到每天提高到50个点,实现了1250%的增长。

尽管他们所做的工作涉及高科技,但这不是一个软件初创企业的故事,甚至也不是一个产品开发团队的故事。在某种程度上,他们相当于一家服务公司,提供高度专业化、危险和致命的服务。自从我和乔恩一起工作以来,一直有源源不断的海军特种兵来上我的课。这些人尤其关注结果,对于不能让他们更快、更有效的事情一概零容忍。

作为一名前记者,我知道抱有怀疑精神是有益的。但怀疑精神必须与接受证据相平衡,否则,怀疑精神就会适得其反,甚至具有破坏性。怀疑精神一旦成了害怕改变的伪装,就尤其有害。

把规则控制在最低限度

20世纪80年代初,在密歇根大学的所在地安娜堡,有一位名叫克里斯托弗·兰顿的研究生,此人着迷于在计算机中建立生命模型,开始研究他所谓的元胞自动机(Cellular Automata)。

元胞自动机是网格上的细胞,其状态根据一组规则随时间变化。每个细胞都在其他细胞的邻域中,其他细胞的状态会影响它们。最简单的邻域就是细胞间的相互接触。规则可以很简单:例如,如果我旁边的单元格是打开的,我也打开。更复杂的情况是,如果我的两个邻居是开着的,一个邻居是关闭的,我就关闭。

这很快就会变得非常复杂。数学太过难懂,在此还是免谈为妙。兰顿所做的是根据规则集是否引起很大的变化,来对规则集进行分类。他将度量标准称为λ。λ值越高,规则集引起的变化就越多。λ值越低,驱动的变化就越少。元胞自动机的有趣之处恰在于此。如果λ值过低,整个系统很快就会冻结和静止。如果λ值过高,系统则会陷于混乱。但是,在惰性和无序两种状态之间存在一个相变。规则不能太严格,太严格会使系统瘫痪;规则也不能太宽松,太宽松会使系统无序。必须有刚刚好的结构,不多不少,正好处于要混乱还没有混乱的边缘。

事实证明,这种混沌边缘学说不仅在数学和计算方面很有趣,还可以描述很多不同的事物。它所描述的对象被称为自适应系统。在自适应系统中,只有系统运行起来,你才能看到结果。即使你完全了解系统的每个部分,也只有当这些部分开始相互影响时,你才会从中看到显露出的属性来。此前,你无法预测这些属性会是什么。

我父亲说,自适应系统就是推动Scrum诞生的顿悟。他读到兰顿的论文时,正在一家银行管理一个大型瀑布项目。兰顿的论述使他明白了为什么他的项目拖延了好几年,而且超出预算数千万美元。兰顿从混乱的边缘看到了数字生活中最高的进化速度——这正是Scrum的设计初衷。

以交通为例。每天早上,地球上的人们,彼此之间没有经过什么讨论,便一跃而上,开着数亿辆汽车,在上班的路上奔驰。你就是其中一员。咖啡在手,你就成了交通系统的一部分。可能出了事故,有人减速,想看一看究竟。然后,后面的人再慢一点,然后是下一个人,很快就产生了涟漪效应,导致整条高速公路交通堵塞。你决定脱离困境,离开高速公路,开到当地街道上。但你并不是唯一产生这种想法的人,很快,车辆就在住宅区的街道上狂奔,堵塞街道。所以你试着走另一条路,发现如果沿着小巷开车,穿过杂货店的停车场,可以绕过拥堵。既成秩序就是这样,需要通过个人行动寻求解决方案。

不仅仅是元胞自动机以复杂的自适应方式行动,经济、生态、神经系统、团队,甚至是社会本身均以复杂的自适应方式行动。倘若规则太严格,则什么都无法改变,文化僵化,一事无成,最终,结构崩溃。但如果规则太松散,就会陷入混沌,街头骚乱,人人为己,社会完全丧失凝聚力。

混沌边缘是发生有趣变化的地方,最好能把结构的状态刚好控制在混沌边缘,驾驭它。这样,创造力就会开花结果,创意得以产生和应用。这样既有表达自由,但也有对表达自由的控制。

这种系统的另一个奇怪之处是,微小的变化可以以非线性、动态的方式放大。换言之,如果改变一件事,整个系统都会改变。这使得单个元素能够自发地、动态地解决问题。这也使得在过程一开始无法确定接下来会发生什么,尽管最后的结果可能看起来很明显,给人的感觉是事情本来就应该是这样的。以美国革命为例。今天看来,殖民地起义、丢弃英国人、建立美利坚合众国,似乎都是不可避免的。但阅读当时的资料就会发现,没有人知道会发生革命,也没有真正的革命计划,直到事情赶到那里,殖民地的居民才知道发生了什么,其成功可谓侥幸。

我想起了亚瑟·韦尔斯利是如何谈到滑铁卢战役的。滑铁卢战役一劳永逸地结束了拿破仑时代,韦尔斯利称之为“你一生中见过的最接近功亏一篑的胜利”。他在一封信中这样描述滑铁卢战役:

一场战役的历史,就像一场舞会的历史一样。有些人可以回忆起所有的小事件,而这些小事件的重大结果是战争的胜利或失败,但没有人能回忆起这些事件发生的顺序或确切的时间,而这些事件的价值和重要性却因此而大不相同。

事后,一切似乎都显而易见。然而,没有人能真正回忆起所有当时起过作用的个体力量。可能就是因为一个人的一次行动,因为在某一时刻,做了正确的事情,结果一切都变了。我发现,在一个有时个人行为似乎没有影响的时代,如果恰到好处地触动既成秩序,一个人就可以改变一切。这一发现让我欢欣鼓舞。

传统管理层对复杂问题的常见反应是建立更多的控制机制和更多的规则,以控制混乱;更多的红绿灯和更多的摄像头,从而使整个体系的齿轮停止转动,决定根本无法做出。

Scrum试图给人们一个工具,来管理各种类型的系统。Scrum不是试图限制系统,而是构建适度的结构和适度的规则。它并不是刻舟求剑,而属于精益化管理。每个人,都能贡献自己的价值。

一家全球性石油公司请我们与他们的一些团队合作,从而决定他们在哪里钻新井。他们有一套精密的阶段门系统,它需要大量的监督、大批的文档和许许多多的会议,工程师们必须通过这一系统工作。Scrum公司的教练到达那里后,把团队变成Scrum团队,我们告诉管理层:不要再告诉他们该做什么。相反,要成为他们的导师。每个团队成员都是一个单独的行动者,大家一起工作,以实现共同目标,即交付新油井。给他们行动的自由!当然,团队确实需要拿出一些文件和数据来,进行正确的研究,但是他们弄清楚了需要什么来做出钻探的决定。我们让他们做的就是谈论他们在每个阶段实际生产的东西,并把结果挂在墙上,使每个人都能看到。然后,通过忽略传统的步骤,转而专注于可交付的成果,他们就可以确定工作的优先级:他们可以看到团队如何协同工作,如何以增量的方式交付成果。他们对阶段门系统进行限制,并将其转化为可执行的待办事项清单。

在Scrum中,团队中的每个人都贡献自己的感想、创意和洞察力,从而塑造整体。在传统结构中,这些想法被系统所压制。系统指挥一切,限制一切,组织越来越繁复。整个体系越拖越慢,齿轮最终停止转动。

Scrum绕开传统管理结构,关注并利用不确定性和复杂的系统动力学。Scrum不是通过将决策集中在一个地方来实现的,而是通过将决策转移到各个“节点”上来实现的,是通过将决策转移到团队和产品所有者来实现的,学问在“节点”上。因此,通过转移决策,事情实际上可以不用等待就完成了。Scrum是一个有目的的复杂系统。或者用兰顿的话来说,是具有确定性的混沌。

完美是良好的敌人

无论做什么决定,真正的答案只会从系统中各个元素的相互作用中产生。在此不妨再引用艾森豪威尔的话,以资佐证:

计划毫无价值,但规划就是一切。二者的区别非常大,当你为紧急情况做计划时,必须从这一点开始:“紧急情况”的定义就是情况出乎意料,因此它不会按计划发生。

但是人们喜欢计划(尤其是他们自己的计划),于是就制订出很多计划。人们想要完美的计划,于是就需要更多的报告和数据来帮助其做出正确的决定。然而,这不可避免地需要越来越长的时间。结果,非但做出决定的目标无法实现,做出决定的过程反而成了目标。经过三番五次的研究、听证、辩论,实际上劳而无功,一无所成。决策的过程可能会持续很久,这取决于决策的性质,因为每个人都想要完美的计划,以为只要掌握足够的信息,就可以使之完美。

然而,完美的计划是不存在的,因为系统是动态的,不可能预知其结果。人们唯一能做的就是尝试些什么,并得到反馈。有行动总比没有行动好,不要犹豫不决,行动起来。在某种程度上,做什么并不重要;重要的是为了学习和进步,要有所行动,有所做才能有所作为。

Scrum所做的就是给你一个快速的反馈,让你知道一个决定是好是坏。Scrum允许你转向,改变主意,寻找一条不同的道路,朝着目标前进。每一个快速的决定都会为下一个决定提供情报。道路从实践中产生。

1999年,在IBM公司工作的戴夫·斯诺登想出一种看待问题的方法,帮助领导者了解其面临的是什么样的问题,应该寻找什么样的解决方案。斯诺登称这种方法为Cynefin框架。Cynefin一词来自威尔士语,意思是“暂栖地”“立足之地”。斯诺登用这个词为自己的理论命名,是因为他认为想解决问题,首先必须弄清楚自己的立足点。

在斯诺登的框架中,第一类问题是简单问题,或者说明显问题。简单问题是一种已经解决了的问题,实际上它一直存在最佳的有效解决方法,一旦能确定问题很简单,就可以从魔术袋中拿出一个已知的秘诀来运用。如果你在打扑克,千万不要把牌亮给对手,就像银行不应该向资产负债率不明之人放贷。在简单的问题中,因果关系不仅清晰,而且显而易见。

第二类问题是困难问题。困难问题是一种已知方法的未解难题。以石油公司为例:当地质学家进行地震勘测以了解在哪里可以开采石油时,他们知道自己不知道答案,但知道如何找到答案。这是专家的职责领域。一旦确定了问题可以解决,就可以找出解决方案,尽管解决起来可能很棘手。如果掌握足够的知识,就可以找出因果关系。我把汽车开进维修店时,总会想到这个。汽车发出一种奇怪的声音,我很担心。我不知道如何解决这个问题,但我知道技工要么知道如何解决这个问题,要么能够弄明白问题的所在并想办法解决。

第三类问题是复杂问题。复杂问题是我们一直在讨论的问题,只有在事后才能弄清楚事情发生的原因。解决这类问题,必须采取一些行动。在再次行动之前,需要做一些尝试,来看看会发生什么。

复杂问题是我们大多数人都要面对的问题。我们始终面对复杂问题,答案不得而知,各种力量也不得而知,但我们必须做点什么。做点什么之后,接下来发生的事情会让你大吃一惊。

让我讲讲Twitch公司的故事。可能有人对Twitch公司不明所以,在此不妨做一番简单说明。它是一家电子游戏直播平台,若不是事后诸葛亮,很少有人会觉察到它是一款爆品。Twitch公司获得了不可思议的成功。2014年,亚马逊以9.7亿美元的价格收购了Twitch。

Twitch公司第一个产品的创意是什么?是与谷歌邮箱(Gmail)集成的日历。当然,之后谷歌自己推出了谷歌日历,无奈,Twitch公司只好决定进入直播领域。其中一位公司创始人开始直播自己的所有生活,他头戴摄像头,背装有电脑的大背包,每周7天,每天24小时,不间断地进行直播。他们建立了极快的直播平台,可供很多人同时直播。但事实证明,没有人愿意看他们直播。于是,他们脑洞大开,想出个点子来——人们会不会希望直播自己?这个创意在当时的市场上也没能行得通。雪上加霜的是,他们的资金即将耗尽。后来,他们注意到很多人喜欢看人们打电子游戏的直播。他们虽然觉得不可思议,但还是跟进了,结果发现有一批狂热的粉丝和娱乐游戏玩家想观看顶级选手的比赛。顶级选手可以通过游戏直播赚很多钱。

这是一个极端的例子,满足了一种无人知晓的需求。今天,我们在商业、政治和社会上所面临的问题都很棘手,我们常常根本没有解决之道,甚至不知道如何寻找解决之道。

所以你需要做的是尝试做些什么,看看会发生什么。参照结果,微调正在做的事情。然后再尝试,再微调,如此反复,让解决方案出现。这就是Scrum:在短时间内进行一系列小实验,以找到解决复杂问题的方法。

赛尼芬框架中的最后一类问题是混沌问题,即危机。正如艾森豪威尔所言,紧急情况是无法制订计划的。应对紧急情况所需要的是领导层迅速而确定的行动。假设发生了海啸,或者石油钻井平台爆炸,或者股市崩盘,首先要做的是迅速采取行动,并开始采取步骤来描述问题,界定问题的极限,使其脱离混乱,成为复杂问题。举个例子,我在阿拉伯的某一天晚上,一群人决定冲进议会大厦,或者类似的地方。总之,数万人抱成一团,向议会大门猛冲过来。我被裹挟进人群中间。突然,尖叫声从一边传来,人群一下子变得混乱不堪,人们四处乱窜,不知如何是好,一个个单一的个体瞬间转化成山呼海啸的群氓。

我当时正和一个年轻的美国学生站在中间,我雇了她做阿拉伯语翻译。我告诉过她,现在我也会告诉你,在骚乱中该怎么办。首先,不要恐慌,这一点怎么强调都不为过。盲目的恐惧会招致踩踏,乃至丢了性命。其次,找不容易被撞倒的东西,一定要牢固,如路灯柱之类的,靠近它。奇怪的是,人群会像河流遇到石头一样,从你身边分开。这样,你就把混乱问题化解成了复杂问题。深呼吸,冷静一下,找出逃生路线,你自由了。倘若你像众人一样,裹在人群中,如同尸体般被抛来甩去,你就只能听天由命了。但是,假如你能摆脱噪声和恐惧,你就可以开始想出一个计划来。

这里,速度很重要。推迟做出决定只会使问题恶化。通过快速迭代——尝试,观察反应,再尝试——最终可以成功地控制危机。在当下,这种试错法会让人感到恐怖。但这也是一种机会。当人们试图弄清楚如何在前一天不存在的环境中工作时,新的做事方式就会出现。

不要等待,要行动

2001年9月11日上午,肯尼斯·霍尔顿和副手迈克尔·伯顿还是市政府内部一个鲜为人知的官僚机构——设计与建设局的领导,负责监督街道修缮、图书馆和法院的建造合同,他们的工作职责在纽约这座庞大城市中是微不足道的细枝末节。那个致命的周二早上,飞机撞上世贸中心后,没有人知道该怎么办。纽约市大肆宣传的应急管理办公室也没有采取行动。霍尔顿和伯顿所知道的是,必须向世贸中心现场提供大量设备和专业知识,以便开始在残骸中进行挖掘,寻找幸存者,清理巨量瓦砾。

他们只是在几个小时前才开始思考,并没有宏大的战略。虽然救援工作原本不是他们的分内之事,他们还是开始给以前签过合同的建筑公司打电话。当天晚上,他们设法接了电,装上电灯,以便在黑暗中继续营救工作。他们绕过所有正常的规则和程序,选择了四家认识的建筑公司开始作业。

起初,警察和消防部门抵制他们。但二人一直在做决定:搜查这栋楼安全吗?大致安全。通常,这种灾难是由联邦应急管理局和陆军工程兵团联合来处理的。但这一次,联邦机构询问情况时,却被告知有哪些工作正在进行中——并被告知不要插手此事。伯顿没有征求任何人的许可。

他们效率极高,完成了大量工作。项目工程庞大,他们的协调却十分出色。市长鲁道夫·朱利安尼为之折服,他告诉其他市政机构,即那些本该负责的机构,退后,让设计与建设局来掌控大局。他们在一家幼儿园的教室里建立了指挥中心,正如威廉·兰吉埃斯切在其杰作《美国土地:重建世界贸易中心》中描述的那样:

没有人有时间衡量如何做出选择、如何制订计划。需要的是行动,纯粹的行动。由于需要明确的沟通,伯顿在幼儿园的一间教室里召开大型会议,每天两次。这是一种简单、低技术含量的管理系统,却特别适合应对室外的大灾难。伯顿的推理像往常一样清晰,他说:“对我来说,能够控制局势的唯一办法是让所有人都来这里。没有时间分发备忘录,也没有时间等待指挥系统逐级传达命令。每个人都要听到问题是什么,就必须做出决定,每个人都必须亲耳听到这些决定。必须确保每个人都朝着同一个方向前进。”

迈克尔·伯顿后来被称为“世贸中心沙皇”。他定义、促成并协调了3000人在不到一年的时间里清除了150万吨瓦砾、灰烬和钢铁。行动,纯粹的行动,是把混乱局面拉回到复杂局面所必需的。

这里的关键经验是,在几乎每一种情况下,首先要弄清楚你所处的环境,然后开始尝试,看看你是不是真的在你所认为的地方。要做决定,不要等待。拖拖拉拉者会被事件压倒,采取行动者则能抓住自己创造的机会。

授权给适合的决策者

大多数人甚至不考虑时间因素,不明白每一刻都十分宝贵,一旦失去,就无法找回。他们没有意识到,每次等待,都在增加失败或拖延的可能性。如果你只能做一件事,就一件,一定要确保这件事是和所有需要做决定的人进行每日立会。像聚在一起讨论这样简单的事情,会大大降低决策延迟。通过授权团队和产品负责人去做决定,你自己就不必亲自做决定,你不必做的决定越多,决策过程就越快。这是一件简单的事情,但你的机构将开始成为一个让最了解问题的人决定如何解决问题的组织。

不妨再举一个拿破仑的例子:拿破仑的大军像波浪一样横扫欧洲,取得一个又一个胜利,短短几年就征服了整个欧洲大陆。当时,当某部队的士兵看到敌人时,一般的规则是不交战,而是上报给司令部,请示该怎么办。拿破仑用两条简单的规则改变了这一切。第一,见到敌人就开枪。第二,驰援枪响之处!这两条规则允许数万法国军队自发地迅速将全部兵力投入战争,而无须征得任何人的许可或指示。一支部队开火,附近的部队也会冲过来开火,就像野火一样蔓延开来,越来越多的法国军队向需要的地方开火。这两条规则永远地改变了战争。

不要等待,要行动!

回顾

不要等着做决定。1个小时。这就是目标。1小时就是做出决定所需要的速度,等待委员会做出决定无异于与命运女神订立自杀协议。如果做一个决定要花5个小时以上,这几乎肯定是一个信号,表明你必须把决定送上审批链进行审批。

授权给适合的决策者。这是关键。只有真正最有学问、最了解情况的人才应该做出决定,这样才能做得快。解决问题的办法不在于管理层的领导,而在于管理层之外的节点上那些与客户直接接触的人。

把规则控制在最低限度。若规则过于死板,则改变无从发生,文化僵化,一无所成。若能将组织的状态刚好控制在混沌边缘,则会发生意想不到的变化。

用简单驾驭复杂。简单的规则产生复杂的适应行为。复杂的规则只会给简单、愚蠢的行为留下空间。Scrum的结构恰如其分,规则不多不少,看似混乱,实则明晰。Scrum反对僵化,重在精益化管理。

待办事项清单

√下次要开会做决定时,为会议计时,计算会议成本。包括与会者的工资成本,计算有多少时间被浪费在等待做出决定上。

√思考你或你的组织最近一次面临的危机。行动能再快一点吗?或者,你对组织的迅速行动和反应感到惊讶吗?下次你如何改变决策过程?

√要得到想要的结果,你能做的绝对最小值是多少?你能停止做什么?

√想象一下你每天都要处理的复杂的流程。如果你关注的是价值而不是过程,将会是什么样子?

[1] Ringi来自日语“稟議”,特指在公司里对于要审批的事项,不举行会议,仅由具审批权的上司或相关人员以书面形式予以审批通过。这个词常被译为集体决策(collectivedecisionmaking),或分享决策。

[2]基本意思是修根、整根(移植树木时,提前一两年从根部周围挖开,切断除主要根之外的旁根,使须根先充分生长)。引申意义是事先疏通,底下打招呼。事前向相关人说明意图、情况等,以取得某种程度的理解。在管理学中,在决定某些事情的时候,为了避免混乱而事先取得大家的同意,这种手段被称为“根回し”。