文｜輕流創始人兼CPO 嚴琦東

工程化水平偏低的“超級工程”

2000年前后，美國政府統計署的數據顯示：全球最大的軟件消費商（美國軍方）每年要花費數十億美元購買軟件，而在其所購軟件中，可直接使用的只占2%，另外3%需要做一些修改，其余?95%?都成了垃圾。

這種投入產出比是令人驚訝的，作為最具影響力的甲方所擁有的供給資源一定是行業頂尖，但是其最終交付的效果依然慘不忍睹。而回看建筑工程，1931 年建成的帝國大廈只花了 410 天，還是提前完工。寫個軟件還能復雜過蓋摩天樓？事情還真沒那么簡單。

難以遏制的系統錯誤

相比于其他工程，軟件代碼編寫的出錯概率更高。往往上萬行的代碼里面，一個字符的錯誤就會導致不同程度的軟件運行錯誤；隨著編碼參與人數的增加，這種排錯和質量管理的難度也呈現指數上升。為了解決不同來源代碼的沖突，我們甚至要花費遠超于編寫本身的成本。

人數增長的邊際收益逐漸趨于0

需求的量太大，團隊很容易盲目追求人數的擴張，然而往往人數的增長邊際收益卻并不理想，投入產出比是明顯下降的。隨著團隊不斷擴大，這種邊際收益逐漸趨于零。其原因是團隊變大，我們不可避免地投入更多精力在與團隊管理和協作溝通上，這些消耗就像“流沙”緊緊拽著陷入的人，越掙扎反而越深陷。

人力堆砌如果沒有伴隨著結構化的管理提升，將會是一種災難，不僅沒辦法提升項目效率，反而極大地降低項目質量。

“工程化”的字面意思代表系統化、模塊化、規范化，但我們無奈地看到大量的團隊處于小作坊階段。工程化程度低意味著企業更加依賴“個人”的發揮和貢獻，而很多時候“人”是不可靠和不穩定的。

優等生：汽車產業的工程化

不同的產業工程化程度是不同的，相對來說汽車行業的工程化程度在多年的發展下更為成熟。

汽車產業鏈主要由五大部分組成，包括汽車整車制造業，汽車零部件制造業，零部件制造相關工業，汽車服務貿易業和汽車產業支撐體系。

汽車零部件可分為“模塊-總成-組件-零部件”幾個層次。在汽車產業鏈的每一個環節都有完善的支撐體系，包括法律法規標準體系、試驗研究開發體系、認證檢測體系等。

完善的產業鏈分層是工程化的標志之一，將風險/質量控制在明確的范圍內，做好產業鏈打通和集成，可以大大提升項目最終的交付質量，縮短研發周期。

這幾年，IaaS、PaaS、SaaS 、iDaaS、aPaaS、bPaaS、FaaS等廠商層出不窮，國內的軟件開發供應鏈分層已經有了雛形。不過閉塞的產業環境還需要進一步開放，國產軟件工程化還需要很長一段時間的發展。

聊勝于無的CMM

軟件管理工程引起廣泛注意源于20世紀70年代中期。當時美國國防部曾立題專門研究軟件項目做不好的原因，發現70%的項目是因為管理不善而引起，而并不是因為技術實力不夠。到了20世紀90年代中期，大約只有?10%?的項目能夠在預定的費用和進度下交付。

在這樣一個大背景下，美國卡內基梅隆大學軟件工程研究所1987年提出了一份用于衡量企業開發能力的標準：CMM；

值得一提的是，全球進行CMM認證的企業中，80%來自于中國。

但是這樣一份流于形式、止于標準和規范的體系就好像給行業畫了一條條分數線，但是沒有告訴行業該如何達到這個分數線，真正意義又有多少呢？

VUCA時代的項目時效性問題

從1988年5月到1989年9月，求伯君把自己關在深圳的一個房間里，只要是醒著，就不停地寫代碼。困了睡一會兒，餓了就吃方便面。在這樣的一年四個月中，求伯君的肝炎反復復發，每次住院一個月到兩個月。在軟件開發最重要的時間，求伯君還把電腦搬到病房里繼續寫。

開發之苦不是病魔纏身，不是身心憔悴，而是孤獨。“有了難題，不知道問誰，解決了難題，也沒人分享喜悅。”求伯君在這孤獨中，寫下了十幾萬行的WPS代碼。

