這是作者第一次主導系統(tǒng)級的產(chǎn)品項目總結(jié)，與大家分享，也希望可以給大家?guī)硪恍┙梃b、參考。

背景

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

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

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

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

下面來進行介紹這套系統(tǒng)的設計思路。

現(xiàn)有系統(tǒng)問題

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

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

新系統(tǒng)做了哪些事情解決這些問題

重新搭建商品數(shù)據(jù)表結(jié)構(gòu)

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

重建新的商品發(fā)布機制

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

新增多維度規(guī)格機制

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

優(yōu)化用戶體驗

1. 優(yōu)化各頁面各功能的SQL查詢，提升加載速度
2. 優(yōu)化頁面結(jié)構(gòu)與界面UI設計

商品系統(tǒng)結(jié)構(gòu)

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

1. 該系統(tǒng)與外部其他系統(tǒng)的關系（如何協(xié)作、功能邊界）
2. 系統(tǒng)內(nèi)底層數(shù)據(jù)庫結(jié)構(gòu)設計
3. 系統(tǒng)內(nèi)應用功能邏輯
4. 系統(tǒng)內(nèi)各界面層建設

系統(tǒng)結(jié)構(gòu)設計

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

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

數(shù)據(jù)庫底層設計

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

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

功能邏輯結(jié)構(gòu)

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

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

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

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

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

看不見的需求 ???

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

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

界面應用層設計

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

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

數(shù)據(jù)同步是個大坑

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

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

設計數(shù)據(jù)同步方案時的幾個注意點：

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

項目回顧

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

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

小彩蛋：為什么先從商品模塊開始重構(gòu)？

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

后記

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

本文由 @KitWu 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。