編輯導(dǎo)讀：低代碼平臺分為兩種，一種是面向業(yè)務(wù)人員的，一種是面向程序員的。這兩個流派面向不同的群體，產(chǎn)品形態(tài)也不同。本文作者認(rèn)為，低代碼平臺并不能解決程序員的效率問題。一起來文中看看吧。

一、低代碼的流派之爭

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

具體的各流派產(chǎn)品形態(tài)分析，可以參考我之前的文章《一文看懂低代碼的現(xiàn)狀、打法和挑戰(zhàn)》。

二、兩派低代碼提供的產(chǎn)品價(jià)值

今天，我們再來引入一個產(chǎn)品分析的經(jīng)典公式。

產(chǎn)品價(jià)值=現(xiàn)有產(chǎn)品體驗(yàn)+優(yōu)化體驗(yàn)-用戶遷移成本-用戶觸達(dá)成本。

由于這兩個流派的產(chǎn)品本就針對不同的用戶群體，而“用戶觸達(dá)成本”這個變量很大程度取決于企業(yè)DNA和渠道優(yōu)勢領(lǐng)域，因此很難進(jìn)行平行對比，我們再對這個公式進(jìn)行一下簡化：

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

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

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

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

現(xiàn)有產(chǎn)品體驗(yàn)我們統(tǒng)一定義為1分，那么對于0代碼產(chǎn)品的“產(chǎn)品價(jià)值”得分就是：1.5分

接下來看針對程序員的低代碼產(chǎn)品，我們先來拆解一下這類產(chǎn)品的用戶使用路徑，就以通過阿里宜搭搭建一個相對復(fù)雜的業(yè)務(wù)系統(tǒng)為例。

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

第二步，定義流程：通過流程表單頁，拖拉拽事件組件，定義業(yè)務(wù)所需流轉(zhuǎn)流程

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

第四步，串聯(lián)邏輯：在JS面板，以函數(shù)方法的形式完成整個應(yīng)用頁面間邏輯串聯(lián)

第五步，上線：點(diǎn)擊上線按鈕，完成應(yīng)用的一鍵上線

帶著這個使用路徑的實(shí)戰(zhàn)體驗(yàn)，讓我們再次回到那個公式。

“優(yōu)化產(chǎn)品體驗(yàn)”這一項(xiàng)帶來的提升主要體現(xiàn)在前端頁面搭建的提效，根據(jù)我們的實(shí)際對比試驗(yàn)，就以標(biāo)準(zhǔn)表單頁+列表頁搭建為例，可視化拖拉拽相比代碼層級的復(fù)制粘貼，提效比較明顯大約4-5倍，我們來先記5小分。

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

最后，開發(fā)提效低代碼產(chǎn)品“優(yōu)化產(chǎn)品體驗(yàn)”這一項(xiàng)綜合得分為1分。

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

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

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

現(xiàn)有產(chǎn)品體驗(yàn)我們依然定義為1分，那么對于面向開發(fā)低代碼平臺的“產(chǎn)品價(jià)值”得分就是：-3分

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

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

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

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

三、程序員需要什么樣的提效產(chǎn)品

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

這里列舉了一些程序員在項(xiàng)目開發(fā)中會面臨的關(guān)鍵節(jié)點(diǎn)，如果從一個全景視角來看，會發(fā)現(xiàn)有這樣的幾個特點(diǎn)：

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

基于這樣的分析，我們對于要解決的問題和目標(biāo)的產(chǎn)品形態(tài)應(yīng)該有一個大致的概念了：

• 提高代碼復(fù)用、增強(qiáng)自動化，減少研發(fā)過程中的“傻活”。
• 通過模板化加強(qiáng)標(biāo)準(zhǔn)規(guī)范落地，降低團(tuán)隊(duì)溝通及新人培訓(xùn)過成本。
• 產(chǎn)品形態(tài)上要拋棄“平臺化”“一站式”的思想，從各個節(jié)點(diǎn)提效，追求累加式提升
• 對于單點(diǎn)解決問題的能力要足夠深入，能否覆蓋不同的項(xiàng)目需求

圍繞成熟的IDE為核心的開發(fā)體系，提供一套插件全家桶，最大程度達(dá)成提效目標(biāo)，應(yīng)該是較好的選擇：

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

四、總結(jié)

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

面向程序員提效的低代碼產(chǎn)品需要摒棄“平臺”的產(chǎn)品形態(tài)，應(yīng)該以IDE為錨點(diǎn)，提供一套插件組合，在整個研發(fā)周期的不同節(jié)點(diǎn)上進(jìn)行賦能提效，追求跬步千里的累加式提升。

本文由 @小博 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自?Unsplash，基于 CC0 協(xié)議