复盘埃森哲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则把“自由”与“责任”作为企业文化的原动力。

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