前段時間做調研，發現國內除了阿里云、華為云、騰訊云，很多PaaS企業，包括涂鴉（IOT PaaS）、有贊（有贊云PaaS）、徐工、吉利（工業互聯PaaS）、恒生電子（Light云）等等，都正在推出或者計劃推出低代碼應用開發平臺。文章嘗試通過對應用軟件研發發展階段的分析，提供一個看待這一趨勢的視角。

第一階段，面向用戶直接需求的應用軟件研發

雖然軟件廠商跟互聯網企業有諸多不同，但是他們也有一個較為明顯的共同點，就是幾乎所有的研發投入都聚焦在面向用戶直接需求的應用研發上（軟件廠商主要是面向企業經營管理需求、互聯網企業主要是面向個人工作生活的需求），很少有專門為應用集成研發的產品，也很少有專門為應用研發團隊提供服務的研發團隊。這一情況類比到制造業，幾乎所有的軟件廠商和互聯網公司都是成品廠商，沒有零部件廠商。所以我把這個階段歸納為“面向用戶直接需求的應用軟件研發”。

但是社會發展充分證明了分工可以提升效率實現創新，于是在應用軟件研發領域PaaS和中臺就出現了。

第二階段，PaaS服務（中臺）

PaaS的出現實際上是對應用軟件研發活動和程序員職責的一種分層，通過分離關注點、提升專業度和能力復用，降低應用軟件研發的整體復雜度和提升效能。PaaS和中臺起始于互聯網，但是深刻影響到企業軟件服務領域。關于PaaS和中臺的討論非常多，大家了解也比較多，這里就不啰嗦了。但是需要說明的是一點是，由于種種原因，起初企業構建的PaaS（中臺）往往只服務于企業內部，這實際上限制了PaaS發揮的價值。

第三階段，開放平臺

開放平臺的主要目的是PaaS能力的開放，把原先只面向企業內提供能力 轉變為面向其他企業、組織甚至個人提供。這里有兩點值得關注：

• 開放平臺主要目的是PaaS能力的開放。這意味著使用這些能力的企業、組織和程序員怎么用這些能力、用來做什么、能否用好，其實并不是平臺關注的核心，管理的手段也較為有限。

• 開放平臺創造了增量，但增量有限。各種PaaS開放平臺的推出，使得某些應用軟件的構建成本大幅下降，使得很多創新企業或ISV通過組織小規模的研發團隊也逐漸具備研發、交付較復雜的應用軟件的能力，這是開放平臺產生的增量。但由于PaaS開放平臺先天定位的不足，使它的增量價值受到較大局限。

• 產品經理的困境是，如果API/SDK設計過于抽象，就會有程序員來吐槽不好用；如果設計的較為具體，則容易限制使用場景。

• 解決方案設計經理的困境是，面對幾乎所有用戶需求場景，IM/視頻直播都只是必要條件而非充分條件。好比手上拿著最好的發動機和輪胎，但是客戶要一輛車，總得給找齊各種沒有的東西，還得說清楚怎么組裝，這其實是挺復雜的事情。
• 解決方案交付經理的困境是，要把解決方案架構師畫在PPT上的應用解決方案給實現出來交付出去，就得組織合適的研發資源，但由于這不是PaaS平臺核心的業務，因此只能找生態伙伴來做。一來項目效率和質量得不到保證，二來項目交付可能無法留下有價值軟件資產，項目二期迭代的時候，可能也會遇到種種困境。他需要一個既能做應用開發、又能沉淀軟件資產、并且能有效組織生態的平臺，但顯然PaaS開放平臺不適合這樣的定位。

第四階段，低代碼應用開發平臺（aPaaS）站上風口

• 對PaaS產品經理來說API/SDK被設計成各種低代碼的組件，成為低代碼應用設計體系內的一部分，可以有效降低學習和使用成本。

• 對解決方案設計經理來說，他原先畫在PPT上各種客戶解決方案可以變成低代碼平臺上的各種應用模版，可以有效拉近和客戶需求之間的距離。
• 解決方案交付經理來說，低代碼平臺可以有效解決客戶解決方案設計實現、資產沉淀、版本管理，規范生態伙伴的合作。

思考總結：

- END -

繼續閱讀：

未經允許不得轉載：RPA中國 | RPA全球生態 | 數字化勞動力 | RPA新聞 | 推動中國RPA生態發展 | 流 > 為什么PaaS平臺企業都在搞低代碼？