低代碼：趨勢向左 價值向右

低代碼：趨勢向左 價值向右

有句話是“拋開現象看本質”。

進入 2021 年，數字化帶來的趨勢幾近滲透到各行各業，而低代碼平臺和零代碼平臺，其創建的應用程序，由于可以隨著需求去輕松地進行定制和強化，也成為很多企業相繼選擇的工具，去幫助業務提高效率和降低項目成本。

正如低代碼的火爆并非空穴來風，繁重的數據對 IT 人員依賴強，同時企業內部相對割裂的系統讓數據聯通存在難度。而低代碼能夠有效降低對開發和運維人員的依賴，讓最明晰需求的業務人員去自行搭建，幫助企業快速建立“敏捷能力”。這讓低代碼成為重構軟件開發中不可或缺的一部分。

那么為何要重構，用低代碼重構能帶來怎樣的價值？客戶永遠是最了解業務實際痛點并最先給到啟示之人。

本篇文章牛透社通過采訪到四位低代碼/零代碼客戶，分別來自制造、互聯網資訊、建筑、地產四個不同行業，通過他們在低代碼使用體驗下的講述，去尋找共性和差異，推敲重構力量的答案。由于涉及廠商和客戶眾多，本文略有編輯刪減。

微制造：零代碼帶來的效率遠超10倍

口述者：微制造創始人——龍彪

微制造是專門為中小微工廠做的 SaaS。我原來在世界 500 強的制造業大公司工作，此前做的生產管理主要是經營生產，屬于流程再造，不太涉及到技術。但是我個人對技術非常重視，曾做過咨詢、硬件、嵌入式的硬件編程，再加上本身也是理工科背景，希望通過互聯網的技術能將管理落實到更好。

1. 為何選擇零代碼

最初我們嘗試自己做開發，成立團隊做 SaaS 的管理軟件。從底層寫代碼開始，這個過程不僅耗時耗力，而且我們做出的東西在每家客戶那邊各有區別，比如我們按照世界 500 強的最佳實踐去做，但是畢竟我們面向的是中國眾多企業的客戶，管理上并不那么規范，這時候是讓對方來適應我的軟件，還是我去適應對方就是個問題。

如果對方來適應我，會涉及到很重的咨詢問題，所以必然我們要做一些妥協，去適應客戶開發成本上又很高，就會導致我們在做商業推廣的時候很難受，單子接也不好，不接也不好。

由于客戶的需求多種多樣，拿一個標準品的 SaaS 很難去滿足個性化需求，尤其我們在這個方向屬于管理，每家特點不同就無法用一個標準產品來進行交付。

這件事如果我們自己開發，效率上無法滿足客戶需求，就開始嘗試用低代碼，此前我們自己開發時也嘗試用過低代碼，肯定這是個好方向，但也深知要想將低代碼一套系統做到完備好用，要花費很大力氣，而通過降低它的邊際成本自會下降我們的總體成本。

所以當時在調研市面上的低代碼工具，發現了明道云這款零代碼，就試用了一下，當時也有嘗試其他家，最后定下明道云是在 2020 年 6 月份。原因在于我們在前期試驗過程中，拿客戶此前的一些需求（那些需求點雖然不大，但我們自己沒辦法滿足），用明道云試過之后發現不但能夠交付，客戶反饋也不錯，因此下定決心用明道云來做總體交付。

2. 為何選擇明道云

當時幾家選型下來，明道云相對更均衡，整體的產品結構設計也比較符合我的設想。其實每個產品我也沒辦法花很長時間去體驗細節，只能是第一眼看過去結構是否清晰，光這一點我就覺得很多產品做不到結構清晰。

遇到過某家產品的圖表報表支持功能特別突出，但當我們在看審批和對數據的處理上，它的呈現方式是將其分離，把審批單獨抽出來放在業務流程之外，在我看來硬生生的把它割裂開是很難受的一件事，我認為對審批的最終結果是要反饋到數據業務表里，明道云在這方面比較符合我們對軟件產品的架構選擇。

3. 關于實質性的業務幫助

零代碼帶來的改變我體會尤深，對內能將我們多個職能多個崗位的人，像是前端、后端、數據庫、產品經理、測試眾多角色去做一個產品。用零代碼后，基本上一個人從頭到尾就能完成，相當于一人身兼數職效率非常高，原來一個迭代基本都要兩周以上，哪怕客戶要改任何一個很小的點，也要兩周后才能給到回復。

