題圖：from unsplash
在經過一番靈魂鬥爭之後，我終於做出了一個自認為非常重要的決定。於今年八月，離開了自己熟稔的傳統軟件開發行業，加入了一家互聯網產品公司。時至今日，不知不覺，已經有一個季度有餘，趁著通勤路上的閒暇時光，梳理了一些感悟，期待能給同樣遇到瓶頸的同學帶來一些思考。作為一名資深的傳統型軟件開發者，我只呆過為數不多的幾家企業。在這些企業其行業背景幾乎截然不同，但其結局大體上可以稱為中國傳統IT產業的一些縮影。總體上可以分 成，項目型軟件公司，產品型軟件公司，和互聯網公司。
作為項目型軟件公司而言，也許開一家軟件外包公司從來不是老闆們的初衷。每位老闆心中都充滿了開發一款熱銷產品的美好憧憬。
然而，市場如同荊棘林，碰了無數次壁後，終於也得接受現實。利用自己的資源，終於利用有限的資源，殺出了一條血路，承接下各種大小不同風格迥異的項目後，卻由於各種原因，只能利用歷史項目的簡單堆砌，快速搭建框架，快速完成。在這樣的情況下，就可能存在一系列問題。
首先當初業務層面的問題。開闢業務之難，難於上青天。往往需要靠企業創始人的人脈度過創業早期的難關，在打開局面之後，需要通過多種途徑開闢新的業務。然而，軟件外包業務往往都是賣方市場，取決於誰擁有最靈通的消息，最快的響應速度和最紮實的人脈，而不僅僅是純粹的技術因素。甚至許多時候，很多項目都屬於內部消化，留給軟件公司的，就只是殘羹剩飯。
其次是項目越來越難做了。表現出來是項目過程中的需求不可控或需求蔓延。許多中小型企業前期接到的許多項目，往往有一個最大的特點，就是功能特別多。有的功能，看起來和主體毫無瓜葛，就是因為某個干係人，或者是業主，或者專家，或者公司老闆說的一句話，就加到系統中來，而開發者為了完成這個目標就得付出百倍的努力來填坑。而且由於不同的項目行業跨度可能比較大，每個功能具體是實現什麼，開發團隊是不一定清楚的，是從頭開始梳理客戶的業務，每個人都成為領域專家麼?沒有，這往往取決於項目的綜合週期。而週期，肯定是不夠的。於是拿業主當小白鼠是沒有辦法的辦法，畢竟是按照業主的想法做出來的東西，是對是錯?得看業主自己的理解。性能問題就不用討論了，反正只有那麼幾個人用，也不需要涉及高併發設計，一個單體應用，一個領域可以搞定的事情，沒必要做成分佈式部署了。一個項目中，一百個功能，只有二十個功能是用得到的，但是為了履行合同，必須花費最大的精力完成另外百分之八十的功能。有時候，負責任的乙方為了更好的打通業務閉環，在跟客戶進行頭腦風暴的過程中，往往會主動提出一些想法。然而，用戶需求就是籠子裡的獅子，一不小心放出來了，就得自己吃苦受累了。拒絕?有一位耿直的小夥伴因為拒絕客戶提出的變更而被客戶從現場驅逐令人不勝唏噓。所以往往只能委婉的拒絕，實際上大部分婉拒，客戶都會理解成你是一定會做的，只是短期不做而已，於是最終還是得做。在無法控制的需求蔓延之下，項目的開發週期被無限期的拉長，一個合同預期三個月的項目，往往需要延遲到半年或更久，更遑論曠日持久的維護週期了。
再其次會遇到的問題是無法對項目進行更加精細化的管理。對於項目型企業而言，往往必須建立完善的項目管理流程，通過制度來確保體系的良好運作。做過對日外包的都知道，對日外包項目往往會視合同額有一本非常厚的開發手冊。日本人對於工作的細緻入微的程度令人欽佩，哪怕是一個簡單功能都會實現流程和偽代碼等精細到每一行代碼。但是對於項目型外包公司而言，由於項目週期和合同額的限制，往往沒有足夠的時間來進行足夠的需求調研和文檔整理工作。為了快速完成某個項目，往往在既有項目基礎上進行迭代。
隨著時代的變遷，當代開發者所接受的教育背景，已經是極限編程或敏捷建模的思想。這兩種編程思想都是明確說明，要拋棄無用的文檔，通過代碼來保證軟件質量。而且，技術人員往往不會關注業務層面的事情，往往傾向於通過技術手段來解決問題。於是變成了四不像的地步，第一點就是，開發者看不懂需求文檔，第二點是所謂的領域專家，千金難找，第三點是開發者也看不懂領域專家們建立的統一模型，功能對不對，代碼寫得是否符合需求，依然取決於開發者和項目經理對於需求的領域和經驗本身。而且由於文檔的缺失，如果懂業務的領域專家或項目經理的流失，對項目將是迎頭痛擊。另外由於需求的不確定性，最終導致項目越來越龐大，越來越臃腫，最終成了一個奇葩。
與只能靠接項目為生的外包軟件公司相比，產品型軟件公司具備一定的優勢。他們或一開始已經擁有一個或多個拳頭產品，能夠面對一定的市場競爭。而這些產品，往往來源於一 些外包型項目中發現的商機。然後將需求提煉，再創造出新的價值，然後再以軟件的形式出售。當前有一種非常流行的概念，saas軟件即服務，已經成為一個非常巨大的市場。但是 對於大部分軟件企業而言，模式只是一個噱頭，該賣軟件還是賣軟件，只不過換了一種形式。以前是買軟件時，要麼自己採購，要麼服務器一起包，現在放在雲服務器上，或者同樣 也可以買軟件送硬件。產品還是這個產品，服務還是這個服務，檔次沒提高許多，實際上換湯不換藥。甚至依然是通過賣產品的形式做項目，最終依然走在外包這條路上。必須承認，基於互聯網的SAAS模式依然充滿了無窮前景，這也是令無數軟件公司趨之若鶩的原因，但是卻並非每家公司都有sales forces公司這麼好的機會。
對於傳統軟件企業而言，還會遇到的問題應該是資源的問題。一方面，客戶資源也是重要的資源，由於缺乏拿得出手的產品，承接項目往往只能靠關係。其次，完成項目的項目組織也是一種資源，如果企業無法維持持續的進步，最終無法逃避的問題是，企業組織的內卷化。優秀的人會最先無法忍受管理團隊犯下的各種弱智錯誤而離開公司，而那些中庸的人，或者技能很差的人卻顯然由於更好的忠誠度而得到了重用，於是，這也說不定會堵死其他新鮮血液加入公司的機會。最終，企業只能朝著更加昏暗的下坡路行進。能否力挽狂瀾，還得看老闆們究竟如何解決業務層面的問題，獲得一線生機。
隨著互聯網時代的到來，無論是哪種形式的軟件公司，都面臨來自互聯網的降維打擊，而且是全方位多維度撲面而來的打擊。
第一個維度是業務層面，也許某某某公司剛剛開發出一個設計優美，功能全面的辦公軟件，準備大幹一場幹出一方事業時，然後去找某某國企領導做推廣，然後，領導說，對不起，我們用釘釘了。某企業想立足於製造業做一個私有云，那麼，也會問到，為什麼不用阿里雲?做如果說，市場是黑暗森林，那麼阿里雲一定是手握二向箔的時空拾荒者，不聲不響間完成了對一個個傳統軟件企業的集體圍剿，讓大家每天都必須都得思考如何過冬。不僅僅是軟件企業，那些昔日靠賣服務器謀生的企業，本來已經微薄的利潤，也被這些行業攪局者破壞的一毛不剩。時空拾荒者們開闢出政務雲，企業私有云市場，讓傳統硬件企業走上了不歸路。
第二個維度是技術層面的。有的企業會說，巨頭們做的業務我們一概遠離，不沾染總可以了吧?對不起，不行。因為，人力資源也是黑森林的一部分，當你以為自給自足在自己的小世界裡經營一番獨門生意時，對不起，市場上的開發者都去幹互聯網了，你該從哪裡招到合適的人?互聯網企業集體狂歡，意味著傳統軟件企業集體悲催。在這個時代，要想不被革命，除非做一個真正閉塞的小圈子，例如某某類型的行業軟件，別人懶得抄的軟件或者沒辦法抄的軟件，或許還有一線生機。
有人會說，困境並非每家企業都得時刻面對，事實上往往這些問題都是在企業發展到了一定程度時才逐步暴露出來。然而，必須清晰的看到，大部分傳統軟件，哪怕是昔日的明星企業，走上了類似的道路。他們曾經業務源源不斷，而今卻逐漸開始老去，逐漸進擊乏力，開始吃老本。頭部玩家們由於歷史的沉澱，也擁有更加廣闊的資源，更能夠度過冬天，而中小企業只會越來越難。從某種意義上講，以傳統軟件例如項目型外包企業，總是有辦法承接項目，但是卻難以做大做強。也許市場上的定製需求是不會隨著時間和技術的遷移而消亡的，但是用戶的需求永遠會越來越高，越來越難以實現。對於軟件企業而言，也意味著需要付出更大的代價來適應用戶需求的升級和技術的更新換代。而且為了維持更好的團隊運作，還需要建立更加完善的薪酬體系，更加合理的管理制度，建立一支穩定的團隊，才能活下去。要想更好的生存，要與時俱進，學習互聯網時代的打法，才能有希望獲得新的轉機。
往期推薦：
- 基於SpringCloud的Microservices架構實戰案例
- 基於SpringBoot的Web API快速開發基礎框架
- 基於SpringBoot-Dubbo的微服務快速開發框架
- 如何從傳統軟件開發順利過渡到互聯網技術開發
- 怎麼定位自己在團隊裡的角色
- 你的經歷不一定都能變成經驗
- 那些會阻礙程序員成長的細節[7]
- 30多歲挨踢人要轉行的焦慮，是真的嗎
- 如何快速的積累經驗
- 學習新技術時你應當掌握的『最少必要知識』
閱讀更多 歪脖貳點零 的文章
