這是作者第一次主導系統級的產品項目總結，與大家分享，也希望可以給大家帶來一些借鑒、參考。

背景

從2016年年初開始，我們內部一直在討論將原來商城代碼逐步模塊化的構想以及可行性。我們在09年初創，是當時國內第一批第三方醫藥電商平臺，當年的技術團隊用了一套開源的平臺電商代碼來二開搭建了這套系統，并一直沿用至今。這七八年時間，電商行業的技術已經飛速發展了，隨著多年的業務發展和多次的團隊更迭之后，再加上中間的管理不善問題，我們原來系統的代碼耦合度很高，拓展性和可讀性不足，導致很多時候修改一個問題會引發更多的問題，團隊效率很低，另外在功能和流程上也不滿足現有和未來的業務需求。所以當時我們內部討論了很長時間，需要從不停修補丁的做法上抽離出來，從系統底層上進行改造，剛好經歷了團隊換血，這件事似乎就更順理成章了。

對此我們討論了不同的做法，包括購買新系統二開還是在原來系統上重構等等，最后決定對現有系統的重點模塊直接進行重構，首先從商品管理系統開始。（為什么從商品管理系統開始？這里就不作解釋了，文末會補充有興趣的童鞋可以最后看一下~）

當時團隊進行了很多次討論，這個決定也反反復復變了多次，最常被提到的問題是“現在的系統是不是真的爛到用不了了？為什么要搞這么大動作？重構完就保證一定比現在的好嗎？這是一個深不見底的坑呀！資源夠嗎？中間有其他緊急項目怎么辦？”… … 我相信這是很多團隊在推動重構性的項目時候被問到最多的問題之幾，但其實這中間沒有必然的對與錯，也沒有標準答案，只是選擇的問題。如果在充分評估過技術方案、團隊實力、可能帶來的風險等因素之后，仍然認為進行重構能夠帶來更大的可預見收益，那么就開干吧。我很開心，當時我們團隊對于要做這件事還是比較有共識的（可能出于程序猿天生不愛看別人代碼），所以即使出現了一些波折，后續也都一一解決了。

但是不得不說，在商品管理系統重構完之后，確實出現了很多問題，尤其是新舊數據庫兼容同步的問題，這或多或少給業務方和系統穩定性上帶來了一些影響，有一些還是不可逆的影響，這是我們非常抱歉的。具體下面會說到。

下面來進行介紹這套系統的設計思路。

現有系統問題

1. 商品結構與規范的藥品管理信息結構不匹配 — 同一批準文號下應可存在多個不同品牌的標準SKU，目前數據結構設計上不符合藥品的特殊屬性；
2. 規格信息無法管理 — 由于發布商品機制和流程的設計問題，數據庫存在大量重復的規格數據，例如商家發布的：3克/片*6片、3g/片x6片、3g/s*6s等本屬同一標準規格的被劃分為3個不同規格，這不利于平臺對商品的整體把控，也不利于用戶在網站端進行搜索和分類查詢；
3. 基礎庫與商品庫混合 — 基礎產品與商品從結構上是混合管理的，不利于未來平臺拓展其他橫向業務的發展需求；
4. 基礎庫數據維護十分耗費人手 — 目前基礎庫信息由內部員工手動維護，沒有引入商家角色共同進行維護，導致人力耗費非常大；
5. 商品結構靈活性與可拓展性不足 — 無法為商品增加多維度SKU的信息，如隱形眼鏡類目的商品，無法根據顏色和度數進行多維度維護，而“100度 珊瑚色”“150度 珊瑚色”“200度 珊瑚色”這樣的SKU商家需要一個個添加；
6. 不支持多渠道的價格 — 不利于未來拓展多品類商品的業務需求；
7. 外部產品接口不規范 — 商品模塊作為對接多個產品的公共模塊，對外接口仍需優化；
8. 界面很老舊，用戶體驗不佳。

