用微博账号登录:

当前位置:首页 > hbr案例首页推荐 > 冲向失败?


冲向失败?

作者:汤姆 • 克洛斯(Tom Cross) 发表于:2011-06-01 冲向失败?

推荐度:

为了给国际空间站制造一套价值12亿美元的巨型机械臂——伸缩臂式兼容抓手(简称REACH),加拿大航天管理局(CAA)已经苦战4年了。REACH项目是外包给两家承包商:赫莱贝克航空器和埃斯科纳软件系统公司来完成的。项目经理萨曼莎从2006年起就一直负责管理这两家公司。

工程的第一阶段如今已经完成,REACH已经连上了空间站,两家公司按时完成了任务,并且没有超出预算一分钱。但问题是在开发过程中,工程质量一直不尽如人意。实际上,4年来,就没有哪一次测试没出过纰漏。“没事,没事,这个能修好。”承包商代表总是这么说,对CAA的担忧充耳不闻。“嘿,快工可出不了细活儿。”有一次,REACH的一只手臂未能对命令做出响应,代表对萨曼莎说,“别忘了,我们早就提醒过你们,赶工有风险。”

萨曼莎管理的合同需要同时进行,也就是说,项目的各阶段——研发、原型机制造、测试、制造以及质量控制——相互重叠,一个阶段开始时,前一个阶段可能有多达50%的工作量尚未完成。在航空界,这种做法简直大逆不道。但是由于空间站建设的时限要求,加上CAA的预算一直面临削减的危险,CAA只能想办法把本应10年完成的工作压缩到6年里完成。同时,一些理应在真实环境下进行的测试则由计算机模拟取代了。零件的质量控制要求也有所降低。而且,由于项目中存在有太多未知因素,CAA接受了“成本+固定费用”模式的合同,按照这种合同,除了付给承包商人工费、材料费和日常管理费以外,CAA还要向其支付一笔固定金额的报酬。

连上空间站的REACH马上将在离地350千米的高空进行首次真实环境测试了,这次的任务是修补空间站内被撕裂了的太阳能采集板。

可是,在空间站情况监控室,萨曼莎听到空间站的宇航员正在谈论“电力切换元件”,她听到了“失灵”这个词。她还听到有人说:“我们只能采用备用方案。” REACH很有可能出现了在最后一次地面测试时发生的问题。

在监控视频上,大家看见,临时启用的起重机载着宇航员韦伯向空间站损坏的太阳能板靠近。REACH连影子都没见着,显然确实出了问题。

萨曼莎看到了特鲁斯,赫莱贝克公司的代表之一。他坐在角落,领带解开,一脸痛苦。但是萨曼莎一点也不可怜他,她只觉得厌烦。萨曼莎跟特鲁斯说,必须修改合同,牺牲速度,以确保二期工程的质量,但特鲁斯觉得很难实施。

此时,手工修补好太阳能板的宇航员韦伯做了一件令人难以置信的事情。他扭头面向地球上的观众,发表了一段为REACH辩护的讲话。他说:“REACH是一项很了不起的技术。CAA在非常紧张的情况下,攻克了许多技术难关,才将REACH按时送到这里。而REACH也将成为我们工作中重要的一份子。一个小小的电力元件故障说明不了什么。机器太复杂,就是会出问题——很正常。我们会修好电力元件,就像我们修好太阳能板一样。我知道在接下来的几个月里,CAA还会做重大升级。”

萨曼莎惊愕不已,她看到特鲁斯也和她一样。特鲁斯朝她笑了笑,问她:“你刚才说合同要怎么来着?”

萨曼莎应该修订REACH合同吗?四位专家各抒己见。

本文刊登于《商业评论》2011年06月,如需阅读全文请到相关杂志用积分购买

“不管人们有多聪明,都不可能预见到复杂技术中可能出现的全部问题。”

 

加里 • 莫(Gary L• Moe)

麦肯锡公司商业技术部主管,该公司位于硅谷。

每当政府出资的大型复杂技术项目未能达到要求时,人们都会将此归咎于时间安排过于“仓促”。他们会说,要是政府部门对承包商催得不那么急,要是能给开发人员多一点时间来完善设计,要是生产时间能延长几个月或几年,那么项目肯定不会出事。但是,事实并非如此。

就算政府能够给予承包商尽可能多的时间和资金,用以进行尽可能详尽的需求分析,并完善项目设计,最终完成的产品可能还是达不到完美无瑕。在所谓的大爆炸式设计(big-bang design)中,为了实现一次性达标的目的,开发人员不遗余力地确保每一个细节准确无误,但就算这样也无法生产出绝对运行正常、毫无瑕疵的产品,这是因为,不管人们有多聪明,都不可能预见到复杂技术中可能出现的全部问题。

要解决这个难题,我们需要迭代开发。第一步,建造一个原型,甚至是个正式的成品,然后进行测试,并总结测试中发现的缺陷。这些缺陷单凭图纸或者3D模拟是根本无法发现的。接下来,根据测试结果改进你的产品,随后再进行一轮这样的测试,一轮一轮反复进行下去,直到最终得到比较令人满意的产品。一项技术越复杂,开发工作需要反复的次数就越多。

非政府部门就是这样进行产品开发的。以汽车工业为例。汽车的生产非常复杂,所以,在全面投产之前,厂商先要利用模型来进行多次开发和测试。在软件行业,这种做法被称为敏捷式开发(agile development)。开发人员花一个星期时间写代码,然后测试,找出改进的方法,再写更多的代码。

在组织进行结构重组的过程中,交互式的方法也十分有效。无论你花多大力气设计结构重组方案,你也只能做对60%,所以你只能持续不断地修改设计,最终达到90%的正确率。(还没有超过90%的)

迭代开发不仅可以运用于大型长期项目,也可用于大型的一次性项目,比如国际空间站许多部件的研发。你可以将开发过程分解,然后将开发再测试、再开发再测试的模式运用到各个部件的开发。

《商业评论》网iPhone客户端

请关注我们的新浪微博官方帐号:

@商业评论网(http://weibo.com/ebusinessreview

@商业评论杂志(http://weibo.com/hbrc)

无觅相关文章插件,快速提升流量
[  标签: 项目管理  HBR案例  hbr案例首页推荐  ] 65703 次阅读2 次评论

读者评论

(评论内容为网友针对本词条展开的讨论,与本网站的观点立场无关。)


  • 王志强

    王志强:

    开发的不确定性总是存在的.在软件开发上尤其突出,软件开发在这方面的思考也是最多的.如此看来, 软件开发的原则,模式和经验确实可以推而广之了.

    ( 2011年07月 )回复(0)

    该文章只有登录后才能评论。请先登录

    分享到:QQ空间 腾讯微博

    评论

    声明:本文由 @商业评论网 http://www.ebusinessreview.cn(转载请保留)拥有版权或由内容合作伙伴授权提供,未经商业评论网书面许可,对于商业 评论网拥有版权和/或其他知识产权的任何内容,任何人(包括博客及个人空间)不得复制、转载、摘编或在商业评论网所属的服 务器上做镜像或以其他任何方式进行使用。


    您也可以直接 在线订购 或致电 800 820 5396 购买刊登本文的当期杂志。 电子版全文将于本月内更新发布,届时您可购买在线阅读卡阅读全文。

    帐户如果还没有点数?立即 购买阅读卡,在线阅读更多精彩文章 注册冲值后仍打不开全文?请点击“ 常见问题”。如需更多信息,请进入 帮助页面
    订阅热线: 800-820-5396    邮局订阅代码: 80-115
    共0人分享过本文,他们是: