當年“你說什麼，我都能實現”的軟體公司，後來都是怎麼死的？

在 #“我，80後，曾經靠副業的收入買車買房”# 的評論區裡，有讀者問，十幾年前，圈內有不少軟體公司，規模大小不一，遍佈各個行業，但這幾年似乎都沒動靜了，他們還活著嗎？

我說，撇開純做 “勞工” 輸出的外包公司，或者有後臺背景的機構，除非產品化轉型成功，那些做專案的，尤其是那些曾對客戶信誓旦旦保障 “你說什麼，我都能實現” 的軟體公司，幾乎全死了，而且死相還挺難看的。

為什麼這麼說呢？

有句話說得好，能靠堆機器突破的瓶頸，通常都不是瓶頸，能用錢解決的問題，幾乎都不是問題，但可悲的是沒機器、沒錢。

在我已知的範圍裡，假如你不惜成本，基本沒有招不到的人，也沒有解決不了的技術問題，但這是偽命題，無論是網際網路公司，還是軟體公司，在技術上都是成本驅動，任何技術研發的投入必須對業務產生正向收益，反之，投入和收益一旦產生逆差，這場戲就很難唱的下去了。

本來嘛，你搞軟體的，距離 “一次投入，多次獲利” 這項標準越近，那就越賺錢，離得越遠，那就越虧錢。

十年前，我在某金融軟體公司工作，剛開始，一個團隊才2-3個人，只做一家客戶，只維護一套程式碼，你要啥，滿足你就是了，你高興，我也嗨皮。漸漸地，隨著客戶數的增多，研發人員的增多，變成了“一堆人，同時維護幾套程式碼”，這樣一來，Bug增多，客戶投訴越來越多，成本與效率/質量的矛盾日益凸顯。

面對這樣的困境，當時的老闆分別採取過3種應對措施：

• 一對一服務 - 專案制：多個團隊，多套程式碼，多套標準，服務多家客戶，但這樣一來成本又難以承受，時間一長，肯定資不抵債。
• 一對多服務 - 標準化：一個團隊，一套程式碼，一套標準，服務多家客戶，但客戶不買賬，客戶說我的需求都是個性化的，你別來某某標準來引導我，叫你咋做，你就咋做，不願意？那您走，我找別人家做。
• 一對多服務 - 產品化：一個團隊，一套程式碼，多套標準，服務多家客戶，透過技術與配置化的手段，利用SOA思想，打造自己的產品化平臺，但對技術投入要求較高，尤其是核心人才的依賴較大，中小型企業一般都很難留住這些人，只要他們一走，公司基本完蛋。

顯然，這是一個悲傷的故事，雖然主動尋求改變，但結果卻不盡如人意。

於是，業務每況愈下，抱怨也隨之變多，幸福感下降，效率打折扣，再加上甲方挖人，最後老闆頂不住，逃去了香港，團隊土崩瓦解，Game Over……

或許是天生愛總結的癖好，前幾年，我曾對 “軟體產品化” 這個話題進行過一些調研和分析，下面與大家分享一些思考。

關於軟體產品化的幾點思考

與其他行業類似，國內的大部分軟體公司都是從開發一、二個軟體專案起家的，而且專案規模和複雜度也不大，依賴某幾位高手（或創始人），他們能夠在客戶適度滿意的狀態下成功完成專案。

在我看來，面對這種定製化專案，成功的因素主要有如下幾點：

• 需求明確且範圍不大，變動不多：要麼客戶方需求明確，要麼企業對需求足夠了解，於是，雙方至少有一個人對需求有全面並且細緻的瞭解，雙方合作氛圍很好，這可以減少需求變更的量和避免衝突尖銳。

• 創始人都是技術或業務的高手，或者手下有1-2名得力干將。

• 專案使用的技術涉及面不廣，往往一兩個人兼而關注就可以把握。

• 一點運氣：正好選對了技術平臺；正好高手沒有離職…… 

然而，隨著時間的推移，企業承接的專案多了，人員多了，企業規模也擴大了。這時候，企業的內外部環境都發生了很大的變化。

先從外部環境來看：

1. 客戶行業發展迅速，需求在寬度、深度、變化頻度上發生了持續的變化。具體來說，要求軟體系統支撐的業務多了（需求寬度增加），併發使用軟體系統的人多了、時間長了，業務過程複雜了（深度增加）。

2. 競爭加劇，客戶需要經常進行業務的調整（變化頻度多了）。這種變化，往往會使客戶的需求管理成為一個專業、持續、並且工作量相當的過程。也就是說，企業具有需求管理與軟體開發進行分工的需求。

3. 軟體系統開發使用的第三方技術平臺種類多，且複雜，更新換代也快，如果軟體系統在效能、持續穩定性有要求，並且軟體使用週期設計要求滿足一定的年限，就要求企業對第三方技術平臺的發展進行跟蹤，並尋求有效應用的實際經驗（最佳實踐規範）。這樣，企業就逐步有將整合應用技術（含軟、硬體整合應用技術）進行專業分工的需求。

4. 市場技術競爭的重要性增加，關係競爭弱化，企業發現為了獲取合同，他們需要有研發能力的保障，並且要在技術競爭考察中勝出。迫使企業對客戶關注的重點專業技術進行投入。 

