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