編輯導讀：低代碼平臺分為兩種，一種是面向業務人員的，一種是面向程序員的。這兩個流派面向不同的群體，產品形態也不同。本文作者認為，低代碼平臺并不能解決程序員的效率問題。一起來文中看看吧。

一、低代碼的流派之爭

從低代碼誕生之日起，就有了渭涇分明的兩種流派。一派追求顛覆式創新，希望通過類0代碼的產品，直接觸達業務人員，打造出一種無須IT即可將業務數字化的全新體驗；另一派希望為程序員提供一站式的編程輔助，提高項目交付效率。

具體的各流派產品形態分析，可以參考我之前的文章《一文看懂低代碼的現狀、打法和挑戰》。

二、兩派低代碼提供的產品價值

今天，我們再來引入一個產品分析的經典公式。

產品價值=現有產品體驗+優化體驗-用戶遷移成本-用戶觸達成本。

由于這兩個流派的產品本就針對不同的用戶群體，而“用戶觸達成本”這個變量很大程度取決于企業DNA和渠道優勢領域，因此很難進行平行對比，我們再對這個公式進行一下簡化：

那么，這個公式里最重要的兩個變量就是“產品優化體驗”和“用戶遷移成本”，讓我們以這兩個變量為錨點來拆解一下這兩個流派的產品，分別為用戶提供了怎樣的價值。

首先，來看0代碼產品。主要對象是業務人員或B端產品運營，瞄準的是原本標準化的SaaS場景和一些SaaS尚未覆蓋，但由于投產原因也被IT忽略的長尾需求。

在我們實際產品推廣實踐過程中，由于瞄準的是用戶之前尚未被滿足的需求，提供了一種全新的產品體驗來如此高效的完成業務數字化，業務用戶普遍對此比較興奮，因此，“優化產品體驗”這一項可以加上1分。

由于提供的是一種全新的產品體驗，不存在客觀意義上的用戶遷移問題，但考慮到低代碼市場還處在較為早期階段，仍然需要投入較大用戶教育成本，因此，“用戶遷移成本”這一項可以減去0.5分。

現有產品體驗我們統一定義為1分，那么對于0代碼產品的“產品價值”得分就是：1.5分

接下來看針對程序員的低代碼產品，我們先來拆解一下這類產品的用戶使用路徑，就以通過阿里宜搭搭建一個相對復雜的業務系統為例。

第一步，定義頁面：拖拉拽組件，完成頁面構建（同時也定義了表及表字段）

第二步，定義流程：通過流程表單頁，拖拉拽事件組件，定義業務所需流轉流程

第三步，定義邏輯對象，及觸發動作：選擇組件屬性，綁定為變量

第四步，串聯邏輯：在JS面板，以函數方法的形式完成整個應用頁面間邏輯串聯

第五步，上線：點擊上線按鈕，完成應用的一鍵上線

帶著這個使用路徑的實戰體驗，讓我們再次回到那個公式。

“優化產品體驗”這一項帶來的提升主要體現在前端頁面搭建的提效，根據我們的實際對比試驗，就以標準表單頁+列表頁搭建為例，可視化拖拉拽相比代碼層級的復制粘貼，提效比較明顯大約4-5倍，我們來先記5小分。

但同時，這個新的路徑中也帶來了一些“負優化”體驗，主要體現在定義邏輯對象和邏輯串聯兩個環節。我們試圖搭建一個案件工單處理系統的過程中，寫了約500行JS代碼，定義了超過50個變量，每一次的定義變量都要經歷“選中組件”-“選中屬性”-“定義變量”-“綁定變量”的循環，操作效率低下的同時，由于變量較多，將變量與組件唯一標識對應也是非常讓人痛苦的，用我們直接上手前端開發同事的話來說就是“把節省的時間又吞回去了”，加上JS代碼編寫過程中的交互體驗以及無法實時調試等問題，這里需要再減去4小分

最后，開發提效低代碼產品“優化產品體驗”這一項綜合得分為1分。

“用戶遷移成本”這一項是面向開發人員低代碼平臺的主要減分項。傳統開發除了需要遵循企業研發管理CI/CD的制度規范、安全及測試相關要求，還有一個最重要的因素——集成開發IDE工具。

