“ ……
你們將首先遇到塞壬女妖們  
她們會唱出美妙無比的歌聲  
以此來誘惑往來穿梭的行人  
若有人靠近聆聽她們的聲音  
他將不可能獲得生還的機會  
再也見不到自己的妻子兒女  
……”

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

　　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).

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

　　所以，專案為什麼會失敗。 :)

https://www.cnblogs.com/sherrywasp/p/9337270.html