軟體產品廣泛服務於各行業，其開發具有高科技、高投入、高產出、高風險的特點。在專案開發和軟體應用中，只有將人員能力的發揮與科學技術的使用應用市場的認識進行最佳的融合，才能發揮軟體的效益。普通企業雖涉足軟體開發業務，但由於業務主導方向不是軟體，企業領導往往忽視軟體工作的特殊性，對軟體的認識停留在“程式設計師編一些程式碼”的水平上。對企業內部的軟體開發缺乏管理意識，使得軟體開發在“認識上”就面臨問題。

與IT業的軟體開發組織相比較，普通企業中的軟體開發工作機構小、人員少。企業裡的軟體人員待遇低，難以吸引高水平的人才，開發隊伍中的人才流失率達到50%以上。由於沒有高水平的開發人員和技術管理人員，軟體工作狀況處於初級的水平，軟體開發不能按照軟體工程的要求執行。企業既對軟體工作沒有清晰的投入產出期望值，對效果不滿意，同時又對軟體工作手足無措。

在這種情況下軟體生產的效果不佳，進行改進勢在必行。但這種改進既要利於軟體開發水平的提高，又要改進整體環境，困難顯而易見。要徹底地改進企業軟體開發，我們要先總結一下企業裡開發軟體的幾個主要問題。

不恰當的組織結構

某企業的軟體開發工作模式如下：當面臨軟體需求時，成立一個臨時專案小組，由提出需求的業務人員為小組組長；指定幾個軟體程式設計師為組員；業務人員提出業務設想，程式設計師整理需求和程式設計，業務設想不斷更新，軟體開發隨之變化，最後業務人員認為效果滿意則採納，認為不可行或開發出的效果不好則專案自動取消。 這是一個比較典型的、作坊式的企業軟體開發的組織模式。

在這個例子中可以看到，許多企業的軟體開發模式存在問題，這類專案開發組織機構關係不平衡：開發人員處於被支配地位，利於開發的需求無法得到滿足；沒有程式開發主要負責人，在技術上缺少整體性考慮和設計，不能按照軟體工程執行；操作過程不規範，一個好的業務設想會因為缺少科學的工程過程、充分的可行性研究、完善的產品設計，導致開發出的軟體產品與設想的產品功能效果相距甚遠。這樣的專案組織結構，生產軟體的成功率可想而知。

職責分配不當

軟體系統建立過程中需要多方面人才：需求方人員、懂得軟體專案管理的人員、軟體程式設計師、系統分析員。普通企業中由於對軟體生產的不瞭解，往往由軟體需求提出方人員對軟體工作直接管理。這個工作顯然超過了其能力範圍，不符合軟體工作的相關原則。業務人員作為專案負責人，既不能合理計劃軟體開發工作，也不能管理好軟體工作中的各種風險。這將使軟體開發處於無序的風險之中。

以筆者瞭解的一個專案為例。該專案的業務負責人既不懂軟體也不懂專案管理，但在專案中對於軟體開發工作的時間要求、工作分配有絕對的控制權，而開發人員僅成為程式設計機器，導致開發人員士氣低下。該專案差兩週就要對外發布時，業務負責人才要求開發人員在一週內完成開發工作。而實際上，開發這個業務的軟體需要至少一個半人月的工作量。可想而知，這個專案最終以失敗告終。

工作流程不規範

由於企業的軟體開發一般是為了對內部業務進行支援，是輔助性的服務工作，所以一般的企業忽略了投資預算和與業務相關聯的成本核算。

企業裡軟體開發的隨意性還表現在：沒有軟體相關的規範管理工作，缺少專案管理的方式方法和應遵守的工程過程，專案成敗完全依賴個人因素和專案小組的自行組合能力；缺少高水平的技術人員和管理人員，軟體方面開發經驗不足，不能把握軟體工程各階段的工作重點，沒有完善的需求確認過程和完整的系統設計，造成重複程式設計和更改大量程式。

有一個例項：某專案開發程式只儲存在程式設計師開發用的計算機中，未加備份。開發過程中，程式設計師的機器硬碟突然出現故障，軟體原始檔處於極度危險之中，最後經過硬體廠商做硬碟修復，才避免前功盡棄。

總結

可以說，我們的企業開發軟體或多或少在某些地方存在“畸形”的現象。專案人員各居其位、各司其職的完善分工，在現在的企業內部軟體專案組裡實不多見。

據統計，企業開發軟體中能達到投入使用標準的專案不足60%；已經開發但尚未完成或剛試用就宣告終止的專案佔23%；使用一到二週時間後就宣告終止的專案佔17%。而在60%完成專案中，有95%專案的維護期遠超過軟體開發期或需要不斷升級。其主要原因是需求描述不充分，系統執行後還不斷追加功能，開發週期短，沒有充分的測試時間等，由此導致專案的軟體開發工作幾乎沒有結束標誌。從開發週期的角度來看，投入開發工時6個人月以上的專案的失敗率達到50%以上。在所有專案中令使用者比較滿意的專案不足5%。

總的來說，企業軟體開發失敗的根本原因在於，沒有專案管理概念和軟體工程概念。其典型的幾個表現是：忽視產品設計階段的工作；忽視或不執行軟體工程過程；沒有確定軟體開發模型；沒有軟體產品化過程；缺少有針對性的培訓。

而且在這類企業中，高層領導關心的是主營業務，雖然對軟體開發不滿意，但不能認識到問題的根源所在，改進的願望不足。他們採取的態度是，只要企業總體利潤能夠支撐這種方式，就甘願維持原狀而不願冒險主動投入、改變落後、減少浪費、提高效率，所以對實際中相關工作支援不力。

在這種情況下，軟體生產的改進必然是一個艱難而漫長的過程。