作者 | 輕流聯合創始人&CPO 嚴琦東

在當下的IT領域，低代碼/無代碼一定是備受關注的熱詞，然而低代碼/無代碼是不是偽需求？低代碼/無代碼是行業毒瘤嗎？低代碼/無代碼時代，IT開發者會失業嗎？······類似的話題討論不斷。

不過低代碼/無代碼并不是一個新詞，實際上，2014年研究機構Forrester就正式提出了“低代碼”的概念，這類平臺面向的是IT專家或者平民程序員，以快速交付應用程序為目的，解決傳統軟件開發模式帶來的周期長、成本高等問題；Gartner隨后用基于aPaaS的高生產力平臺（hpaPaaS）來命名這一類產品， Microsoft、Mendix等深耕低代碼頭部企業也逐步入局。

輕流《無代碼未來十大趨勢白皮書》（2022）

Gartner也曾預測到2025年，企業70%的新應用將由低代碼/無代碼開發。

目前行業內普遍認為低代碼包含無代碼，但我們通過觀察發現市面上絕大多數低代碼平臺更加適合有技術基礎的IT人員使用，而作為沒有IT基礎的業務人員卻很難上手；而我所在的企業輕流一直致力于無代碼平臺的建設，我們認為無代碼可以讓不會寫代碼的人也可以像搭“積木”通過拖拉拽的方式建立企業管理系統，從這個角度來看，無代碼平臺適用的人群會更加廣泛。因此，原先“無代碼是低代碼的子集”的觀點正在被解構，低代碼和無代碼的邊界也越來越明晰。

在這里，我們不去深入討論低代碼/無代碼的概念，毫無疑問的是，數字化背景下，業務與IT的不平衡的發展關系，引發了越來越多新的需求，而技術變革又會影響著企業數字化進程中不同角色之間的關系。

那么在數字化進程中，一方面企業不斷追求業務增長，另一方面低代碼/無代碼技術也在快速發展，而IT作為其中關鍵的角色之一，未來將何去何從？

我從一個故事談起。

01

信息化的“大公司病”

之前跟一個從事信息化工作的朋友交流，他所在的公司人數超過了1.2萬人，占去了所屬行業國內30%以上的份額。2021年以來，公司明確數字化將會是公司下一階段的重要戰略之一。公司有著150人左右的信息化團隊（這位朋友負責的團隊人數約50人）面對這樣的戰略決定喜憂參半，動力和壓力并進。我們針對企業進行信息化落地工作中的種種難題展開討論。討論過程中發現很多問題恰恰是具備一定信息化規模的企業才會有切身的體會，而這些問題也普遍存在于大部分的“大公司”中。

弊端一：核心系統運維難

該公司的系統是2015年開始設計，在2017年正式上線使用。5年的時間對于一個核心系統的生命周期來說并不算長，但是卻疲態驚現，老邁地走不動路了。

由于各種原因，團隊人員構成已經產生了很大的變化，最開始負責開發的同事已經不在了。項目初期的文檔維護不規范導致老舊邏輯缺失，難以澄清。新的團隊往往需要花費倍數的人力才能上手工作，團隊的排錯和修復工作都需要花費成倍的人力。

然而核心系統的穩定性往往牽扯到核心業務的正常運作，一個再小的錯誤都會直接導致不同程度的業務損失。所有的穩定性背后都是成本的投入，為了能夠保障這種程度的穩定性，一個大型的信息化團隊對于已有產品的維護和質量保障投入往往占去了超過50%的研發資源，這個數字隨著核心系統的復雜度提升而不斷攀升。

令人唏噓的是，穩定性所帶來的“業務損失”并沒有減少，而是以“IT成本”的形式出現在了財報中。

弊端二：信息化協作鏈路長，響應糟糕

大公司的“大”首先體現在復雜龐大的組織架構上。該公司超過1.2萬人，共有5家分公司以及分散在全國各地40家左右的實驗室的。為了服務這1.2萬人進行協作和管理，公司組建了150多人的信息化團隊；而為了維護這樣規模的團隊，每年公司需要支付總計數千萬的各項成本，堪比一個小型企業全年的營收。這樣級別的投入對于大部分公司來說都是難以想象的。

中心化的IT信息化團隊在企業內扮演了乙方的角色，承接各個子公司、業務部門的信息化需求。在資源有限的情況下往往出現互相擠占以及排隊現象，往往一個非常小的功能需求排期就動輒數月的等待周期。不僅是排不上隊，即便排上隊伍了，落地質量也差強人意。龐大的組織架構弱化了部門與部門之間的聯系，中心化的IT團隊離業務一線越來越遠，使得甲乙雙方有著巨大的信息差和理解差，這種差距直接導致了最終需求的落地效果差甚至無法落地。

這些問題在這家公司的集中暴露并不是偶然，在大企業中屬于普遍現象。大企業的信息化陷入了一個怪圈：“投入越來越多，效果卻越來越差”。信息化的“大公司病”就像房間里的大象顯而易見卻又難以改變，所有人都默默的承擔著，然后繼續負重前行。

02

“甲乙方”式的協同存在的弊端

生產資料的稀缺性以及生產工具的使用壁壘導致了甲乙方的協作模式。這個基本原理在“信息化”領域同樣生效。我們發現正是這種“甲乙方”的信息化協作方式的弊端，造成上述的種種亂象。

弊端一：甲乙雙方對于需求的理解有斷層差距

軟件開發是一項具備高度專業性的工作，其包含了兩項重要“任務”：

任務一：將抽象的業務需求設計為可操作的系統功能；

任務二：通過代碼將任務一的系統設計進行實現；

