1.軟體高效贏利模式 那麼在這種環境下，如何通過軟體來最大程度化的贏利呢，最簡單的想法就是兩點，論述如下： 1.1.程式碼複用 在前面也有提到，軟體的成本主要是在其開發階段，一旦開發成功，後續的成本是非常之少的，所有的軟體都可以通過拷貝來解決。如果能對軟體的程式碼進行復用，那麼這是節約成本的一個非常好的辦法。對於軟體專案來說，每個專案都有其獨特性，差異很大，如果做到完全複用，那是不可能的，但是基礎程式碼的複用還是很可行的。目前國內很多大的軟體公司，都有自己的基礎架構平臺、模組庫、函式庫，對於非常特殊的業務規則才開始編碼。更有勝者，有些公司已經把很多語言根據不同行業的規則，封裝成了原子構件，開發不再使用程式碼，直接拿原子構件拼裝。（例如：普元公司的EOS）。但是所有的這些只是程式碼的部分複用，真正要做到程式碼的完全複用，只有一個辦法，那就是做成軟體產品。深入的挖掘某個行業客戶的通用性需求，組織開發成產品，這是軟體贏利最大化的準則之一。當然要做一個通用性的產品並不容易，有時候很難用一個產品將同一個行業的需求統一起來，這樣就出現了一個軟體產品的不同版本，例如：企業版，標準版等。這樣是允許的也是必需的，但是如果為了滿足某些客戶的需求，在產品中開發了太多客戶私有的需求，那麼這就不是一個產品了，而是一個專案，是為某個使用者定製的。這是違背了產品贏利最大化原則的，需要經最大的努力控制，在很多大的軟體專案中，我一直在使用者滿意和產品通用性之間找平衡。 1.2.

和硬體的結合 由於軟體的形態、軟體開發的門檻不高等原因造成軟體行業不是很好做。但是如果將軟體和硬體結合起來，這又是另外一個局面了。軟體和硬體的結合主要有幾種形式，第一種是嵌入式軟體，也就是硬體裡面的軟體。第二種是硬體管理軟體，第三種就是和硬體結合的應用軟體。這三種軟體形式在很多公司中都有體現，前兩種軟體在市場上的贏利也是非常不錯的，由於篇幅關係，不想在這裡展開討論。對於第三種軟體，我個人認為，將是軟體行業的一片藍海。這主要有幾個原因： 1.2.1.門檻很高 並不是任何一個軟體公司都有實力開發和硬體結合的應用軟體的。大部分能夠做這類應用軟體的公司都是有著非常強大的硬體基礎，這樣才能夠給應用軟體的開發提供一個很好的環境和支援。就這一條的加入，將會擋住很多軟體公司無法涉足這個市場，所以藍海不會很快變紅。但是有一點要注意的就是，這類應用軟體和硬體的結合點一定要足夠多，這樣才能夠和沒有和硬體結合的軟體分出優劣。如果應用軟體和硬體結合的很好，那麼就不單是賣產品了，我們是賣解決方案，是給客戶解決一攬子問題的Solution! 1.2.2.

帶動硬體的銷售 單個的硬體銷售是蒼白無力的，如果能包裝成解決方案，那就不一樣了。軟體和硬體的結合正是包裝成解決方案最好的辦法之一（當然還有很多其他的方面，例如：培訓、服務等）。一個好的硬體型應用軟體將會大幅度的帶動公司硬體的銷售。 2.軟體如何才能有優勢 上面介紹了軟體如何高效的贏利，已經軟體優勢的問題，但是不夠全面，下面還要介紹其他的幾個方面。 2.1.天時 軟體出現的時機是非常重要的，而且這個時機與市場成熟度也是有很大關係，並不是越早越好。如果市場不夠成熟，使用者對自己的問題認識的還不夠深刻，也沒有迫切解決的需求，那麼這個時候去推相應的軟體，即使是好東西，投入的成本也會非常高，而且很容易失敗，所有的投入將會為後繼的公司做鋪墊。如果市場成熟，使用者解決問題的想法很迫切，這種解決的方案市場運作地又非常好，被廣大使用者所接受，那麼這個時候推出軟體是非常合適的。例如：BEA在J2EE標準出來之後，迅速推出符合J2EE標準的應用伺服器weblogic，在市場上取得了巨大的成功。只要市場成熟了，相應應用軟體的出現是越早越好的，時間也是應用軟體的優勢之一。 2.2.

