2023年【6000 字實戰(zhàn)分享】我在大廠做低代碼

【6000字實戰(zhàn)分享】我在大廠做低代碼class="size-fullwp-image-5791427aligncenter"src="vGrRtE7FiXzh7J7bbEey.png"alt=""width="900"height="420"/>

聲明：本文全部觀點，僅代表個人

前幾天的春季發(fā)布會上，飛書正式推出了業(yè)務三件套，其中就包括飛書自研的低代碼平臺：飛書應用引擎。

恰好至今年3月9日，我加入字節(jié)跳動整整一周年，也在飛書做低代碼產(chǎn)品整整一周年。在我們?nèi)ψ佑幸痪湓挘凶鲎止?jié)一年，人間三年，以此來形容字節(jié)跳動工作的繁重和壓力。

對我來說，這漫長的一年的確有很多值得回顧和復盤的地方，雖然在一年的時間節(jié)點上幾乎沒有任何儀式感，由于始終有下個重要的任務等著你去完成，但從個人成長的角度來說，這個特別的節(jié)點是值得紀念的，而紀念它的最好方式，莫過于寫下這樣一篇文章了。

我知道字節(jié)、飛書、產(chǎn)品經(jīng)理，都是互聯(lián)網(wǎng)圈子里的流量詞匯，在很多自媒體或是職場社交平臺，都能看到與之相關(guān)的內(nèi)容。但這篇文章并不會將過多的筆墨放在字節(jié)、飛書、職場、大廠的話題，我會更關(guān)注我在這一年的真實收獲，那就是在做低代碼產(chǎn)品這件事上的收獲。

為什么呢？

在字節(jié)跳動這樣一個超大型組織內(nèi)，每天都會有許多事情剝奪你的精力，平臺的光環(huán)也好、盛傳的裁員危機也罷，這些消息就像精神鴉片，吸食起來很爽，卻幾乎沒有好處。

相反的，你正在做的事情，事情背后體現(xiàn)的力量，力量背后蘊含的基本功，反而是每天勞碌的會議背后，更簡單被忽視的東西。對個人來說，這些東西才是我們在平臺之外所獨有的，真正屬于我們自己的東西，說白了：

這是可以帶走的東西。

一、關(guān)于產(chǎn)品

我在飛書做的是低代碼產(chǎn)品，雖然這個領(lǐng)域在大類上屬于toB產(chǎn)品，但同已經(jīng)比較成熟的企業(yè)內(nèi)部工具或SaaS產(chǎn)品來說，低代碼在國內(nèi)還是比較新的領(lǐng)域。

這個「新」體現(xiàn)在：

不同公司對低代碼的理解和策略可能都不一樣，沒有一個成熟而公認的從0到1的演進模式，產(chǎn)品的形態(tài)基本都跟公司對低代碼的定位有關(guān)；少有成熟的方法論可借鑒，只能從現(xiàn)有的產(chǎn)品去倒推底層的產(chǎn)品設計理念；圈子很小，5年以上的低代碼產(chǎn)品經(jīng)理很少很少，聘請候選人許多是B端其他業(yè)務領(lǐng)域的產(chǎn)品，或者是國外PaaS平臺的產(chǎn)品（如Salesforce）這些也導致我們在做這款產(chǎn)品的時候，也面臨了許多的不確定性。

在這種不確定下，必定會導致爭論→結(jié)論→推翻→爭論的無限循環(huán)，這對于一線產(chǎn)品經(jīng)理來說某種程度上是一種消耗和損害。

但另一方面，也正是在這樣的無限爭論中，我們才能對自己所做的事情有更多理解，更深刻地熟悉到它的價值和做事情的正確方法。

在這一年的時間里，我從完全不了解低代碼，到開頭能用低代碼平臺搭建應用，再到漸漸了解每個平臺背后設計的理念，這其中最深的感受只有一條，我姑且把它叫做：用戶分層。

