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

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

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

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

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

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

首先，我們需要一種新的技術(shù)架構(gòu)來應(yīng)對這些情況，低代碼技術(shù)在前幾年開始崛起。我們發(fā)現(xiàn)，一些低代碼公司在做專業(yè)的系統(tǒng)，如CRM系統(tǒng)，甚至一些公司還在做ERP系統(tǒng)，而ERP系統(tǒng)是可以檢驗(yàn)一個平臺質(zhì)量和框架的天花板；其次，低代碼可以結(jié)合傳統(tǒng)開發(fā)，突破限制，可以低成本實(shí)現(xiàn)小程序、H5、漂亮界面的軟件系統(tǒng)；最后也是最重要的一個原因，低代碼本身擁有的一些特別優(yōu)勢，我們詳細(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)生一個復(fù)雜的需求文檔，然而，這個需求文檔對于業(yè)務(wù)同學(xué)來說并不容易理解，往往需要花費(fèi)大量的精力去理解和揣摩。相比之下，現(xiàn)在的拖拉式開發(fā)方式更加友好，很好地滿足了業(yè)務(wù)需求，在項(xiàng)目的后期，需求變更的次數(shù)也明顯減少，因?yàn)榍捌贗T與業(yè)務(wù)的融合更加充分。

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

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

三、為什么選擇明道云

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

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

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

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

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

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

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

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

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

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

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

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

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

· 項(xiàng)目計劃

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

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

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

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

實(shí)際上，我們在底層就做了豫園股份的數(shù)據(jù)中臺，所有的業(yè)務(wù)系統(tǒng)數(shù)據(jù)都要進(jìn)去。所以我們在部署了明道云私有版本后做的第一件事情，就是打通豫園股份的敏捷中臺跟數(shù)據(jù)中臺，敏捷中臺里所有的數(shù)據(jù)全部要推到數(shù)據(jù)中臺去，由我們部門來定義數(shù)據(jù)規(guī)范。除此之外，業(yè)務(wù)人員不允許在敏捷平臺上直接建模，必須要通過 IT 確認(rèn)一下，以確保你的數(shù)據(jù)能融在整個體系里。比如說商品數(shù)據(jù)、門店數(shù)據(jù)、倉庫數(shù)據(jù)，這些都是主數(shù)據(jù)，能融進(jìn)體系是一個前提。

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

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

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

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

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

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

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

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

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

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

我們做了一個門戶，后面的邏輯全部用低代碼做的，前端用了現(xiàn)在比較流行的一個框架。之前公司用的泛微OA，但我一直覺得它的界面不夠美觀，操作也有些不夠簡便，并且泛微沒有辦法做到將我們所有的系統(tǒng)整合到一個門戶里，現(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)用于報備和管控。同時，為了跟進(jìn)產(chǎn)業(yè)中核心事項(xiàng)的辦理情況，我們開發(fā)了一個督辦管理系統(tǒng)。另外，我們還建立了一個BD生態(tài)系統(tǒng)。所謂BD生態(tài)系統(tǒng)，就是我們的不同產(chǎn)業(yè)之間聯(lián)合營銷的一些活動，例如購買一定金額的酒就可以獲得手表等，像這種我們也建立了一個相關(guān)的系統(tǒng)去管控。

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

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

4.各端口界面

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

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

5.AIGC領(lǐng)域

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

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