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