在改革開放前十年當中，除了求伯君之外，還誕生了許多在中國軟件史上有篳路藍縷之功的軟件英雄。比如嚴援朝在1983年推出CCDOS，走出了中文操作系統的關鍵一步；王永民在1983年發明“五筆字型”，專家稱“其意義不亞于活字印刷術”；吳曉軍41歲在1988年將CCDOS漢字系統升級到了2.13E版；“殺毒軟件之父”王江民于1989年推出殺毒軟件KV6；周志農在1988年設計完成《自然碼漢字輸入系統》；朱崇君在1988年首創中文字表編輯概念，推出CCED2.0版……

中國軟件產業在1988年前后迎來最初的繁榮期。許多軟件作者成為當時的明星奠基人物，也激勵了諸如雷軍、馬化騰這些正在大學讀書的學子們成為后起之秀。而中國軟件產業也迎來了百花齊放的歷史時期。

VUCA時代，后英雄時代

進入21世紀之后，我們越來越少聽到這些關于軟件領域的英雄傳說了。需求越來越復雜，變化越來越快，工業級的軟件生命周期在變短。悶頭寫一年然后驚艷整個世界的做法已經行不通了。

在如今的烏卡（VUCA） 時代，【易變不穩定（volatile）、不確定（uncertain）、復雜（complex）、模糊（ambiguous）】，企業是否足夠柔韌正變得越來越重要：

• 易變不穩定（volatile）
• 不確定（uncertain）
• 復雜（complex）
• 模糊（ambiguous）

從傳統的垂直化供應鏈、精細化供應鏈管理到柔性供應鏈管理、“互聯網+供應鏈”...... 從CRM到SCRM；從BPM到BPA再到RPA；業務管理的模式也在不斷適應這個變幻莫測的環境。

據Mendix最新的調查報告顯示，59%?的中國IT決策者表示，疫情期間的數字變革速度超過了他們的預期，93%?的中國IT開發者認同其企業的軟件開發速度需要加快。

然而越是快速發展/創新的行業，其標準化就越難做，越是沒辦法通過一次性的IT投入來完成信息化建設。（外包項目中的“一次性”代碼，屬于純粹的虛擬垃圾）業務應用級別的企業軟件保質期是非常短的，而且在變得越來越短，最怕的是：“還沒生產出來，就成了過期產品”。

清晰的產業鏈上下游分層對于縮短相應周期會起到非常重要的作用。在生產領域，我們探討柔性生產；在建筑領域我們探討裝配式建筑。那么，在IT軟件研發領域呢？

Gartner：組裝式應用開發

Gartner在最近兩次的技術趨勢報告中都提到了組裝式的概念。“組裝式”三個字從字面意義并不難以理解，就是將業務模塊或者軟件功能模塊封裝成一個個大小適中的積木，支持靈活搭配和調整，從而提升企業面對環境變化時的韌性。

理想情況下，應用層（直接被終端用戶用于業務活動中）的軟件開發將逐步邁向無代碼組裝的時代。面向業務需求時，系統設計人員只需要挑選合適的模組/積木進行裝配就行，就好像我們為新房子挑選合適的家具一樣簡單。你不用擔心家具的制造細節，只需要關注款式或者質量等實際表現是否符合預期即可。

圖片源于：Gartner

從此往后，我們可能不會再聽到力挽狂瀾的個人英雄傳說了。但是不再依靠“大衛擊敗哥利亞式”的個人英雄主義，也意味著產業在逐漸走向工程化。

企業管理者一定不能錯過的輕流

自從2015年開始，輕流就專注于將面向企業的應用層軟件開發進行無代碼化。通過7年的產品更新迭代，我們完善了一整套組裝式開發工具。我們將原本面向IT的頁面表現層和業務邏輯層進行了面向業務人員的重新抽象和設計，提出了6大引擎的開發框架。

可以將整體開發成本降低?90%?以上，并且縮短項目周期?80%?以上。

除此之外，輕流還提供了面向IT的輕代碼板塊，可以基于無代碼的引擎基礎提供額外的拓展能力以及集成能力。相對解藕的產品架構設計在滿足靈活拓展的前提下，保障可維護性。

獨立的數據分析產品：輕析，可供業務人員進行自助式的業務報表分析，是的數據平臺和業務平臺可以密切配合。

在面向不同角色推出的產品線背后，我們還完善了一整套的管理后臺，保障了統一組織架構、統一用戶池、統一權限體系的企業及配置能力。

總結

以上是生活随笔為你收集整理的别把“IT信息化”不当“超级工程”的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。