本文分享的是基于低代碼的敏捷式開發(fā)和在豫園實(shí)踐落地的一些成果，分解出來主要講三點(diǎn)：第一點(diǎn)是為什么需要低代碼？第二點(diǎn)是為什么低代碼需要配套敏捷式開發(fā)？敏捷式開發(fā)具體怎么做？第三點(diǎn)是我們做了什么？也就是敏捷開發(fā)模式在豫園體系中的一些實(shí)踐成果分享。

一、尋找一種新的技術(shù)框架

現(xiàn)在，我們來看一下為什么要選擇這種技術(shù)架構(gòu)。在早期，我們通常使用一些成熟的企業(yè)方案，使用傳統(tǒng)的開發(fā)方式或是直接購買一些套件。但是我們會(huì)發(fā)現(xiàn)，有兩種情況我們無法實(shí)現(xiàn)。

第一種情況，某些公司業(yè)務(wù)非常廣泛，在市場(chǎng)上可能會(huì)有很多解決方案，但是由于它的專業(yè)性，軟件價(jià)格比較昂貴。而且有些企業(yè)有比較特殊、復(fù)雜的管理要求，這些軟件實(shí)際上可能只有20%到30%的功能可以直接使用，仍需要進(jìn)行大量的開發(fā)才能滿足我們的需求，公司會(huì)認(rèn)為自己花了很多冤枉錢。舉個(gè)例子，比如我們成立一家實(shí)驗(yàn)室，實(shí)驗(yàn)室起初可能只有幾個(gè)人，我們?nèi)ベ徺I一套LIMS系統(tǒng)，別人的報(bào)價(jià)可能是70萬，實(shí)際上我們暫時(shí)不需要那樣復(fù)雜的流程和功能，公司可能希望初期只花5、6萬元去解決這個(gè)問題。

第二種情況，在后疫情時(shí)代，我們會(huì)發(fā)現(xiàn)業(yè)務(wù)變化特別快，數(shù)字化變得非常困難，因?yàn)閮?nèi)部管理和業(yè)務(wù)模式都在快速變化中。這種情況下，你無法在市面上找到直接可用的軟件，只能自己開發(fā)。傳統(tǒng)的開發(fā)方式起碼以季度去計(jì)量開發(fā)周期，等開發(fā)完，業(yè)務(wù)模式可能又更新了。

二、為什么會(huì)選擇低代碼技術(shù)

首先，我們需要一種新的技術(shù)架構(gòu)來應(yīng)對(duì)這些情況，低代碼技術(shù)在前幾年開始崛起。我們發(fā)現(xiàn)，一些低代碼公司在做專業(yè)的系統(tǒng)，如CRM系統(tǒng)，甚至一些公司還在做ERP系統(tǒng)，而ERP系統(tǒng)是可以檢驗(yàn)一個(gè)平臺(tái)質(zhì)量和框架的天花板；其次，低代碼可以結(jié)合傳統(tǒng)開發(fā)，突破限制，可以低成本實(shí)現(xiàn)小程序、H5、漂亮界面的軟件系統(tǒng)；最后也是最重要的一個(gè)原因，低代碼本身擁有的一些特別優(yōu)勢(shì)，我們?cè)敿?xì)地講一下。

· 開發(fā)周期短、費(fèi)用低，覆蓋范圍廣

大部分業(yè)務(wù)數(shù)字化，無需編程，少量的代碼就可以實(shí)現(xiàn)業(yè)務(wù)復(fù)雜邏輯，豐富的開放API 可實(shí)現(xiàn)更多功能。

· IT和業(yè)務(wù)更融合，產(chǎn)出質(zhì)量更高

早期的開發(fā)方式是讓產(chǎn)品需求人員進(jìn)行調(diào)研，然后與開發(fā)協(xié)調(diào)溝通，最終產(chǎn)生一個(gè)復(fù)雜的需求文檔，然而，這個(gè)需求文檔對(duì)于業(yè)務(wù)同學(xué)來說并不容易理解，往往需要花費(fèi)大量的精力去理解和揣摩。相比之下，現(xiàn)在的拖拉式開發(fā)方式更加友好，很好地滿足了業(yè)務(wù)需求，在項(xiàng)目的后期，需求變更的次數(shù)也明顯減少，因?yàn)榍捌贗T與業(yè)務(wù)的融合更加充分。