現在我們自己開發一個產品或者說交付一個項目，迭代周期甚至可以做到每天交付。當然對這個人的考驗也更大，因為他不僅要考慮實現功能，還要考慮用戶的體驗以及平臺特性。

對外來看，無需貼錢也能夠接原來接不了的項目，成本上也算得過來；另一方面迭代速度加快我們能迅速響應客戶需求，這樣即便產品本身有一定瑕疵，也不會影響到客戶滿意度。

原來我們盡心盡力，也才能兩個禮拜給客戶答復，現在只要客戶說出需求，我們能很及時地幫他去進行調整或增加。總體來說，對外讓客戶的滿意度、成本、交付都得到大幅提升。

比如我們現在服務三一重工，最早是我們自己開發的一個標準品，因為我們自己對工業比較了解又做得足夠用心，客戶體驗還是蠻好，但是客戶滿意的同時會希望我們再多加一些功能。

比如增添一些場內質量管理方面的功能，但是提完以后我們自己算一筆賬覺得相對困難，評估下來大概按照原來的開發方式，起碼是 4 個人花 2 個月時間才能夠交付，但是算下來人力成本很高。我們只做標準品，希望能把相同的功能賣到 10 個客戶那邊，這樣才能開始掙錢。

因為它的一些特殊點并不通用，這個時候我們只能算了，沒這能力暫時不接這個活，等我們后來用低代碼反過頭去進行實驗，拿原來不敢接攢下的需求去嘗試，試完以后發現原來 4 個人 2 個月的活基本上 1 個人 2 個禮拜就搞定。所以我的親身體驗，零代碼效率一定遠超過 10 倍。

4. 關于限制

低代碼像是一個粘合劑，因為它本來是云原生，開放性足夠高，可以接入很多其他外部的工具甚至于他不提供的東西。比如說跟算法相關，我們可以做自己的算法放在自己服務器，利用 API 調完以后把結果返回去，實現更多功能。

像明道云這樣的零代碼公司，并不需要自己把它做到特別完善，只要在它的業務流程里能夠 cover 住大多數需求，少部分需求諸如算法也可以交到外面來做，這部分就是他不具備但也沒必要去做那么完備，會有一定邊界。

還有一個問題，畢竟基于公有云很多服務是公有，當我們深度使用以后，會有很多并發問題。但我認為技術上是可以解決，頂多在前期增長最快客戶量又大的時候，技術上相對吃緊，所以我認為這是一個階段性的東西。我能夠體會到明道云在努力做這方面的調整，所以這其實是屬于低代碼廠商都會面臨到的類似問題。

5. 關于信任

零代碼是解決信任特別好的事，原來只能拿原型工具去跟客戶談，你是不是要做成這樣，我們畫個原型你先看對不對，對了我們再開發，原型要做出很好的交互效果相對麻煩，所以當時我們在取得信任最后百分之二三十的非標部分時很吃力。

用零代碼來建立信任就很快，只要對方有意愿做這件事，并認可我們的專業度，只要他說出我們標準產品里面沒有的需求，我們也會按照客戶需求迅速搭建，原來畫原型的時間現在都能夠把應用做出來。

所以客戶的信任度高，一個很重要因素在于響應速度，響應速度越快，客戶對你的信任程度就越高。低代碼的好處在于所見即所得，你有怎樣的需求可當場做一個簡易版，要想用戶體驗調整更好一點，可能多花兩天時間就能做出來，基本很少有哪家公司會認為我做一個這樣的產品，能夠在一周之內給他想看到的東西。所以基本只要一周以內給他，就已經超出客戶預期。

艾瑞咨詢：以 To C 標準打造 To B 場景

口述者：艾瑞咨詢信息管理部經理郝欣誠

我在艾瑞 2003 年成立時加入，在這里工作 18 年，在公司負責公司的技術體系，數據產品的研發，主要還是在做研究領域的數字化和大數據系統平臺。

1. 為何選擇零代碼

艾瑞嘗試低代碼系統的初衷，實際上是要做一個 OA 系統的升級改造。我們上一代的 OA 是 Sharepoint 做的，Sharepoint 的代碼系統盡管沒那么低，但也已經屬于低代碼思想，能夠滿足我們的需求。這一代我們想找更簡單的開發方式。

