產(chǎn)品和項目是相輔相成的關(guān)系，產(chǎn)品的規(guī)范、成熟，為項目的快速落地提供支撐，項目的落地反哺產(chǎn)品，促進(jìn)產(chǎn)品的成長成熟。本文作者就兩者的關(guān)系，及延伸出的低代碼平臺展開了分析，希望對你有幫助。

軟件工程的初期是，我們需要什么，就立項項目，通過項目實現(xiàn)需要。

隨著項目的增多，發(fā)現(xiàn)項目的相似度很大，甚至于有一些部分能夠直接重用。則逐漸將能夠重用的部分整合在一起，形成一個新的產(chǎn)品。

產(chǎn)品和項目需求越貼合，項目實現(xiàn)的效率就越高，項目落地的代價就越低。

隨著項目的變多，類型的擴(kuò)展，產(chǎn)品本身的復(fù)雜度就會提升，乃至于成為一個專門的課題。這也是當(dāng)前低代碼平臺興起、火爆的原因之一。

產(chǎn)品或工具的本質(zhì)，都是為了降本增效。

產(chǎn)品和項目相互促進(jìn)

產(chǎn)品的規(guī)范、成熟，為項目的快速落地提供支撐；項目的落地反哺產(chǎn)品，促進(jìn)產(chǎn)品的成長成熟。

一、低代碼平臺產(chǎn)品

低代碼產(chǎn)品要解決兩個問題：一是常見系統(tǒng)所必備且相似的模塊復(fù)用；二是降低系統(tǒng)開發(fā)的難度。

基于模塊復(fù)用，幾乎所有系統(tǒng)都需要的權(quán)限、組織、用戶，就成為了低代碼平臺的基礎(chǔ)部分；

基于降低開發(fā)難度，通過頁面及元素的拖拉拽完成系統(tǒng)搭建成為設(shè)計指導(dǎo)方案，表單、工作流、報表就成為了低代碼平臺的核心模塊。

低代碼平臺成長藍(lán)圖

整體的梳理過程，構(gòu)建了低代碼平臺各功能模塊的相互聯(lián)系，厘清了各模塊的優(yōu)先級，從而形成低代碼平臺成長藍(lán)圖：

第一版本：搭建基礎(chǔ)：

權(quán)限、組織、用戶為系統(tǒng)的基礎(chǔ)模塊；

應(yīng)用開發(fā)工作臺，為應(yīng)用開發(fā)提供基礎(chǔ)環(huán)境；

第二版本：核心模塊搭建：

表單、流程、報表為系統(tǒng)的核心模塊，作為低代碼搭建系統(tǒng)的核心工具；

集成應(yīng)用，補(bǔ)全應(yīng)用開發(fā)及發(fā)布的整體流程，實現(xiàn)應(yīng)用開發(fā)的完整生命流程；

第三版本：補(bǔ)全更多業(yè)務(wù)場景：

APIX 支持接口編排，實現(xiàn)更多的業(yè)務(wù)流，豐富實現(xiàn)路徑；

圖表，提供更為豐富的展示方式，為大屏效果奠定基礎(chǔ)；

數(shù)據(jù)模型，打通另一種低代碼搭建的指導(dǎo)方案，通過模型復(fù)原頁面交互；

第N版本：完善業(yè)務(wù)場景，提升用戶體驗：

通用數(shù)據(jù)處理平臺，提供數(shù)據(jù)同步、數(shù)據(jù)清洗、數(shù)據(jù)應(yīng)用的能力，實現(xiàn)數(shù)據(jù)再利用；

消息，支持平臺消息，提高復(fù)用率……

低代碼平臺產(chǎn)品架構(gòu)圖

二、項目實現(xiàn)及管理

在產(chǎn)品還未建立起來的時候，兄弟們就只能親身上場，真槍實干，去把項目一個個搶出來。

產(chǎn)品出來了，針對新的項目，那必須帶著產(chǎn)品上陣。這是產(chǎn)品得到驗證的第一步，也是關(guān)鍵且很難的一步。畢竟這是產(chǎn)品的初次露面，想象的很美好，實際上可能并不是那么肥四？

涉及到的問題大致包含：

1. 產(chǎn)品在項目中使用并不完全貼合，需要基于項目需要改造；
2. 除開產(chǎn)品已有部分，其他需求都需要新做，那高低代碼如何融合，以及融合的效率如何；
3. 在項目執(zhí)行過程中，產(chǎn)品完成升級，是否將最新產(chǎn)品合并到項目中來；