再從內部狀況來看： 

1. 企業同時運作軟體專案數量增多，但依賴於高手的專案模式沒有改變。各專案都需要高手來保障，如果沒有高手，專案就停滯不前，而且往往以非正常手段結束。

2. 隨著軟體專案的深入展開或軟體的升級換代，企業會發現有些模組的開發總是在重重複復地做，上一個版本做了，這個版本還要繼續做，同時開展幾個專案，都有類似的事情在重複做。但要直接使用之前的內容，又不行。

3. 技術人員總是有很多理由不去寫文件，如果不是一個人將一個模組從分析設計負責到程式碼，後一個環節的人總是得意於自我創新，並容易發生設計人員和開發人員的扯皮。

4. 軟體專案在前期開發時候是一路凱歌，到了快要交付的時候，卻又難產，總是達不到要求，改改程式碼重新測試，沒完沒了。而技術人員又非常辛苦。甚至出現部分或大全部返工現象。

5. 軟體專案開始的時候，誰也不知道什麼時候能完成，領導說三個月就三個月，半年就半年，實際上，沒有按期完成的，延期3-5個月是常事，1-2年也是有的，甚至不得不換班子重開爐灶。 

面對以上變化和問題，企業的解決辦法之一是延續原有專案的成功模式——高手主導的專案模式，即給每一個專案配備高手。但這樣問題來了，如果沒有那麼多高手，就讓把所有的專案壓在有限的高手身上。如果高手有限的話，實際上企業是將問題轉移給相對低資源能力的高手去解決。

當然，有限的高手也同樣可以使用同樣的手法進行問題轉嫁。

但這種解決辦法由於將所有的問題轉移到高手身上，企業管理就研發方面的決策難以形成明確的方向和目標，在研發方面只有用人的戰略。

尤其在網際網路時代，如何留住高手，如何在符合企業價值觀（薪資）與戰略的前提下，找到高手，都是世界級難題。

顯然，以上並非根本性的解決方案。一旦高手動盪，企業業務發展就受限，而且這種方式面臨的風險很大，過度的專案定製開發不但影響專案的交付進度和質量，也使成本居高不下，侵襲了企業本來就比較有限的利潤。

那麼，出路只能是走向產品化。

然而，軟體產品化是一件相當困難的事情，企業在各個方面都將面臨挑戰，並必須作出相應的改變。

首先，企業需要轉變經營理念和思路。

其實不管是專案化還是產品化，都要堅持客戶導向，但是就客戶導向的內涵和實現方式上，很多企業往往是被動地滿足客戶需求，甚至遷就客戶五花八門的需求。我們到底選擇什麼樣的客戶？這是企業成長中必須作出的回答。即便已經明確了這個問題，對客戶各種需求也不是不加區別的滿足，而是需要抓住目標客戶的核心需求和偏好，並認識到客戶只要在核心利益上得到足夠的滿足，他們願意犧牲一些個性化的特性——這正是產品化的前提假設。

根據以往經驗，產品平臺化實施過程中將面臨各方面的困難。

面對外部一些新的市場機會和客戶特殊需求，營銷人員總是傾向於把握新機會和響應客戶的新需求，如果高層在增長壓力下沒有確定相應的戰略原則去約束產品決策，則很可能使既定產品定位和產品化方向的努力付諸東流。即使公司界定了產品定位和方向，在具體操作時，到底使用者的某個特性是否需要加入產品規劃中，到底某個需求是否應當納入到產品功能開發中……

如何在標準產品與客戶最終產品之間取得平衡，這仍然產品化開發模式下最為頭痛的問題。比如，有些需求一旦納入標準產品之中，對產品可能是致命的打擊。

在平臺化開發模式下，產品架構和模組/元件設計將更多地考慮開放性、通用性和冗餘設計，從區域性來看會影響產品開發的進度和效率，尤其對新產品系列的第一個產品，將需要更長時間才能推向市場，這是企業必須認識和接受的代價，但換來的是後續產品開發速度的大幅提升。

另外，產品平臺化開發還會來自內部高手的挑戰和開發人員習慣的阻力。高手們總是希望按照自己的思路規劃和開發產品，要讓大家都統一到一致的平臺架構和開發模式下絕非易事。開發人員也不喜歡條條框框，總是想弄點什麼新的東西，但平臺化則需要更多的標準化和規範要求。

綜上，要解決這些難題，企業需要足夠的決心和耐心。 

顯然，軟體產品化不僅僅是技術上的問題，然而技術也是其中關鍵的一環，包括架構設計、技術平臺、模組化構造、資料結構、函式/演算法、介面技術等。例如技術平臺的工作一般包括：

1. 第三方技術平臺選型 技術使用研究，確定軟體專案技術路線和技術架構；

2. 制定開發規範，並形成開發案例和模板，掃清開發隊伍大規模開發時的障礙；

3. 開發技術控制元件，提高開發隊伍大規模開發的效率等等；

好了，就扯這麼多吧，有些零碎，湊合看吧。

軟體產品化還與行業發展狀況、企業產品形態成熟度、企業管理成熟度、軟體技術發展、人員職業化程度等因素相關，所以還有很長的路要走。

邊走，邊看，邊改進吧。