以上的這些從#4~#8的需求其實在目前外購或者開源的電子商務系統上已經有非常成熟而穩定的解決方案，但由于這套系#1~#3的需求是基于自身業務的，醫藥屬性強，其他一般的電商系統不支持，再加上希望做到跟原有系統更和平的過渡，所以我們最后計劃是自己來開發。

新系統做了哪些事情解決這些問題

重新搭建商品數據表結構

1. 取消“自定義SKU”機制，針對標準化類目建立標準產品與商品的強制關聯關系；
2. 將基礎產品庫與商品庫從結構上進行分離，并建立基礎庫和商品庫中的各層商品基礎信息映射關系，日后基礎產品庫會作為打通其他橫向產品業務的公共庫，而商品庫則主要給到電商平臺使用。

重建新的商品發布機制

1. 在商品發布時，允許商家申請新增基礎產品、允許商家修改基礎產品信息提交審核，審核通過后基礎產品信息自動入庫；
2. 將商品發布與基礎產品數據維護整合在一起，引入商家角色維護基礎信息，節省內部維護人手。

新增多維度規格機制

如下圖，增加“類型”與“通用規格”的邏輯，與類目關聯，為同類型的商品增加多維度規格的維護。

優化用戶體驗

1. 優化各頁面各功能的SQL查詢，提升加載速度
2. 優化頁面結構與界面UI設計

商品系統結構

系統級的設計從大到細一般分為四個層次，一般從我們平時做產品設計的時候，可能會比較多在#3和#4上，而如果培養自己習慣從#1和#2層開始去思考這個功能和界面的設計，往往設計出來的功能可執行性會更高，與程序猿撕逼的機會會更低：

1. 該系統與外部其他系統的關系（如何協作、功能邊界）
2. 系統內底層數據庫結構設計
3. 系統內應用功能邏輯
4. 系統內各界面層建設

系統結構設計

一般的電商系統可以拆成好幾塊主要業務。訂單、用戶、商品、促銷等等，對于第三方平臺系統來說還有商家。我們目前的系統是按端來拆分的，像文章開始說的，PC端、移動端、平臺后臺、商家后臺。各個端的邏輯是自己管自己的，所以從代碼的層面每一個端都會有一套相對獨立的訂單、用戶、商品、促銷邏輯。這樣子就會造成說，由于各種原因導致PC和移動端的處理邏輯可能不統一，不同模塊之間的耦合度高，例如可能改一下商品的顯示邏輯，可能會影響訂單的和用戶的，加大問題定位的難度。所以我們最后決定逐步建立模塊化系統的方案。其實這也是目前很普遍的技術方案，優勢是更加靈活、拓展性強，邏輯相對各模塊獨立對于問題的定位也更精準。（模塊化的架構設計大家可以參考一下《淘寶技術發展》）

而考慮到我們的資源問題，以及考慮到重構后的系統跟現有業務進行和平對接，所以我們第一期先以搭建新商品數據庫、替換平臺后臺與商家后臺管理功能（涉及到所有產品與商品數據增刪查改的功能）為主，其他讀取商品數據的功能（如網站前端、其他功能）則維持原來的邏輯，并在新舊數據庫之間建立同步機制，完成第一期的開發內容。（如下圖）新舊數據庫的同步機制在這一點上我們這次踩了很多坑，這一點下面會有專門的模塊講到，所以也希望大家跟架構師和開發經理討論的時候，對于新舊數據和功能系統的切換方案，還是要謹慎謹慎再謹慎。

數據庫底層設計

很多人說系統的設計歸根到底就是管數據的，建立功能和邏輯來去管控這些數據的流轉以及儲存。這樣的說法雖然片面，但也不無道理。建立一套系統，其實搞清楚其數據庫表結構，就相當于搞清楚了它所管理的“對象”還有“對象和對象之間的關系”，這對于后續的功能設計是非常重要的。

