• Scrum@scale-2
  • Shine-scrum-02
  • Arne
  • Jim-banner
  • Cams2
  • Cal
  • Inner-training
  • Growth-process
  • Jens-heart-of-scrum
硬件敏捷先驱——波音777案例分析

1995年,在这个世界的某两个角落里,发生了两件看似毫不相关的事情,分别是:第一架波音777飞机投入商业服务和Scrum论文第一次公开发布。


在纷繁曲折的历史中,波音公司在软件行业提出敏捷方法前就已经实际使用了敏捷的方法。

 

在80年代后期,波音公司试图决定如何来填补767和747之间产品线上的缺口。一种选择是在767设计基础上继续演进,但是最后波音公司决定斥资50亿美元建造一部全新的波音777飞机。即使在1990年代波音公司财务实力雄厚,但是50亿美元的项目,一旦失败可以击溃任何再牛X的公司。

 

-  波音777是首架采用3D CAD制图的飞机,也许在今天我们很难想象,还能用其他的 方式来进行设计工作。但是在777之前飞机是用2D来设计的,并且只有当原型做出来以后才可以对其进行测试。

- 在旧版本767的开发过程的各个阶段中,仅仅在舱门设计上的大大小小的变更,就有13000多次。如果事情没有所改变的话,777的开发,只会变得更糟。但波音公司数据显示,777项目中的变更和错误比之前的项目减少了80%。

- 有遍布在美国,欧洲,日本,澳大利亚的10000名工程师参与了777的开发。从合作的噩梦或者犯错的机会上来看,那么777项目可以说极有可能是一个大坑了。

- 1990年1月开始概念设计,1993年开始第一个原型机的生产,1994年6月12日首航,并且在之后不到一年的时间里—1995年5月在联合航空投入商业运营。

- 777首次快速交付就被联合航空所接受,其中只有一点点小小的缺陷被记录了下来。这对于任何一个复杂的系统而言都是超乎非凡的,不管是考虑到一架飞机所需具备的安全性或是可靠性而言。

- 777第一架原型机,经过更新后,于2000年被国泰航空投入商业运营。

 

当时负责波音777项目的Alan Mulally将他自己的工作的模式“一起工作”运用到了项目中。而“一起工作”让我们从波音777项目中看到许多熟悉的Agile理念。


个体和沟通的价值高于流程和工具


“一起工作”模式将人们从不同的部门拉拢到一起,在Agile中我们叫做“多功能团队”。这是过去的做事方式大为不同的,过去设计工程师设计他们的图纸,然后把他们的设计扔给制造团队—瀑布模式。这是波音公司1990年代的操作方式,但是想一想,今天,在你的公司里是否仍然在使用这一方式?


为了解决交流的问题,Mulally组织起了约250个多功能团队DBT(Design-Build Team),每个DBT团队负责一个功能模块。比如一个DBT负责引擎,一个负责货舱舱门,一个负责客舱舱门,一个负责机翼前缘,一个负责方向舵等等。


每个DBT都由综合多样的人员组成,可以把一个特定的设计从概念到制造和维护都落实下来。团队中有设计人员,制造人员,模具人员,财务,材料,维护,分包合同代表,甚至客户代表来确保作业、制造和维护的方方面面都被涵盖了。


这种做法有个潜在的问题就是单个的DBT团队不能跟上整个项目的设计步伐, DBT每周进度例会一定程度上解决了这个问题。但是波音公司意识到团队总是需要以更高层次的目标被联系起来。也就是当你埋头工作的时候,时不时需要抬起头来,看看你周围的伙计们,确认下你的工作没有和他们的脱离,而是相辅相成的。


为了实现这一点,Mulally做了一件非常震撼人心的事情。他将波音777的所有10000个员工每个季度都汇集到西雅图,开为期两天的all-team meeting!这样的会议在30个月里开了9次!



这两天的全体会议,使得大家找到那个最合适的人面对面地沟通,从而减少错误和工作脱节,并且减少长时间延误。10000个工程师汇集西雅图2天会议的费用(10000 x 2 天工资和出差费用)比起项目延迟1个月的费用(10000 x 30 天工资加上项目延期的后续影响)来说太少了!

 

回想在我们的项目里,虽然大家都在做同一个产品,是否很少互相交流?各个部门的成员不常碰面,周会很少能聚齐所有成员,很多问题都用email来回地解释说明。遇到问题,还是先找部门领导,部门领导再去找对应负责的人员。很多的时间和精力都浪费在了流程、逐级沟通和写email上。我们是不是能够撤去部门的壁垒,迈动起步子,来到大家的面前,面对面地及时地切实地去沟通,最后把结论写下来。许多软件项目的团队已经把开发、测试部门之间的壁垒瓦解了,施行后效果不错!硬件项目的团队是要比软件团队更大一些,包括设计、开发、制造、采购、模具、备料、仓储、财务、维护、分包合同代表,甚至客户代表。我们可不可以先把其中几个壁垒撤了,先建立起核心团队,然后逐渐地去影响更多周边团队?波音777的案例无疑是值得我们学习的。


工作的软件比完备的文档更有价值


