沒有敏捷的項目，只有敏捷的組織。
這兩天埃森哲坑爹的新聞在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則把“自由”與“責任”作為企業文化的原動力。
閱讀更多 敏捷之美 的文章