地利 所謂的地利就是這個產品佔有的各種各樣的資源，比如說市場的資源、客戶的資源以及硬體支援的資源等等。特別是對有大客戶群軟體的二次銷售，是個很值得關注的點。 2.3.人和 這裡的人和指的並不是“得道者多助，失道者寡助”，而是在整個軟體生命週期裡面，人的行為和方法，這也是決定軟體成敗的重要因素之一。 2.3.1.軟體質量 要保障軟體的質量，最主要的有兩個方面，第一個方面軟體開發的保證，第二個是軟體測試的保證。 至於軟體開發中如何來保證軟體的可用性、穩定性、魯棒性、可擴充套件性等等，在軟體工程裡面都有非常詳細的論述，在這裡就不在贅述了。 在這裡要談的就是關於軟體測試的問題。目前國際上流行叫“SQO”，也就是“軟體質量優化”。軟體質量優化是一個非常龐大的概念，其中包括了測試管理、bug追蹤，自動化功能測試、自動化效能測試、自動化效能監控等方面。要將這麼龐大的一個體系建立起來不是一天兩天的事情，也需要投入不少的資金，但是對於自動化功能測試來說，我覺得有必要深入討論一下。 功能測試在軟體測試中是最基本的，也是最重要的，當然工作量也是最大的，對於一次性開發的軟體（也就是以後需求不會再變，軟體也不再升級）來說，這種工作量還不會充分體現出來，但是這類軟體非常少。當前的大部分商業化軟體，軟體的需求都會有變化，產品的版本也會不斷更新。只要軟體存在這需求的改變和版本的更新，就有一個問題，那就是功能測試中的“迴歸測試”。軟體和其他的產品不同，修改了一個bug有可能帶來很多其他的bug，開發了一個新功能有可能使得原有的一些功能出錯，於是理論上來說，每次修改bug，每次新增一個新功能都要求將軟體所有相關的功能重新測試一遍。但是現實之中很少這麼做，因為這個工作量實在是太龐大了，更本無法開展。如果修改一個bug就測試這個bug是否還存在，加入一個功能，就測這個功能是否好用，這個明顯是不夠的，會給整個軟體帶來潛在的風險。一般公司的軟體都存在這種情況，由於軟體不斷的更新，版本不斷的替換，使得軟體測試的工作量很大，經常一個版本的發行很多時間花費在測試之上，很難滿足市場的去要。那麼如何來解決這種矛盾呢，這裡我提出的就是自動化功能測試。自動化功能測試主要的目的就是滿足迴歸測試的需要，在第一次功能測試的時候，將所有的測試用例錄製成測試指令碼，到了下次需要回歸測試的時候執行測試指令碼，則系統自動完成所有的功能測試，這樣不僅降低了人工的工作量，而且測試快速、準確，不存在人為操作失誤而帶來的缺陷遺漏。所以我認為，自動化功能測試工具的引入將會大大提高軟體開發的效率，保證軟體測試的質量和縮短軟體開發的週期。 2.3.2.服務 同很多產品一樣，軟體產品的服務也是非常重要的，這也是衡量軟體好壞的標準之一。一般的軟體服務體系應該包括： （1）遠端支援 5×8的電話支援服務，產品論壇建設等 （2）現場支援 產品技術培訓；緊急情況現場處理；產品定期巡檢等 3.綜述 總之軟體是一件比較特殊的商品，做好軟體是非常不容易的事情，需要考慮到方方面面的因素，只有這樣才能使得軟體在市場上取得成功。以上純屬喝醉了瞎掰，發洩一下而已，大家看後有收穫最好，沒有收穫一笑了之罷了！