針對項目來說，賺錢才是根本，所有項目過程中的決策都應(yīng)該以成本是否最低來考量。

當(dāng)然，在具有代表意義的項目上，就有可能需要背著產(chǎn)品扛過去。產(chǎn)品在初始項目中使用，總是會存在各種各樣的問題。若是完全用成本來考量，可能產(chǎn)品上前線的機(jī)會就會很渺茫。

在項目具有典型場景的情況下，需要用項目驗證并打磨產(chǎn)品，這時候就不得不上了。用這一個項目的打磨，讓產(chǎn)品某一個模塊成為標(biāo)準(zhǔn)產(chǎn)品，在未來相似的項目上，就能夠獲得直觀的回饋。這算是成本考量，只是這個成本是長遠(yuǎn)、多個項目下的綜合考量。

產(chǎn)品搭建項目

隨著產(chǎn)品的發(fā)展，各個版本產(chǎn)品都會有開發(fā)出來的項目，從而形成一個復(fù)雜的樹，乃至于網(wǎng)。確保良好的溯源記錄，在代碼樹的管理上，需要應(yīng)用好tag，做好各個上線版本的封版。同時，配合文檔等記錄，可以進(jìn)行產(chǎn)品、項目各自的溯源。

若每個項目完結(jié)不再有后續(xù)，那么溯源實際上并沒有那么重要。畢竟，新的項目基本都會基于最新產(chǎn)品去開發(fā)。

項目嘛，軟件嘛，要的是啥，要的是升級呀，要的是擴(kuò)展吶，要的是更智能??？這是啥，這是機(jī)會呀？也就是錢啊？

我們的產(chǎn)品升級了，有更好的應(yīng)用，有更好的能力，你們要不要升級一下？

你們的操作要優(yōu)化？業(yè)務(wù)數(shù)據(jù)要調(diào)整？人員結(jié)構(gòu)要調(diào)整？

可以的，我們可以這么做這么做，這不需求就來了嘛。

項目管理

在線下，卷起來的現(xiàn)在，每個人怎么可能只有一個項目呢？那作為項目經(jīng)理，需要項目中面面俱到、無微不至嘛？有時間有精力，可以的哇！但一個人哪有這么多精力呢？！

項目管理，需要抓大放小。

項目要去詳細(xì)、精細(xì)管理的話，五大過程組，十大知識領(lǐng)域，足夠讓人沉溺其中。

進(jìn)行中的項目區(qū)分為“正?！被颉爱惓！?，直接就可以把項目的很大部分精力節(jié)省下來。針對異常項目，抓住關(guān)鍵部分，需求框架、技術(shù)框架、最小驗證，這些沒有問題，其它問題有也是小一點的問題，多加一個人、多給一點時間，也就搞定了。

再配合項目管理列表，周期性進(jìn)行更新，通常性項目管理就沒有大問題的。為啥是通常性的，那種本來就很難、很亂的項目，通常管理肯定是不夠的！而通常性項目高效管理才能結(jié)余更多精力，應(yīng)付那些非通常性的項目。

三、產(chǎn)品和項目相輔相成

在操作系統(tǒng)基礎(chǔ)上，用產(chǎn)品構(gòu)建解決方案，實現(xiàn)一個個項目。

產(chǎn)品模塊越來越豐富，就會在廣度、深度上平衡。每個模塊要解決更為廣泛的問題，通用性就要很強(qiáng)，而在指定方向的實現(xiàn)上，就會沒有那么便捷。

在產(chǎn)品上就會逐漸細(xì)分：SaaS型應(yīng)用，實施型應(yīng)用，產(chǎn)品應(yīng)用。

• SaaS型應(yīng)用：此種應(yīng)用只需要錄入客戶的基礎(chǔ)信息，簡單配置就可以使用；甚至于通用基礎(chǔ)數(shù)據(jù)、字典數(shù)據(jù)，都可以系統(tǒng)內(nèi)置；培訓(xùn)和咨詢也都可以相對固定下來，落地的效率最高。
• 實施型應(yīng)用：此種應(yīng)用需要按照一定流程搭建應(yīng)用，配合實施流程的培訓(xùn)，學(xué)習(xí)成本比較低，適用該流程的業(yè)務(wù)實現(xiàn)效率高，在框架內(nèi)靈活度高。相比SaaS型應(yīng)用，落地要緩慢一些，靈活度高一些。
• 產(chǎn)品型應(yīng)用：此種應(yīng)用需要了解各個產(chǎn)品的能力，配合產(chǎn)品培訓(xùn)，再梳理客戶需求，梳理出實施通路，然后落地實現(xiàn)。整體學(xué)習(xí)成本較高，實現(xiàn)效率較低，但整體靈活度高，適用范圍廣。

