复盘埃森哲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。
为什么大家好像都在用敏捷方法做软件项目，但是还有大量的项目失败？
因为真正的敏捷不会出现在一个项目里面，只会出现在一个组织里面。先看一下一个网友对埃森哲这一事件的评论：
在一个项目里，如果作为工程师不能得到用户的原始需求，只是被告知：做这个；做那个；不能做这个。试想这样的项目，使用什么敏捷方法可以成功？
然而像这样套用Scrum、Kanban、SAFe等等套路的“敏捷”项目，几乎是当前的主流。
我们再来看一个网友在评论中分享的经历，他曾作为第三方跟埃森哲合作过几个项目。
这些真实的经验说明了一件事：在一个并不敏捷的组织里，真正的敏捷不会在项目中单独（凭空）出现。如果出现，也只不过是碰巧赶上了项目组里有一两个很“敏捷”的关键人物，项目的成功完全是他们个人能力的展现，跟真正的敏捷还相去甚远。
只有出现在组织里面的敏捷才是真实有效的方式。当人被赋予了自由和平等的权利时，个体才能在项目里面承担起相应的责任。不是被指派、被要求什么能做，什么不能做，而是被完全的信任和授权，你觉得该做什么？怎么做？
当工程师不是被当成工具、或者小孩子来看待，而是被当做一个可以承担“自由”与“责任”的成年人对待的时候，他们才会有动力和权利去挖掘真实的用户需求，才能真正对产品负责，提交令客户满意的、有价值的东西。这才是敏捷宣言的本意。
而这样的方式，在埃森哲这样的大企业里面，往往是难以实现的。所以为什么会有网友建议Hertz不如找个小公司。这也是为什么Basecamp这样的公司会一直钟情于只保持37个signals。Netflix则把“自由”与“责任”作为企业文化的原动力。
本文授权转载自微信公众号：敏捷之美
第一时间获取面向IT决策者的独家深度资讯，敬请关注IT经理网微信号：ctociocom
除非注明，本站文章均为原创或编译，未经许可严禁转载。
相关文章：
关于作者
