近期學(xué)習(xí)低代碼產(chǎn)品的設(shè)計理念，在不同平臺上看到了很多觀點，有的人認為低代碼技術(shù)是福音，特別是國內(nèi)外IT大廠的官方說法，總體對其保持樂觀態(tài)度。也有很多人拋出了低代碼簡直就是“毒瘤”的觀點。 在學(xué)習(xí)過程中，尤其是了解新事物的過程中，我們始終都應(yīng)該帶著批判性的思維去看待各種觀點，與直接認同某個看起來正確的觀點相比，深入了解發(fā)言人的立場、了解他為什么抱有這種觀點，才是更高層次的學(xué)習(xí)方式。 01 為什么不看好？低代碼所處的位置比較尷尬，很多人認為其恰恰處于一個半吊子的位置。尤其是從大多數(shù)程序員的視角來看，低代碼這個東西的定位非常雞肋。 首先，對于非技術(shù)人員，比如產(chǎn)品、運營、銷售甚至是甲方客戶來說，低代碼的操控并不算便捷，上手是有一定難度的，并且還需要系統(tǒng)的學(xué)習(xí)，才能初步掌握其使用方法。 而對于開發(fā)者來說，低代碼的自由程度和靈活性跟真正的代碼肯定無法比擬，一些用戶的靈活需求，如果要是一開始設(shè)計的低代碼系統(tǒng)能配置還好，如果不能配置，最終還是得在底層進行修改，而且修改起來肯定比直接按需開發(fā)的系統(tǒng)費勁的多。 這個東西就像混動汽車一樣充滿爭議，混動汽車的動力系統(tǒng)介于油車和電車之間。認為它好的人，認為它平時既能燒電省錢，萬一充不上電還可以加油續(xù)航，不用擔(dān)心趴窩，滿眼都是它的優(yōu)點?？床黄鸹靹悠嚨娜?，認為它燒起油來比油車費油的多，動力又不太足，總之滿是槽點。 其實，無論是用來舉例的混動汽車也好，還是低代碼這個工具也好，處在中間位置的這類工具，必然是優(yōu)劣兼具，甚至還將某些優(yōu)勢和劣勢進行了放大。關(guān)鍵還是要明確使用場景和使用者，之后恰當?shù)厥褂迷摴ぞ?，從而揚長避短。 講到這里，我們需要明確低代碼這一工具，真正的使用者應(yīng)該是誰。筆者認為，應(yīng)該是數(shù)字化轉(zhuǎn)型技術(shù)廠商的“產(chǎn)品運營”或“售后/售前技術(shù)支持”?？偠灾瑧?yīng)該交給乙方的非技術(shù)人員使用。這些專門人員在經(jīng)過合理的上崗培訓(xùn)后，也會熟練使用低代碼工具。 與此相匹配的工作流程是：產(chǎn)品研發(fā)者在大量項目中不斷積累經(jīng)驗，開發(fā)出不同場景下對應(yīng)的低代碼產(chǎn)品，之后由乙方非技術(shù)人員操刀，通過與客戶進行持續(xù)溝通，使用低代碼工具為同場景下不同的客戶配置并交付符合其使用習(xí)慣的最終平臺，并在實際使用過程中發(fā)現(xiàn)問題，提出需求，為研發(fā)團隊迭代優(yōu)化低代碼產(chǎn)品提供依據(jù)。
（圖片來源：點維數(shù)智PM原創(chuàng)） 02 數(shù)智化，走向標準還是定制任何一家提供數(shù)字化轉(zhuǎn)型服務(wù)的技術(shù)廠商都會告訴你，不同行業(yè)、甚至同一個行業(yè)的不同公司，數(shù)字化產(chǎn)品的設(shè)計都是千差萬別的。然而等他們以各種方式拿下項目后，研發(fā)人員一定都會想著在做系統(tǒng)時，能不能照搬和復(fù)用之前做過的系統(tǒng)，實在不濟，參考著改一下也行。 數(shù)字化轉(zhuǎn)型產(chǎn)品，到底是走向標準化還是定制化，其實是一個難以抉擇的問題。對于數(shù)字化轉(zhuǎn)型解決方案提供商來說，走標準化路線意味著可以大量、快速地復(fù)制并推廣其產(chǎn)品，從而極大減少邊際成本，實現(xiàn)持續(xù)盈利，也可以薄利多銷，讓數(shù)字化轉(zhuǎn)型技術(shù)普惠更多受眾。 另一方面，基于用戶使用體驗來說，客戶也期望看到數(shù)字化轉(zhuǎn)型服務(wù)商深入其一線調(diào)研，并對其實際出現(xiàn)的問題進行深刻的理解，并最終交付與其業(yè)務(wù)流程高度匹配的產(chǎn)品?？蛻舻南敕ㄒ埠芎唵危骸?strong>既然我給你錢了，那你的眼里只能有我，不要拿給別人做的東西復(fù)制過來糊弄我?！?br> 而筆者個人的看法是，數(shù)字化產(chǎn)品也趨向于走入標準和定制的中間態(tài)模式。當然，這種和稀泥的結(jié)論，也意味著產(chǎn)品設(shè)計者需要結(jié)合具體情況，審時度勢，能力要求和主動程度都需要進行大幅度的提升。 在瀏覽過大量的項目案例后，筆者發(fā)現(xiàn)，在很多產(chǎn)品場景中，使用低代碼可以很好地解決系統(tǒng)在標準化和定制化之間的平衡問題。 流程引擎其實就是一個非常好的例子。目前很多低代碼或零代碼產(chǎn)品，都習(xí)慣性地往OA工具上發(fā)展，這就是因為低代碼高度靈活性和可配置性的特點，實實在在解決了企業(yè)審批系統(tǒng)的痛點。 比如說，一個大型制造業(yè)企業(yè)中，不同事業(yè)部、不同部門和不同產(chǎn)線上，審批流程花樣百出。還有的需要加很多規(guī)則在里邊，例如“資金超過200需要領(lǐng)導(dǎo)審批，低于200自動通過”。再加上頻繁的人事調(diào)動，也意味著審批環(huán)節(jié)上的每個人都需要及時更新。 假如所有的流程都是研發(fā)同事們直接開發(fā)出來的，那對于這種變動非常頻繁，規(guī)則復(fù)雜且繁雜的應(yīng)用場景，幾乎每天都需要不斷迭代，耗費大量開發(fā)精力。 所以，如果OA系統(tǒng)靈活可配置，在日常運營過程中，即使流程千變?nèi)f化，也只需要安排一些普通員工隨時配置即可?，F(xiàn)在的OA工具，低代碼基本已經(jīng)占據(jù)主導(dǎo)，但在其他領(lǐng)域，筆者認為，這種產(chǎn)品理念貫徹地還不夠深入。
（圖片來源：點維數(shù)智PM原創(chuàng)） 接下來，筆者將通過自己設(shè)計的產(chǎn)品案例，來進行低代碼這一產(chǎn)品理念在產(chǎn)品設(shè)計中應(yīng)用的復(fù)盤。在實際項目中，筆者對這兩個產(chǎn)品進行了大膽創(chuàng)新，雖然還有很多地方需要完善，但這兩個案例，在低代碼解決數(shù)字化項目中標準與定制之間矛盾的問題上，已初具雛形。 03 案例：樓宇自控項目復(fù)盤樓宇自控系統(tǒng)一般會在智慧樓宇項目中體現(xiàn)。我們平日所見的高樓大廈，內(nèi)部都安裝著復(fù)雜的電氣設(shè)備，來保障樓宇內(nèi)環(huán)境的舒適。其中包括調(diào)節(jié)溫度的空調(diào)系統(tǒng)、保持室內(nèi)環(huán)境清新的送排風(fēng)系統(tǒng)、以及常見的給排水系統(tǒng)、變配電系統(tǒng)、照明系統(tǒng)等。 樓宇內(nèi)各種系統(tǒng)的詳細工作原理，日后再與大家做詳細討論。在數(shù)字化項目中，針對樓宇自控系統(tǒng)，我們一般需要做如下功能：
筆者在設(shè)備臺賬管理、數(shù)據(jù)監(jiān)控和下發(fā)控制命令層面，引入了低代碼的設(shè)計理念，設(shè)計了一套自由，可配置化程度比較高的通用型產(chǎn)品。 首先，要想實現(xiàn)樓宇自控的基礎(chǔ)功能，大體需要規(guī)劃兩個模塊，一個是軟件平臺，另一個是協(xié)議解析模塊。 先說協(xié)議解析模塊，如果我們遇到比較好的硬件商家，從系統(tǒng)平臺上直接提供API接口，那開發(fā)就可以直接寫代碼對接了，省時省力。如果硬件商家提供的是遵循某個協(xié)議的數(shù)據(jù)傳輸服務(wù)，那我們就需要解析協(xié)議，并封裝成標準接口或消息推送，常見的物聯(lián)網(wǎng)傳輸協(xié)議包括obix、modbus等。 總之，提供給軟件平臺的，必然是已經(jīng)封裝好的標準化接口，按照以往的開發(fā)方式，我們都會先按照客戶需求，開發(fā)好對應(yīng)的界面，之后由開發(fā)同事進行接口對接，提取數(shù)據(jù)進行分析，并做一些按鈕，下發(fā)控制指令。 這樣做的劣勢是，系統(tǒng)的定制化屬性太強，特別還是智慧樓宇這種，不同客戶差異性比較大的項目，幾乎每換一個客戶，都要重新開發(fā)一次。而且還需要拿到所有電氣及弱電系統(tǒng)的點位、設(shè)計圖之后，才能進行分析、開發(fā)，不僅開發(fā)量大，工期也難以保障。 所以，為了使系統(tǒng)更為靈活，筆者從數(shù)據(jù)角度出發(fā)，對點位數(shù)據(jù)進行分類整理，設(shè)計了一套智慧樓宇低代碼產(chǎn)品。產(chǎn)品部署完成后，可以由非技術(shù)人員進行配置，在拿到設(shè)備點表以及接口列表后，可以快速配置并上線。
（圖片來源：點維數(shù)智PM原創(chuàng)） 對智慧樓宇場景下的數(shù)據(jù)來說，如果按照數(shù)據(jù)類型來劃分，總共也就數(shù)字類型和模擬類型兩種。工科的同學(xué)可能清楚，數(shù)字類型無非就是0或1，例如設(shè)備的開和關(guān)，設(shè)備的在線/離線，就可以用0和1來代替。模擬類型則代表連續(xù)值，例如溫度值、濕度值等連續(xù)且可以在一定范圍內(nèi)任意取值的數(shù)據(jù)指標。當然，在實際場景中，受制于設(shè)備采集精度，也只能取離散值。 如果按照功能類型來劃分，所有的數(shù)據(jù)分為兩種，采集數(shù)據(jù)和控制數(shù)據(jù)。例如某些接口中的數(shù)據(jù)，我們需要調(diào)用接口將其采集上來，而某些接口中的字段，我們可以通過調(diào)用進而控制其開關(guān)或進行溫度、濕度等數(shù)值的設(shè)定。 基于此，我們可以開始設(shè)計智慧樓宇低代碼管理系統(tǒng)的雛形。首先，在主頁面設(shè)置一個列表，列表橫向分為三個區(qū)，一是設(shè)備信息區(qū)，用來導(dǎo)入設(shè)備臺賬；二是數(shù)據(jù)采集區(qū)，用來讀取各個點位所檢測的數(shù)據(jù)；三是控制指令區(qū)，用來手動發(fā)送控制指令。 在設(shè)備信息區(qū)，我們可以添加一個導(dǎo)入功能，將設(shè)備臺賬中的設(shè)備導(dǎo)入進去，并且獲取其設(shè)備ID。這樣就可以明確，每一行數(shù)據(jù)在調(diào)接口時，采集的是哪個設(shè)備的信息。當然，在設(shè)備信息區(qū)，我們也可以隨設(shè)備臺賬加入其他設(shè)備屬性，例如設(shè)備名稱、設(shè)備位置、設(shè)備自定義編碼等。 在數(shù)據(jù)采集區(qū)，我們可以逐個為指定設(shè)備添加一個個需要采集上來的字段，在配置每一個字段時，我們需要配置以下幾點信息：
控制指令區(qū)與數(shù)據(jù)采集區(qū)的道理基本相同，我們在控制指令區(qū)配置控制字段時，每個字段都需要配置字段名稱、字段類型、接口地址和對應(yīng)字段這幾項，不同的是，數(shù)據(jù)采集區(qū)錄入的對應(yīng)字段要從接口的輸出值中找，而控制指令區(qū)錄入的對應(yīng)字段要從接口的輸入值中找。
（圖片來源：點維數(shù)智PM原創(chuàng)） 04 物模型以上章節(jié)都是在沒有相關(guān)理論知識儲備的情況下，作為一個新入門的產(chǎn)品經(jīng)理，在行業(yè)通用產(chǎn)品的設(shè)計過程中普遍的思考邏輯。 在對市面上成熟的物聯(lián)網(wǎng)平臺產(chǎn)品進行使用和分析后，我們可以發(fā)現(xiàn)，雖然與低代碼工具有一定差別，但物聯(lián)網(wǎng)平臺要實現(xiàn)其靈活性，貫徹低代碼的理念是非常重要的。 面對復(fù)雜多樣的物聯(lián)網(wǎng)設(shè)備，現(xiàn)行的通用且先進的解決方案是將具有同一類功能的設(shè)備定義為一個產(chǎn)品，之后為這個產(chǎn)品匹配物模型。物模型在物聯(lián)網(wǎng)平臺中也是一個重要的概念，受篇幅限制，本次只進行簡單介紹，后續(xù)有機會我們可以詳細拆解。 當我們把同一類功能相同的設(shè)備集合成一個產(chǎn)品后，對產(chǎn)品物模型的定義，要從三個維度進行，分別是屬性、服務(wù)和事件。
物模型定義好以后，相當于在物聯(lián)網(wǎng)軟件平臺上構(gòu)建好了相關(guān)設(shè)備的虛擬數(shù)字化實體，該虛擬實體實時映射實際設(shè)備，而我們接下來在搭建應(yīng)用時，如設(shè)備臺賬、設(shè)備巡檢、組態(tài)可視化、邏輯編排等，可以直接面向已經(jīng)設(shè)置好物模型的虛擬數(shù)字化實體進行操作。所謂數(shù)字化的第一步——數(shù)據(jù)采集，我們也算踏過了其中一個門檻。 本文由 @點維數(shù)智空間 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載 題圖來自 Unsplash，基于 CC0 協(xié)議 該文觀點僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù) |