· 大量減少系統(tǒng)運(yùn)維成本

一套部署承載多個(gè)應(yīng)用，減少了大量的服務(wù)器和運(yùn)維工作，平臺(tái)自帶高穩(wěn)定、高并發(fā)、高安全屬性。低代碼平臺(tái)一個(gè)平臺(tái)可以部署很多應(yīng)用系統(tǒng)，假設(shè)做了20個(gè)系統(tǒng)，在傳統(tǒng)領(lǐng)域里面至少需要 20 臺(tái)服務(wù)器，如果要做到高可用、高并發(fā)，可能還要加倍，這就需要多少運(yùn)營成本了？如果一個(gè)軟件是以 5 年作為一個(gè)迭代周期，那 5 年中人的成本、服務(wù)器的成本，其實(shí)是很多經(jīng)營者們看不到的，但這些成本很高。用了低代碼以后，在這塊成本可以大幅減少，可以讓企業(yè)更多的成本投入于產(chǎn)出、項(xiàng)目，而不是運(yùn)維保障機(jī)制。

三、為什么選擇明道云

首先，我們并不只是把低代碼看做一個(gè)簡(jiǎn)單的表單填報(bào)式工具，而是定位為解決業(yè)務(wù)核心邏輯的工具，按照這個(gè)邏輯，有三點(diǎn)非常重要。首先，我們需要中式操作習(xí)慣，雖然很多外國軟件功能強(qiáng)大，但是其拖拉的界面并不適用于我們的員工，而且我們也不是很理解外國式的思路，因此我們選擇國內(nèi)的平臺(tái)作為我們的資源。其次，我們必須考慮的兩點(diǎn)是其拖拉式能力以及代碼的支持度，拖拉拽能力強(qiáng)大，業(yè)務(wù)人員才能更好的上手，代碼的支持度高，平臺(tái)的適用性才會(huì)高，這兩個(gè)要素缺一不可。

我們對(duì)市面上的低代碼開發(fā)平臺(tái)進(jìn)行了比較，總體可以分為3類，一類是平臺(tái)所有操作完全通過拖拉拽的方式，組件也很多，對(duì)業(yè)務(wù)人員非常友好，但是很多軟件都做不了，天花板太低，這類軟件肯定不在我們的考慮范圍內(nèi)；而另一個(gè)類就是重代碼，他設(shè)計(jì)思路是從原來的腳手架開發(fā)起來的，天花板很高，但需要專業(yè)技術(shù)人員才能掌握，這也不是我們考慮的范圍；最后，我們選擇的是介于兩者之間的明道云，明道云的代碼能力稍遜于傳統(tǒng)的開發(fā)，但在市面上產(chǎn)品的評(píng)估中，它是最適合我們的方案，如果明道再稍微向右偏一點(diǎn)點(diǎn)，那么它的適用場(chǎng)景會(huì)更廣泛，我們希望明道在這方面能夠不斷擴(kuò)展。

四、為什么需要敏捷式開發(fā)

為什么需要敏捷式開發(fā)？我們發(fā)現(xiàn)在進(jìn)行項(xiàng)目開發(fā)時(shí)，僅靠簡(jiǎn)單的拖拉無法完成大型項(xiàng)目，除非你只是做一個(gè)非常小的項(xiàng)目，否則一定需要敏捷式開發(fā)的機(jī)制來保障。

就像建工程一樣，傳統(tǒng)開發(fā)方法論中有瀑布式開發(fā)、IBM的Scrum開發(fā)等，雖然方法論強(qiáng)調(diào)需求的重要性，但實(shí)際執(zhí)行時(shí)大量資源被傾斜到了開發(fā)中，在低代碼開發(fā)中使用這樣的方法論就不合適了，因?yàn)榈痛a開發(fā)工作量很小。我們可以看到的是當(dāng)下低代碼缺少一套標(biāo)準(zhǔn)的方法論，最直接的表現(xiàn)就是項(xiàng)目的需求文檔該怎么寫？傳統(tǒng)開發(fā)可能還要寫設(shè)計(jì)文檔、開發(fā)文檔，現(xiàn)在都不需要了，以前可能還要設(shè)計(jì)數(shù)據(jù)庫、畫ER圖，現(xiàn)在也不用了，那整個(gè)項(xiàng)目的實(shí)施計(jì)劃該怎么列？這些都需要一套標(biāo)準(zhǔn)的方法論來支撐。

