2021年11月6日 – 11月7日，人人都是產品經理舉辦的【2021產品經理大會?深圳站】完美落幕。用友網絡助理總裁@劉鑫 為我們帶來了精彩的分享，他分享的主題是《工具型產品經理的思考》。添加大會小助手豆豆（微信號：13265455310），回復暗號【031】，獲取本場嘉賓分享視頻回放，觀看完整演講。

大家上午好，簡單介紹一下個人經歷。目前我就職于用友，另一個身份是APICloud?的創始人，這是一款移動應用開發平臺，也是云上交易平臺。

今天我所分享的核心主題是低代碼。這個詞近來大家也聽說得較多，為何低代碼近兩年這么火？它跟企業的關注點、落腳點有緊密聯系?？梢韵嘈诺氖?，低代碼起碼還會再火三年，因為到今天為止，低代碼在國內仍沒有一個有效的、真實的邏輯。

今天我便會從一款低代碼產品設計工具的誕生，來分析整個產品的設計思路。

用友有一條產品線，叫YonBuilder，它可以助推BIP 商業創新平臺的完善，起到低代碼前置和展示的作用。今年用友并購了APICloud，也表明了用友想做低代碼的決心。不過Gartner的分析師更傾向于將低代碼說為輕量代碼。

相信大家都聽過MADP和LCDP，這兩個平臺之間有什么關聯？從過往Gartner的一個報告來看，左側MADP象限里涵蓋了一些公司，如Microsoft?PowerAPP等，因此這些今天聽說過的低代碼開發平臺公司，他們也有可能同時存在于移動應用開發平臺的象限之中。

右側即我們常見的低代碼中臺。二者緊密相連，假如你是一個低代碼開發平臺，那你也會是一個移動應用開發平臺。

因此我們會發現，當我們訪問Mendix或OutSystems網站時，對方除了說明自己是低代碼平臺之外，還會說自己是移動應用開發平臺。

此外，低代碼有沒有標準？可能現下大家相對直觀的感受便是，基本上所有軟件公司都會說自己為低代碼、甚至無代碼公司。但其實低代碼有自己的相關技術標準。從Salesforce代碼開發平臺來做分析。它主要由三個板塊組成：

1. aPaaS heroku；
2. MADP lightning；
3. Marketplace AppExchange。

綜上，低代碼平臺需要涵蓋三種能力，即aPaaS能力——底層云端服務器的能力、前端偏重移動開發平臺的能力。而在以工作流的方式操縱了底層的aPaaS能力以及表層的MADP之后，便形成了最終的低代碼生態，或者是應用開發市場。

這三個方面涵蓋之后，可以起到什么作用？

一、MADP/LCDP都是為了RAD

低代碼本身需具有圖形化、可視化、流程化的操作能力，主要應用于移動端產品。

企業需求正在逐漸變化，從最開始IaaS需求轉變為PaaS需求，再過渡到RAD，即快速應用開發平臺。不少企業近幾年選擇上云，會發現一個直接問題，即將企業的IT系統從內網移到外網、或者移到云上，似乎并不能解決核心問題。

而中臺的本質即PaaS，到今天不少企業也發現：上了云、上了IaaS，中臺也做了，但是核心問題仍舊沒有解決。這就要求我們發現企業所想解決的問題本質為何：即不管利用中臺或其他基礎的云，產品一定要將滿足所有業務需求應用開發出來。

再倒推來看，企業上中臺或上云，核心目的即將最終應用開發出來，這也是近幾年低代碼這么火的原因。

因此關于RAD：無論IaaS或者PaaS，無論上云或者使用中臺，都是過程而不是最終的結果。

而關于APP，各種應用（Web 小程序 移動應用 HTML5）才是最終承載業務的抓手。

現在企業數字化、智能化中最重要的矛盾存在于業務部門各種小的、甚至不太看得上的需求之中，IT部門在實現時，依舊周期長、成本高、問題大。

因此低代碼未來一定會面向應用本身。近幾年這么火，是因為它可以解決企業核心的、看似最平常的應用問題。

二、Low Code

那么低代碼是不是只能做小的、輕型的應用？

這個問題其實對從業者來說打擊性很大，因為人們可能會說低代碼平臺本身即低價值的，它只能做小程序、小應用。

好像的確是這么回事兒。

首先，低代碼的主要能力涵蓋的是小型應用，這里面有其自身的邏輯。

2015年，Gartner曾經有過這樣一個分析象限，其中，應用場景分為三類。

其一，基礎設施型應用。這類應用其實施周期、生命周期都相對較長，企業內部的實施周期大概為七年左右；與此同時，它在企業內部的存活周期可能會超過12年，變化相對較小。典型代表為ERP。

其二，差異化設施應用。這類應用的實施周期大致1-2年，存活時間大致1-3年，這類應用的典型代表為CRM。

其三，創新型應用。這類應用生命周期短，規劃周期和實施周期不能超過6個月。該應用在企業內部的生命周期大致在一年之內；同時要求快速交付。這類應用適用于持續集成、以及敏捷開發等場景。

第三類應用就是我們今天所說的小應用、小程序。

