項目爲何會失敗

「 ……
大家將首先遇到塞壬女妖們  
她們會唱出美妙無比的歌聲  
以此來誘惑往來穿梭的行人  
如有人靠近聆聽她們的聲音  
他將不可能得到生還的機會  
再也見不到本身的妻子兒女  
……」

—— 荷馬史詩，奧德賽，第十二卷。

　　1964年，通用電氣、貝爾實驗室和麻省理工聯合發起了一個極具野心的項目，Multics. 目標是建立一個用於大型機的分時共享操做系統。但項目的難度超過了你們的想象，到1969年，貝爾實驗室判定 Multics 是一個代價高昂的錯誤，率先退出了該項目。最終，項目以失敗了結。

　　2002年，原 Lotus 公司 CEO, 上世紀80年代 IBM PC上的殺手級應用 Lotus 1-2-3 的創始人 Mitchell D. Kapor，成立了 Open Source Applications Foundation (OSAF) ，啓動了一個頗具野心，試圖超越 Microsoft Outlook 的 PIM 項目，名叫 Chandler。到2008年，Kapor 辭去 OSAF 主席一職，並宣佈撤資。Chandler 項目歷時 6 年半時間，兩打頂尖程序員，上百萬美圓的投入，倒是南柯一夢。

Wikipedia上的 Chandler詞條

　　我所在的公司也曾陷入過一次困境。幾年前，公司與一家日本企業進行了深度合做，啓動一項(方向錯誤的)產品戰略。老闆很是看好項目的前景，雄心勃勃地直接將公司作了技術轉型。項目週期很長，持續數年，參與項目的同事們夜以繼日的像日本人同樣努力地幹。最終等待你們的，是產品在日本市場根本推不出去的尷尬，拿回國內也因爲設計思想不符合國情，毫無價值。最終，在 demo 以後，老闆雖不甘心但迫不得已地壯士斷腕。

 

　　軟件開發這一行，失敗是遍地開花的，因此成功才顯得榮耀。每一個項目的失敗都有着這樣那樣的緣由：需求分析沒作好，產品設計有缺陷，市場調研過於樂觀，項目週期太緊，人手不足，技術門檻過高，主程半路跳槽了，前端失戀了，設計師休產假了，產品經理是二貨，項目經理是擺設，老闆是外行，客戶就是一坨翔…… (如下省略1萬字)

　　其實，事情沒這麼繚亂。

　　OOP的世界有個「通病」，逮着什麼都想封裝，既然「萬物皆對象」，那失敗也應該能夠抽象。

 

　　這幾年的從業經驗，我抽象了一個規律：

1.  若是客戶以爲事情簡單，那麼項目必定會延期。
2.  若是客戶和老闆都以爲事情簡單，那麼項目會爛尾。
3.  若是客戶、老闆和團隊，同時以爲事情簡單，那麼…… 全部人最後死都不知道怎麼死的。

　　項目中全部的 delay，均可以歸結爲一個緣由：對困難估計不足！
　　

　　而失敗，就是無限期 delay.

 

　　把控 delay 風險，是一件很難的事情。在軟件開發活動中，精確地預估項目週期是一個僞命題。想要搞清楚一個事情須要多少時間完成，習慣性的思惟是從過去的同類項目經驗中尋找依靠，可悲劇每每在於，軟件項目不是簡單的複製，總會有意外發生。更不用說那種50%以上的需求產生於交付以後的項目了。（朋友，勾起你的回憶沒有？）

　　預估完成時間就像信用卡消費，刷起來容易，還起來要命。

　　因此，大多數人都很容易把問題想得太簡單，這種思惟陷阱就像塞壬(Siren)的歌聲，充滿了誘惑力，這就是爲何失敗比成功更廣泛。

 

　　人類很容易膨脹，尤爲是男人，而咱們又處於一個男權世界。（這裏我並不想討論女權問題，可能有人會說當今社會已經大力提倡男女平等了。對此，我只想說，男女平等這個口號的提出，自己就意味着男女不平等的事實，女權主義的存在，正是由於女權的缺失。）

　　1944年6月，由於事先知道任務的艱鉅性，盟軍作了足夠的準備，因此，諾曼底登錄成功了。這個成功很是巨大，以致於對於訓練有素的，天天都在拿命操做的軍人們也瞬間被衝昏了頭腦，喊出聖誕節前結束戰爭的口號，發動了著名的市場花園行動，結果盟軍大敗，損失慘重。這下才意識到從諾曼底到柏林，還有很長的路要走。

　　生死攸關的戰爭中，人類均可以盲目自大，況且一個軟件項目。

經典美劇《兄弟連》第4集，講述「市場花園行動」

 

　　我曾讀過一本很棒的間諜小說，福賽斯(Frederick Forsyth) 的 《豺狼的日子》(The Day of the Jackal)，驚心動魄的情節中最令我印象深入的，是代號「豺狼」的職業殺手在執行任務前的各類準備工做。其中有一段劇情：在接下任務以後，豺狼爲了肯定最重要的暗殺時間及地點的選擇，他很多天泡圖書館，經過《大英百科全書》檢索有關戴高樂的參考書目，而後用假身份郵購了全部資料，花了三週的時間，閱讀了全部能蒐集到的戴高樂的資料，從中分析他的性格，習慣，總統日程等。最終發現戴高樂在每一年6月18日——「自由法國運動」記念日——一定會出席一個不管颳風下雨都要公開露面的儀式，地點就在「六月十八」廣場。敲定了時間和地點以後，豺狼又用了三天，實地考察了準備行動的廣場，並肯定了暗殺時藏身的公寓。

 

　　對困難估計的越充足，準備工做就越周全，成功的機率就越高。

　　一個項目中的困難，是須要全部的項目干係人都意識到，纔會有解決方案。之因此這麼說，是由於我曾經合做過一個優質客戶，甲方對困難的估計很是充分，光立項就花了半年的時間，並制定了400人天的研發週期，而當項目中意外頻發，不可避免地仍是面臨 delay 時，甲方很理解地說對此有充分地心理準備，主動調整 deadline，這才保證了項目在和諧的氛圍中「如期」上線。

　　作軟件很難，須要每一個人都不犯渾才能取得成功。

 

　　回到1969年，Multics 項目的失敗後，其中一名叫作 Ken Thompson 的工程師總結了 Multics 中的種種經驗教訓，而後就有了 Unix . 這聽上去有些荒謬，大名鼎鼎的 Unix 起源於一個失敗的項目。事實確實如此，Unix 最開始叫作 Unics ，起這個名字自己就是針對 Multics 而言的，Multics 但願作成大而全的系統，而 Unics 就只作好一件事。「小便是美」的哲學正是吸收了 Multics 失敗的教訓。這種影響也一脈相承到 Unix 的孿生兄弟 C語言文化中。

　　前面提到的 OSAF/Chandler 項目的失敗，卻由此誕生了一本不可多得的著做《夢斷代碼》(Dreaming in Code).

　　

　　

　　有句話怎麼說來着：失敗是成功的媽媽…… 嗯？

 

　　因此，項目爲何會失敗。 :)

 

 

 

 

 本文已獨家受權給腳本之家(ID:jb51net)公衆號發佈