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

一、低代碼的流派之爭(zhēng)

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

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

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

今天，我們?cè)賮?lái)引入一個(gè)產(chǎn)品分析的經(jīng)典公式。

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

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

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

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

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

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

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

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

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

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

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

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

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

帶著這個(gè)使用路徑的實(shí)戰(zhàn)體驗(yàn)，讓我們?cè)俅位氐侥莻€(gè)公式。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

四、總結(jié)

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

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

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

題圖來(lái)自 Unsplash，基于 CC0 協(xié)議