我們都聽說過這樣的故事：某某公司將要開發一套大型的先進的ERP系統。這套系統將要取代三分之一的公司里現有的軟件系統，可以消減二分之一的費用，每個 人都會因此受益而高興。但現實中，這個項目超期2年還未完工，花掉的費用比原先預想的多出2倍，最終做成的系統就是一堆垃圾。

[[108275]]

Photo by Quinn Dombrowski, used under the Creative Commons license.

于是，追責行動開始了。開發商用瀑布開發模式忽悠客戶，收取了高額的需求變更費。軟件購買者不知道如何在一個信息系統里扮演客戶。需求說明書沒寫好/不詳細/不嚴格/太寬泛。顧問從一開始就不稱職。等等等等。

在失敗的軟件項目中，上面說的各種因素都有可能，但有一個因素卻是幾乎在所有失敗的項目中普遍存在的：軟件購買方并不是軟件的用戶。

這 個簡單的事實卻隱含著巨大的禍根。是否聽到過“客戶根本不知道自己要的是什么”的話？必然，因為他們的確不是真正的客戶。大部分的軟件項目都幾乎完全沒有 按照最終用戶的思維模式去開發。它們的需求要么來自CTO的自負，要么來自CTO的一個碰巧開了一個軟件公司的泥瓦匠兄弟的大腦，或者就是因為投標的價格 過低所致。不管怎樣，軟件設計總是要符合開發商的***利益，并迎合購買方決策者的喜好，卻跟真正使用這個系統的人無關。

當然，并不是每個購 買軟件的公司都表現的那么糟糕。很多的公司領導是真正關心系統開發的好壞和關心這套系統的最終使用者。如果不是因為其它的原因，至少是這個項目開發的好壞 會直接影響公司的運營。但即使這樣也不會好到哪里去，因為他們缺乏一線工作員工的那些經驗。他們不知道軟件如何做才是最適合它們的最終使用者。如果軟件的 設計是由XXX組委會/顧問委員會設計的、并有個很大的政治口號，那就更糟了。

因為我們幾乎沒有辦法改變當今的這些大型項目的投標招標簽約過程，作為軟件開發者，我們可以做些什么呢？一句話：換位思考。如 果你接到需求后沒有任何疑問的去實現它，那你應該自責。所有的失敗都歸咎于你也不為過。你的責任并不是照本宣科、需求上怎么寫你就怎么做。你的任務是為客 戶——不，是為最終用戶——做出有用的東西。為此，不論作為程序員這樣做是如何的大不敬，你也必須越職去跟那些將要使用你開發的軟件的人交流。

這就是為什么讓軟件程序員去體驗最終用戶的工作是如此的重要。如果你將要開發一套客服系統，就讓你的程序員去客服中心工作一天或一周。如果你要開發Web應用，就讓程序員和設計師直接面對用戶反饋，不要把它們外包給印度。

為 了理解軟件的真正需求，除了直接跟真正用戶交流或在現實生活中真正的使用，沒有其它更好的辦法。雖然很多的企業型軟件項目在開發時沒有辦法先自己體驗/反 饋，但你絕對可以將程序員送到真正的客服中心，沒有什么能比真正用戶的需求和痛苦能讓你更深刻的了。任何需求文檔都無法提供你一個完全的真實情況。任何技 術在沒有專業領域知識的支持下都不會出彩。沒有人會比那些沖到客戶現場***線的開發者更受客戶喜歡。這就是我們Bear Metal公司在每個項目上堅持的工作方式。所以，我認為你也應該這樣。

原文鏈接：http://bearmetal.eu/theden/do-you-know-the-biggest-reason-why-enterprise-software-sucks/

譯文鏈接：http://www.aqee.net/do-you-know-the-biggest-reason-why-enterprise-software-sucks/