從我們的角度，OA 是為公司業務所服務，所以我們希望在能滿足需求的情況下，資源占用越少越好。但 OA 系統不可能一次成型，每家企業都有業務迭代，客戶迭代問題，很難說哪家公司要定做一個 OA，一次性能把所有需求談清楚去做完整方案。我們自己也是感覺兩年多時間沒做升級，積累的問題太多，就干脆再做一套，把現有問題解決掉。

我認為一個公司 OA 系統若做得好，會下降對郵件和 Excel 的依賴，我們當時內部勢頭反而是上升，郵件和 Excel 去完成更多的管理工作，還在用大量郵件溝通，而不是在一個有序的狀態下的表單溝通，就說明 OA 系統不能滿足需求。

我們在上一代 OA 沒切換之前，內部有些部門的業務目標管理用 OKR，有些用財務 KPI 指標，還有一些是以工作進度為核心的管理，這就導致用之前 OA 系統進行項目管理不能滿足需求。最后就變成大家都用 Excel，無論申請資源還是跑流程都寫郵件，相當于沒有系統。

2. 為何選擇明道云

其實我們一開始不知道零代碼，還是按照低代碼的開發模式在找產品，因為早年便結識明道云任總，我們就問到他們怎么看待這個產品。他們在聽完我們的需求后，告訴我們這個項目他們完全能接下來，給我們仔細看了別家公司案例是做成怎樣，為什么能很快的去滿足需求，我們覺得很有道理，這才轉向了以業務驅動的零代碼。

其實我們八年前就用過明道的產品，當時明道還不是智能表單，屬于工作協同平臺。但是轉向智能表單，是在我們參加完他們的產品發布會有了解之后，做選型的時候決定要用明道。

零代碼首先給業務帶來最明顯的提升是迭代速度。明道比傳統的 sharepoint 的開發時代快了太多倍，零代碼平臺嚴格來講不是開發平臺，而是配置平臺。

業務流程描述形式，開會時間即能邊聽邊做，流程怎么走，后面數據怎么出，都能在開會過程中完成討論，會議結束之后設置個自動化系統，先去跑一個版本，有問題能及時群里反饋。這個迭代速度甚至不能用里程碑來衡量，基本上就是隨時迭代，而且自定義的程度非常高。

第二是所見即所得的交付能力。以前做 Java 開發時，在前端、后端、數據庫上，需求方和開發者之間有一個周期性分割和思想溝通上的隔閡，開發過程實際跟交付過程處于割裂狀態。但零代碼平臺不存在這個問題，基本開會時間就已經在做，推快整個項目效率。

第三是 bug 比較少。由于屬于配置性開發，不屬于真正的代碼性開發，就不存在發布版本問題，最多只是邏輯誤判，而不會出現一個技術型 bug 崩潰導致流程走不下去。bug 少就能節約大量測試環節，甚至可以放心的讓用戶去直接測試。

第四是門檻變低以后能讓更多人參與開發。有些 DIY 能力強的同事看到開發過程后領悟很快，會主動要一個開發者權限，自行做應用給部門用，形成一個社區性開發，讓更多非專業的開發人員在內部做開發。這只有零代碼平臺才能實現，哪怕低代碼平臺，非開發人員也根本參與不了，所以我認為明道把這種零代碼做到很強是可以取代某些開發人員的工作場景。

3. 關于限制

限制是由于每家公司都會有自己風格的界面和操作文化所導致，比如這個字段只能這樣，最多只能改變它的某些屬性參數，但不能夠改變大的形態。

這種情況下所產生的自由度是會帶來一些功能限制，比如某個界面，傳統方法是點完某個按鈕出來一個下拉菜單，直接把這三四個信息合起來進行選擇，在一個小菜單上就能實現。但由于低代碼平臺界面控件選擇有限，所以它在操作界面上相對受限，只能適應明道的操作方案。

另外從編程角度也受到部分限制，比如審批工作流，有種工作流沒有設計過，這個時候我們會去找明道廠商詢問有沒有可能實現，可能出現的答案是：沒打算實現以后也不會實現；現在沒有但建議很好，后面的版本會把這個功能加上；再就是我們其實有這個功能，只是你不會用。

