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

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

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

產品和項目需求越貼合，項目實現的效率就越高，項目落地的代價就越低。

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

產品或工具的本質，都是為了降本增效。

產品和項目相互促進

產品的規范、成熟，為項目的快速落地提供支撐；項目的落地反哺產品，促進產品的成長成熟。

一、低代碼平臺產品

低代碼產品要解決兩個問題：一是常見系統所必備且相似的模塊復用；二是降低系統開發的難度。

基于模塊復用，幾乎所有系統都需要的權限、組織、用戶，就成為了低代碼平臺的基礎部分；

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

低代碼平臺成長藍圖

整體的梳理過程，構建了低代碼平臺各功能模塊的相互聯系，厘清了各模塊的優先級，從而形成低代碼平臺成長藍圖：

第一版本：搭建基礎：

權限、組織、用戶為系統的基礎模塊；

應用開發工作臺，為應用開發提供基礎環境；

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

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

集成應用，補全應用開發及發布的整體流程，實現應用開發的完整生命流程；

第三版本：補全更多業務場景：

APIX 支持接口編排，實現更多的業務流，豐富實現路徑；

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

數據模型，打通另一種低代碼搭建的指導方案，通過模型復原頁面交互；

第N版本：完善業務場景，提升用戶體驗：

通用數據處理平臺，提供數據同步、數據清洗、數據應用的能力，實現數據再利用；

消息，支持平臺消息，提高復用率……

低代碼平臺產品架構圖

二、項目實現及管理

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

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

涉及到的問題大致包含：

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

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

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

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

產品搭建項目

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

若每個項目完結不再有后續，那么溯源實際上并沒有那么重要。畢竟，新的項目基本都會基于最新產品去開發。

項目嘛，軟件嘛，要的是啥，要的是升級呀，要的是擴展吶，要的是更智能??？這是啥，這是機會呀？也就是錢??？

我們的產品升級了，有更好的應用，有更好的能力，你們要不要升級一下？

你們的操作要優化？業務數據要調整？人員結構要調整？

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

項目管理

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

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

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

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

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

三、產品和項目相輔相成

在操作系統基礎上，用產品構建解決方案，實現一個個項目。

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

在產品上就會逐漸細分：SaaS型應用，實施型應用，產品應用。

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

產品細分及相互關系

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

實施型應用，如設備集成，在了解產品設計基礎上，了解設備協議，新建設備類型，完成設備接入；實施流程相似，只是不同協議需要深入了解，以及客戶所擁有設備不同。

實施應用搭建系統過程抽象

產品應用，如低代碼平臺，就需要了解各個模塊的功能，然后梳理用低代碼搭建什么系統，梳理完整通路的基礎上，逐漸落地。這種方式前期的學習成本很高，但是應用面足夠寬。

產品應用搭建系統過程抽象

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

產品–實施–SaaS 自我驗證，及項目落地反哺

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

在基于搭建的實施應用，搭建出來SaaS應用，就能夠成為各個細分方向的解決方案，在深度上進行深遠的拓展。

在產品實現上是有捷徑的。

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

在如下圖所示，產品領域內，構建“產品應用”；通過“產品應用”搭建“實施應用”，實現“產品應用”的檢核，尤其是各個“產品應用”使用在不同的“實施應用”上，他是否仍舊能夠擔起自己的責任。

產品領域 和 解決方案領域

通過“實施應用”搭建“SaaS應用”，本質就是打造解決方案，可以深入業務的深度部分，也反向驗證、檢核“實施應用”、“產品應用”。

低代碼平臺實現的捷徑是：標桿客戶的關鍵項目。

產品設計按照自身的設計原則，進行產品藍圖建設，然后進行“實施應用”、“SaaS應用”搭建模擬，驗證設計的合理性。

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

完成標桿客戶的建設，是產品落地的實例，為推廣、演示提供高可信的資料。且標桿客戶本身在行業的地位，也會促進推廣，形成自傳播效應。

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

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