面對頻繁多變、需緊急上線、隨時調整的運營頁面，該如何規劃好？本文以電商CMS系統為例，總結零代碼平臺搭建實戰，希望對你有所幫助。
面對頻繁多變、需緊急上線、隨時調整的運營頁面，采用傳統開發方式成本過大、無法滿足想改就該需求；而零代碼平臺幾乎可以完美解決上述問題，那么該如何規劃呢，本文將詳細論述下。
一、系統價值
1. 什么是電商CMS系統/零代碼平臺？
一個運營同學可通過圖形化的用戶界面拖拽&配置組件生產頁面的系統，可跳過產品、開發、測試等流程實現頁面的低成本、快速上線。
2. 系統價值
- 降低人力成本：傳統頁面開發流程「運營需求–產品–設計–前/后端開發–測試–代碼發布部署發布」，通過零代碼平臺開發流程「運營需求–設計–配置頁面」，不難看出可以節省大量人力；且公司業務大則系統價值更高（生產單頁面的邊際成本降低）；
- 顯著降低AB 實驗成本：可根據AB 實驗數據「A 為一頁面，B 為另一頁面」，及時調整對應方案，提高AB實驗效率；提高運營響應速度
- 提升突發熱點事件響應能力：需運營緊急調整或搭建相關運營頁面，通過零代碼系統可迅速調整頁面并發布上線，顯然傳統開發流程很可能造成黃花菜涼的局面；
- 降低線上bug風險：因頁面無需走開發，理論上不存在線上 bug 風險「前提組件上線經充分測試，無 bug」。
二、功能框架
篇幅有限，僅列舉系統框架，不做細致功能點展開；
三、系統規劃關鍵點
1. 渲染器一定要做好
- 是啥？負責將頁面&組件等配置效果實時渲染并展示在瀏覽器的控件。
- 為啥很重要？因搭建頁面所需組件及配置相對較為繁瑣，需實時渲染展現配置效果，以便根據效果及時調整，渲染器直接影響配置效率。渲染器功能做好，系統就成功一大半了。
2. 業務組件設計應遵循以下幾點
組件顆粒度要小，以保證其高復用：頁面搭建可以看作是積木搭建，理論上單個積木越小搭建出的東西越多，同理組件的顆粒度越小其組合可滿足的實際業務場景理論上也更多。
舉例：橫向商品列表標題配置應從組件本身剝離出來，用「橫向商品列表 文本框組件」或「橫向資產列表 圖片組件」配置，這樣配置的好處就是有特殊標題字體或特殊樣式可以用圖片組件組合使用滿足；如果標題屬于商品列表組件的屬性，這種運營場景顯然是無法滿足的。如圖：
考慮數據結構的通用性：多數組件會隨著時間或業務的發展變得不再適用「需兼容歷史組件/數據」，因此在初期設計組件時應充分考慮之后場景，以便開發據此設計合理的數據結構，保證組件拓展性；
可適當考慮邏輯組件「類似插件」：為了組件解耦&高通用性，可將組件的通用屬性抽象形成邏輯組件；舉例：想讓A組件、B組件、C組件具備定時展示能力「設置展示時間段，非展示時間段內 隱藏組件」，無需去修改每個組件屬性，只需新增一個有定時能力的邏輯組件，將需要定時的組件拖入即可「哪些組件可拖入采取配置文件配置方式，一次開發就可賦予所有組件定時能力」。
組件交互要統一：這說的統一不僅僅是系統內組件的交互統一，還包括與市面上設計軟件的統一，以降低用戶使用門檻「零代碼平臺本質與常用設計軟件并無本質區別」。
3. 組件埋點一定要重視
數據驅動的業務才能越做越好，且數據有很大部分來自埋點上報「路徑分析、漏斗分析等均依賴埋點上報」，因此組件埋點一定要重視。組件應按照公司埋點規范 組件埋點上報規范提出埋點需求并由開發嚴格上報。
總結
綜上只有公司業務夠大「運營頁面多，且需頻繁調整，需低成本做AB 實驗」，才適合搭建零代碼平臺，只有這樣才能發揮零代碼平臺的價值。
本文由 @小米粥 原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。