通常只有這三種回答，我們會感覺到還是要依賴廠商，不像定制開發可以任意提需求，基本都是回答可以做。從明道的角度來講，一定要找共通性，所以對我們的需求，也不是 100% 滿足。不過，我們提的需求里只有兩到三成他們解決不了，這不是他們的路線，大部分是可以實現。

4. 關于實質性的業務幫助

我們收到的郵件、聊天系統、Excel 越少，證明 OA 比以前要做得好，因為很多流程可以跑在上面。我們一個基本評估指標是去看老板的郵箱，去挖掘還有哪些流程沒有標準化，我們上海老板的郵箱事務性郵件，大概減少七成的樣子。

上一代 OA 系統沒有達到有效降低郵件的目標，反而帶來了一些負向增加，系統本身設計還有一些不合理的地方，有些東西沒考慮到選項不在，員工為了能讓單子通過，反而要發一個郵件強調是 OA 上面沒有選項。

這一代 OA 解決掉這個問題，基本員工說沒有選項，直接解釋一下為何要增添選項，只要我們評估下來功能正確，馬上就可以加。上一代 OA 系統基本不可能實現，增添選項得去找工程師，改數據庫，以及測試，所以低代碼還降低了溝通碎片化的問題。

除 OA 以外，我們現在把一些數據生產系統也移到明道上。我們做市場研究每天要處理大量數據，有一些要寫程序，有一些是由數據庫來管理。自從用明道的工具，DIY 能力強的同事就能用這個工具來幫助他處理數據，我們把諸多數據后臺的管理平臺接到了一個平臺上，只要有 API 和數據庫，基本都可以連上去。

5. 關于明道云產品使用體驗

其實我們也用過一些其他零代碼，對比下來會發現很多界面不夠精致，如果以 APP 市場所有的 APP 作為衡量標準，大廠的 APP 因為是為 To C 服務，產品的用戶體驗自然追求到極致。

明道的產品，相對更接近于大廠的消費級 APP 產品，無論是從 APP 端還是從 PC 端去瀏覽，不像是一個工業品。以往看到的給企業用的軟件，總有一種工業味道，諸如字段排列比較隨意，按鈕偏左一點還是偏右一點，其實也無所謂，在 To B 的場合大家都可以容忍。

明道在這方面做的至少比我接觸的幾家要工整精致的多，我認為這對用戶體驗影響很大。當然，其它家也各有所長，只是從界面上來講，他們選擇的是以實用主義為準的路線。比如精簡前端代碼，輸入數據時瀏覽器的效率更高，是明顯不走用戶體驗風而是走簡潔風，目的是為了操作響應更快。

國內有大量的精致的消費級網站、App 產品，我個人認可這種產品界面，現在我們已經被大廠的產品鍛煉到，如果不順著這個操作模式，就會覺得這是個問題。這件事已經形成一個標準思維，你必須 follow，這樣同事根據直覺就能學會大部分基本操作，不需要更多時間來進行培訓。

如果一個東西要反復講，會花費大量時間成本，我們以前 OA 有一張操作手冊叫常見問題，有六七十個問題。因為開發資源有限，一動就要動全身沒法優化界面，最后就將這 60 多個問題寫成文檔，這兩三年一直就是新人必問。這就不是一個好的系統，好的系統理論上只要熟悉業務就能看明白該怎么用。

所以明道云大幅緩解了我們對于基礎性問題的回復工作，我們現在對新人的培訓也著重在業務問題而不是操作性問題。

如果說服務客戶可能現在還不太合適，因為它的界面可能達不到商業化的服務客戶，尤其面對服務消費者，是要做花哨一點，用戶體驗也要再貼近于當時的場景，這個不適合用明道。但是管理包括給 To B 的客戶做服務，這個界面已經足夠友好。

6. 關于信任

我們本身是做 To B 的公司，做 To B 的生意大家都知道信任是基礎，價值是動力，有價值有信任的生意才能做。其實我們跟明道有淵源，是十多年的老朋友，當時明道云還叫梅花信息，兩家老板以前創業時候也一起共事過。

任總這個人從前做產品，就屬于不管做什么事，都會往消費級上面要求，哪怕他做的是一個工業品，也會往消費上靠，尤其是在技術產品上面，我們并不擔心明道在技術開發方面有一些低水平的 bug 或者低水平問題，我們基于對他十幾年的認識，了解他的做事風格，這與他個人的職業素養或者價值觀有關。

