低代碼開發平臺選型三大要素

低代碼開發平臺如今火的一塌糊塗！低代碼開發平臺已經爲大多數軟件公司和終端企業所接受，這着實是喜事一件！但**面對國內五花八門的低代碼開發平臺，大家又不免陷入幸福的煩惱——該如何選型靠譜的低代碼開發平臺呢？**廢話不多說，我把這些年來在甲方、乙方做信息化建設積澱下來的開發平臺選型心得分享給大家，姑且算是拋磚引玉吧：

一、過硬的開發技術功力（技術）

打鐵還需自身硬，作爲開發軟件的軟件，一款靠譜的低代碼開發平臺毫無疑問應該具備過硬的開發技術功力！微服務架構有木有？真正微服務還是僞微服務？多租戶模式有木有？可以跨域流程審批嗎？容器部署有木有？性能測試報告拿得出嗎？自主核心技術（如流程引擎）有木有？全部開源的東西來拼湊？倒不是說具體選型時這些要素都得滿足，而是告訴大家從這些要素可以大致判斷出這款低代碼開發平臺的技術功力。

怎麼個判斷技術功力法呢？不管是可視化的托拉拽快速配置能力還是視覺層面不太容易見的接口集成能力，**一看產品介紹、二做技術交流、三做平臺測試！PPT能造假，但沒有真正硬實力技術交流就容易露餡，如果對方真的很能扯那還有平臺測試來把關！等等，可是國內宣稱能夠事低代碼開發平臺產品和服務的公司已經多達近百家，這什麼時候才能選到頭？又或者我們自身的IT實力就不是很強，那怎麼辦？行，那就教大家一個簡單粗暴的辦法，沒有專注低代碼開發平臺領域十年以上的公司不選！**理由很簡單，技術是個講究積澱的東西，能夠經得起十年以上的歲月跌宕還仍然屹立不倒那技術差不了。

二、豐富的業務領域知識（業務）

什麼是業務？這裏的業務說的是解決方案或案例，爲什麼業務知識如此重要？那是因爲我們購買低代碼開發平臺不是用來看的，而是要應用它並指望其能給企業賺錢、幫助企業提升經營管控水平的！但我在《國內低代碼開發平臺發展現狀》一文中給大家明確的指出：國內各家低代碼開發平臺設計理念和業務擅長相差很大，有的擅長複雜業務流程處理、有的擅長數據填報分析、有的擅長APP/小程序定製，不考慮業務匹配性就極有可能導致驢脣不對馬嘴！

那怎麼考察低代碼開發平臺的業務知識呢？**一看解決方案、二做方案交流、三做案例演示！**解決方案網上是能抄但方案交流就不是那麼好矇混過關的，**沒有親自接觸甚至理解實際業務你一聽就知道是水貨，**案例系統演示更加絕了，甭管他們和你說多少好話、甭管他們給你灌多少酒，你就要求把平臺做過的案例系統拿出來看看，是騾子是馬溜溜就知道啦！

三、創新的本地交付服務（服務）

你們在北京有辦事處嗎？你們在上海有分公司嗎？你們在廣州的團隊是技術還是商務？類似的話語大家很熟悉吧，我非常能理解甲方的後顧之憂，但說真的這種對「物理本地化」的追求意義不大，因爲現代網絡通訊發達，絕大多數問題通過遠程即可處理！更爲關鍵的是，如果乙方的合作模式及服務機制不友好，哪怕乙方開在甲方隔壁甲方不掏錢恐怕也不頂用！

如何纔能有效消除甲方的後顧之憂呢？這就是我要和大家說的創新本地化服務：**一方面要能夠提供全源碼交付版本，讓甲方沒有受制於人的後顧之憂！二方面要提供培訓+聯合開發模式，幫助甲方掌握低代碼開發平臺工具和實施方法論，讓甲方沒有信息化建設的長遠之憂！**這纔是真正意義上的本地化！在這樣創新的合作模式和服務機制下，甲方專注於平臺在業務層面的應用，乙方專注於平臺本身的迭代和進化，雙方互利共贏！

總結：**低代碼開發平臺選型三要素=過硬的開發技術功力+豐富的業務領域知識+創新的本地交付服務！**低代碼開發平臺選型還有沒有其他思路或方法？那肯定是有的，但我這一套模型近年來真的是屢試不爽，幫助很多甲方找到了靠譜的平臺，也得到了不少乙方的認可，一般人我還真不願意告訴他，但獨樂了不如衆樂樂，若能給到大家一點點啓發我也就滿懷欣喜了！

另外對下期文章做個預告，看到很多網友對於低代碼平臺的發展歷史不是很清晰，甚至存在較爲嚴重的誤判，我準備對此做一個大致梳理和簡介~