我國軟件工業從上世紀90年代初期的接近60％的凈利潤（下同），下調到目前平均利潤不到5％。這個現象說明我國的軟件工業正在面臨一個重大的危機，如何面對未來的挑戰？繼續生存和發展呢？
歐美軟件企業目前還可以維持平均17％的利潤，印度更能維持27％的利潤。以我國一家年營業額達到人民幣五千萬的軟件企業來說，規模已經不少，技術人員總有一百多人，但平均5％利潤只能為企業帶來人民幣兩百五十萬元的凈收益。萬一有一兩個大型項目發生重大延誤的時候，這家軟件企業便會面臨一個嚴峻的考驗，繼續掙扎生存，還是改善運營的模式。
一些軟件企業嘗試引進項目管理，希望能夠利用這門管理科學改善企業的效益，但在過去數年中，成功利用項目管理來提升項目實施效率，能夠控制成本，能夠提升交付質量的個案并不多見。項目經理只是一個高薪的技術人員，不但未能發揮項目管理的作用，也未能有效地使用項目管理的知識來降低項目的延誤，減少項目范圍變動的需求，有效地與客戶進行溝通，適當的利用資源的技術能力來讓項目如期完成項目的交付。
主要的原因是軟件企業內部未有一個完善的管理環境，也缺乏一套可操作的管理制度。一些軟件企業的領導多以“競爭激烈”為理由。但處于一個市場經濟的大環境下，競爭是必然的事實，我們必須考慮如何提升自身的競爭能力，有效地降低交付成本，提升企業的利潤，才能夠面對未來的挑戰，讓企業能夠繼續發展。
我國軟件工業的開發特色
從上世紀70年代開始從事軟件開發的工作，分別在歐洲、美洲和澳洲等地經歷了三十多年的IT項目經驗。各地的IT從業人員都有明確的工作崗位和職責，從早期的程序員（Programmer），系統分析員（System Analysts），系統設計師（Systems Designers），系統工程師（Systems Engineers）等主要職位，到后期因應IT科技的技術發展而增加的通信/網絡工程師（Communication/Network Engineers），數據庫設計師（Database Designer），數據庫管理員（Database Administrator），項目經理（Project Manager）等職位。但回顧我國的IT行業多只有軟件工程師的職位，其中可能分為高級工程師，中級工程師，和初級工程師三大類。一些企業內部可能會添加網絡管理員來維護網絡系統的運行。
國外IT企業的崗位是依據企業所采用的系統開發體系(System Development Methodology)和企業本身的商業運營模型（Business Operation Models）而建設。主要是為了建立技術人員的專業能力，讓技術人員有足夠的時間一步一步地學習和擴展本身的專業知識和提升技術水平，從開始進入行業執行編碼的工作，積累足夠的經驗后才開始進入系統分析的工作，能夠積累分析問題和找出原因的經驗后才知道如何解決問題成為系統設計師。在整個項目開發過程中利用不同的專業人員本身的經驗和專長在不同的階段提供最優質的交付。
其中最重要的一環是團隊必須定期進行溝通，把自己發掘及建立的信息不斷轉移到其他成員身上，不斷互相進行比較。系統設計師依據系統分析師所建立的系統需求說明來建設系統的架構和邏輯，建立系統和程序的規格，然后交由程序員按照規格進行編寫。測試結果必須與系統需求和系統規格吻合后才能夠完成交付。對系統的質量在過程中受到全面的監控和審核。
反觀我國大部分軟件企業在系統開發過程中，完全是一個軟件工程師對一個模塊、或一個功能、或一個子系統進行全程負責，從開始調研、到設計、到編碼、到測試、到安裝，到文檔編寫、完全是“從一而終”。我們的軟件工程師是全能的工程師，可以負擔整個開發過程中所需的工作。但很明顯易見，我們的全能軟件工程師并沒有達到我們的要求，不管是執行調研的任務，還是設計的任務，還是編碼的工作，還是測試的過程，我們的軟件工程師是“通”而不“精”。導致項目開發過程中不斷進行返工，修改，和測試。到最后系統勉強進行交付，后期補上的文檔不但未能符合系統工程的基本要求，而且“殘缺不全”，對系統的邏輯和后期的維護帶來負面的結果。這個開發模式我稱為CAF開發模式（Code and Fix），在開發過程中不斷進行修改，測試，返工，測試，重做，測試，在修改，到最后，程序的邏輯出來這位軟件工程師外，其他技術人員絕對沒有辦法理解。
更重要的一點是我們的軟件工程師不著重“分析”，缺乏了分析的過程，我們便不能夠理解企業建設系統背后的原因，未能把握問題，我們便不能夠設計高效的解決方案，更缺乏創新的思維。所以我們大部分軟件工程師在調研階段是希望能夠從客戶口中獲知系統的功能需求，而不是從把握現狀后對信息進行分析，結論出系統的功能需求（請參閱“我國軟件工程的冤枉路”一文）。
降低系統開發成本
我國軟件企業對服務報價也有本身的特色，就是一口價。我說的一口價并不是眾所周知的“定額合同”總費用的一口價，是我們在合同內報價那部分編列出來“共？？？工作天或？？？人月”的費用。我國軟件企業多以一個基準費用進行報價，不管是高級軟件工程師，中級軟件工程師，初級軟件工程師，或項目經理，這個基準費用適用于各級別的技術人員，基準收費如何建設不在本文范圍，但可以肯定，這個基準費用不會為企業帶來很大的利潤空間。再加上合同談判過程中被客戶壓價，那么合同的總費用更沒有多余的空間來應對項目延誤所帶來的損失。
大家都知道，軟件工程這個行業的最大成本支出是勞動資源的費用，工齡越久的技術人員工資可能是新進技術人員的十倍，而我們所慣用的CAF模式主要工作量是編碼和測試，修改和測試，或返工和測試。這些工作估計占去整個系統開發工作量的70％。能夠建立一套模式可以讓初級人員負責編碼的全部工作，當然可以降低服務成本，提升企業的利潤。
改善CAF開發模式
我國的一些軟件改進協會和學會組織，只把焦點集中在某類技術應用上進行改善和改進，從未考慮改進我國的系統開發流程，建立一套適合我國軟件工程環境的開發體系。技術上應用的改進不能夠降低我們在開發過程中的返工和重做的需要，我們要提升軟件工程師的調研能力，分析能力，設計能力和溝通能力，進行有效的分工，提供合理的開發成本和管理方法，才能夠幫助我國的軟件工業擺脫目前的困境。
我們不能一下子把目前的CAF開發模式調整為國外慣用的架構性系統開發體系。但我們可以改善目前的CAF開發模式，讓我們能夠在改善的過程中不斷調整和培育技術人員對系統開發過程的專業能力。
首先是讓管理人員和中、高級軟件工程師認同一套合理的系統開發文檔，內容、填寫方法和執行人。開始的初期不用劃分太細，否則會產生很多矛盾和爭議。開發模式大致上可以分為前期階段，編寫階段和結項階段。每一個階段中的工作以工作包進行授權，實施，和審核。目的是讓中、高級軟件工程師編寫合理和完整的系統規格說明書讓初級軟件工程師可以按照系統規格編寫有關程序，同時在高級工程師或技術總監的指導下讓初級軟件工程師按照規格和系統需求進行程序和模塊的測試。
結項會議是整個改善模式最重要的一環，目的是讓項目組成員回顧項目實施過程中任何可以學習和改善的地方，對信息收集的方法，需求分析和說明的內容，系統設計和規格說明等文檔內容可以改善的地方和方法，記錄在案并發布，讓其他項目組成員能夠從中學習。同時可以嘗試歸納項目的個別工作包內容，建立架構性的項目開發流程。慢慢改善軟件工程師的開發能力，配合軟件開發流程，達到“人盡其才”的最終目的。
同時讓初級軟件工程師負責全部編碼工作，可以降低項目的開發成本，提升企業的利潤。
全面的改革
要全面改革我國的軟件工業，能夠與國際企業競爭國際市場，我們必須規范本身的技術應用方法，項目管理不能夠有效管理不規范的技術實施過程。在我們未能改善技術的實施過程前，任何項目管理知識和體系也不能夠幫助我們提升效率。以目前我國軟件工業平均利潤指標來衡量未來發展的空間，只有改革技術實施過程，提升技術資源的專業能力，配合實施過程的需求，和配合科學管理的概念，才能夠開展軟件企業的潛能，拓展未來的生存空間。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