根據Stack Overflow2021全球開發者調查報告的結果，VSCode繼續蟬聯榜首，獲評最受喜愛的集成開發IDE工具。自2011年微軟邀請Erich Gamma開始孵化Monaco Editor（VSCode前身，2015年移植到桌面平臺后更名VSCode），到2018年VSCode首次登榜，走過了7年的漫長時光，這期間不斷進行著市場教育、產品用戶相互塑造的過程。即便在VSCode霸榜多年的今天，身邊很多Java開發朋友依然在堅定的選擇IntelliJ和Eclipse。由此可見，對于一款毋庸置疑的生產效率工具，要想完成用戶遷移的挑戰是十分巨大的，更何況Web端IDE還不得不面對一些瀏覽器性能的客觀邊界，行業龍頭Mendix也不得不選擇自研本地IDE編輯器這種相對“笨重”的方式，來對沖這個問題。

由此可見，出于對原有生產效率工具挑戰這一原因，“用戶遷移成本”這一項我們來減去5分。

現有產品體驗我們依然定義為1分，那么對于面向開發低代碼平臺的“產品價值”得分就是：-3分

從我們天使用戶焦點小組訪談中獲得的信息也同樣印證了這一點。

用戶表示“如果是以搭建一個重業務邏輯的復雜系統來講，前端頁面可視化拖拉拽帶來的提效放在項目的全景中不值一提，而其他的體驗相較于十分熟練的IDE工具，是非常令人絕望的”。

相較于0代碼平臺給業務人員帶來的“驚喜地”完整解決方案，低代碼平臺的部分提效以及伴隨的“負體驗”和巨大遷移成本，確實無法提供較高的產品價值。

那么，除了低代碼平臺，究竟應該如何給程序員提效呢？

三、程序員需要什么樣的提效產品

要想最大程度提高產品價值，我們還是要回到之前的公式，“用戶遷移成本”是效率工具產品的最大挑戰，無論你提供怎樣優秀的新體驗，都可能被遷移成本輕易的打回原形，因此面向程序員的代碼級提效工具最好是維持以本地IDE為核心的產品形態，盡量少或不對用戶構成遷移挑戰，以便于我們更好的在“優化產品體驗”條線進行發力。

這里列舉了一些程序員在項目開發中會面臨的關鍵節點，如果從一個全景視角來看，會發現有這樣的幾個特點：

• “神聚而形散”：從抽象的角度，研發過程的確逃不出這樣幾個關鍵節點，但針對不同項目特點、團隊規模以及企業研發管理要求不同，各個節點從工具選擇、產出形式都沒有明確的標準；
• “傻活比重不小”：再整個研發過程中，除了令人興奮的創作性工作，還存在不少重復的“傻活”。例如無趣的環境搭建、反反復復不知道寫了多少遍的通用樣式、常用接口。
• “依賴人治”：研發過程中代碼規范很依賴程序員的個人能力以及熟悉程度，人員流動造成的沖擊大

基于這樣的分析，我們對于要解決的問題和目標的產品形態應該有一個大致的概念了：

• 提高代碼復用、增強自動化，減少研發過程中的“傻活”。
• 通過模板化加強標準規范落地，降低團隊溝通及新人培訓過成本。
• 產品形態上要拋棄“平臺化”“一站式”的思想，從各個節點提效，追求累加式提升
• 對于單點解決問題的能力要足夠深入，能否覆蓋不同的項目需求

圍繞成熟的IDE為核心的開發體系，提供一套插件全家桶，最大程度達成提效目標，應該是較好的選擇：

• 代碼工程模板、服務框架：跳出單個項目的具體情況，將同類項目模板化，更好的落地代碼規范、架構規范，也免去了腳手架搭建的繁復工作。
• 組件庫、物料庫、Jar包庫搭配模擬器：在落地項目、模板、代碼級復用的同時，又提供了較高的靈活度，將原本需要反復編碼的“傻活”簡化為排列組合問題。
• 自動化測試、一鍵初始化環、AI輔助編碼：通過自動化的方式，進一步降低對人員能力的依賴以及對重復工作的成本投入

四、總結

相較于0代碼平臺帶給業務人員的“十倍改進”級驚喜的產品價值，簡單的一站式低代碼平臺很難滿足程序員對場景單點的深度需求，加之極高的遷移成本，使得這類產品的價值十分有限。

面向程序員提效的低代碼產品需要摒棄“平臺”的產品形態，應該以IDE為錨點，提供一套插件組合，在整個研發周期的不同節點上進行賦能提效，追求跬步千里的累加式提升。

本文由 @小博 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自?Unsplash，基于 CC0 協議