复盘埃森哲2亿败局:不敏捷的代价

IT经理网点评:昨天微信朋友圈被《坑爹!花费2亿耗时2年,网站没建完Java都写不好,顶级咨询公司埃森哲被告上法庭》一文刷屏,从产品完成度方面列举了埃森哲的“十大罪状”,不少Twitter、微信微博上的瓜友认为3200万美元的项目如果交给一个小公司也许反而不会“翻车”。我们认为大家可能忽略了一个实质问题:什么才是真正的敏捷?此事无关项目和团队大小,正如本文的副标题:没有敏捷的项目,只有敏捷的组织。

马玉年/文

没有敏捷的项目,只有敏捷的组织

这两天埃森哲坑爹的新闻在IT的朋友圈热议。本着兼听则明的态度,我立马跑到theregister去看了原文。

首先这不是啥新闻,而是4月23日的旧闻。网站的头条上还是Facebook侵犯用户隐私遭到3国的起诉。

如果搜索Accenture这个单一关键词,News里面第一条就是 Hertz sues Accenture for screwing up $32 million website redesign 

但这件官司仿佛并没有影响埃森哲的股票价格。月线还有小幅上涨。

如果再翻翻历史,2016年俄勒冈州政府起诉Oracle,1亿美金不能如约履行医疗网站交付。

2017年滨州政府起诉IBM,1.7亿美金不能履行税务系统交付。

这看起来似乎是大组织的通病。相比其他两家,Hertz这3200万美元还算少的。

有人说,难道埃森哲不用敏捷方法吗?难道Hertz的IT部门不知道敏捷吗?这就说回到这篇文章的主题。

Agile如今如此的火爆,埃森哲一定会在这个项目中实践敏捷的。甚至在争取这个项目的过程中,也一定会使用大量的敏捷方法去打动Hertz。

为什么大家好像都在用敏捷方法做软件项目,但是还有大量的项目失败?

因为真正的敏捷不会出现在一个项目里面,只会出现在一个组织里面。先看一下一个网友对埃森哲这一事件的评论:

“我曾在埃森哲做过程序员(注意:此前几年,我做内部应用程序开发,而不是为客户开发)。我可以保证,在那儿,程序员从来不了解真正的客户需求(未被告之过任何合同需求)。我经常被这样要求:“这样做——不要以你的方式,而是以我们认为应该的方式”。瞎子领导瞎子,这就是埃森哲的工作方式。只要他们能以某种方式盈利(通常是通过建议客户裁掉一群人,以便首席执行官能买一艘新游艇),他们就不在乎结果。无论如何,这世界上有谁会为建一个网站花费3200万美元?就是那些付钱给咨询公司建网站的人。”

在一个项目里,如果作为工程师不能得到用户的原始需求,只是被告知:做这个;做那个;不能做这个。试想这样的项目,使用什么敏捷方法可以成功?

然而像这样套用Scrum、Kanban、SAFe等等套路的“敏捷”项目,几乎是当前的主流。

我们再来看一个网友在评论中分享的经历,他曾作为第三方跟埃森哲合作过几个项目。

“我代表一个第三方客户与埃森哲公司合作过几个IT项目,我能理解赫兹的痛苦……(该公司)大多数人的工作表现都只能说勉强“达标”。尽管也有一些人出类拨萃,那主要都归功于他们个人的卓越表现。拖延、糟糕的配置,甚至简单的东西都提交不了,是每天都会发生的事情。”

这些真实的经验说明了一件事:在一个并不敏捷的组织里,真正的敏捷不会在项目中单独(凭空)出现。如果出现,也只不过是碰巧赶上了项目组里有一两个很“敏捷”的关键人物,项目的成功完全是他们个人能力的展现,跟真正的敏捷还相去甚远。

只有出现在组织里面的敏捷才是真实有效的方式。当人被赋予了自由和平等的权利时,个体才能在项目里面承担起相应的责任。不是被指派、被要求什么能做,什么不能做,而是被完全的信任和授权,你觉得该做什么?怎么做?

当工程师不是被当成工具、或者小孩子来看待,而是被当做一个可以承担“自由”与“责任”的成年人对待的时候,他们才会有动力和权利去挖掘真实的用户需求,才能真正对产品负责,提交令客户满意的、有价值的东西。这才是敏捷宣言的本意。

而这样的方式,在埃森哲这样的大企业里面,往往是难以实现的。所以为什么会有网友建议Hertz不如找个小公司。这也是为什么Basecamp这样的公司会一直钟情于只保持37个signals。Netflix则把“自由”与“责任”作为企业文化的原动力。

本文授权转载自微信公众号:敏捷之美

第一时间获取面向IT决策者的独家深度资讯,敬请关注IT经理网微信号:ctociocom

   

除非注明,本站文章均为原创或编译,未经许可严禁转载。

相关文章:


关于作者

X