第二點(diǎn)是容易形成數(shù)據(jù)孤島，難以與現(xiàn)有系統(tǒng)深度融合。這個(gè)問題源于低代碼平臺(tái)功能過于強(qiáng)大，導(dǎo)致它可獨(dú)立完成業(yè)務(wù)系統(tǒng)的開發(fā)，無需IT人員參與。但從IT的角度看，由于系統(tǒng)過多，數(shù)據(jù)不對(duì)接，導(dǎo)致缺乏數(shù)據(jù)連貫性，這是最令I(lǐng)T擔(dān)心的問題。例如，在公司采購和物流業(yè)務(wù)中，兩個(gè)部門各自開發(fā)了一套系統(tǒng)，但由于其商品定義不同，數(shù)據(jù)無法對(duì)接導(dǎo)致出現(xiàn)了數(shù)據(jù)孤島。在考慮如何將低代碼平臺(tái)融入公司整個(gè)體系時(shí)，需要解決這些數(shù)據(jù)孤島問題。

另外，對(duì)企業(yè)來說，必須回答老板的投入產(chǎn)出問題，即ROI。我們做第一個(gè)項(xiàng)目的時(shí)候還是很順利的，我作為產(chǎn)品經(jīng)理加上另一個(gè)全棧工程師，我們兩個(gè)花了一個(gè)多月的時(shí)間就做出了一個(gè)很專業(yè)的實(shí)驗(yàn)室管理系統(tǒng)，當(dāng)然，只是做了其中的一部分，包材測(cè)試環(huán)節(jié)。然后老板就問我，你采購的新項(xiàng)目準(zhǔn)備配多少人？做多少產(chǎn)出？我就可以直接回復(fù)老板，我們兩個(gè)人就可以很完整快速的去做一個(gè)項(xiàng)目。

五、如何進(jìn)行敏捷開發(fā)

1.項(xiàng)目管理調(diào)整

首先，低代碼開發(fā)方式?jīng)]有傳統(tǒng)的開發(fā)過程，但其他環(huán)節(jié)仍然存在，我們將所有項(xiàng)目資源集中于最重要的需求方面。以前的需求規(guī)格說明書通常只是針對(duì)開發(fā)人員的，但實(shí)際上，為什么需求在后期會(huì)發(fā)生無法控制、不斷變更的情況呢？因?yàn)樾枨笠?guī)格說明書之前還有東西沒有完成。

第一個(gè)來自于業(yè)務(wù)的訴求，這并不是需求，而是老板對(duì)業(yè)務(wù)的期望目標(biāo)，這是非常重要的一點(diǎn)；第二個(gè)是將具體事項(xiàng)拆分開來，以確定先優(yōu)先實(shí)現(xiàn)哪一塊，這樣我們就可以先去完成20%的目標(biāo)了，大部分的業(yè)務(wù)只需要實(shí)現(xiàn)20%目標(biāo)就差不多完成了，剩下的80%只是覺得用戶用得少，我們需要對(duì)這20%的經(jīng)驗(yàn)進(jìn)行分析，但這需要對(duì)業(yè)務(wù)和整個(gè)組織之間的關(guān)系有深入的了解。因此，我們?cè)谙肴绾瓮ㄟ^已有的訴求信息來制定需求，并做業(yè)務(wù)需求分析和需求規(guī)格說明書。在整個(gè)項(xiàng)目過程中，我會(huì)參加兩個(gè)會(huì)：立項(xiàng)會(huì)和復(fù)盤會(huì)。我們會(huì)開兩個(gè)人多小時(shí)的會(huì)去確認(rèn)立項(xiàng)單的內(nèi)容，核心邏輯就是去確定項(xiàng)目業(yè)務(wù)訴求和背景目標(biāo)，這個(gè)是在項(xiàng)目里面很重要的事情，然后對(duì)業(yè)務(wù)的流程進(jìn)行大致定義。并且，會(huì)將立項(xiàng)單發(fā)給對(duì)應(yīng)的產(chǎn)業(yè)高層領(lǐng)導(dǎo)以確保大家對(duì)這件事情的重要性認(rèn)知一致。

· 業(yè)務(wù)建模

