作者 Harri Paavola 發表了《 軟體專案為何失敗？》這篇博文，筆者從中摘譯了一些。我們一起來看下：
所謂“失敗”也就意味著與他們的預期不一致。”失敗可以分為三種：
- 管理問題
- 工程問題
- 文化問題
以上三個問題，很難說其中一個問題凌駕於另外兩個問題之上或者說某個問題更為常見。
缺乏遠見和權力
幾年前，芬蘭最高的一座公寓樓就建在了我家附近（與其他城市最高的建築物相比，這並不算高）。左邊呈現的這幅圖是當時參與競賽的設計圖，而右邊的則是實際呈現出的效果。
建築行業 VS. 軟體行：舉個例子，目前房地產很火，造什麼樣的房子，只要資金到位，都能保質保量的造好。造 10 層樓，1 層用多少人，每天做什麼，很容易計劃，分配任務，人力資源，而且需求是不會變的。沒見過造房子，蓋了 3 層之後改主意了，拆了重新蓋。而軟體就大大不同了，需求的變化是不可避免的，而且凡是做過專案的人都知道，需求的變化實際上還挺頻繁。這樣一來，很容易造成計劃趕不上變化。
當工程專案拖延了工期，可以多加人手，把工期趕回來。而軟體就不這麼簡單了，新來的人要熟悉專案的內容就要花時間，工期很難完全趕上。很多 IT 的老總們體會不到這個問題，總以為多加人手，加班就能搞定。真正的有效的專案管理是要靠一個有效的管理體系來支撐的。
糟糕的開始
許多產品還未完成就被叫停了，這跟產品負責人也有關係。那麼，在什麼情況下會挑選下一任產品經理來負責該專案呢？——原先的產品負責人不喜歡該產品，對該產品毫不在乎。
當產品負責人對產品沒有強烈的慾望時，那麼他對產品的質量也不會有太大的要求。如果長期目標威脅到短期目標（獎勵機制），他會以快速且不負責的心態完成，如此一來，產品功能也跟著下降，最後呈現出的結果差強人意。比如 Nokia 推出的手機以及 Windows Vista 系統，事實表明，很少有人願意為此而買單。
管理人的軟弱
軟體開發，尤其是在管理層上，包含大量的政治色彩。有時，高層管理不會讓產品負責人追逐他們的夢想。這現象很普遍——不讓新的產品蠶食老產品。高層管理人無法接受這樣的市場蠶食。長此以往，我們所擁有的都是些殘缺的產品。不僅如此，有時其他產品負責人當看到新產品會吃掉現有產品的銷售份額時，他們也會發動反擊。當然這種行為建立在獎勵機制上，銷售下降，獎金也會跟著下降。
產品負責人的無能=產品的失敗
如果產品負責人對產品沒有強烈的責任心，那麼該產品必定是失敗的；如果產品負責人沒有為公司制定夢想，那麼產品失敗；如果產品負責人敵不過其他產品負責人，那麼該產品也是失敗的。
釋出壞的、不完整、不合適的程式碼
蘋果公司釋出的" goto fail"就出現了 Bug，這個 bug 會引起中間人攻擊，bug 的描述中說，這個問題是因為丟掉了對連線認證的合法性檢查的步驟。就這因為這個 Bug，所有 iOS 裝置與 SSL 有關的都出現了漏洞。Goto Fail 成為一個經典事件。（這裡推薦閱讀酷殼網陳皓的這篇 Bug 解析）
開發商的莫不關心
很多開發者不使用任何靜態分析工具以及不執行任何程式碼審查過程，儼然已經成為一種普遍現象。從程式碼技術層面來說無需進行高質量的程式碼審查就意味著該團隊中的每一個成員都能編寫出高質量的程式碼。很明顯這種假設是錯的。
實踐證明，大多數團隊中至少有一名開發者無法真正做到高效程式設計。因為每個人都會有心情不好的時候，當某個人意志薄弱時難免會出錯。
每個人都想成為老好人
即便在程式碼審查過程中發現了錯誤的程式碼，很多人還是選擇隨它去了。這是因為每個人都想充當老好人。而通常這類錯誤的決定以及誤解都是由同一類人造成的。
當審查者查詢出錯誤，哪怕是有一丁點錯誤也不放過，長此以往這就使得審查者與開發者之間不再和諧，開發者認為審查者是在故意找茬，兩者的矛盾慢慢就會產生。（推薦閱讀： 測試者和開發者，為何我們不能友好地相處？），審查者自身也認為這樣顯得太過苛刻，於是他們給自己放鬆了標準。
開放但不等於成功，滿足使用者所需才是最重要
儘管微軟在 Windows 8 上注入了大量心血，但其市場份額並不理想，業界對此也褒貶不一，很多使用者認為 Metro 介面和老的桌面體系並存，但融合的卻不那麼平滑，有種非此即彼的分裂感覺。
這裡還有兩個原因，筆者一句話帶過，即不聽——大多數不去輕易的嘗試產品，不願傾聽別人的反饋；不問——大多數人不會主動去問別人意見。
寫在最後
產品失敗存在很多因素，只有做到做到面面俱到，方可在軟體開發領域分得一杯羹。