二、用戶分層

凡是做產(chǎn)品經(jīng)理的，肯定會對一個問題特別敏感：我們的用戶是誰。而對低代碼產(chǎn)品經(jīng)理來說，這個問題又顯得略微抽象一些。

廣義上，低代碼的用戶是開發(fā)者，但開發(fā)者是誰，他們和企業(yè)的關(guān)系是怎么樣的，低代碼又如何為他們供應了不行替代的價值，這些都是我們在做這款產(chǎn)品時，需要去思索的問題。

經(jīng)過一年的探究，我發(fā)覺去討論開發(fā)者這個群體時，也需要用到用戶分層理論。

我最早接觸到用戶分層，是在美團做會員產(chǎn)品經(jīng)理的時候，無論是VIP體系，還是等級體系，本質(zhì)上都是按某種標準對用戶做分層，目的是在不同的層次下，匹配不同的功能和資源，從而達到整體收益最大化。

開發(fā)者也同樣需要并且可以分層。這個群體大致可以分為三個層次：

1.無代碼開發(fā)者

典型畫像是中小型公司內(nèi)的業(yè)務人員，他們的訴求是盼望通過一款好用的工具，快速搭建出一個業(yè)務系統(tǒng)。

這種業(yè)務系統(tǒng)一般是經(jīng)典的四件套：數(shù)據(jù)表格、詳情、表單和報表，例如最簡易的圖書借閱系統(tǒng)。包括全部圖書的列表、單本圖書的詳情、借閱申請表單和借閱數(shù)據(jù)統(tǒng)計，再輔以簡潔的審批流程和權(quán)限掌握，基本上就能搭建出一個最簡潔的圖書借閱管理后臺了。

大多數(shù)無代碼開發(fā)者很少具備寫代碼的力量，因此供應給他們的產(chǎn)品需要足夠好用，易用性需要足夠強，才能被他們喜愛。

詳細來說，在產(chǎn)品設計上，既需要保證肯定的抽象性，功能不能太定制化，否則就偏離了PaaS的定位，同時也要屏蔽開發(fā)者無需感知的功能細節(jié)。

以按鈕的樣式配置為例，對無代碼開發(fā)者來說一般需要的是封裝好的快速的樣式配置：藍底白字無邊框的按鈕，一般用在強提示場景下，例如表單的提交；白底黑字有邊框的按鈕，一般用在弱提示場景下，例如頁面的返回。

假如我們將按鈕的CSS樣式全部開放給無代碼開發(fā)者，他們可能會覺得沒有必要且特別難用，由于他們的業(yè)務系統(tǒng)對敏捷性要求沒有那么高。

但這樣的限制在某種程度上也同時限制了業(yè)務系統(tǒng)本身的天花板。

2.混合開發(fā)者

典型畫像是大型企業(yè)里的業(yè)務人員，他們一方面渴望一個好用的應用搭建系統(tǒng)，另一方面盼望這個盼望滿意肯定的敏捷性，哪怕是通過寫部分簡潔的代碼實現(xiàn)。為此，也要求他們懂得一些基礎的編程學問。

對大型公司的簡單業(yè)務系統(tǒng)來說，完全無代碼的搭建幾乎很難滿意自己的需求，而對公司內(nèi)的業(yè)務人員來說，完成比完善更加重要。

他們更看重的是能不能實現(xiàn)，其次再是體驗好不好。對他們來說，假如力量上無法實現(xiàn)，即使產(chǎn)品再好用，價值也等于零。

對這部分開發(fā)者，在產(chǎn)品設計時需要盡可能避開黑盒規(guī)律，盡可能白盒化展現(xiàn)。更通俗一點來說，從易用性動身，需要做一些規(guī)律封裝，但這種封裝規(guī)律需要在產(chǎn)品上展現(xiàn)出來，最終目的是便利開發(fā)者可以自主修改。