關于數據庫底層結構很多產品經理會覺得這是開發經理和架構師所需要溝通和建立的事情，產品經理主要還是在業務邏輯和界面上來策劃，這也沒有錯，但是為了更好地掌控開發出來的系統質量，我選擇參與到數據庫表結構建設的工作來，下面幾張圖是我基于產品邏輯上的理解對各種商品管理系統中涉及到的“對象”和“對象與對象之間的關系”而制作的圖表。其實這些圖表均不復雜也不“技術”，是產品經理力所能及的事情，但很有助于開發以及測試還有各方干系人更好地理解系統，這樣后面設計出來的功能邏輯和界面也會更加清晰。

功能邏輯結構

一般的第三方平臺型的商品管理系統都會有幾個固定模塊，商品發布、商品管理、商品上下架、商品審核，這幾塊的流程以及管理功能都是商品管理系統所必須的。而由于醫藥類目的商品都是屬于高度標準化的商品，而且對于信息準確性的要求非常高，市場上的所有藥品、醫療器械、保健食品、化妝品等都必須在中國國家食品藥品監督管理局登記在冊，而且對于該類商品而言，有規范化的參數與標準，包括批準文號、通用名稱、功能主治等所有信息都以在國家藥監局注冊的為準，所以我們在設計商品管理系統的時候需要建立產品庫，并與商品庫分開，另外在工作流上需要將產品庫的信息標準掌握在平臺管理員手中，而限制商家修改這部分信息的權限。

在設計這套系統的時候，我參考了天貓的達爾文商品管理系統（http://open.taobao.com/doc2/detail.htm?articleId=102155&docType=1）。當年2012年左右的時候，淘寶針對SPU、SKU亂象的問題建立起這套商品管理系統，從流程上通過天貓、商家、品牌商多方參與共建一個準確有效的天貓產品庫， 通過品牌歸一、型號歸一等解決現存的重復SPU的問題。我們基礎庫的做法其實是參考了達爾文的，但是在達爾文的大框下，在數據表設計和工作流上再做了適合我們平臺業務的修改。

在功能邏輯這一層，除了考慮到功能點之外，也需要考慮到工作流，每一項功能的工作流，什么角色在什么權限下能夠做什么樣的操作，需要做怎么樣的判斷，判斷正確和判斷錯誤分別會進行什么樣的操作和提示什么樣的信息，這樣的流程會讓項目里的所有人（包括開發、測試、業務方）都能清晰每一件事情的走向，也對產品經理在后續檢驗自己的策劃是否有錯誤，也對后續項目上線后的驗收或者使用有很大的幫助。

一般商品管理系統的流程主要是發布商品、審核商品、上下架的規則判斷等，而在我們的這次系統設計上，還會加入基礎產品信息發布和維護，以及因為基礎產品信息維護而影響商品狀態的流程和同能。這一點大家可以根據自身的平臺需求來進行設計。在流程上標識好每一個節點即可。

這一點《后臺設計小結》 這一篇文章的小哥寫得很不錯，后臺管理系統的設計上除了功能和界面之外，權限流、工作流和日志流也是非常重要的，但這往往我們在設計后臺功能的時候會忽略，尤其是經驗不足的時候。在項目策劃時期，盡量把每一個場景、每一個數據、每一句的提示都覆蓋到，把需求做細做精，其實是能夠節省大量在項目中期撕逼的情況（雖然還是免不了要撕逼，:）。下圖是當時做的原型文件中的頁面：

看不見的需求 ???

除了以上看得見的需求之外，還有一部分需求是看不見的。

