為什么需要產(chǎn)品化
產(chǎn)品化的三個(gè)層次
個(gè)性化需求帶來(lái)的問(wèn)題
通過(guò)對象編輯器定義數據模型
通過(guò)流程編輯器定義業(yè)務(wù)邏輯
在交互、組件層面的產(chǎn)品化設計
一套標準化產(chǎn)品的功能架構
對內增強集成能力
對外拓展產(chǎn)品邊界
從定制化到產(chǎn)品化
自研系統可以產(chǎn)品化么？
PaaS、aPaaS、低代碼與無(wú)代碼
低代碼與公民開(kāi)發(fā)者
低代碼的三種模式
低代碼在甲方的應用
對于一款商業(yè)化B端產(chǎn)品，如何將不同客戶(hù)的需求提煉抽象，形成標準化功能，通過(guò)靈活的配置和設計，滿(mǎn)足不同客戶(hù)的個(gè)性化需要，是一件很有挑戰的事情。
本章，我們將聚焦于產(chǎn)品的標準化設計，從商業(yè)、功能、生態(tài)三個(gè)層面來(lái)拆解產(chǎn)品化的核心原則，并給出一般性的設計建議。
同時(shí)，我們也會(huì )探討和產(chǎn)品標準化設計能力緊密相關(guān)的低代碼產(chǎn)品的設計、應用特點(diǎn)。
產(chǎn)品化早在項目制軟件時(shí)代就已存在，例如Oracle、SAP、用友、金蝶，雖然早期是私有化部署，但都具備很強的產(chǎn)品化能力。
作為高科技企業(yè)，軟件公司希望提升毛利，賺軟件產(chǎn)品被“復制使用”的錢(qián)，有條件的軟件公司經(jīng)過(guò)多年打磨和沉淀，都會(huì )構建標準化產(chǎn)品，收取軟件售賣(mài)的費用，而將定制化實(shí)施工作交給合作伙伴ISV（Independent Software Vendor）完成，畢竟，實(shí)施、開(kāi)發(fā)費用是一份“辛苦錢(qián)”。
同時(shí)，產(chǎn)品化能力的強弱，又決定了實(shí)施的成本。產(chǎn)品化做的越好，實(shí)施工作可能只是簡(jiǎn)單地配置，而不需要復雜的硬編碼。
SaaS模式的發(fā)展，進(jìn)一步推動(dòng)了軟件產(chǎn)品標準化的建設，因為SaaS作為一套標準產(chǎn)品部署在云端，更需要靈活的功能設計，實(shí)現對不同客戶(hù)的適配。
B端產(chǎn)品的產(chǎn)品化，可以分為三個(gè)層次來(lái)探討，如下圖。
B端產(chǎn)品化的三個(gè)層次
首先是商業(yè)層面，任何產(chǎn)品都是公司戰略的載體，我們必須追本溯源，從公司戰略、目標客群、產(chǎn)品價(jià)值、覆蓋場(chǎng)景等角度，思考產(chǎn)品的核心本質(zhì)和靈魂。
其次是產(chǎn)品自身功能的層面，屬于產(chǎn)品的基本功，業(yè)務(wù)型B端產(chǎn)品，面臨錯綜復雜的場(chǎng)景，如何提煉需求，抽象業(yè)務(wù)，設計出具有高度擴展性和靈活性的軟件解決方案，面臨著(zhù)較高的挑戰，但也有可借鑒的路徑。
最后是生態(tài)層面，一方面，可以通過(guò)OpenAPI，將軟件能力對外暴露出去，讓市場(chǎng)中更多的第三方介入，一起圍繞軟件構造外圍應用，形成生態(tài)；另一方面，甚至可以基于產(chǎn)品的能力和數據，打通產(chǎn)業(yè)鏈上下游，創(chuàng )建全新的商業(yè)、運營(yíng)模式。
接下來(lái)，我們對這三個(gè)層面分別展開(kāi)探討。
在商業(yè)層面，我們有幾個(gè)關(guān)鍵點(diǎn)需要思考清楚，分別是細分目標客群、明確價(jià)值主張、規劃發(fā)展路徑。
很多產(chǎn)品團隊經(jīng)常有個(gè)困惑：“我們的產(chǎn)品化面臨的客戶(hù)需求非常發(fā)散，好不容易提煉了共性需求，結果遇到新的客戶(hù)，依然沒(méi)法復用，造成了團隊疲于奔命，效率極低，該怎么做出一套標準化產(chǎn)品，能適配不同客戶(hù)呢？”
如果遇到類(lèi)似問(wèn)題，可以先梳理下提問(wèn)者服務(wù)的的目標客戶(hù)群體，可能會(huì )發(fā)現，面臨高度發(fā)散需求的產(chǎn)品團隊，他們的客戶(hù)群體也往往非?；靵y，沒(méi)有明確的的細分客群。有很多企業(yè)，不是根據目標客群找客戶(hù)，而是根據成交的客戶(hù)來(lái)做項目！
找到并聚焦細分客群是軟件產(chǎn)品化成功運作的核心要素之一。同類(lèi)特征的客戶(hù)群體，業(yè)務(wù)特征、管理模式、場(chǎng)景和痛點(diǎn)都是高度相似的，這就為軟件產(chǎn)品的標準化設計創(chuàng )造了天然的良好條件，不論是商業(yè)運作，還是功能設計，都會(huì )更加清晰可落地。
做產(chǎn)品，最難的不是選擇做什么，而是不做什么。在商業(yè)上取得成功的產(chǎn)品，一定不是滿(mǎn)足了所有客戶(hù)所有訴求，而是解決了目標客群核心痛點(diǎn)的那一個(gè)。
客戶(hù)什么都想要，而資源畢竟有限，究竟該做什么，不該做什么，先做什么，后做什么？決策的依據，要來(lái)自于于產(chǎn)品的價(jià)值主張——產(chǎn)品要解決目標客戶(hù)的什么痛點(diǎn)？我們的獨特亮點(diǎn)是什么？
例如，某公司核心核心產(chǎn)品是品牌連鎖餐飲的運營(yíng)管理系統，當客戶(hù)提出希望提供一體化進(jìn)銷(xiāo)存能力時(shí)，產(chǎn)品經(jīng)理必須要做出決策，究竟是把資源繼續集中在核心主打產(chǎn)品，解決客戶(hù)的運營(yíng)問(wèn)題？還是覆蓋更多的業(yè)務(wù)場(chǎng)景，提供全家桶產(chǎn)品方案，涵蓋進(jìn)銷(xiāo)存業(yè)務(wù)？作為成長(cháng)型公司，更需要在垂直領(lǐng)域做深做精保證自己的競爭壁壘，擴展場(chǎng)景可以考慮以OpenAPI的方式和其他做餐飲進(jìn)銷(xiāo)存的廠(chǎng)家做深度合作和集成，來(lái)解決客戶(hù)訴求，因此產(chǎn)品經(jīng)理（更可能需要CEO來(lái)決策）決定不介入進(jìn)銷(xiāo)存場(chǎng)景，而繼續深耕運營(yíng)管理。
在思考產(chǎn)品功能是不是要覆蓋更多場(chǎng)景，提供更多擴展功能時(shí)，我們要反問(wèn)自己，這樣做，能不能對產(chǎn)品解決核心問(wèn)題上帶來(lái)更大的價(jià)值和幫助，如果不能，相當于要進(jìn)入一片全新的領(lǐng)域，對于客戶(hù)來(lái)講，是否已經(jīng)有其他更好的解決方案，你的競爭力在哪里？
在產(chǎn)品發(fā)展演化的路徑中，一切決策都應該基于商業(yè)決策。要不要做aPaaS？要不要做開(kāi)放平臺生態(tài)？這些看似技術(shù)的架構和路線(xiàn)，本質(zhì)上依然是商業(yè)問(wèn)題。以aPaaS為例，對于業(yè)務(wù)型軟件產(chǎn)品，初期首要目的是開(kāi)拓市場(chǎng)驗證產(chǎn)品，站穩腳跟需要開(kāi)拓更多行業(yè)時(shí)，才需要考慮要不要通過(guò)構建aPaaS能力來(lái)降低研發(fā)成本，滲透到更多客戶(hù)群體；而實(shí)現aPaaS投入資源大，在產(chǎn)品PMF階段中顯然沒(méi)有必要涉及。因此，在什么階段，實(shí)現什么樣的產(chǎn)品形態(tài)，需要結合商業(yè)的策略和計劃，做充分的規劃。
以上給出的三個(gè)產(chǎn)品化商業(yè)層面的建議，只是供大家參考并引發(fā)一些思考，在現實(shí)的商業(yè)世界中，遇到的情況和挑戰要更加復雜，我們來(lái)看一個(gè)虛構的案例。
Y公司是一家聚焦銷(xiāo)售型CRM產(chǎn)品的SaaS公司，創(chuàng )始人李總在這個(gè)領(lǐng)域摸爬滾打多年，終于決定自己出來(lái)做一番事業(yè)，用SaaS的形態(tài)來(lái)打磨一款面向未來(lái)的產(chǎn)品！
李總精心挑選了目標市場(chǎng)，決定切入醫療CRM垂直細分領(lǐng)域，避免戰線(xiàn)被拉長(cháng)，和其他頭部廠(chǎng)商產(chǎn)生正面競爭。
業(yè)務(wù)發(fā)展初期還比較順利，早期的幾個(gè)種子客戶(hù)反饋都比較好，也有一定的續費意愿，但是在進(jìn)一步的拓展中，遇到了不小的阻力和挑戰，新客戶(hù)的開(kāi)發(fā)不如預期，而公司的現金流正在逐步枯竭，而最近資本市場(chǎng)融資也比較艱難。
就在此時(shí)，李總依靠以前的人脈，拿下了一個(gè)大訂單，但是要進(jìn)入一個(gè)計劃外的行業(yè)，為這家大客戶(hù)做一個(gè)純定制版的CRM。李總感到很頭疼，如果不接這單，公司現金流出問(wèn)題，還不一定能撐到下半年；如果接了這單，客戶(hù)完全不是之前預期的目標客戶(hù)畫(huà)像，而且定制化的系統，和之前的標準化產(chǎn)品差異很大，既無(wú)法完全復用，也無(wú)法沉淀下產(chǎn)品化能力。
“這不又做成外包公司了么！”李總有點(diǎn)氣餒的嘟囔著(zhù)。
時(shí)光飛逝，一年過(guò)去了。
李總靠幾個(gè)大型定制化項目穩住了現金流，確保產(chǎn)品化的方向繼續沉淀前進(jìn)，公司業(yè)務(wù)也算可控。
創(chuàng )業(yè)初期，李總就決定只深耕他最擅長(cháng)的SFA（Sale Force Automation，銷(xiāo)售過(guò)程自動(dòng)化，聚焦于線(xiàn)索到商機、客戶(hù)轉化的銷(xiāo)售型CRM）CRM方向，如果客戶(hù)有其他場(chǎng)景的訴求，Y公司會(huì )通過(guò)OpenAPI能力和其他伙伴公司做集成，來(lái)幫助客戶(hù)解決問(wèn)題。不論是企業(yè)微信生態(tài)下的SCRM（Social CRM），還是客戶(hù)服務(wù)場(chǎng)景的Service CRM，Y公司都是通過(guò)集成接口，和其他伙伴做了深度綁定。
然而慢慢的，李總發(fā)現情況產(chǎn)生了變化。
首先很多客戶(hù)一再提出希望得到“全家桶”的解決方案，而不希望買(mǎi)一堆不同公司的產(chǎn)品做組合；其次和Y公司合作的廠(chǎng)商，居然偷偷摸摸的也開(kāi)始做SFA CRM產(chǎn)品，雖然功能不齊全，但是能夠提供“全家桶”方案給客戶(hù)，甚至還是免費的。
這就讓Y公司非常被動(dòng)。
“做！他們做，我們也能做！我們除了SFA，也要做SCRM！還要做Service CRM！甚至是Marketing CRM！”李總氣憤地低語(yǔ)著(zhù)！
然而切入多產(chǎn)品線(xiàn)，不就違背了當年創(chuàng )立Y公司要聚焦細分領(lǐng)域的初心了么？而且這樣會(huì )導致資源被稀釋?zhuān)绾纬掷m保證主營(yíng)產(chǎn)品的核心競爭力呢？
在這個(gè)虛構的案例中，李總遇到的情況和最終的決策，每一個(gè)都違背我們之前給出的建議，但卻又是無(wú)奈之舉。商業(yè)世界是殘酷和復雜的，產(chǎn)品化的運作，首先是商業(yè)行為，道路中充滿(mǎn)挑戰和困難，沒(méi)有任何一個(gè)方法絕對指向成功，一切都要在摸索中前行。
如果說(shuō)商業(yè)層面是產(chǎn)品化的“道”，那么功能層面則是產(chǎn)品化的“術(shù)”，相對于“道”的不可捉摸，“術(shù)”顯得更加可控一些。接下來(lái)，我們探討產(chǎn)品化功能層面設計要點(diǎn)，正好果凍最近也在研究這個(gè)課題，而公司負責CRM的資深產(chǎn)品專(zhuān)家大可曾在Y公司做過(guò)CRM產(chǎn)品化工作，果凍可不能放過(guò)向公司前輩學(xué)習的機會(huì )，挑選了一個(gè)大可心情不錯的日子，虛心的向他請教。
果凍：“大可老師，我一直有點(diǎn)暈，搞不清楚個(gè)性化、標準化、產(chǎn)品化這些概念到底有什么關(guān)系？”
大可：“很容易理解啊，我們平常給M公司做內部系統，面臨的業(yè)務(wù)方只有一個(gè)，所以相當于一直在做一個(gè)定制版的系統，但如果設計的系統要給不同客戶(hù)使用，不同客戶(hù)有不同的需求，那么你就要進(jìn)行取舍，將一些需求做進(jìn)標準化產(chǎn)品中，有些個(gè)性化的需求只能舍棄?！?/span>
果凍：“還是有點(diǎn)模糊，為什么要取舍？都做成標準產(chǎn)品不行么？”
大可：“我來(lái)舉個(gè)例子吧，我當年在Y公司負責的CRM產(chǎn)品，主要服務(wù)于銷(xiāo)售領(lǐng)域，完成線(xiàn)索到商機、客戶(hù)的轉化，產(chǎn)品初期聚焦于能源領(lǐng)域，在我們的標準功能中，線(xiàn)索只能手工轉化成商機，有一天新簽單的客戶(hù)1提出需求，希望在他們公司線(xiàn)索被跟進(jìn)3次就自動(dòng)轉化成商機，這就是一個(gè)標準版產(chǎn)品不支持的個(gè)性化需求，但是分析后我們判斷其他客戶(hù)可能也有類(lèi)似的需求，所以將這個(gè)需求做進(jìn)標準版本，并增加一個(gè)配置開(kāi)關(guān)，允許線(xiàn)索被添加了N條拜訪(fǎng)記錄后就自動(dòng)創(chuàng )建商機，例如下圖這樣?！?/span>
一個(gè)典型的參數配置功能
果凍：“明白，這是根據對客戶(hù)群業(yè)務(wù)的理解，將一些常見(jiàn)的能力做成配置功能，方便有需要的客戶(hù)直接使用，而不用開(kāi)發(fā)?！?/span>
大可：“是的，但如何識別這些共性功能，是很有挑戰的事情，需要對客戶(hù)群體有很深的理解洞察，才能做出合理的抽象提煉。而有些時(shí)候，客戶(hù)的需求并不一定合理，或者產(chǎn)品經(jīng)理也不確定是否是共性需求，就可能忽略這些需求。比如說(shuō)客戶(hù)2的老板提了個(gè)需求，要求銷(xiāo)售人員打開(kāi)優(yōu)質(zhì)線(xiàn)索的詳情頁(yè)后，詳情頁(yè)能發(fā)光，這就是一個(gè)純個(gè)性化需求，也并不是很合理，我們大概率會(huì )拒絕?！?/span>
果凍：“但是，如果客戶(hù)2是大客戶(hù)，這個(gè)功能不實(shí)現，對方就要換其他家產(chǎn)品，怎么辦呢？”
大可（正在喝水，被嗆了一口）：“呃，這個(gè)么，確實(shí)比較棘手，要么直接給客戶(hù)做個(gè)單獨部署的定制版吧！”
果凍：“直接做進(jìn)標準版不行么？雖然可能不會(huì )有其他客戶(hù)用，但畢竟不用搞個(gè)單獨管理的定制版??？”
大可：“我們做產(chǎn)品，一定要保證標準版簡(jiǎn)潔干凈，如果什么功能都往上邊累加，最后會(huì )讓系統變得不堪重負，不僅難用，代碼維護也會(huì )越來(lái)越困難。而且客戶(hù)2的情況，既然是個(gè)性化十足的大客戶(hù)，還不如單獨做一個(gè)定制版，如果有很好地最佳實(shí)踐，在單獨抽出來(lái)放進(jìn)標準版?！?/span>
果凍：“明白了，聽(tīng)起來(lái)有道理?！?/span>
大可：“標準化產(chǎn)品設計，遠比我說(shuō)的這個(gè)小例子要復雜。假如說(shuō)，我們又開(kāi)發(fā)了教育領(lǐng)域的客戶(hù)3，而客戶(hù)3提出一個(gè)個(gè)性化需求，針對教育領(lǐng)域，線(xiàn)索（也就是潛在學(xué)員）需要參加試聽(tīng)課，如果參加了2次以上試聽(tīng)課，則線(xiàn)索自動(dòng)轉化成商機，這是不是又是一個(gè)新的訴求？”
果凍：“是啊，而且這個(gè)需求是一個(gè)針對新行業(yè)的新需求！”
大可：“為了實(shí)現這個(gè)需求，不僅要實(shí)現配置開(kāi)關(guān)，還要實(shí)現一個(gè)新的'試聽(tīng)課上課記錄’的數據對象，和線(xiàn)索進(jìn)行關(guān)聯(lián)，線(xiàn)索可以對應多個(gè)'試聽(tīng)課上課記錄’，當'試聽(tīng)課上課記錄’的有效記錄超過(guò)2條，就自動(dòng)創(chuàng )建商機?！?/span>
果凍：“為什么要創(chuàng )建一個(gè)新的數據對象呢？直接做成配置參數不行么？”
大可：“因為我們很快發(fā)現，其他教育客戶(hù)有類(lèi)似又不完全一樣的需求，比如大家都會(huì )有試聽(tīng)課的環(huán)節，但是有些客戶(hù)是根據試聽(tīng)課的累計上課次數來(lái)決定創(chuàng )建商機的時(shí)機，有些客戶(hù)則是根據參加試聽(tīng)課的累計人次，有些則是根據學(xué)員中的關(guān)鍵KP是否出席，總之圍繞試聽(tīng)課這個(gè)數據對象的業(yè)務(wù)邏輯很多，個(gè)性化字段也很多，需要實(shí)現專(zhuān)門(mén)的'試聽(tīng)課上課記錄’數據對象進(jìn)行管理，并且基于這個(gè)數據對象來(lái)設置商機創(chuàng )建規則?！?/span>
果凍：“媽呀，聽(tīng)起來(lái)好復雜，我還以為標準化產(chǎn)品，通過(guò)幾個(gè)開(kāi)關(guān)參數配置就能實(shí)現了！”
大可：“要有這么簡(jiǎn)單就好了，對于工具型產(chǎn)品，例如會(huì )議系統，企業(yè)網(wǎng)盤(pán)，可能一些參數配置就能解決所有客戶(hù)的個(gè)性需求了，但是對于業(yè)務(wù)型產(chǎn)品，背后面臨復雜的業(yè)務(wù)單據、流轉規則，除了已有數據對象的字段要能自定義，還要支持新增數據對象！”
果凍：“這個(gè)聽(tīng)起來(lái)確實(shí)復雜，我們做內部系統設計，如果遇到這類(lèi)訴求，都是由研發(fā)硬編碼解決的！”
大可：“是的，但是標準化產(chǎn)品就不能這樣做了，而要通過(guò)一些底層能力的構建，支持對數據底層對象的編輯和自定義。比較成熟的商業(yè)化產(chǎn)品，都支持這樣的能力！”
大可（喝了口水繼續說(shuō)道）：“實(shí)現對數據對象的自定義，有兩種典型的方案，一種是表單驅動(dòng)的設計，一種是模型驅動(dòng)的設計。對于業(yè)態(tài)不是特別復雜的產(chǎn)品，可以考慮表單驅動(dòng)的設計，特點(diǎn)是容易上手，配置簡(jiǎn)單，缺點(diǎn)是靈活性有限，不能實(shí)現更加復雜的訴求。例如下圖，是知名項目管理軟件Jira的管理后臺，Jira采用了類(lèi)似表單驅動(dòng)的數據模型定義能力，管理員通過(guò)定義表單中的控件，來(lái)完成背后數據對象的定義?！?/span>
Jira的表單模式的數據對象編輯界面
果凍：“是說(shuō)像我們用Axure畫(huà)原型一樣，把文本框、下拉框這樣的控件拖到屏幕上，背后就能自動(dòng)創(chuàng )建文本型、枚舉型這樣的數據字段么？”
大可：“孺子可教也，理解的很快嘛！類(lèi)似于Jira這樣的商業(yè)級軟件，背后的表單設計器，都是實(shí)時(shí)生效的，這就是經(jīng)典的PaaS平臺能力，修改字段配置后，實(shí)時(shí)生效！除了修改已有數據對象（或者叫表單）的字段，也可以新增數據對象，你仔細看截圖中左側有個(gè)菜單叫做'Add issue type’，就是Jira提供的由用戶(hù)自定義新數據對象（或者也可以叫做表單）的功能?！?/span>
果凍：“為什么叫做創(chuàng )建Issue呢？”
大可：“不同方向的商業(yè)化產(chǎn)品，都有圍繞自身業(yè)務(wù)和場(chǎng)景的基本數據模型，Jira聚焦于項目管理，所以對數據模型有一些基本的預定義，Issue是Jira中很重要的預置概念，Issue對象只能是Epic、Bug、Task等類(lèi)別中的某一個(gè)，如下圖?！?/span>
Jira的中可以創(chuàng )建的Issue類(lèi)型
大可：“另一種數據對象定義的模式，叫模型驅動(dòng)的設計，更加復雜的商業(yè)軟件會(huì )采用這種方式，例如Salesforce，下圖就是Salesforce管理后臺的數據模型編輯器的可視化呈現，配置能力更強，用起來(lái)也更復雜?！?/span>
Salesforce Schema Builder視圖下的數據對象編輯器
果凍：“這個(gè)界面，好像老馬教我的ER圖??！”
大可：“你說(shuō)的沒(méi)錯，所謂數據對象，也就是ER建模中的實(shí)體，最后對應著(zhù)的關(guān)系型數據庫表結構設計。不論是表單驅動(dòng)，還是模型驅動(dòng)，都是讓我們在前臺通過(guò)拖拉拽描述數據對象，PaaS平臺會(huì )自動(dòng)動(dòng)態(tài)編譯數據庫表結構，并且自動(dòng)化生成CRUD代碼（Create、Read、Update、Delete，數據操作的經(jīng)典命令）?！?/span>
果凍：“感覺(jué)突然茅塞頓開(kāi)！”
大可：“有了這樣的對象編輯器能力，你想想，之前提到的教育類(lèi)客戶(hù)3 的個(gè)性化需求，要新增'試聽(tīng)課上課記錄’數據對象，是不是完全可以通過(guò)拖拉拽實(shí)現，而不用編碼？”
果凍：“沒(méi)錯！”
大可：“接下來(lái)，我們要解決下一個(gè)問(wèn)題，業(yè)務(wù)邏輯的靈活配置能力！你還記得客戶(hù)1提出的需求么，當線(xiàn)索被跟進(jìn)3次，自動(dòng)轉化成商機？”
果凍：“記得，之前的方案，是把這個(gè)邏輯做成開(kāi)關(guān)，并且將跟進(jìn)幾次做成參數配置?！?/span>
大可：“實(shí)際上，這個(gè)需求是業(yè)務(wù)型產(chǎn)品典型的業(yè)務(wù)邏輯類(lèi)需求，完全可以通過(guò)流程引擎這樣的產(chǎn)品底層能力實(shí)現！在業(yè)務(wù)型產(chǎn)品設計中，有大量的需求可以被提煉成一句話(huà)，'在什么情況下，對什么數據做什么處理’，流程引擎就是實(shí)現這樣簡(jiǎn)單業(yè)務(wù)邏輯的強力組件！”
大可（整理了下思路）：“首先，需要定義觸發(fā)條件，可以是某個(gè)數據被修改，也可能是到了某個(gè)時(shí)間，或者是用戶(hù)做了某個(gè)動(dòng)作；定義觸發(fā)條件后，接下來(lái)要描述業(yè)務(wù)邏輯，業(yè)務(wù)邏輯可能包括基于某個(gè)數據來(lái)更新另一個(gè)數據，或者自動(dòng)創(chuàng )建一條新數據，或發(fā)一封郵件等等，處理邏輯中可能包含了循環(huán)、邏輯分支等。例如，下圖是低代碼產(chǎn)品Airtable的流程編輯器，是我認為交互設計非常棒的一種簡(jiǎn)化的流程編輯器，左側是觸發(fā)器設置，右側是執行邏輯?！?/span>
Airtable的流程編輯器
大可（整理了下思路）：“再例如，下圖是Jira的流程編輯器，也是比較容易上手掌握的?！?/span>
Jira的流程編輯器
大可：“更加復雜、專(zhuān)業(yè)的流程編輯器，會(huì )提供流程畫(huà)布的交互，例如下圖是Salesforce的流程編輯器Flow Builder的配置界面，對于設計邏輯更加復雜的流程，顯然流程畫(huà)布會(huì )更加合適?！?/span>
Salesforce的流程編輯器
大可：“有了流程編輯器，客戶(hù)3的需求也就可以輕松實(shí)現了，無(wú)非是創(chuàng )建一個(gè)新流程，如果針對某個(gè)線(xiàn)索的'試聽(tīng)課上課記錄’有效數據超過(guò)2條，則自動(dòng)觸發(fā)流程，流程中會(huì )創(chuàng )建一個(gè)新的商機對象，商機名稱(chēng)取自對應的線(xiàn)索，商機狀態(tài)為'待跟進(jìn)’，商機根據規則自動(dòng)分配給后續跟進(jìn)的銷(xiāo)售?！?/span>
果凍：“太強大了，聽(tīng)起來(lái)有了這樣的底層能力，就不需要研發(fā)存在了呀！”
大可：“設計強大的對象編輯器、流程編輯器，其實(shí)就是PaaS的核心能力之一，確實(shí)可以大幅度減少研發(fā)的編碼工作，但是這些底層能力本身需要投入巨大的研發(fā)資源，甚至要沉淀、打磨很多年才能真正發(fā)揮價(jià)值。如果在產(chǎn)品打磨的初期，客戶(hù)群體聚焦，完全可以通過(guò)抽象共性，以參數配置的方式完成產(chǎn)品的標準化，而不是一上來(lái)就做一套PaaS底層?！?/span>
果凍（不住地點(diǎn)頭）：“有道理，真是學(xué)習到了！”
大可：“其實(shí)所謂低代碼平臺，核心底層也是需要實(shí)現數據的自定義和流程的自定義能力，和PaaS的本質(zhì)是相通的。除了這兩個(gè)能力，完整的產(chǎn)品化解決方案，還需要前端的可視化組件，來(lái)完成最終的人機交互?！?/span>
果凍：“聽(tīng)起來(lái)，這就是軟件設計經(jīng)典的MVC三層架構嘛，Modeling完成數據底層的定義，Controller完成業(yè)務(wù)邏輯的定義，View完成交互層的定義！”
大可：“你理解的非常正確，不論是PaaS平臺，還是低代碼產(chǎn)品，就是在一定的場(chǎng)景約束下，實(shí)現了MVC三層架構的自定義能力！類(lèi)似于視圖編輯器、詳情頁(yè)、報表、儀表盤(pán)，以及任務(wù)、消息、公告、搜索這些組件，都是前端應用層的產(chǎn)品化標配。例如視圖編輯器這種組件，對于自研自用系統顯然有點(diǎn)大材小用，但是對于客戶(hù)群體龐大的商業(yè)化軟件，就顯得非常核心且必要了！另外，這些產(chǎn)品化的前端組件，《決勝B端》第二版這本書(shū)中的第六章已經(jīng)有很詳細的介紹，你可以去讀一讀，我就不細說(shuō)了！”
果凍：“這就去讀！”
一套業(yè)務(wù)型標準化產(chǎn)品，從軟件工程實(shí)踐的角度來(lái)講，是有章可循的。軟件系統的本質(zhì)就是表單數據 業(yè)務(wù)流程 約束規則，在此基礎上加入權限、字典、API等能力，核心遵循MVC的三層架構，基于這個(gè)思考，我們可以總結標準產(chǎn)品的架構圖如下圖。
多租戶(hù)形態(tài)標準化產(chǎn)品的典型架構
Model是模型層，也即數據底層，靈活的商業(yè)化產(chǎn)品可以做到用戶(hù)自定義數據模型；
Controller是控制層，也即業(yè)務(wù)邏輯層，靈活的商業(yè)產(chǎn)品背后的業(yè)務(wù)流程都是可以用流程引擎自定義設計；
View是視圖層，包括了自定義視圖、詳情頁(yè)、報表、儀表盤(pán)，以及各種基本前端組件，例如消息、公告、搜索、任務(wù)等；
除了以上三層，還需要具備全面的配置能力，以及系統對外的開(kāi)放API能力；架構圖最底層是租戶(hù)管理模塊，SaaS產(chǎn)品需要通過(guò)租戶(hù)管理模塊實(shí)現對多租戶(hù)客戶(hù)的交易、產(chǎn)品、權限的管理。
如果我們從使用角色的角度來(lái)看待這張圖，不同板塊的目標用戶(hù)如下：
標準化產(chǎn)品不同組件板塊的目標用戶(hù)
對于工具型產(chǎn)品，核心并不是數據表單與業(yè)務(wù)流程，而是場(chǎng)景化的解決方案和組建能力，因此并不需要模型層、業(yè)務(wù)邏輯層的自定義能力，甚至也不需要自定義頁(yè)面相關(guān)能力，只需要完善的工具組件，加一些企業(yè)級相關(guān)的配置能力即可，如下圖。
工具型標準化產(chǎn)品的典型架構
例如，對于會(huì )議系統、企業(yè)網(wǎng)盤(pán)這些工具型軟件，基本不需要數據底層對象的編輯能力和業(yè)務(wù)流程編排能力，更多的需要Open API的集成能力，以及針對企業(yè)級應用場(chǎng)景下的權限管理、組織機構同步等功能。有些工具型SaaS宣傳自己具備PaaS平臺能力，嚴格來(lái)講并不是真正的PaaS，而只是一些組件化的功能封裝加接口集成而已。
有一點(diǎn)大家務(wù)必注意，標準化產(chǎn)品，并非必須是SaaS模式，私有化部署的軟件產(chǎn)品一樣可以是標準化產(chǎn)品，例如Oracle、SAP、用友、金蝶的ERP產(chǎn)品，都是私有化產(chǎn)品，但其產(chǎn)品化能力非常強，在針對不同客戶(hù)做個(gè)性化二次開(kāi)發(fā)時(shí)，ISV（Individual Software Vendor，獨立軟件開(kāi)發(fā)商）完全可以基于標準化產(chǎn)品能力快速的實(shí)現訴求。
在國內，部分行業(yè)的客戶(hù)分布形態(tài)具有明顯的倒金字塔結構特點(diǎn)（參見(jiàn)本書(shū)第四章），例如通信、金融、政務(wù)等領(lǐng)域，這些領(lǐng)域中客戶(hù)數量少，每個(gè)客戶(hù)規模體量都很大，而服務(wù)于這類(lèi)行業(yè)的軟件廠(chǎng)商，雖然是私有化部署，同樣會(huì )將產(chǎn)品實(shí)現標準化建設，抽象底層能力，從而降低實(shí)施團隊的二開(kāi)成本，其標準化產(chǎn)品架構圖和上述架構圖沒(méi)有區別，無(wú)非是去掉了租戶(hù)管理板塊，如下圖。
非SaaS形態(tài)標準化產(chǎn)品的典型架構
以上介紹了從軟件工程角度來(lái)看待標準化產(chǎn)品需要具備的功能和組件，大家可以挑選一兩款成熟的商業(yè)軟件產(chǎn)品做上手體驗和研究，從而加深對上述架構圖的理解。
所謂Open API，即開(kāi)放的服務(wù)接口。接口可以將軟件背后的業(yè)務(wù)能力進(jìn)行封裝，對外暴露后，既可以完成系統對接，也可以擴展應用場(chǎng)景，放大業(yè)務(wù)價(jià)值。應用程序接口抽象與服務(wù)化，并不是單純的技術(shù)問(wèn)題，還可能是業(yè)務(wù)問(wèn)題，甚至是商業(yè)問(wèn)題。
從應用系統自身來(lái)講，系統要融入到客戶(hù)的應用架構環(huán)境中，就必須具備豐富的接口能力，實(shí)現數據打通和系統集成的訴求；
從商業(yè)化角度來(lái)講，靈活開(kāi)放的接口體系，可以吸引更多的第三方開(kāi)發(fā)者參與生態(tài)建設，構建更加豐富的應用選擇，既滿(mǎn)足了甲方多樣的需求，又為乙方構建了豐富的生態(tài)，還可以幫助ISV或獨立開(kāi)發(fā)者創(chuàng )收，屬于一舉多得。
任何一款在企業(yè)中使用的軟件產(chǎn)品，都不可能是獨立的、封閉的，必須要考慮和客戶(hù)的應用架構融合問(wèn)題，從數據底層打通，到接口的服務(wù)化，系統、模塊既要保證松耦合高內聚的設計特點(diǎn)，又必須實(shí)現組件化、可插拔的接口能力。
例如，一款銷(xiāo)售型CRM產(chǎn)品，在甲方部署實(shí)施時(shí)，首先要考慮用戶(hù)賬號體系、權限接入管理問(wèn)題，其次要考慮底層的線(xiàn)索、客戶(hù)數據打通或同步問(wèn)題，除此以外還要思考某些功能模塊組件的復用、共用問(wèn)題，比如說(shuō)線(xiàn)索的創(chuàng )建和查重能力要同時(shí)開(kāi)放給代理商系統，再比如說(shuō)CRM中的消息和待辦，是不是需要將數據推送到甲方企業(yè)集團門(mén)戶(hù)的統一消息、任務(wù)調度中心。
可見(jiàn)，企業(yè)級軟件產(chǎn)品面臨著(zhù)復雜的集成場(chǎng)景，而這些訴求都需要完善的接口能力支撐。此外，良好的接口設計，還可以加強產(chǎn)品標準化的能力，減少個(gè)性化需求對產(chǎn)品的影響，因為所有個(gè)性化需求通過(guò)外置程序調用核心接口即可，不需要影響產(chǎn)品核心邏輯。尤其是工具類(lèi)產(chǎn)品，完整、豐富的接口組件，是產(chǎn)品化成功的重要前提之一。
下圖是企業(yè)微信開(kāi)發(fā)者中心的“獲取客戶(hù)列表”接口的說(shuō)明文檔，可以看到，一個(gè)完整的接口涉及輸入參數、輸出結果、調用方式、安全性認證等內容。
企業(yè)微信的接口文檔
接口設計，雖然是技術(shù)問(wèn)題，但需要設計人員對業(yè)務(wù)有很好的理解，才能抽象出合理的顆粒度和功能，產(chǎn)品經(jīng)理可以和技術(shù)人員一起參與接口的設計工作。
關(guān)于接口相關(guān)的基本技術(shù)知識和概念，我們在第10章第4小節會(huì )進(jìn)一步探討。
如果產(chǎn)品所覆蓋的場(chǎng)景或業(yè)態(tài)足夠復雜，其間會(huì )存在很多微創(chuàng )新的機會(huì )，以及各類(lèi)個(gè)性化訴求。對于軟件廠(chǎng)商來(lái)講，實(shí)現豐富生態(tài)，融入更多的第三方開(kāi)發(fā)者進(jìn)入生態(tài)，為客戶(hù)提供服務(wù)，形成共贏(yíng)，是一種非常值得深入研究實(shí)踐的模式。
例如，企業(yè)微信聚焦于核心產(chǎn)品能力的研發(fā)和健康生態(tài)的運營(yíng)，在基本邏輯框架的限定下，大量第三方開(kāi)發(fā)者入局，基于企業(yè)微信的Open API實(shí)現了不同的SCRM產(chǎn)品，有的融入了營(yíng)銷(xiāo)自動(dòng)化能力，有的實(shí)現了公私海設計，這就讓企業(yè)微信生態(tài)有了更多豐富的產(chǎn)品選擇，解決不同客戶(hù)的訴求。
再例如，Salesforce開(kāi)放了其強大的PaaS平臺能力，圍繞以客戶(hù)為中心的場(chǎng)景，ISV可以開(kāi)發(fā)各類(lèi)獨立的，甚至和CRM無(wú)關(guān)的業(yè)務(wù)應用系統。下圖就是Salesforce應用程序商店AppExchange中，財務(wù)分類(lèi)下的的第三方應用。
Salesforce的應用商店
對于擁有強大資源和技術(shù)實(shí)力的軟件廠(chǎng)商，在平臺和生態(tài)的建設投入上會(huì )更加宏達，例如阿里云、用友等，其開(kāi)放平臺已經(jīng)不能簡(jiǎn)單的用PaaS來(lái)概括，而是構建了完整的企業(yè)級應用生態(tài)運行的底座和操作系統，意圖打通一切應用，鏈接所有信息和服務(wù)。
本節我們討論功能層面，軟件產(chǎn)品從定制化到產(chǎn)品化的演進(jìn)路勁。
對于“土豪”廠(chǎng)商，產(chǎn)品化的過(guò)程可以一步到位，一次實(shí)現所有理論上該有的標準功能；但對于創(chuàng )業(yè)公司來(lái)講，研發(fā)資源有限，產(chǎn)品化的路徑必須謹慎選擇，讓每一分錢(qián)都花在刀刃上，讓每一個(gè)功能都在合適的時(shí)機上線(xiàn)。
在企業(yè)級領(lǐng)域，產(chǎn)品化的前身往往是項目制，從第一個(gè)種子客戶(hù)使用的充滿(mǎn)了硬編碼的定制版，一步一步發(fā)展到功能靈活的標準化產(chǎn)品。
對于資源有限的創(chuàng )業(yè)團隊，在創(chuàng )業(yè)前期，重點(diǎn)是驗證市場(chǎng)，打磨核心產(chǎn)品能力，沒(méi)有必要實(shí)現所有的標準化功能。舉個(gè)最簡(jiǎn)單的例子，早期客戶(hù)只有十幾個(gè)，對客戶(hù)痛點(diǎn)都還沒(méi)摸索清楚，有必要就做一套靈活訂制的視圖編輯器么？顯然沒(méi)有必要。
在軟件產(chǎn)品的各個(gè)模塊和組件中，從最死板的硬編碼，到最靈活的配置化，有著(zhù)可遵循的演變路徑，不同產(chǎn)品可以根據自身的情況，選擇不同的軌跡和策略，來(lái)逐步完成產(chǎn)品化的建設。
從配置化訴求最低的自研自用系統，到逐步產(chǎn)品化的階段I、II、III，下表是我總結了不同板功能塊可能的產(chǎn)品化的思路。
產(chǎn)品化過(guò)程中各個(gè)組件模塊的演化路徑
表格中已經(jīng)非常清楚的描述了方案的演化路徑，因此不再贅述解釋。需要注意的是，并不是所有產(chǎn)品都必須演化到最終的形態(tài)，最終的形態(tài)并不一定適用于所有產(chǎn)品類(lèi)型。
例如，某針對中小餐飲連鎖品牌的運營(yíng)管理產(chǎn)品，不同客戶(hù)雖然有不同訴求，但還遠沒(méi)有復雜到需要自定義實(shí)體數據對象的程度，面對明確的客群，系統背后的數據模型是穩定的，最多需要給不同客戶(hù)配置不同的字段，因此，這款產(chǎn)品，在模型層，只需要實(shí)現階段I的“預留擴展字段”的方案，就足以支撐業(yè)務(wù)了，完全沒(méi)有必要去開(kāi)發(fā)模型編輯器、表單編輯器這類(lèi)復雜的底層產(chǎn)品能力。
IT研發(fā)中心，在企業(yè)中一般屬于成本中心，不論是企業(yè)自身為了尋找第二增長(cháng)曲線(xiàn)，還是IT團隊為了提升地位和影響力，在國內有很多公司選擇將IT團隊分化出去，成立科技公司，嘗試將自研自用的軟件，進(jìn)行商業(yè)化運作，對外售賣(mài)。
這些嘗試產(chǎn)品化、商業(yè)化的公司中，有些成功了，有些失敗了，有些則變成了項目制運作，不停地擴充人力，給客戶(hù)做定制化開(kāi)發(fā)。
自研軟件系統，和商業(yè)化軟件系統，不論從產(chǎn)品形態(tài)、技術(shù)架構、商業(yè)運作模式來(lái)講，都是完全不同的“物種”，自研系統商業(yè)化，當然可以選擇嘗試，但之前一定要想清楚這些問(wèn)題。
下表列示了兩類(lèi)產(chǎn)品形態(tài)的對比，供大家參考。
自研系統和商業(yè)化產(chǎn)品的對比
上表中關(guān)于自研系統產(chǎn)品經(jīng)理能力一項，描述為業(yè)務(wù)思維>軟件設計思維，并不是說(shuō)針對自研系統，產(chǎn)品經(jīng)理的軟件設計能力不重要，而是想強調，做內部系統，首先要解決業(yè)務(wù)問(wèn)題，軟件工程實(shí)踐上的架構、抽象、建模等復雜設計問(wèn)題優(yōu)先級都可以往后放。
從上表的對比，我們也可以看出，自研系統和商業(yè)化產(chǎn)品區別較大，如果企業(yè)決定將自研系統對外售賣(mài)，大概率需要將系統從原有的應用環(huán)境中解耦出來(lái)，并且進(jìn)行全面的重構，否則很難支持不同客戶(hù)的不同需求，而這些抽象設計能力，原團隊并不一定擅長(cháng)，或者需要很長(cháng)的時(shí)間積累和沉淀。
更重要的是，軟件商業(yè)化售賣(mài)，不單純是產(chǎn)品問(wèn)題，更是業(yè)務(wù)運作問(wèn)題，如何組件市場(chǎng)、銷(xiāo)售團隊，完成種子客戶(hù)的開(kāi)發(fā)與拓展，期間面臨d的挑戰，和創(chuàng )業(yè)公司是一樣的，而IT團隊的負責人，畢竟在商業(yè)化和業(yè)務(wù)管理上的經(jīng)驗欠缺一些，直接管理科技公司的商業(yè)化運作，挑戰不小。
當然，自研系統商業(yè)化，也有著(zhù)自身的優(yōu)勢。如果企業(yè)本身在行業(yè)中屬于頭部標桿，那么自己使用的軟件系統，相當于融入了業(yè)務(wù)管理和運作的最佳實(shí)踐，潛在客戶(hù)一定對此非常有興趣和意愿。但問(wèn)題又來(lái)了，自研系統的潛在客戶(hù)，都是原公司業(yè)務(wù)的競爭對手，那么該不該用自己的系統去賦能競爭對手呢？如果不這么做，自研系統的優(yōu)勢和價(jià)值又體現在哪里呢？
所以，自研系統商業(yè)化，最核心的問(wèn)題，還是要先想清楚商業(yè)目的。
產(chǎn)品化的過(guò)程中，必然會(huì )涉及到PaaS、aPaaS、低代碼這些概念。通過(guò)9.3章節的分享，大家應該比較深刻的理解了軟件平臺底層配置化能力的核心，這也是PaaS平臺的本質(zhì)。本節，我們進(jìn)一步探討PaaS相關(guān)的概念，以及低代碼平臺。
在業(yè)界，圍繞PaaS，有眾多概念，很容易讓新手眼花繚繞，十分困惑，我們將之前介紹過(guò)的標準產(chǎn)品架構圖做一些調整，進(jìn)一步闡述解釋不同概念的區別和定義，如下圖。
云計算模式下的標準產(chǎn)品架構圖
SaaS（Software as a Service）：SaaS位于架構最上層，提供開(kāi)箱即用的軟件服務(wù)，一般認為SaaS聚焦于終端用戶(hù)使用的應用層。
aPaaS（application Platform as a Service）：SaaS的底層配置、定制化平臺，例如流程編輯器、對象編輯器，都是典型的aPaaS能力組件。aPaaS更聚焦于應用程序的定義和配置，屬于PaaS的子集。
PaaS（Platform as a Service）：PaaS比aPaaS的范圍更大，進(jìn)一步涵蓋了技術(shù)層面的組件和模塊，例如消息中間件、運維自動(dòng)化等，也包括軟件的編譯、發(fā)布、運行時(shí)環(huán)境。很多時(shí)候我們提到PaaS，總是等同于aPaaS，主要聚焦于應用配置和定制開(kāi)發(fā)能力；
IaaS（Infrastructure as a Service）：云計算架構的最底層，負責存儲、網(wǎng)絡(luò )、算力等資源的管理和調度；
需要注意的是，上圖中不同功能模塊所處的層次，僅僅是示意性質(zhì)的總結，分類(lèi)的方式并沒(méi)有絕對的標準和對錯，大家要避免陷入對細節和概念的糾結，更重要的是理解這些邏輯分層的特點(diǎn)和背后的思考。例如，你可以認為配置管理屬于aPaaS層而非SaaS層，也可以認為視圖層的報表引擎和動(dòng)態(tài)儀表盤(pán)，屬于PaaS能力的一部分，這都是正確的說(shuō)法。
除了以上名詞，還有一些很重要的概念需要大家了解：
Low Code（低代碼）：通過(guò)拖拉拽等GUI交互界面與適量的微小代碼開(kāi)發(fā)應用系統的方式，由咨詢(xún)公司Forrester于2014年提出，注意這個(gè)概念首次提出時(shí)，Forrester并未明確指出低代碼必須基于云計算架構實(shí)現；
No Code（無(wú)代碼）：相對于低代碼的概念，完全不用編碼即可實(shí)現應用程序開(kāi)發(fā)，起源已無(wú)從考證；
LCAP（Low Code Application Platform）：Gartner于2019年提出，更加豐富的低代碼平臺，融合了低代碼、aPaaS等概念；
習慣上，我們將SaaS的底層研發(fā)平臺叫做PaaS（或aPaaS），PaaS的目標用戶(hù)是乙方實(shí)施團隊或甲方系統管理員；而低代碼產(chǎn)品（指基于云端部署的低代碼產(chǎn)品，后同），一般是指一類(lèi)獨立產(chǎn)品，不依賴(lài)于SaaS，目標用戶(hù)（之一）是非技術(shù)背景的公民開(kāi)發(fā)者。
另外，已經(jīng)很少有人刻意區分低代碼和無(wú)代碼了，一般低代碼公司都喜歡稱(chēng)自己為L(cháng)CAP，可能是因為業(yè)界翹楚Gartner將所有低代碼供應商都放在其每年發(fā)布LCAP的魔力象限報告中進(jìn)行統一打分。
低代碼并不是一個(gè)新穎的概念，其背后的核心能力——數據建模、流程自動(dòng)化、頁(yè)面自定義、權限管理等，早在大型商業(yè)化套裝軟件時(shí)代就已經(jīng)非常成熟，例如Oracle EBS和SAP都有類(lèi)似的功能。
將低代碼部署在云端，是這兩年才興起的，再加上產(chǎn)品功能越來(lái)越容易學(xué)習、使用，這就讓低代碼的應用場(chǎng)景和目標用戶(hù)群體更加豐富立體。如果說(shuō)以前的商業(yè)軟件套件中的低代碼只適合專(zhuān)業(yè)的需求分析師和實(shí)施人員使用，那么現在的低代碼目標用戶(hù)已經(jīng)拓展到了非技術(shù)背景的業(yè)務(wù)專(zhuān)家。
公民開(kāi)發(fā)者（Citizen Developer）是伴隨低代碼興起的概念，根據Gartner的定義，公民開(kāi)發(fā)者是指這樣一些企業(yè)員工，他們可以使用IT授權的工具，來(lái)創(chuàng )建自用或給伙伴使用的應用系統；是一種角色畫(huà)像，而非具體某個(gè)崗位，他們往往屬于業(yè)務(wù)部門(mén)，而非IT部門(mén)。
可以說(shuō)，低代碼廠(chǎng)商，很重要的商業(yè)模式之一，就是希望將產(chǎn)品賣(mài)給非IT背景的業(yè)務(wù)用戶(hù)，方便他們低成本、高效率的創(chuàng )建、管理、使用業(yè)務(wù)軟件系統。
Gartner公司每年都會(huì )對不同IT領(lǐng)域的廠(chǎng)商進(jìn)行打分排序，即行業(yè)內知名的魔力象限圖，下圖是2021年Gartner LCAP魔力象限圖，列示了全球領(lǐng)先的低代碼廠(chǎng)商。
2021 Gartner企業(yè)級LCAP魔力象限
國內習慣將低代碼產(chǎn)品按照數據模型實(shí)現的方式分為模型驅動(dòng)模式、表單驅動(dòng)模式兩類(lèi)，除此之外還有比較特別的一類(lèi)，即表格模式（在這里我們姑且稱(chēng)為表格驅動(dòng)模式，業(yè)界并沒(méi)有統一的叫法），這幾類(lèi)形態(tài)不僅技術(shù)實(shí)現方式不同，目標用戶(hù)群體和整體產(chǎn)品設計理念更是不同。
核心特點(diǎn)：通過(guò)數據對象編輯器的方式來(lái)完成底層數據建模，功能強大、靈活；
目標用戶(hù)：具備IT背景的研發(fā)人員、需求分析師、項目經(jīng)理；
代表產(chǎn)品：Mendix、OutSystem、Salesforce等；下圖是全球知名低代碼產(chǎn)品Mendix Windows客戶(hù)端版本的模型編輯器截圖，可以看出，Mendix的使用界面非常復雜，已經(jīng)非常接近研發(fā)人員使用的IDE（Integrated Development Environment）工具。
Mendix Studio Pro 8模型編輯器界面
一般比較復雜的業(yè)務(wù)型SaaS產(chǎn)品背后的PaaS平臺也都采用了模型驅動(dòng)的建模方式，例如9.3.2小節展示的Salesforce，國內的銷(xiāo)售易、紛享銷(xiāo)客、北森等。因為模型驅動(dòng)的產(chǎn)品，需要用戶(hù)具備一定的IT能力，所以這類(lèi)低代碼產(chǎn)品不論是頁(yè)面編輯功能，還是流程編排功能，專(zhuān)業(yè)性都更強，當然也比較難上手使用。
核心特點(diǎn)：通過(guò)配置表單的形式來(lái)完成數據建模，容易理解和上手使用；
目標用戶(hù)：非IT背景的業(yè)務(wù)人員；
代表產(chǎn)品：Jira、釘釘宜搭，下圖是釘釘的低代碼平臺宜搭的表單編輯界面，從界面交互就能看出其易用性更勝一籌，但靈活性和擴展性必然會(huì )受到限制；
釘釘宜搭表單編輯界面
一般輕量級的SaaS，如果需要PaaS底層，會(huì )選擇表單驅動(dòng)的方式，研發(fā)成本低，靈活性足夠支撐業(yè)務(wù)場(chǎng)景，并且容易使用，例如Jira、Trello等；表單驅動(dòng)模式，目標用戶(hù)是非IT背景人員，相關(guān)的流程自動(dòng)化、頁(yè)面定義功能也都比較簡(jiǎn)單易用，定制化能力也會(huì )更弱一些。
核心特點(diǎn)：用戶(hù)像在使用Excel表格一樣實(shí)現數據模型的定義，表格模式是一種更加簡(jiǎn)單、便捷、易用的低代碼產(chǎn)品形態(tài)；
目標用戶(hù)：非IT背景的業(yè)務(wù)人員；
代表產(chǎn)品：Airtable、飛書(shū)多維表格，下圖是Airtable的主界面，可以發(fā)現整體交互風(fēng)格非常像Excel的表格管理與數據透視表功能。
Airtable的主界面
表格驅動(dòng)模式的低代碼平臺是一種更加輕量級的產(chǎn)品設計方案，任何熟練使用Excel和數透表的用戶(hù)，只要具備基本的數據關(guān)聯(lián)性抽象設計的思維，都可以快速上手搭建系統。在體驗這類(lèi)產(chǎn)品時(shí)，我甚至恍惚以為自己在用Excel 簡(jiǎn)化版VBA。
低代碼和PaaS（嚴格講是aPaaS）本質(zhì)上是相通的，PaaS更多的強調作為SaaS的底座存在，對于SaaS公司來(lái)講，PaaS首先要解決的是產(chǎn)品定制化過(guò)程中的成本問(wèn)題，覆蓋更多的行業(yè)和客戶(hù)群體，建設過(guò)程要圍繞SaaS業(yè)務(wù)的核心數據底層模型與產(chǎn)品形態(tài)而開(kāi)展，在此基礎之上，可能會(huì )開(kāi)放PaaS平臺給客戶(hù)獨立使用，創(chuàng )建獨立應用。
例如，客戶(hù)完全可以使用Salesforce的PaaS平臺創(chuàng )建和CRM無(wú)關(guān)的業(yè)務(wù)應用，Salesforce的應用商店中就有大量HR、財務(wù)、供應鏈等領(lǐng)域的應用，當然，如果基于PaaS創(chuàng )建的第三方應用能?chē)@SaaS本身的業(yè)務(wù)場(chǎng)景去做拓展，基于底層的數據模型構建應用生態(tài)，則會(huì )更加如魚(yú)得水。
PaaS并不是為了單獨售賣(mài)而存在，PaaS首先要服務(wù)于主產(chǎn)品（可能是SaaS，也可能是私有化部署的商業(yè)軟件），而且有些情況之下還會(huì )受限于主產(chǎn)品，例如在Jira的PaaS平臺中自定義數據對象時(shí)，就必須符合Jira基于項目管理業(yè)務(wù)的最低要求，而不能隨意做出定義。
所以，我們會(huì )發(fā)現Gartner的企業(yè)級LCAP魔力象限圖中，既有Mendix、OutSystem這樣的專(zhuān)門(mén)從事低代碼的獨立廠(chǎng)商，也有Salesforce、ServiceNow這樣的SaaS公司。
低代碼產(chǎn)品的確可以大大縮短業(yè)務(wù)型應用系統的開(kāi)發(fā)周期，但因為其提供的組件、框架都是固定的，必須在限定的功能范圍內進(jìn)行開(kāi)發(fā)，拓展性必然會(huì )受到制約；雖然低代碼很容易上手使用，但是業(yè)務(wù)型軟件系統最難的部分并不是交互，而是背后的數據模型設計和業(yè)務(wù)規則的提煉抽象，即便公民開(kāi)發(fā)者可以不具備IT背景，但必須擁有很好地建模知識和抽象設計思維，否則難以抽象出一套軟件系統，因此多少需要受到一些需求分析和建模的專(zhuān)業(yè)訓練。
對于大中型企業(yè)，低代碼常應用于非核心業(yè)務(wù)場(chǎng)景中，用來(lái)解決局部的、個(gè)性化的業(yè)務(wù)問(wèn)題，實(shí)現業(yè)務(wù)線(xiàn)上化，這是很有意義的；如果是核心業(yè)務(wù)系統，基于安全性和拓展性的考慮，可能不太會(huì )選擇低代碼產(chǎn)品。
對于小微型企業(yè)，如果存在一些飛書(shū)、釘釘這類(lèi)比較便捷數字化工具無(wú)法覆蓋的業(yè)務(wù)場(chǎng)景，用低代碼來(lái)快速支持，是個(gè)不錯的選擇。
聯(lián)系客服