實(shí)際上，業(yè)務(wù)人員常常會(huì)提供許多單據(jù)或者其它業(yè)務(wù)場(chǎng)景下需要的數(shù)據(jù)，因此，我們的數(shù)據(jù)建模也會(huì)偏向于這些業(yè)務(wù)數(shù)據(jù)為基礎(chǔ)進(jìn)行建模，這些建模圖看起來像是一個(gè)ER圖，但實(shí)際上這只是業(yè)務(wù)邏輯的體現(xiàn)。在建模的過程中，我們也會(huì)邀請(qǐng)業(yè)務(wù)人員一起參與，以業(yè)務(wù)為導(dǎo)向，避免涉及技術(shù)原則，相信大多數(shù)同學(xué)都能看得懂。

· 項(xiàng)目計(jì)劃

項(xiàng)目計(jì)劃包括需求可行性評(píng)估、立項(xiàng)、需求設(shè)計(jì)、開發(fā)、測(cè)試和上線，我們把所有的方法論全改了。第一是需求溝通，為了出立項(xiàng)單，第二個(gè)是模型確認(rèn)，第三個(gè)步驟是POC制作，我們會(huì)先按照我們的理解快速做一版，然后你看一下效果，你說同步我去改，逐步進(jìn)行優(yōu)化，不同的業(yè)務(wù)理解需求的深度不同，因此我們的計(jì)劃是基本上2個(gè)禮拜到一個(gè)月就能修改完成，最后是上線試運(yùn)行和復(fù)盤階段。我們會(huì)在一個(gè)月后對(duì)項(xiàng)目進(jìn)行復(fù)盤，了解客戶對(duì)我們的態(tài)度，我們一年做了將近30個(gè)項(xiàng)目，很少遇到客戶投訴的。

· 功能/角色職責(zé)景圖

最終我們需要出一個(gè)功能角色的職責(zé)圖，系統(tǒng)是給人用的，所以要定義出來這個(gè)系統(tǒng)到底是給哪些人用的，每個(gè)人的角色是什么，每個(gè)角色要給他哪些功能。

2.技術(shù)架構(gòu)的適配和調(diào)整

實(shí)際上，我們?cè)诘讓泳妥隽嗽@股份的數(shù)據(jù)中臺(tái)，所有的業(yè)務(wù)系統(tǒng)數(shù)據(jù)都要進(jìn)去。所以我們?cè)诓渴鹆嗣鞯涝扑接邪姹竞笞龅牡谝患虑?，就是打通豫園股份的敏捷中臺(tái)跟數(shù)據(jù)中臺(tái)，敏捷中臺(tái)里所有的數(shù)據(jù)全部要推到數(shù)據(jù)中臺(tái)去，由我們部門來定義數(shù)據(jù)規(guī)范。除此之外，業(yè)務(wù)人員不允許在敏捷平臺(tái)上直接建模，必須要通過 IT 確認(rèn)一下，以確保你的數(shù)據(jù)能融在整個(gè)體系里。比如說商品數(shù)據(jù)、門店數(shù)據(jù)、倉庫數(shù)據(jù)，這些都是主數(shù)據(jù)，能融進(jìn)體系是一個(gè)前提。

第二點(diǎn)，我們準(zhǔn)備將一些核心信息系統(tǒng)之間進(jìn)行打通，比如職能型公司中的OA系統(tǒng)，業(yè)務(wù)型公司中的ERP系統(tǒng)，他們之間也可以進(jìn)行打通，后面開發(fā)的時(shí)候就會(huì)簡(jiǎn)單很多，因?yàn)樗臄?shù)據(jù)、業(yè)務(wù)都是通的。

最后，我們建立了統(tǒng)一認(rèn)證、統(tǒng)一入口、釘釘體系這套體系，改善用戶訪問體驗(yàn)，用戶不用記多個(gè)賬號(hào)密碼，對(duì)于他們來說這就是一個(gè)整體的龐大的系統(tǒng)。在此基礎(chǔ)上，我們使用了低代碼技術(shù)和敏捷開發(fā)加上傳統(tǒng)開發(fā)做了一套工作門戶，將業(yè)務(wù)系統(tǒng)倒置進(jìn)低代碼平臺(tái)中，以確保低代碼技術(shù)與整個(gè)體系兼容。

3.團(tuán)隊(duì)架構(gòu)和團(tuán)隊(duì)人員技能的配置