1. 上文講到的權限管理。作為后臺管理系統，用戶角色權限系統管理都是必要的功能模塊。由于要兼顧舊有平臺的使用，以及避免要管理兩套用戶權限，所以這一期商品管理系統的權限管理是直接使用接口的方式跟舊有平臺進行同步。
2. 上文講到的日志管理。這一期的開發我們并沒有考慮到日志操作管理，導致我們在后面遇到因為數據同步還有程序出現問題的時候，我們沒有辦法非常有效和及時地定位出問題。日志操作管理是為了方便管理和跟蹤業務處理過程，并依據業務系統使用活動過程記錄的信息，分析系統的使用情況、存在問題和對任意業務處理的過程追蹤管理。而如果一開始忘了，后面要補可能是一個相對復雜的過程，就像我們現在這樣。所以我們下一版本也計劃把操作日志記錄這塊補上。
3. 商家ERP接口對接。我們有部分商家自己沒有技術力量，所以如果我們的ERP接口的需要重新開發的話，會對商家的業務有很大影響。在跟團隊商量過后，我們決定保留原來接口的協議以及邏輯，但是對接到新商品數據庫上面來，在商家不需要做任何修改的情況下，依然正常使用。（因為目前我們的ERP接口只有查詢和更新少量商品信息的功能，沒有發布和提交審核功能，所以可以這樣改。）
4. 新舊平臺數據同步機制。第一期我們將幾乎所有涉及商品數據增刪查改的功能全部進行了替換，換到新的管理平臺進行，舊平臺只保留查詢功能以及3個影響商品數據的功能。因為資源和時間問題，而且考慮到風險的問題，所以我們第一期仍保留網站前端的功能不變，前端依然讀取舊商品庫，通過新舊商品庫單向同步（新的同步到舊的）的方式更新舊庫商品數據。而3個影響商品數據的功能采用數據庫觸發器的方式單向從舊庫同步到新庫。就是上文架構圖所寫的。后續計劃在系統運作相對穩定，資源相對充足的情況下，會針對各個端逐步替換，最終拋棄舊的數據庫。

界面應用層設計

界面應用層的設計是大部分產品經理每天都做的工作了，主要需要考慮到的就是用戶體驗方面的功能。這次的商品管理系統，界面只有后臺界面，用戶分別是平臺各部門的同事以及商家。我認為后臺系統的界面或者說用戶體驗是否好，主要考察的是兩點，提高效率，降低出錯。

除了頁面布局和UI界面以外，其實對于控件使用統一性、適量清晰的提示、數據加載的時間、動畫的流暢度、出錯時的提示等等這些都屬于用戶體驗的一部分，這些都非常有助于提升用戶操作的效率以及降低其錯誤率。界面這一塊我就不多說了，還是要多看看其他人的設計，多用心站在用戶立場試用，后期多搜集用戶意見就能夠清楚了。

數據同步是個大坑

總結整個項目下來，遇到比較多問題的引起都是由于新舊數據同步以及不兼容而產生的。如上文所述，由于資源和時間問題，而且考慮到風險的問題，所以我們第一期仍保留網站前端的功能不變，前端依然讀取舊商品庫，通過新舊商品庫單向同步（新的同步到舊的）的方式更新舊庫商品數據。這個方案在立項之前其實我們就已經多次討論過，當時有三個方案，一個是在舊的數據庫上進行改造，另一個是做節點（在上線之后，直接拋棄舊庫）。

但最后決定用新舊同步的方案原因是這樣對系統的穩定性影響最低。由于我們是從根本結構上進行改造，原有的表結構不能使用了，要變更數據庫表結構，那么連同其應用層的邏輯基本上都需要重寫。這意味著如果不進行同步，我們需要全網整體代碼進行替換，這樣的工作量太大，且如果萬一新系統有嚴重問題，會對業務影響很大。而采用同步的方法，工作量相對小，且如果新系統有嚴重問題，只要將同步機制斷掉（如下圖），將平臺和商家后臺切換回原來的舊后臺，也能保持正常使用。

設計數據同步方案時的幾個注意點：