但我認為這只是個巧合，因為我們也做過其他產品的選型，假設沒有信任基礎的情況下，我們開始從頭做，我們的方法就是多家產品特點，表格化橫向對比，從邏輯當中去尋找價值，并在合作當中考察合作伙伴的品質。

有一定的信任基礎，讓我愿意親自花時間去了解這個東西。如果是按正常流程，我們會先把市面上的所有家找出來然后列張表，優勢劣勢列清楚排著做一遍后再進行選擇，但是有信任關系的話，是可以直接跳過一些環節進入到實質性環節。

7. 關于低代碼的看法

低代碼本身并不神奇，只是人類正常需求被更有效地得到滿足。標配就是軟件行業的開發標準得到提升，要求你具有更強的配置性。另外標準軟件可配置性能力的提升，吃的是以前需要定制軟件的市場，所以既然我看好低代碼，其實是不看好傳統定制軟件行業的發展前景。

我覺得低代碼其實并沒有走到革命性的遠，只是這本來就是標品軟件，該做好的事兒沒做好。以前軟件你要學要用也不會為你做出什么改變，或者說改變成本極高，現在將這個級別拉低，salesforce 20 年前就已經明白這個道理。

綠城建筑科技集團：讓精力專注于解決方案

口述者：綠城建筑科技集團有限公司，信息管理部經理，李楊

綠城建筑科技集團是綠城下屬的全資子集團，主要做建筑地產下游產品，例如裝飾、幕墻類，以及一些產業投資配套。公司未來 5 年規劃，主要是科技裝修方向，這也是母公司綠城中國給我們的任務。

1. 為何要搭建低代碼

我們主要是想解決重代碼下，外包人員不好控制的情況，我們作為地產下游的乙方施工單位，施工行業本來就是利潤薄的一個部門，整個行業對信息化投入比例都很小。當時公司也遇到信息化發展瓶頸，第一是不確定未來的發展方向，第二是不知道信息化該如何跟公司業務匹配。

那時候我和領導兩個人一塊出去考察，參觀下來發現同行還都是用重代碼，并未給我們帶來很多的未來方向啟示。后來一家航空公司的小伙伴，跟我們分享了他的想法，說我們可以去了解低代碼工具，這樣簡道云的產品進入到我們視野，但在和簡道云團隊對接初期時，我們也沒感覺它的優越性在哪里。直到慢慢看過一些案例，以及他們詳細解決方案講解，當時感覺找到了低代碼工具作為公司信息化的方向。

2. 為何選擇簡道云

我們 2020 年 9 月發現簡道云，開始對接和試用，今年 6 月正式使用，目前我們的綜合管理系統的產業配套板塊已經用簡道云完全覆蓋了，其他板塊也在嘗試覆蓋。

首先我們整個流程體系都在用帆軟的 FineReport 跟 FineBI 這兩款產品，這兩款產品一直合作下來，從高層到一線員工，對產品的認可傾向性很高。

第二簡道云可以和帆軟集成，從前端的數據收集，到報表和BI數據上的展現，整個鏈條上技術實現上沒有障礙。

第三也是最重要的一點，我們最看重的是簡道云的更新速度，基本上一個月兩到三次迭代。簡道云團隊會時常詢問我們的需求和建議，主動打電話回訪，讓我覺得這家公司是負責任的。這三點是我選擇簡道云最主要的原因。

我們在選型時期，也了解過很多其他家產品，沒有選擇其他家一個直觀原因是不提供試用。簡道云給我的感覺比較友好，不但提供試用還提供技術支持。別家產品一定要先購買才提供技術支持和試用，這其實已經給人一個拒之門外的感覺。

另外簡道云提出各個行業的解決方案吸引到我們。例如我們后面想研究離散制造這塊業務，花了大量精力想把這個行業做起來，一方面能讓我們成長，我們的經驗也能放到簡道云上進行推廣。簡道云在技術上給我們提供免費支持，我們是共同研究、相輔相成的一種關系，其他平臺方沒有這種優勢。

3. 關于實質性的業務幫助

最直觀的一點就是降低了我們信息化的投入成本，包括系統建設成本，人員投入成本。尤其是現場施工勞務人員的用人成本，重代碼的時候花大心思，投入了大量的金錢和精力，但信息化也做的并不好，這是主要的一個致命問題。

