目標 校驗 能力 至少 測試 開放 一定的 擴大 上一個

國內很多軟件企業尤其是行業軟件企業是從開發一、二個軟件項目起家的，而且項目規模和復雜度也不大，依賴其中一兩個高手，他們能夠在客戶適度滿意的狀態下成功完成項目。基於以往研究，成功的主要因素是項目具備以下特點：

• 如果是需求定制形的項目，項目需求明確且範圍不大，變動不多。這樣的項目要麽客戶方需求明確，要麽企業對需求足夠了解，這樣，意味著項目雙方至少有一個人對需求有全面並且細致的了解；雙方合作氛圍很好，這可以減少需求變更的量和避免沖突尖銳。
• 如是技術引領型的項目，則依賴於企業的獨特技術。
• 企業有一兩名技術和業務的高手。
• 項目使用的技術涉及面不廣，往往一兩個人兼而關註就可以把握。
• 一點運氣：正好選對了技術平臺；正好高手沒有離職……

隨著時間的推移，企業承接的項目多了，人員多了，企業規模也擴大了。這時候，企業的內外部環境都發生了很大的變化。 從外部環境來看： 1） 客戶行業發展迅速，需求在寬度、深度、變化頻度上發生了持續的變化。具體來說，要求軟件系統支撐的業務多了（需求寬度增加）；並發使用軟件系統的人多了、時間長了，業務過程復雜了（深度增加）；競爭加劇，客戶需要經常進行業務的調整（變化頻度多了）。這種變化，往往會使客戶的需求管理成為一個專業、持續、並且工作量相當的過程。也就是說，企業具有需求管理與軟件開發進行分工的需求。 2） 軟件系統開發使用的第三方技術平臺種類多，且復雜，更新換代也快，如果軟件系統在性能、持續穩定性有要求，並且軟件使用周期設計要求滿足一定的年限，就要求企業對第三方技術平臺的發展進行跟蹤，並尋求有效應用的實際經驗（最佳實踐規範）。這樣，企業就逐步有將集成應用技術（含軟、硬件集成應用技術）進行專業分工的需求。企業的軟件項目越多、第三方技術平臺越多樣復雜、軟件系統的要求故障時間越短，這方面的需求就越迫切。 3） 市場技術競爭的重要性增加，關系競爭弱化，企業發現為了獲取合同，他們需要有研發能力的保障，並且要在技術競爭考察中勝出。迫使企業對客戶關註的重點專業技術進行投入。 從內部狀況來看： 1) 企業同時運作軟件項目數量增多，但依賴於高手的項目模式沒有改變。各項目都需要高手來保障，如果沒有高手，項目就停滯不前，而且往往以非正常手段結束。 2) 隨著軟件項目的深入展開或軟件的升級換代，企業會發現有些模塊的開發總是在重重復復地做，上一個版本做了，這個版本還要繼續做，同時開展幾個項目，都有類似的事情在重復做。但要直接使用之前的內容，又不行。例如，很典型的是，每個軟件項目都在做系統的登陸權限管理；每個軟件項目都有錄入合法性校驗問題等等。 3) 技術人員總是有很多理由不去寫文檔，如果不是一個人將一個模塊從分析設計負責到代碼，後一個環節的人總是得意於自我創新，並容易發生設計人員和開發人員的扯皮。 4) 軟件項目在前期開發時候是一路凱歌，到了快要交付的時候，卻又難產，總是達不到要求，改改代碼重新測試，沒完沒了。而技術人員又非常辛苦。甚至出現部分或大全部返工現象。 5) 軟件項目開始的時候，誰也不知道什麽時候能完成，領導說三個月就三個月，半年就半年，實際上，沒有按期完成的，延期3-5個月是常事，1-2年也是有的，甚至不得不換班子重開爐竈。 面對以上變化和問題，企業的解決辦法之一是延續原有項目的成功模式——高手主導的項目模式，即給每一個項目配備高手。如果沒有那麽多高手，就讓把所有的項目壓在有限的高手身上。如果高手有限的話，實際上企業是將問題轉移給相對低資源能力的高手去解決。當然，有限的高手也同樣可以使用同樣的手法進行問題轉嫁。這有點像項目承包，企業完成軟件項目的能力依賴於不同的高手，如果高手恰恰不行的話，軟件項目將一塌糊塗。高手們在項目中可以進行分工調整，由於項目的臨時性特征，這些調整註定也是為項目服務的。形成公司能力積累的方式往往是產生一些專業的高手。而且，項目出現的問題越多，這樣的高手越能獲得公司的重視。這種解決辦法由於將所有的問題轉移到高手身上，企業管理就研發方面的決策難以形成明確的方向和目標，在研發方面只有用人的戰略。 顯然，以上並非根本性的解決方案。企業很難找到或培養那麽多高手，導致企業業務發展受限，而且這種方式面臨的風險很大；過度的項目定制開發不但影響項目的交付進度和質量，也使成本居高不下，侵襲了企業本來就比較有限的利潤。那麽，出路只能是走向產品化。 然而，軟件產品化是一件相當困難的事情，企業在各個方面都將面臨挑戰，並必須作出相應的改變。 首先，企業需要轉變經營理念和思路。其實不管是項目化還是產品化，都要堅持客戶導向，但是就客戶導向的內涵和實現方式上，很多企業往往是被動地滿足客戶需求，甚至遷就客戶五花八門的需求。我們到底選擇什麽樣的客戶？這是企業成長中必須作出的回答。即便已經明確了這個問題，對客戶各種需求也不是不加區別的滿足，而是需要抓住目標客戶的核心需求和偏好，並認識到客戶只要在核心利益上得到足夠的滿足，他們願意犧牲一些個性化的特性——這正是產品化的前提假設。 在實現方式上，當然就是要堅持平臺化的開發模式，基於需求分析提煉和規劃產品平臺，然後在產品平臺的基礎上，劃分產品系列，從而形成平臺產品或產品版本。在貫徹平臺化開發思想的過程中，應註意在差異化和通用性上取得平衡。可以說，復制是軟件利潤的唯一來源，所以軟件重用度的目標甚至要優先於差異化的目標，因為只要有足夠大的重用度，就能夠大幅度降低成本，企業只要在核心需求上滿足了客戶，再加上價格和速度的優勢，必將在競爭中處於不敗之地。 根據以往經驗，產品平臺化實施過程中將面臨各方面的困難。面對外部一些新的市場機會和客戶特殊需求，營銷人員總是傾向於把握新機會和響應客戶的新需求，如果高層在增長壓力下沒有確定相應的戰略原則去約束產品決策，則很可能使既定產品定位和產品化方向的努力付諸東流。即使公司界定了產品定位和方向，在具體操作時，到底用戶的某個特性是否需要加入產品規劃中，到底某個需求是否應當納入到產品功能開發中……如何在標準產品與客戶最終產品之間取得平衡，這仍然產品化開發模式下最為頭痛的問題。有些需求一旦納入標準產品之中，對產品可能是致命的打擊。在平臺化開發模式下，產品架構和模塊/組件設計將更多地考慮開放性、通用性和冗余設計，從局部來看會影響產品開發的進度和效率，尤其對新產品系列的第一個產品，將需要更長時間才能推向市場，這是企業必須認識和接受的代價，但換來的是後續產品開發速度的大幅提升。另外，產品平臺化開發還會來自內部高手的挑戰和開發人員習慣的阻力。高手們總是希望按照自己的思路規劃和開發產品，要讓大家都統一到一致的平臺架構和開發模式下絕非易事。開發人員也不喜歡條條框框，總是想弄點什麽新的東西，但平臺化則需要更多的標準化和規範要求。綜上，要解決這些難題，企業需要足夠的決心和耐心。 顯然，軟件產品化不僅僅是技術上的問題，然而技術也是其中關鍵的一環，包括架構設計、技術平臺、模塊化構造、數據結構、函數/算法、接口技術等。例如技術平臺的工作一般包括：

• 第三方技術平臺選型
• 技術使用研究，確定軟件項目技術路線和技術架構
• 制定開發規範，並形成開發案例和模板，掃清開發隊伍大規模開發時的障礙
• 開發技術控件，提高開發隊伍大規模開發的效率等等。

軟件產品化還與行業發展狀況、企業產品形態成熟度、企業管理成熟度、軟件技術發展、人員職業化程度等因素相關，所以軟件產品化和平臺化建設還要與企業研發管理、項目管理、人力資源管理一同推進。

（轉）關於軟件產品化，平臺化的思考