還是以按鈕的樣式為例，在產(chǎn)品設計時既要考慮將通用的B端業(yè)務領(lǐng)域閱歷沉淀為快速的封裝配置，同時這種封裝規(guī)律的底層應當是原子化的。

例如，對強提示場景下的「藍底白字無邊框」按鈕來說，這種封裝應當體現(xiàn)為「背景=藍色」、「文字=白色」、「邊框?qū)挾?0px」等原子化配置。開發(fā)者在90%以上的場景下不需要關(guān)懷底層的規(guī)律，但是需要修改時，例如「公司內(nèi)部的設計規(guī)范要求，強提示場景下的按鈕必需用黃色」，可以快速進行修改。

與無代碼開發(fā)者相比，給混合開發(fā)者供應的產(chǎn)品功能在天花板上是更高的，但由于暴露的產(chǎn)品細節(jié)也要多許多，因此在易用性的設計上挑戰(zhàn)更大。

但有一個原則我認為是需要達成共識的，對這部分用戶來說，他們往往并不喜愛黑盒規(guī)律，他們的訴求是：

我可以不用，但你不能不告知我。

3.低代碼開發(fā)者

典型畫像是獨立軟件開發(fā)商（IndependentSoftwareVendors）的IT人員，他們對平臺的要求是供應最大程度的開放性。他們?nèi)粘５墓ぷ魇腔诘痛a平臺供應的力量去做二次開發(fā)，對他們來說，大部分的應用搭建過程其實還是寫代碼的過程。

這類開發(fā)者往往基于低代碼平臺去構(gòu)建簡單的業(yè)務系統(tǒng)，包括CRM、ERP、HRS等常見的SaaS產(chǎn)品，都有可能是ISV基于低代碼平臺開發(fā)完成的。

面對這類用戶去做產(chǎn)品設計時，往往需要考慮更底層的通用性，有時候甚至是代碼級別的通用性。舉幾個例子：

平臺自帶的數(shù)據(jù)模型模塊和外部數(shù)據(jù)源，能否作為一個統(tǒng)一的數(shù)據(jù)查詢端口供前端頁面調(diào)用，這種狀況一般發(fā)生在系統(tǒng)遷移中。簡單的業(yè)務系統(tǒng)遷移許多時候是頁面先行，數(shù)據(jù)基座不變。

假如客戶公司有一套獨立的組件設計規(guī)范，那這套規(guī)范在接入低代碼平臺的同時，能否復用平臺已有的組件力量，包括屬性、樣式、大事、動作、方法等力量。

這些簡單的場景都需要產(chǎn)品經(jīng)理在設計某個模塊的時候，前置地去考慮更多開放力量的接入，而這對低代碼產(chǎn)品經(jīng)理的考驗是巨大的。

甚至，可能只有產(chǎn)品架構(gòu)師才能完成面對低代碼開發(fā)者的產(chǎn)品設計。

如上可得，即使我們的用戶都叫做開發(fā)者，但這個群體的角色、身份、所在公司不同，對平臺的訴求是不一樣的，沒有一套統(tǒng)一的標準可以描述低代碼產(chǎn)品應當怎么做，緣由也許就在這里。

三、關(guān)于方案設計

做低代碼產(chǎn)品，對需求文檔的要求特別高。

簡單的需求文檔，一般會有兩個階段：1、需求概要；2、需求方案描述。

在需求概要中，產(chǎn)品經(jīng)理需要描述清晰問題的背景和價值、競品調(diào)研、核心方案。

背景和價值說明白為什么要做這個需求，為什么要在現(xiàn)階段做這個需求。低代碼產(chǎn)品的技術(shù)簡單度很高，因此說清晰需求的價值無論對于資源的安排，還是后期的跨團隊協(xié)作，都是非常重要的事情。

在這一年的時間里，我也經(jīng)受過焦急忙慌地把需求方案趕出來，最終由于沒有對齊價值，導致在評審會上被質(zhì)疑，最終使得需求被降級或取消，這樣的事情對產(chǎn)品經(jīng)理來說是特別致命的資源鋪張。