其次，它的建設周期比較短，常規一套項目大概需要半年以上才能開發出來。自從采用了簡道云，我們基本上一個月就能出一套應用、功能或模塊。成為一個良性循環，業務部門提出的業務需求我們快速響應，響應之后他們會主動的提更多需求，以前重代碼開發時，響應不夠及時，客戶也就懶得再去提，到現在大家都積極主動的來提供改進措施，通過信息化手段來落地。

我們正在上線的幕墻業務模塊，傳統用重代碼開發基本都要半年以上時間，而且做出來之后，業務方對我們做出來的這套軟件系統也不是特別滿意，有很多的吐槽點，比如我們的動態成本，在重代碼的時候一直沒做出來。

上簡道云之后，7 月 12 號正式開始立項調研開發，今天已經開發測試完，下個月 10 號就正式上線。除去中間一個月疫情的時間，實際干活時間也就一個月左右。

第三個是需求變更少且容易調整。我們在用簡道云開發時，就發現過一次需求變更，當天就將它調整過來，不會影響到框架業務。

第四個在數據上，通過通用的接口來對接我們的數據庫，避免通過Excel手工干預數據的大量重復工作，極大提高上線速度。

在建筑行業內沒有一家企業能做到完全的動態成本，我們在用重代碼的時候也講不透，這是我們行業的一個關鍵痛點。

上了簡道云以后，我的研究方向是想用簡道云工具來搭建實現我們的所有過程動態，包括投標成本、清標成本、過程成本，將這三個維度作為指標性參考來落地，對于我們后期預警以及計劃具有很好的參考性。

后續我希望這個部門變成生產力部門，輸出我們的行業解決方案和行業經驗。不單單是建筑施工，而是多業態復合型企業，每個人帶課題去研究綜合性多業態的解決方案，讓我們的信息化部門也可以產生效益。

4. 關于限制

長期使用之后，我們發現簡道云平臺能解決一些標準的、通用的業務邏輯，比如制造業 CRM 客戶管理，而解決行業或企業定制的需求還有困難。

例如我們建筑行業 BIM 、CAD、圖紙設計這塊專用工具，簡道云還不具備這類能力，后來我們只做了一個 CRM 的展示，BIM 還是接我們的專用工具。因此簡道云還不能夠去覆蓋專業上的工具，只能服務一些流程上的業務。

5. 關于改變

行業經常說技術不懂業務，業務不懂技術。現在我們可以完全將這個拿掉。業務部門最了解需求，那想要什么需求自己畫出來之后，由技術去發揮技術力量。我們之前做了估算，從人力上來講，以前我們開發人員需要配兩到三個，現在一個人就能做出相同內容。

現在公司整個層面對信息化的信心也高，信息化人員工作方向更明確，以前信息化更像是一個部門工具培訓的邊緣部門，現在從整個公司層面得到改觀。

在團隊建設上，以前我們的UI表單都是由技術人員構建后再將它畫出來。現在業務部門想要什么自己來畫，我們信息化人員只幫他去做數據邏輯關聯上的底層事情，更多的精力就考慮放在對部門管理、公司要求、行業還有哪些難點，更多去關注解決方案的事情，對我們來講也更有意義和價值。

6. 關于信任

為什么對簡道云有這樣的信任，一開始我也不了解簡道云，不了解帆軟，因為集團母公司在用，我們也就跟著在用 Report。我們是在跟簡道云技術人員對接過程中，遇到技術問題請他們幫忙時，他們響應速度很快，所以信任是在這個層面建立的，可以放心的交給他來解決問題，這是我的主要觀點。

因為我們的業務基本上都是 B 端，用簡道云搭建我們的業務系統，可以縮短開發和項目時間，產生的良好效果能影響到我們整個綠城的體系，包括我們下游的一些客戶，以及 B 端供應商，他們看到我們使用低代碼獲得的巨大收益，會把我們樹立成標桿來學習。

7. 關于低代碼暢想

未來 90% 以上的中小型企業會使用低代碼搭建自己的業務系統，特別是對信息化投入不高的小型企業，低代碼覆蓋率高且推廣起來會很快。

因為低代碼具有開發周期短的優點，信息化含量高、投入高的大型企業或是跨國性公司，也會適當采用一些低代碼的開發方式，我們的母公司就用到簡道云去實現某一塊功能。