那么這幾類應用誰來督導、發行？這類應用多為部門發起，所處理的事宜大多也為企業內的“雜事兒”。比如HR計劃做一次內部的健康篩查，此時會需要建立這類小應用；比如傳統IP覆蓋能力產值，這事兒會由IT部門主導。因此可以看到，第三類應用有著典型的不同。

今天的企業為何要上云？前兩種應用并不是企業上云的目的，盡管企業內網的ERP、CRM等東西可以挪至外網，但這并不具備任何實際價值，僅是移動搬家時代的體現，可以讓場景使用相對豐富而已。但本質上，內網已經可以滿足原有需求。

因此大家應有一個直觀認識，低代碼并非只能做小型應用，云上用戶之所以上云，是為了快速開發和迭代，滿足業務部門的需求。因此，低代碼開發平臺主要是為了解決新問題，主要用來做基于移動和云的、業務部門發起的創新型的數字化智能化應用。假如技術人員、IT部門不能很好地滿足業務部門的數字化、智能化需求，此時企業便需要借用低代碼平臺來打造數字化的競爭優勢。

另外，低代碼的推廣不能只講太多技術說的話，這并不適用于低代碼的全球市場環境。

國內低代碼公司的從業人員大多講的和國外不一樣，他們借助低代碼的概念，講的是中臺。而今天的低代碼雖然涵蓋了中臺的能力，但這并不是它的核心要務。低代碼所需解決的，是公民開發者如何參與到企業的IT進程中的問題；真正的賦能公民開發者才是低代碼的價值。而如何提升IT部門效率的問題，才是傳統PaaS或中臺所需解決的。

那什么“不是技術的話”？如outsystems，這是全球低代碼領域內的一個標桿公司，單筆融資了上億美金?？梢钥吹?，它所講的是customer experience，即利用低代碼平臺可以做出擁有更佳用戶體驗的應用；operational efficiency，即自身效率的提升，實現系統的現代化；還有digital transformation等等。

因此，低代碼并不等于中臺，它只是涵蓋了中臺的能力。更核心的在于它能不能做出更好的、比如和outsystems相似的分配標準。

因此低代碼有這樣幾個特點：

• 少量代碼：降低重復性工作；
• 快速試錯：提升效率；
• 圖形化：讓業務團隊能參與進來。

其一，進入行業較久的互聯網朋友們可能聽過一些DISCUZ系統；在當時，有些系統可以以無代碼的方式拖拽式生成一個手機網站，以及適用于各種場景的、基于論壇和新聞展示為模式的建站系統。

但是無代碼并不具備核心競爭力。與之相對，低代碼的基礎標準是這樣的：涵蓋了aPaaS的能力、涵蓋MADP，以圖形化、可視化、流程化的方式進行組合，驅動底層的PaaS和表層的MADP，最終形成低代碼。

因此，低代碼不代表無代碼，它需要一定的代碼工作量，其目的是為了讓業務部門參與整個過程，形成完整的組合和有效的低代碼應用，實現APP數字業務的創新。而無代碼無法滿足企業將數字化當成核心競爭力的這一前提。

其二，快速試錯，提升效率，即企業可以快速地變化、升級。

其三，圖形化，即讓業務團隊參與進來。低代碼平臺其實很適合產品經理。以往產品和研發提需求時，如果研發態度不好，可能甚至會告訴產品這個需求無法實現。但是低代碼時代來臨之后，產品可以幫研發將事情做到七八成，研發只需完成剩下的部分。

而關于低代碼開發平臺的最終檢驗標準，有這三個方面：

1. 能不能開發2C和智能硬件的應用；
2. 能不能有效連接企業內部和云端的API；
3. 具不具備三種能力：圖形化、MADP、aPaaS。

早期低代碼開發平臺只能做表單式，但是能否做好2C體驗的產品，才是低代碼平臺的核心價值之一。

今天的低代碼開發平臺也需要很好的連接能力，畢竟現下企業做應用時，并不要求完善自身內部的所有程序，它可能會用到多家的系統。因此連接能力是必須的，這也是PaaS的能力之一。

而以圖形化的方式進行組合，可視化驅動底層的PaaS和表層的MADP，則是衡量一個低代碼平臺有效性以及真實性的基礎標準。

三、企業怎么用？

低代碼開發平臺給企業IT解決什么問題？給誰用？

Forrester是相比Gartner更早定義低代碼的公司。在分析報告里，它提出了低代碼的兩種定義：

其一，面向企業內傳統IT開發團隊，給專業研發人員使用的開發平臺。

其二，面向業務團隊，即非傳統IT人員群體使用的開發平臺，即公民化開發者。

因此在國外，Low Code 分成兩種產品模式，面向不同的群體實現輸出。當下在國內，我們很少聽到有人專門面向產品經理提供低代碼工具，更多的還是第一種，可能通過模型驅動，提供專業的IT數據，但這種工具對我們而言還是太復雜了。

那么，企業到底該怎么用低代碼開發平臺來做應用？

而我作為產品經理、作為低代碼開發平臺分析師，我又該如何設定我的產品？