在價值證明階段，最簡單消失的沖突是產(chǎn)品自身的規(guī)劃與用戶反饋之間的沖突。例如在很早期的階段，低代碼產(chǎn)品大多都很難用且天花板也比較低，共創(chuàng)客戶可能會有特別多的負向反饋。那這時候，究竟是先提升力量還是先提升體驗，就特別考驗產(chǎn)品leader的推斷力量。

許多人會說，就不能「既要也要」么。

假如資源充分，當前可以。

但經(jīng)濟社會的常態(tài)就是「資源永久稀缺」，否則就沒有成本的概念。當一個選擇肯定伴隨著成本時，優(yōu)先級的選擇就成了產(chǎn)品經(jīng)理每天要面對的最大沖突。

當價值確定了，該怎么做就成了其次個問題。

中國的低代碼市場整理來說起步較晚，2022年，Saleforce的PaaS平臺已經(jīng)承載了上萬個應用時，國內(nèi)的PaaS平臺可能還在襁褓階段。

對于后來者來說，追擊領(lǐng)先者的有力武器便是借鑒，你也可以理解為「抄」。我覺得抄并不是一件丟人的事情，當我們對一個新事物的認知真的很有限時，與其用并不科學的舊法則來套用，不如用現(xiàn)成的新法則來嘗試。

但這個過程中對產(chǎn)品經(jīng)理最大的挑戰(zhàn)不是搞清晰別人是怎么做這個功能的，而是搞清晰別人是怎么解決這個問題的，以及為什么是這樣的解決方式。

圍繞問題而不是圍繞功能，這是低代碼產(chǎn)品做競品調(diào)研的核心。

當然，正如用戶分層里說到，不同的產(chǎn)品針對的目標用戶是不同的，因此他們設計的理念也是不一樣的。

做競品調(diào)研時，找到值得討論的競品比調(diào)研本身可能更重要。只有你的產(chǎn)品和討論對象在目標用戶分層中基本保持全都，這樣的調(diào)研才更有參考價值。

最終就是核心方案，這部分的首要原則是解決核心問題的規(guī)律需要自洽。寫核心方案其實并不需要太多的筆墨，但難點在于推導過程是否規(guī)律自洽，是否是跑得通的。

在這一年的前半程，我的概要方案許多時候總會在若干個特定的點上沒有跑通，比如權(quán)限問題沒有考慮，跟其他系統(tǒng)的協(xié)作沒有考慮，跟正在開發(fā)的其他需求之間的沖突沒有考慮等。

因此要做到規(guī)律自洽，無其他更好的方式，只能不斷使用自己的產(chǎn)品，對產(chǎn)品的全部模塊都特別了解。這樣在一個簡單需求里，你才能在一開頭就知道涉及到的重點有哪些。

只要在一開頭沒有硬傷，后續(xù)的細節(jié)都是可以漸漸打磨的。

假如概要沒有問題，那更詳細的方案設計就基本沒有問題，只是依據(jù)不同產(chǎn)品經(jīng)理的水平不同，有的人可能寫得很細致，這樣開發(fā)過程中的溝通會更高效，有的人可能寫得比較粗略，那過程中的溝通就會更頻繁。

四、關(guān)于項目管理

雖然團隊里有PMO這個角色，但是許多時候需求的項目管理角色都會由產(chǎn)品經(jīng)理擔當，在簡單的需求里，項目管理力量有時候可能比產(chǎn)品設計力量更為重要，由于它確保了交付成果。

對于產(chǎn)品經(jīng)理工作的考察，大家都有一個共識，只有真正上線的需求，才算是一個產(chǎn)品經(jīng)理的成果，在此之前的全部內(nèi)容，都只能算是過程。