我覺得每家公司都在逐漸意識到低代碼的優勢，其實我們不算走的很靠前，有很大一部分企業已經走在我們的前面。去年我們還很少聽到低代碼的聲音，而今年身邊一些同行業的競爭對手都在陸續嘗試使用低代碼。

富力集團：低代碼是打開傳統開發的黑盒子

口述者：富力集團CIO 馬劍

我們是一家綜合性的房地產，以開發房地產為主營業務的集團型公司。富力在業務發展中追求多元化的目標，在酒店、商業文旅、醫療康養，包括設計建造等領域都有涉及。

1. 為何選擇得帆云

2018 年底，我們內部就已經在看應用開發平臺，包括一些技術走向，只不過當時市場上還沒有很明確的概念和產品。后來在我們把周邊一些配套體系逐一構建后，進入到平臺選型，對比了行業內一些不同廠商，正式定下跟得帆合作。

作為用戶來說，從以往IT建設的經驗教訓來說，我們希望它本身具有融合性又有開放性。選擇得帆其實有優點也有缺點，我們相對看重的是他們的團隊。

得帆是一家技術風格較為鮮明的公司，包括整個團隊在解決企業內部特定的復雜問題上具備很多經驗。他們在關鍵方面的提升能力，也符合B端企業真正在技術平臺落地時所面臨的一些困難需求。

第二個它本身的開放性沒有太多的生態綁定，能夠從我們企業的角度去實現與其他體系的結合，比如服務的治理和 API、流程和用戶體系的集成。