先說一下我們的組織結(jié)構(gòu)，豫園股份是一個(gè)集團(tuán)，下面有很多產(chǎn)業(yè)公司，每個(gè)公司都有自帶的IT，產(chǎn)業(yè)公司會(huì)做業(yè)務(wù)和技術(shù)協(xié)同，包括用戶的推進(jìn)反饋，股份則會(huì)做整體的規(guī)劃、實(shí)施，包括沉淀產(chǎn)業(yè)公司間相似的東西。

股份的人員配置基本都是產(chǎn)品經(jīng)理，因?yàn)橹挥挟a(chǎn)品經(jīng)理才能更好地駕馭這個(gè)平臺(tái)，我們是有一個(gè)偏向UI的，一個(gè)偏向數(shù)據(jù)的，還有三個(gè)全棧產(chǎn)品經(jīng)理。全棧產(chǎn)品經(jīng)理比較核心，也比較難找，我們都是內(nèi)部自己培養(yǎng)的。由于產(chǎn)品需求與開發(fā)不同人造成的溝通不暢，做出來的產(chǎn)品一直無法達(dá)到預(yù)期，現(xiàn)在需求和開發(fā)合并為一個(gè)人，這個(gè)問題就解決了，同時(shí)，大幅度的減少了協(xié)同的工作量。

4.精益數(shù)字化管理系統(tǒng)的支持

我們自己開發(fā)了一套項(xiàng)目管理系統(tǒng)，因?yàn)槲覀冇X得市面上的項(xiàng)目管理軟件不夠符合我們的需求，特別是像禪道、Teambition這樣的產(chǎn)品，對(duì)于我們來說太薄了，他還是偏向于做開發(fā)的。說實(shí)話在有這個(gè)敏捷開發(fā)之前，我其實(shí)很反感使用項(xiàng)目管理系統(tǒng)，做個(gè)項(xiàng)目還要填系統(tǒng)，整個(gè)項(xiàng)目的管理成本非常高，但是我們發(fā)現(xiàn)做了低代碼后，項(xiàng)目瓶頸不在項(xiàng)目組，而在用戶。

舉個(gè)例子，之前我們?yōu)榭偛康姆▌?wù)部門制作了一套無形資產(chǎn)管理系統(tǒng)，以控制所有產(chǎn)業(yè)公司、產(chǎn)業(yè)品牌的無形資產(chǎn)。 這個(gè)項(xiàng)目開發(fā)用了一個(gè)月時(shí)間，但要花費(fèi)半年多時(shí)間才上線，因?yàn)榉▌?wù)團(tuán)隊(duì)一直梳理管控流程，和產(chǎn)業(yè)領(lǐng)導(dǎo)確認(rèn)管控方式是否合適，梳理無形資產(chǎn)的數(shù)據(jù)。這種情況下，我們的團(tuán)隊(duì)都會(huì)閑在那里，我們必須為他們安排一些其他任務(wù)，因此，每個(gè)同事通常同時(shí)處理2到5個(gè)項(xiàng)目。由于項(xiàng)目跨度很大，所以我們需要一套系統(tǒng)來沉淀所有文檔和信息，此外，匯報(bào)項(xiàng)目也很重要，我需要告訴我的領(lǐng)導(dǎo)我們目前在做什么項(xiàng)目，為什么項(xiàng)目那么沒有上線。所以我們就開發(fā)了一個(gè)項(xiàng)目管理的系統(tǒng)用于管理、沉淀這些項(xiàng)目數(shù)據(jù)。

六、實(shí)踐成果分享

1.建設(shè)工作門戶體系

我們做了一個(gè)門戶，后面的邏輯全部用低代碼做的，前端用了現(xiàn)在比較流行的一個(gè)框架。之前公司用的泛微OA，但我一直覺得它的界面不夠美觀，操作也有些不夠簡(jiǎn)便，并且泛微沒有辦法做到將我們所有的系統(tǒng)整合到一個(gè)門戶里，現(xiàn)在我們用明道云就很好的實(shí)現(xiàn)了。

2.集團(tuán)職能管控領(lǐng)域