在過去我們非常關注“任務二”的專業度卻忽略了“任務一”中軟件的業務邏輯設計同樣具備專業性。大部分的IT開發者并不缺乏coding能力的專業度，但是缺乏對于業務需求/痛點的深度理解。大型企業的組織架構和業務流程往往龐大且復雜，大部分的IT開發者都距離業務一線非常遙遠，而業務問題同時具備廣度和深度，非實際經歷很難有切身體會。

IT開發者能夠意識到“需求理解”的重要性，但在大量的開發排期面前往往卻有心無力。這種差距導致甲乙方的服務落地質量得不到保障。服務滿意度較低。這種犧牲“開發質量”而追求“開發數量”的做法并不可取，但身處其中的IT開發者其中并沒有能力扭轉局勢。

弊端二：甲乙方的中心化協同缺乏響應業務變化的靈活度

VUCA時代，企業業務變化的周期被大大縮短。對于信息化工作的靈活度有了更高的要求，超過59%的中國IT開發者認同其企業的軟件開發速度需要加快。

然而甲乙方的協作模式下，企業內所有的業務系統需求，都通過一個龐大的信息化中心來完成，一個標準的研發流程包含需求梳理、方案設計、落地研發、質量測試、版本發布等等環節，每個環節都是專人執行。項目參與人數越多，協作難度越大。過程中的信息損耗、效率低下問題也是反復出現。各個業務部門對于中心化的排期資源搶占也變成了一種企業內的負和博弈，增加了不必要的成本支出。

這一切都使得響應周期過長，系統還未開發就變成了“過期產品”。這些都大大提升了信息化投資的風險，企業每年投入大量的資金進行信息化投資，大部分都處于無法明確收益比的情況。這也難怪大部分的企業主想做信息化但又不敢做。

面對這個現狀，我們需要做出改變。

03

做出改變：從“甲乙方”到“圓桌式”

圓桌十二騎士的故事深入人心。傳說中不列顛君王亞瑟（Arthur）所領導了這樣一群優秀的騎士，騎士們在戰場上沖鋒陷陣，在圓桌上議論國內事務。近代以來，圓桌形式的會議屢屢在關鍵的歷史節點中發揮作用，大大的加速了相關歷史事件的節點進程。

“圓桌式”代表著平等的對話、密集的信息交互、各司其職的配合，即模糊了“甲乙方”的邊界，也模糊了“生產者”和“使用者”的邊界。回顧歷史，我們可以看到各個領域的技術普及都是一場場的去“甲乙方”的革命。

從專業媒體到自媒體（模糊了內容消費者和內容生產者的邊界）；
從專業視頻到短視頻（模糊了視頻消費者和視頻生產者的邊界）；
……

技術和工具的門檻降低，使得使用者有能力參與到生產過程中，從而指數級地提升整體的生產力。

在剛過去不久的輕流第三屆無代碼探索者大會上，我們與國際知名數據公司IDC共同發布了新的系統搭建協作機制——圓桌式開發，它既不是依賴個人專家輸出、也不是傳統的甲乙方合作，而是一種更加扁平、敏捷的開發方式。在今年1月份輕流發布的《無代碼十大未來趨勢白皮書》和輕流的無代碼未來趨勢論壇中，輕流就預告了這種協作模式。

隨著無代碼等自動化技術的出現，我們欣喜地看到，源于“無代碼系統搭建平臺”的易用性和低門檻，“輕流”正在實現業務人員參與到信息化系統開發的歷史性轉變。越來越多的業務人員通過短暫快速的上手學習，完成了自身業務的數字化轉型。通過應用軟件技術的門檻降低，一種新的人才類型正在越來越多地出現在企業中，企業信息化的深度參與角色變得越來越多元，我們發現IT與非IT的之間的邊界正在變得模糊。

不管是系統使用者還是專業開發者，都可以通過各自趁手的工具來發揮自身的優勢在一個圓桌上密切協同高效敏捷地完成應用系統落地工作，這就是我們所倡導的——“圓桌式開發”協同方式，該方式讓各種角色有能力在一個圓桌上通過高度協同、各司其職共同完成系統落地。

04

圓桌式開發中IT人員的角色轉變

以無代碼開發平臺為基礎的圓桌式開發方式也將會改變IT人員在企業信息化中的角色。

從大包大攬轉變為側重于核心業務系統的開發

在過去，IT信息化協作中由于編程的壁壘存在，業務人員沒有能力參與需求落地。IT人員需要大包大攬所有的業務系統需求。而這中間80%以上都是非常簡單的系統修改。IT人員在核心系統的管理和各個業務部門零碎的需求之間苦苦尋求平衡，不僅資源分配困難，一線業務的滿意度也是非常低的。

通過無代碼平臺，業務人員也可以在自己的能力范圍內實現一部分系統需求，不用再苦苦等待排期，大大縮短了整個落地周期。而這個過程中，IT資源也被大大的釋放了，IT人員不需要在業務部門間疲于奔命，可以將更多的精力投入到核心業務系統的維護和激活中。

這不僅大大提升了IT的投入產出比，也提升了一線業務的滿意度。

從系統需求的執行轉變成信息化的技術賦能

圓桌式開發讓企業擺脫了純粹的中心化信息化，組成了一個個小型的開發圓桌。更多的業務人員能夠深度參與到系統的開發過程中。為了讓業務人員更好的開發系統從而為IT人員減負，企業需要在轉型過程中培養一批具備無代碼平臺使用能力的“業務技術人員”，這樣一種訴求下， IT人員將從一個業務需求落地的角色轉變為賦能企業內更多人有能力進行系統開發的角色。

IT人員通過頂層的權限架構設計，為不同的業務部門進行不同程度系統開發授權，支持業務人員可以更好的展開系統落地工作。

遇到業務人員不乏解決的復雜問題時，IT人員也可以通過專業的編程技能，和業務人員一起協同開發，賦能復雜系統落地。