第三個非常重要的方面，是需要從客戶那里積累大量經驗，這方面得帆實踐經驗會更成熟。我們所了解到得帆在很多客戶這邊，并不是以賣產品高溢價的方式，我印象里一直記得張桐總所說，如何評判成功項目：一是能收回錢，二是有后續合作(二期三期），三是能帶客戶去現場參觀。我覺得這三方面是蠻實在的一種說法。

2. 關于上低代碼的初衷

本身低代碼要解決的是應用開發問題，如果從整個數字化轉型或者是管理的角度，解決的又是一個效率問題，如何將現在不確定的業務在短時間內更好的給到用戶，給到這個公司一個快速響應，解決的也是一種業務隊伍變化速率上的理解問題。

在富力我們并不是叫低代碼平臺，叫做應用開發者體系，低代碼是其中一環。現在整個的應用開發很大程度上是基于我們的各種多端的應用，包括基于互聯網的應用。

這種情況下我們需要考慮，第一我們要有云計算的基礎設施配套，能夠支持基于現在原生的技術框架。比如現在整個的 docker 容器，能夠便于我們最終在應用實踐的形態層面，更好的適應現在這種模式。

第二需要在開發的整個的供應鏈條上進行拉通，包括 devOps、CMDB、這些要能夠跟本身的開發工具去進行拉通和聯動，它不是單一存在。

第三在基礎網絡安全層面要構建相應的能力去配套。要考慮到用戶在使用應用中，會通過多端多鏈路的任何地點任何端去使用你的應用場景或功能。

所以除了可見功能之外，還需要有很強大的一種公共或者是共享服務能力，去將下層各類后臺系統的內容進行一定封裝改造，形成組件化的服務，以后低代碼可能最終面向的是能夠構建應用服務的市場。

3. 關于實質性的業務幫助

一種是平臺的建設。

第二個是我們一些示范性的應用，也跟我們自身對于以后像特別是這種在企業中間還有其他的一種能力或者組織的轉型有關系。

真正引入低代碼之后，最大的影響實際是建立在組織相應的一些轉型基礎上。低代碼跟用戶溝通和設計的體驗更好，會加快項目本身的成果孵化。能夠在用戶需求和預期上拉齊，對項目的風險控制，包括開發質量，以及整個的迭代周期都能起到促進。后面也會在相對有規范的方式下，注重原來專業化工作的縱深發展。

很多時候用戶在使用中的問題包括新需求，要有一個很長的周期去解決。現在有了低代碼和我們自己相關的研發體系配套，只需重點關注核心工作，把作為專業角色的能力去更好外延。所以我們并不是關注純粹一個點上的問題，而是整套體系，在滿足業務變化上更高質量的去理解和實現客戶需求。

我們現在重點放在 iPaaS 和 aPaaS 上。iPaaS 層面我們更多是做集成能力相關，aPaaS 主要用于應用構建和共享服務的構建。

解決具體應用開發上面，第一怎么在整個開發的過程，對于角色或者是組織轉型上起到一個推動作用，讓大家重新定位和改變自己的工作方式，包括提升工作技能。

第二個是應用開發本身，能更精細化的管理整個產品的交互過程。結合我們自己研發體系，包括整個 devOps 的供應鏈，能夠打開我們原來傳統開發過程中的黑盒子，清楚的看到整個軟件產品生產過程，并進行更好的把控。

第三個是我們在體系下面也在做相應的軟件開發規范，去改變后邊對于供應商的一些生態結構。前面關于設計大的原則把控我們已經足夠清晰，就能找更多價格低廉多種類的供應商去參與到項目中。

4. 關于限制

其實我覺得任何工具，任何軟件都有自己的邊界。再去選擇一個東西的時候，一定不是說因為看到了低代碼，所以要去選低代碼。首先要自問想要解決什么問題，現在轉化成想達到的結果。

如果說現在有什么不足，我認為限制就是短時間里大部分沒有業務性的解決方案，缺少一個業務模型，企業若沒有積累沉淀自己的業務模型，低代碼就只是一個小場景化的開發工具；而企業有相應的業務能力和業務積累后，就可以用低代碼去進行相對復雜的業務應用重構。但通常低代碼沒有，這是一個普遍問題。

第二個就是圍繞這個基礎，可能有一些特定的應用場景和界面交互的方式構化。這些是原來應用廠商積累更深的地方，低代碼還沒有達到這個程度。

所以主要還是看人，它的缺點在于自身對于它的定位，還在于客戶的一個選擇和考慮，就怕是錯用，或者把低代碼的預期和價值抬得過高。不管是IT用戶還是業務用戶，在面對新概念的時候容易產生一種誤區。特別像低代碼技術性比較強，很多時候對于 IT 用戶沒法甄別。

5. 關于信任

不管是得帆跟我們合作，還是我們再去服務自己的客戶，都是首先要誠信，因為沒有用戶的信任想做任何創新都不能夠持續。

如果從IT的角度，很多公司在提科技以人為本或者科技向善，這里面最核心的就是說通過你的服務過程和產品體驗。

另外在合作的過程中，對技術的信任也至關重要，大家要誠實講出能做什么不能做什么，這個問題其實不必回避，不能為了銷售行為去刻意夸大，永遠不要忽視用戶的判斷力。

所以在跟客戶溝通時不是在秀自己多好多強，讓別人取得信任的前提是要傳遞價值，這個價值是基于別人需求的價值，要先看到別人的需求和你傳達的東西是否匹配。

6. 關于低代碼未來發展看法

我覺得這個東西一方面是要通過一些新的概念，去思考一些新的價值，概念可能會帶來一些新的思考和創想，它不完全是壞的，但需要審慎一點，去看到它的本質和核心，解決問題才是關鍵。以前講不要拿著榔頭去找釘子，首先應該要去明確想解決的問題。

我認為低代碼是階段性的技術發展產物，以后會以不同的技術形式解決問題。現在低代碼能夠做應用、做場景、做服務，但當以后應用場景、服務觸點、和形勢發生變化后，需要有新的技術，現在的低代碼就不能滿足。

比如說最近看到像微軟的 Hololens，它就是基于 VR 、AR 或者 3D 的一種場景來進行交互。但是低代碼的生命期應該會蠻長，現在剛好處在炒作期，企業客戶需要仔細甄別，也需要實踐過程中能夠真正運用得當。

我覺得以后大多數公司都會在自己的產品用到低代碼，就像以前的 Java 架構，現在的云原生的支持容器架構，以后低代碼會成為一個基本能力。但是基本的能力不代表著誰都可以做的很好，而且在企業的環境中間，不希望被生態綁定。

其實我覺得現在還是缺少一個真正能夠得到用戶信任有號召力的平臺。但市場是多樣化的，就像有很多大的云服務商，自己也提供云計算技術、以及 IaaS、PaaS，包括研發生態。

未來企業可能會將多種能力進行組合，我覺得這種生態意味著大家不會偏信某一家公司，而是會綜合更多不同公司最好的能力來做組合。我始終認為低代碼是一個階段性，會在其他技術的推動下發生新的變化。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。