我们说工作的软件比完备的文档更有价值,目的都是为了创造出快速的反馈闭环,在还能修改的时候,以尽早发现问题。敏捷是一种快速失败的模型。波音777项目在这一点上也是投入了巨大的努力,可以说是—竭尽所能地创造出可以得到反馈的增量。


当然那个时候波音还没有在一个个Sprint里面创造和测试飞机的增量,但是777是几乎完全使用三维CAD软件代替二维图纸设计的第一架飞机。在建造第一个原型之前,3D CAD模型就可以组合在一起进行实时验证。这就加快了反馈闭环的形成,增量的质量也有一定的提升,从而能够更早更好地得到反馈。



在3D图纸之后,相比较于传统的飞机项目通常制作6个原型,波音777制作了9个原型。每个花费1亿美元来计算的话,波音777花在原型开发上的费用占了总费用的20%。另外,波音将777项目中做好的引擎,先放在了747飞机上,做了一次试飞。



这些花费和投入值不值得呢?从结果上来看,无疑是值得的,更快更多更好地在开发过程中获得反馈、发现问题,永远是值得的!


回想今天我们的硬件开发,整个开发过程并不短,2,3年的不算长项目,在这2,3年里我们做了几次原型?我们可不可以像boeing777那样把一部分模块先放到先前版本上去运行试试?我们有没有竭尽所能地去发布可测试的增量,竭尽所能地去尽早拿到反馈尽早暴露问题?如果没有,那么到了项目最后,才发现问题,回头返工推倒重来,也怪不得别人了。


客户合作胜过合同谈判


经过激烈的竞争,最终美国联合航空公司选择了波音公司和波音777, 220亿美元的采购合同也促使“777”从概念变成现实。联合航空和波音公司确实签署了合同,但是除此之外,他们还签署了著名的“Condit-Guyette”手写备忘录。全文如下:

Condit Guyette备忘录,转录

B777目标


美国波音公司和普惠+


为了及时推出一个真正伟大的飞机,我们有责任共同设计、生产和引进飞机。超过飞行机组,机组人员和维护和支持团队,最终我们的旅客和货主的预期。

从第一天开始:

–行业内提供最佳的可靠性

–行业内最佳的用户吸引力

–用户友好和运行良好

1990年10月15日

由美国联合航空公司签署,普惠公司和波音公司高管

 

这份备忘录充分地说明了一点:用户合作高于一切。

只有充分地把客户拉进项目里面来,或者说我们和客户的距离越近,我们做出来的东西,越接近客户的真实需要。

 

反观我们的硬件项目,往往是产品经理定了个大致的立项愿景和市场依据(还有可能并未和所有项目成员做过充分的说明)。产品需求是项目经理找各个部门的经理写的,产品经理对负责的产品的各项需求并不知道,优先级也并未经过产品经理的梳理。同时整个团队和客户的交集似乎也只有这个不常出现,不常言语的产品经理身上。这是多么可怕呀!我们到底凭什么认为我们做出来的东西是客户需要的?我们需要做的改进很多,目标只有一个:靠近客户!我们和客户之间,不仅有合同,更需要合作!大力地创造获取客户反馈的闭环条件,是确保我们在做正确的产品的唯一途径。闭门造车只有死路一条,我们真的是时候放下身段,好好地向我们的客户讨教一番了。

 

响应变化胜过遵循计划


敏捷倡导拥抱变化。变化来自哪里?变化来自客户反馈。


还是来看boeing 777的例子。在波音777项目中,共有8家航空公司常驻波音西雅图公司。其中最多的时候仅仅英国航空就有75人常驻为了boeing777项目常驻波音。他们为1500个设计功能进行了review,并对其中的300个提出了改进建议。


还有许多其他需求变化的故事,比如澳大利亚的方向舵团队,不得不忍受了2次,在生产开始之后的需求变更。这些都是大的可见的变化,对于那些小的日常变化呢?


对于那些小的日常的变化,DBT多功能团队会来处理新涌现的信息,并在制造和设计工程师之间形成快速的反馈循环。需求变更以往需要消耗几周,但是在DBT团队一天就可以搞定了。当你可以快速合作,应对变化就会变得更容易。


激动人心的波音故事背后,遗憾的是,今天我们仍然看到在传统制造行业,应对变化是如此的艰难,冗长的流程,合作的缺乏,一个小小的变化就能击溃人心。

 

波音的故事是讲完了,由此引发的思考和反思还远远没有结束,也许才刚刚开始。只要这个思考开始了,相信如果敏捷能使得波音777如此成功地起飞,那么也一定能让我们的硬件产品起飞!


参考资料:《Agile at Boeing in 1990s – the 777 Program》,原文链接:https://theleanviking.wordpress.com/2014/10/07/agile-at-boeing-in-1990s-the-777-program/?from=singlemessage

作者唐怡佳,致力于运用软件行业敏捷经验,尝试在硬件领域的内部敏捷转型的传播和实践。

审核:寿佳炎


ShineScrum捷行好文征集

如果您想将您在Scrum敏捷之路上的所见、所闻、所想分享给更多的敏友们,欢迎发送邮件至cathy.hu@shinescrum.com投稿,文章审核通过后,我们将会在ShineScrum捷行微信公众平台发布。