產(chǎn)品細(xì)分及相互關(guān)系

SaaS型應(yīng)用，如班組管理，就是指定了用戶群體及管理的具體事項。在具體實施時，也無非就是明確使用人員賬號及使用模塊。整體的理念培訓(xùn)、使用培訓(xùn)都是一致的。

實施型應(yīng)用，如設(shè)備集成，在了解產(chǎn)品設(shè)計基礎(chǔ)上，了解設(shè)備協(xié)議，新建設(shè)備類型，完成設(shè)備接入；實施流程相似，只是不同協(xié)議需要深入了解，以及客戶所擁有設(shè)備不同。

實施應(yīng)用搭建系統(tǒng)過程抽象

產(chǎn)品應(yīng)用，如低代碼平臺，就需要了解各個模塊的功能，然后梳理用低代碼搭建什么系統(tǒng)，梳理完整通路的基礎(chǔ)上，逐漸落地。這種方式前期的學(xué)習(xí)成本很高，但是應(yīng)用面足夠?qū)挕?/p>

產(chǎn)品應(yīng)用搭建系統(tǒng)過程抽象

進(jìn)行深度拆解后，要實現(xiàn)低代碼平臺的深度、快速成長，就需要使用各個層級的產(chǎn)品來搭建項目，從而進(jìn)行更為深入的錘煉，使得產(chǎn)品各模塊更加合理。也在搭建過程中，實現(xiàn)業(yè)務(wù)的深入理解，從而制作模板，讓其他客戶基于模板開發(fā)，再次極大提升效率。

產(chǎn)品–實施–SaaS 自我驗證，及項目落地反哺

要實現(xiàn)低代碼平臺，就是需要其完整解決方案的能力，在少編碼的情況下實現(xiàn)系統(tǒng)搭建。而在項目落地上，需要更高的效率，用低代碼平臺本身產(chǎn)品應(yīng)用，搭建實施應(yīng)用則實現(xiàn)對產(chǎn)品本身的校驗，還提升了項目實施的效率。這是良性循環(huán)的開啟，至關(guān)重要！

在基于搭建的實施應(yīng)用，搭建出來SaaS應(yīng)用，就能夠成為各個細(xì)分方向的解決方案，在深度上進(jìn)行深遠(yuǎn)的拓展。

在產(chǎn)品實現(xiàn)上是有捷徑的。

捷徑不是偏門，而是少走、不走彎路！

在如下圖所示，產(chǎn)品領(lǐng)域內(nèi)，構(gòu)建“產(chǎn)品應(yīng)用”；通過“產(chǎn)品應(yīng)用”搭建“實施應(yīng)用”，實現(xiàn)“產(chǎn)品應(yīng)用”的檢核，尤其是各個“產(chǎn)品應(yīng)用”使用在不同的“實施應(yīng)用”上，他是否仍舊能夠擔(dān)起自己的責(zé)任。

產(chǎn)品領(lǐng)域 和 解決方案領(lǐng)域

通過“實施應(yīng)用”搭建“SaaS應(yīng)用”，本質(zhì)就是打造解決方案，可以深入業(yè)務(wù)的深度部分，也反向驗證、檢核“實施應(yīng)用”、“產(chǎn)品應(yīng)用”。

低代碼平臺實現(xiàn)的捷徑是：標(biāo)桿客戶的關(guān)鍵項目。

產(chǎn)品設(shè)計按照自身的設(shè)計原則，進(jìn)行產(chǎn)品藍(lán)圖建設(shè)，然后進(jìn)行“實施應(yīng)用”、“SaaS應(yīng)用”搭建模擬，驗證設(shè)計的合理性。

在產(chǎn)品落地上，可通過標(biāo)桿客戶梳理解決方案，由解決方案梳理實施方案，由實施方案梳理產(chǎn)品模塊，最終通過低代碼產(chǎn)品搭建實現(xiàn)出來，實現(xiàn)整個通路的落地驗證。

完成標(biāo)桿客戶的建設(shè)，是產(chǎn)品落地的實例，為推廣、演示提供高可信的資料。且標(biāo)桿客戶本身在行業(yè)的地位，也會促進(jìn)推廣，形成自傳播效應(yīng)。

抓住標(biāo)桿客戶，實現(xiàn)客戶需求落地。過程中，不自覺就完成低代碼平臺0-1的界線跨越。

人生也是有捷徑的，少走彎路就是捷徑。