接著我們看一下低代碼在協(xié)同職能層面做了哪些工作單？首先是管理所有產(chǎn)業(yè)的核心指標(biāo)，這些指標(biāo)在我們內(nèi)部都是以戰(zhàn)役的方式去管理的，所以我們搭建了一套戰(zhàn)役管控系統(tǒng)用于報(bào)備和管控。同時(shí)，為了跟進(jìn)產(chǎn)業(yè)中核心事項(xiàng)的辦理情況，我們開發(fā)了一個(gè)督辦管理系統(tǒng)。另外，我們還建立了一個(gè)BD生態(tài)系統(tǒng)。所謂BD生態(tài)系統(tǒng)，就是我們的不同產(chǎn)業(yè)之間聯(lián)合營銷的一些活動(dòng)，例如購買一定金額的酒就可以獲得手表等，像這種我們也建立了一個(gè)相關(guān)的系統(tǒng)去管控。

3.零售業(yè)態(tài)的業(yè)務(wù)

在零售業(yè)態(tài)里我們也做了一些系統(tǒng)，雖然不是很深入，但對(duì)業(yè)務(wù)也有很大幫助。比如我們之前做的庫存管理，海外的CRM管理，我們一直想知道我們的就在海外各個(gè)國家的銷售情況，但那些代理商都不是我們自己的公司，所以他們也不太愿意把數(shù)據(jù)給我們，所以我們就通過監(jiān)控他的采購數(shù)據(jù)來推算，分析他們的銷售情況，像這一類特別的需求，市場(chǎng)上是沒有符合要求的系統(tǒng)的，我們就用低代碼自己搭建；還有我們之前做了化妝品的主數(shù)據(jù)管理，餐飲門店的內(nèi)部調(diào)撥管理等，通過低代碼去一些做非專業(yè)的系統(tǒng)，對(duì)我們的業(yè)務(wù)非常有幫助。

4.各端口界面

在我們理解中，低代碼更多用于做內(nèi)部管理系統(tǒng)。但實(shí)際上，我們?cè)S多創(chuàng)新業(yè)務(wù)都是對(duì)外的，所以，我們與傳統(tǒng)式開發(fā)合作，創(chuàng)建了一些對(duì)外的模式。例如，左側(cè)的“豫園股份投訴”掛在我們的官網(wǎng)上，如果你到老廟去投訴，而老廟沒有響應(yīng)你的意見，你可以到股份來投訴，這個(gè)投訴會(huì)在這個(gè)系統(tǒng)里被處理，并根據(jù)匹配關(guān)鍵字推送給老廟，同時(shí)，在股份層面也會(huì)推進(jìn)這件事情的處理，它是一個(gè)多維多層級(jí)的邏輯。

還有消費(fèi)洞察小程序，背后也是低代碼加部分 Python加前端開發(fā)，開發(fā)成本很低。當(dāng)我們的化妝品上市時(shí)，要必須在真實(shí)人體上做過測(cè)試才可以，因此，我們創(chuàng)建了這個(gè)消費(fèi)者洞察系統(tǒng)給化妝品體驗(yàn)館去做相關(guān)測(cè)試的一些支持。

5.AIGC領(lǐng)域

我也負(fù)責(zé)豫園股份的AIGC，我們會(huì)通過文森圖的邏輯去實(shí)現(xiàn)一些 AIGC 的場(chǎng)景，幫助設(shè)計(jì)師獲得靈感。因?yàn)槲覀冇泻芏鄬?shí)驗(yàn)室痛點(diǎn)明顯，實(shí)驗(yàn)室的科學(xué)家做的所有東西對(duì)消費(fèi)者一定是有幫助的，基于這個(gè)線路推進(jìn)產(chǎn)業(yè)。然而我們發(fā)現(xiàn)實(shí)驗(yàn)室科學(xué)家與用戶語言不通，如何將你所做工作表達(dá)出來讓消費(fèi)者產(chǎn)生知道呢？我們就通過 AIGC 來彌補(bǔ)這個(gè)問題，在低代碼上開發(fā)并通過自訓(xùn)練和公域模式來嘗試去做。這個(gè)如果用傳統(tǒng)方式開發(fā)估計(jì)需要幾個(gè)月時(shí)間，等做出來這個(gè)風(fēng)頭也過去了，而低代碼只需兩周。

現(xiàn)在整個(gè)低代碼行業(yè)非常卷，尤其是明道云，我看見他的產(chǎn)品線路圖，每季度有大量新功能上線，我相信這些功能上線后對(duì)于上層應(yīng)用開發(fā)和業(yè)務(wù)方面都會(huì)有很大幫助。