首先，面向經過培訓的業務團隊，我們給他使用的應該是圖形化、可視化的工作臺。且要想讓這類非專業人員使用低代碼，我們可以從普通互聯網用戶角度出發來進行思考，滿足他們的需求。

其二，代碼部分應該如何配合這類人員？則應當讓業務團隊優先處理各種需求，讓碎片化的需求規范化（如輸出PRD、專業的Axure原型等），進而推動業務向研發團隊行進。

舉個例子。比如HR部門發起一個訴求，此時需要進行需求梳理，再設計產品原型UI等。在分析完整個流程之后，我們會發現，圖中標黃的部分在原本IT能力范圍之外，標綠部分則是企業IT人員所擅長的。

因此我們在想，關于前半部分，我們是否能夠做出一個工具將其串聯起來，并跟后半部分也串聯起來，形成一個完整的流程，讓每一個小的需求都在規范流程里流走，并形成一定的技術標準。即產品經理最后畫出的原型會變成代碼，最后IT團隊則可以輕松地完成剩余事情。為此，我們劃定了右側部分，將其變為標準化的流程。

而碼前便是基于這樣的邏輯下誕生的。它可以做什么事呢？

首先，它可以將Idea快速孵化，利用現成的事物實現高度復用，縮減時間周期。比如開發注冊頁面，此時我們可以挑選模板，這些模板的核心功能并無太大差別，利用模板，我們實現引導頁面復用、通用化功能復用等，不僅輸出了產品原型，更是完成了低代碼的輸出。

其二，降本增效；即一個人便可以完成多個人的工作，可能未必專業，但是減少了溝通環節；之后再交付專業人士。

其三，管理便捷，即所有流程都可以被串聯起來，在一個平臺上實現通用化的流轉。

而這能起到什么幫助？

比如，可以幫助業務部門精準地描述企業IT數字化需求，利用模板方式創建引導，進行產品設計，形成高保真的、可實時保存的云端協作原型設計。低代碼開發也可以實現前后同步驅動，聯動前端開發與后端開發。

以上便是我對產品經理可使用的、低代碼工具的設計和思考。

說回一個問題，是不是人人都可以做產品經理呢？就我個人經歷而言，這個問題的答案是否定的。

產品經理可以分為兩種，其一，會畫原型的產品經理；其二，也是大家更為追求的，即可以從戰略角度出發、把控整條產品線的產品經理，這類產品經理需要對市場方向等方面有所思考。

而我們做低代碼，也是基于整體方向的思考上進行。因此我覺得，產品經理其實跟藝術創作類似，都需要一些天賦。做研發的，可以學習計算機、學習自動化；做UI的，則大多是美術出身；這些角色都是有地方可以進行學習的。但是學校里并沒有專門開設一門關于產品經理的課程。

舉個例子，為什么微信PC端一定要掃碼登錄？按我個人理解，使用PC端登錄微信的場景相對較多，此時輸入用戶名、密碼進行登錄反而更為簡單快捷，為何從產品出現伊始，它就要求用戶PC端必須掃碼登錄呢？

可能最開始關于這個產品設想，研發團隊并沒有太多思考。但今天微信仍在堅持，我覺得，這便是一個產品的邏輯，是產品的堅持和設計。每家產品都有自身的戰略思考，不會輕易地被用戶調研左右，因為用戶需求調研所得的需求很可能都是偽需求。更核心的，還是在于思考。

而碼前這個工具可以做什么？當下我們梳理產品需求的時候，大多按頁面進行處理；生成這些頁面之后，碼前支持將所有頁面導出為一個個對應的sketch文件。最簡單的邏輯在于，這一方式可以防止頁面遺漏，這也是對UI工作的一個有效提升。

總結一下，產品經理需要有自己的堅持，這是最核心的道路。產品經理也需要擁有戰略思維。

四、最后

2000年我還在上大學，2003年我選擇輟學創業。在我做產品經理的時間里，我覺得最核心的，便是有自己的堅持，從綜合的、商業的角度鍛煉自己的想法。想法始終是產品領域最核心的、自我歷練的基礎之一。

我個人比較認可英國的撒切爾夫人所說的一段話：

Watch?your?thougts，they?become?words；

Watch?your?words，they?become?actions；

Watch?your?actions，they?become?habits；

Watch?your?habits，they?become?character；

Watch?your?character，for?it?becomes?your?distiny.

而作為一個產品經理，我們的想法是所有一切的來源。希望大家都可以成為一個獨當一面、涵蓋所有能力的產品經理，這其中可能需要一點天賦，大家可以校驗一下自己。

相關閱讀

大部分成功的商業創新，來自于組合創新——2021產品經理大會·深圳站現場報道

年度行業大會開啟巡回

互聯網圈年度盛典，聽一線實戰專家深度分享，與數千位互聯網圈同行深度交流，拆解產品、運營實戰案例，挖掘行業新機會！

掃描下方二維碼添加大會小助手，回復暗號【032】領產品經理&運營人必備工具包，獲取全年大會最新資訊！

本文為【2021年產品經理大會·深圳站】現場分享整理內容，由人人都是產品經理運營 @Aine 整理發布。未經許可，禁止轉載，謝謝合作

題圖來自大會現場