我国最大的IT项目管理门户网站,国内IT项目管理培训与咨询服务提供商
1995年,在这个世界的某两个角落里,发生了两件看似毫不相关的事情,分别是:第一架波音777飞机投入商业服务和Scrum论文第一次公开发布。
在纷繁曲折的历史中,波音公司在软件行业提出敏捷方法前就已经实际使用了敏捷的方法。
▪波音777的开发背景
在80年代后期,波音公司试图决定如何来填补767和747之间产品线上的缺口。一种选择是在767设计基础上继续演进,但是最后波音公司决定斥资50亿美元建造一部全新的波音777飞机。即使在1990年代波音公司财务实力雄厚,但是50亿美元的项目,一旦失败可以击溃任何再牛X的公司。
▪波音777取得的成绩
- 波音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
作者:唐怡佳,致力于运用软件行业敏捷经验,尝试在硬件领域的内部敏捷转型的传播和实践。
免责声明:
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的,并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,请浏览者仅作参考,并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体,版权归原作者或原发布媒体所有。如文章涉及版权等问题,请联系本站,我们将在两个工作日内进行删除或修改处理。敬请谅解!
Copyright © 2021 IT项目管理界 版权所有 京ICP备17062359号-4 如转载本站文章,请注明原作者和原发布媒体
本着互联网分享精神,本站部分内容转载于其他网站和媒体,如稿件涉及版权等问题,请联系本站进行删除或修改处理
客服电话:010-89506650 89504891 非工作时间可联系:18701278071(微信) QQ在线:511524637
新闻与原创文章投稿:tougao#cpmta.com 客服邮箱:info#cpmta.com(请将#换成@)
IT项目管理界——我国最大的IT项目管理门户网站,隶属卓橡公司