沒有一個產(chǎn)品經(jīng)理在寫簡歷的時候會說，我上一段工作經(jīng)受中共寫了多少篇需求文檔，一共包含多少個字。大家在聊的都是，上線的需求對實際業(yè)務究竟帶來了多少價值。

關(guān)于項目管理的標準流程，就不必多說了，在這里想共享一些推動大型簡單需求時，在標準流程之外的發(fā)力點。

1.前置溝通

雖然從流程上來說，需求在設計完后就是評審，但為了評審順當，是需要做許多工作的。尤其是對低代碼產(chǎn)品來說，由于這是個新事物，且團隊里的許多人可能之前就不是做低代碼相關(guān)的領(lǐng)域，因此在熟悉上對齊就顯得更為重要。

溝通的內(nèi)容與概要中的內(nèi)容基本全都，也都是做這件事的價值和大致思路。

有溝通就有分歧，面對分歧時，需要產(chǎn)品經(jīng)理供應足夠的參考信息，主要是競品的參考信息和用戶的反饋，在由于主觀熟悉不同而導致的分歧中，這樣的客觀信息反而能在求同存異時發(fā)揮更大的用處。

2.showcase

對簡單需求來說，最大的成本可能就是返工成本。為了避開返工，在流程中可以增加一環(huán)叫showcase，即面對研發(fā)、產(chǎn)品、設計展現(xiàn)冒煙用例，在提測之前將已有的問題盡可能暴露，這樣在研發(fā)階段中可以增加一個質(zhì)量監(jiān)督節(jié)點，確保最終交付的需求是符合業(yè)務預期的。

3.需求范圍管理

簡單需求往往牽一發(fā)而動全身，雖然B端產(chǎn)品不能像C端產(chǎn)品那樣快速交付持續(xù)迭代，但對于低代碼這個新領(lǐng)域來說，假如產(chǎn)品還在商業(yè)化之前的基建階段，我的建議是找到共創(chuàng)客戶，快速靈敏地交付獨立模塊。

對于低代碼平臺來說，只有真正能搭建出實際的應用，并經(jīng)受住真有用戶的考驗，它才算是一個合格的低代碼平臺，而平臺背后的產(chǎn)品經(jīng)理，也才算是真正的低代碼產(chǎn)品經(jīng)理。

因此，明確管理每個需求的范圍，在指定時間內(nèi)交付指定的功能給到用戶，接收真實業(yè)務場景的考驗，并拿到真實的反饋，可能才是低代碼平臺向前迭代的最踏實的道路。

五、關(guān)于低代碼業(yè)務

最終，聊聊我個人對低代碼業(yè)務的理解。

很早之前，我在讀吳軍的《浪潮之巔》時看到過這么一個觀點，假如某種技術(shù)對生產(chǎn)力的提升是10倍以上，那這個技術(shù)的誕生很有可能會顛覆某個領(lǐng)域。

例如從馬車到汽車的進化，從汽車到飛機的進化，每一個新物種的消失，都帶來了產(chǎn)業(yè)革命性的變化。

低代碼是這樣一個新物種么？很圓滿，我認為并不是。

至少在目前來看，低代碼對于生產(chǎn)力的影響，并不足以達到10倍以上。目前天花板級別的低代碼產(chǎn)品，也只能實現(xiàn)說「全部通過寫代碼而生產(chǎn)的應用，都可以通過拖拉拽+簡潔的代碼實現(xiàn)」，況且能實現(xiàn)這個目標的產(chǎn)品，屈指可數(shù)。

既然不是新物種，無法消失突變式的演進，那就必定要遵循B端產(chǎn)品已有的客觀規(guī)律，漸進式演進。

在團隊內(nèi)部的全員大會上，我向「飛書應用引擎」的負責人提過一個問題：假如說有一條原則需要全部的低代碼產(chǎn)品、研發(fā)、設計、業(yè)務人員都去遵循，那這個原則是什么？

答案照舊是：客戶第一