資訊

當年“你說什么,我都能實現”的軟件公司,后來都是怎么死的?

在?#“我,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. 開發技術控件,提高開發隊伍大規模開發的效率等等;

好了,就扯這么多吧,有些零碎,湊合看吧。軟件產品化還與行業發展狀況、企業產品形態成熟度、企業管理成熟度、軟件技術發展、人員職業化程度等因素相關,所以還有很長的路要走。邊走,邊看,邊改進吧。

我還沒有學會寫個人說明!

《MySQL主從不一致情形與解決方法》

上一篇

含光出鞘,鋒利無比 | 阿里第一顆自研芯片問世,最強 AI 芯片含光800發布

下一篇

你也可能喜歡

當年“你說什么,我都能實現”的軟件公司,后來都是怎么死的?

長按儲存圖像,分享給朋友

ITPUB 每周精要將以郵件的形式發放至您的郵箱


微信掃一掃

微信掃一掃
篮球比分雷速直播网