1. 表結構設計。在進行表設計的時候，要將舊庫的每一張表每一個字段可能影響到的每一個功能都詳細列出，并做好一一對應，這樣在設計新表的時候就能夠更好地兼容所有商品相關功能。除了舊對應到新表上面去，也要思考新表的數據如何對應回舊表并兼容舊平臺的功能，因為我們有部分功能還是要在舊平臺上實現，所以兩邊的數據表和數據結構如何做到兼容是很關鍵的。這一點上我覺得我們做得還是挺不錯的，在新舊數據庫表和功能之間的覆蓋基本上做到了95%以上，沒有出現比較大的問題。
2. 數據初始化。平臺經過了多年的發展，再加上之前的維護不夠，存在著大量的臟數據。有一些臟數據是無法從功能和邏輯上說得清的怎么產生的，有一些臟數據是之前由于bug產生的數據，但是因為在正常使用中，所以也必須考慮是同步過去還是丟棄掉。除了臟數據之外，還需要考慮數據的不同狀態。在初始化之前再三多方共同檢查初始化腳本、做好數據的備份、溝通好初始化數據檢查的機制，包括初始化數據的數量、狀態，初始化后進行比對。這個工作量是很大很枯燥的，而且很重要，一旦初始化之后沒有檢查清楚投產使用，后面會產生更多問題數據，就沒有辦法恢復了。我們在這件事情上，吃了很多虧，直到現在都還有一些問題持續在處理當中。
3. 數據同步機制。我們針對不同的功能采用了不同的數據同步機制，針對一般時效性要求不高的功能采用程序觸發隊列更新的同步機制，針對需要及時修改的如商品價格和上下架和庫存等數據采用程序直接觸發新舊庫更新的機制，針對舊庫同步到新庫的功能（如前端用戶下單后扣減庫存）采用數據庫觸發器的機制。同步機制的制定可以根據不同功能的要求，充分與開發技術進行討論確定下來。
4. 數據檢查機制。除了初始化的數據檢查機制之外，在維護期可能會有頻繁地批量操作數據的事情，尤其是當批量功能沒有在需求策劃階段被考慮進去的情況，所以當需要批量操作數據的時候，往往由于各種原因出現問題，所以數據比對的檢查機制就很重要了。這個可能需要拉上開發和測試的同學，使用數據比對的工具進行。

項目回顧

最后回顧一下項目的時間節點和成員，大家在進行類似項目的時候可以大致參考一下。2016年6月開始需求調研，2016年8月開始需求策劃，2016年9月底項目啟動，原計劃2016年12月底項目上線，這樣能夠趕在2017年1月底過年之前有一個相對長的運作期，恰好是元旦后春節前，商家和用戶操作會減少，如果真的出問題影響會比正常時間要小。但后來因為有項目插隊還有開發時間延長的問題，最終在2017年2月初春節后回來上線。截止2017年4月迭代了5個小版本，仍然持續迭代中。

項目成員包括產品經理一個、前端一個半、后臺開發三個、測試兩個半、運維一個，還有其他包括舊平臺的開發童鞋協助。由于后臺系統采用的是一個開源框架來做前端，所以并沒有用到設計資源。

小彩蛋：為什么先從商品模塊開始重構？

1. 作為醫藥電商平臺，我們的商品數據結構需求是一般的電商系統無法兼容的；而訂單、會員等其他功能，基本與其他電商系統無異，目前的系統仍然能支撐業務，所以其他模塊的優先級不高；
2. 商品管理從功能界限上相對獨立，但是大部分的邏輯都在商品管理系統內部，與外部系統以及第三方對接少，影響可能相對低；
3. 考慮到公司的整體戰略規劃，未來希望建立自己的藥品庫，可以提供給不同的產品進行對接，包括資訊社區、問答社區、疾病庫等等，可以作為我們自身的專業數據庫。

后記

這是我第一次主導系統級的產品項目，雖然只是我們公司內部電商系統的一個商品子系統，但是在經歷了這半年一個人從需求調研到產品策劃設計一腳踢，從開發開始到延誤三次最終上線，從上線后被狂批再到目前經過幾次版本維護后逐步順暢起來，中間的思考和多次踩坑的經驗，都讓我對產品設計有了不同的認識，我希望把這些記錄下來，算是給自己這半年工作一個小結，也希望能夠跟其他童鞋一起交流~

本文由 @KitWu 原創發布于人人都是產品經理。未經許可，禁止轉載。