關於互聯網後端產品設計的一些思考
在泛電商領域，持續負責後端產品設計1年半了。按照時間順序，這段時間內負責的部分如下：業務的基礎數據模塊1年半，重點客戶旗艦店接入1年，近半年演變成負責整個供應鏈端&系統支撐。
總的來說，是從點到面，負責的東西越來越多，項目/產品經歷了若干次迭代，業務經歷了從無到有到初步完成框架的過程。嘗試對過去這1年半做一做回顧總結，盡量將零散的點歸攏成塊，身在局中，可能讓人費解而不自知，歡迎指出。
一、初期新手，如餓牛入菜園，大快朵頤
剛開始的時候，不懂業務，也無崗位經驗，只有興趣和決心。於是不挑活兒，什麼都是新鮮的，全部掄一遍。做的第一個「項目」，現在看來實在是不值一提：把一個輸入項由文本框自由填寫改為標準化的多個選項方式。那時對產品設計，還只停留在「畫交互頁面」的層面上，對於背後的系統邏輯毫無sense，也不知道「需求分析」這回事。以至於在方案評審的時候，研發問「為什麼要這麼做」，愣住了的我脫口而出「因為老大說要這麼做」 o(╯□╰)o 。那時其實連交互頁面也畫的不到位，比如一些交互動作的後續效果並沒有想到。
後來接了「基礎數據」的一個項目，項目的目標是把缺失的運價數據補齊，除此之外並未更多可以依靠的信息：現有的情況未知、系統的邏輯不明、業內的情況也不明。一切都是未知，更不用說「運價」有何作用居於何種地位我也是未知的。
那時除了這個大項目，也參與一些雜七雜八的事：幫助運營梳理流程、因為QA人手不足做一些測試工作。大概就剩沒有寫代碼了。 因為沒做過，所以任何事都是新鮮的，都有收穫。這時做的事情，是從0到1——立竿見影，收效明顯，進步飛快。這時的項目效果，相當於從60分，做到了90分。
二、逐步考慮一些數據之間的關聯性
在做運價項目的時候，發現數據缺失的一個原因在於所依賴的另一項數據也是缺失的，同時這2個數據系統之間的調用、數據統計的方式，都存在一些漏洞。
於是做完運價補齊的項目，很自然的就產生了新需求，接著做了上游另外2個數據的補齊，對上游系統做了一遍排查。如此追溯，推而廣之，對於業務的10幾項基礎數據，乾脆列了一個矩陣（數據類型及每類數據的項目里程碑）。接下來，重點對其中影響交易的重要數據，優先做了補齊，完善了系統之間的邏輯關係。這個階段，逐漸的由單個項目，擴展到一個模塊的一條線上的項目了，對本業務的「基礎數據」的範圍有了更清晰的認識，明白了更多的行業知識。差不多在1年內，把10幾項數據都做了補齊，達到了初步完善的狀態。這些數據項，如果用百分制打分，從各種起點都做到了90分。
回看這個階段，還是存在不足的：對於每項數據的特性，還是存在沒有把握到的細節，以至於對異常情況欠缺考慮；「基礎數據」與業務中其它部分的關係、作用、地位、不同點，還缺乏深刻認知。這些不足，阻礙了系統從90分做到99分，在業務規模變大時，這些問題也會被放大。
三、做交易流程，是另外一種感覺
差不多在開始了半年後，我參與到了重點客戶旗艦店建設中，至今有1年的時間。開設旗艦店，涉及到全部交易流程，是另外一種feeling。
相比於基礎數據，交易流程，是一個動態過程。基礎數據，主要是對外提供一種服務，要求是數據的全、准。交易流程，是用戶在整個交易過程中的動作流程，要求體驗的快、穩定可靠，同時要能承載業務的一些意圖。交易流程如同一根線，串起了整個業務環節。基礎數據的價值，在於給整個交易流程的各個環節提供服務支撐，是數據的供應方。基礎數據是原材料，「堆放」在倉庫里，庫存要全，不能有壞品。交易流程是生產流水線，不斷運轉，加工動作不能出錯，還要速度快。
在旗艦店建設的1年中，主要是從無到有（不斷接入新客戶），少量參與了一些研發主導的重構工作，勉強可算「從有到優」。如果打分來表示，大概是從0分做到了70分。
四、系統建模很重要
與100分之間的差距，發生在偶爾出現的意外中。比如一次，由於某項基礎數據在某個日期要發生改動，但是由於該數據在設計的時候，並沒有「有效日期」這個屬性，導致即使提前知曉了變化，也無法修改——改早了或晚了都不對。甚至，幾個本應該使用這項數據的調用方，使用的竟然是一個自有的固定配置表，根本沒有使用基礎數據的服務。這不僅暴露出老系統遺留的問題，更暴露了PM團隊對系統模型的不重視和對業務的不精通，隨便的各自為戰。
沒有完整、合理的模型，導致在應對新增、變化時，只能臨時拼湊。長久下去，必然漏洞百出。業務規模是個放大器，當規模大到一定程度時，這些問題會加倍放大出來，到時苦不堪言。為了長遠利益，應該花力氣做系統化的重新梳理，切忌被急功近利的「要短期見效」所蒙蔽。
就業務整體來說，需要熟悉業務和行業知識的產品經理與研發架構師，一起來給系統建模，設計系統架構。在建模開始前，需要搞清以下問題並形成文檔產出物：
1、行業的原理和運行流程是什麼？
2、行業有何規律性特徵？各組成部分有何規律，有何例外？
3、行業採用了什麼技術？
4、行業上下游，未來3-5年會有怎樣的變化趨勢?
5、我方在行業中處於什麼位置，要採取什麼樣的發展策略？
有了對以上問題的考慮，能保障建立的模型，在未來3-5年內是合理的。之前聽到一個說法，在快速發展的互聯網領域，3-5年對系統進行一次重構，是一個比較合理的節奏。
下面可以啟動建模和系統架構工作了。基於以上問題的調研、思考，產品經理和研發架構師，按照順序需要完成如下事情：
1、我方系統，採用什麼樣的模塊框架、技術選型？
2、每一個模塊「稱其為好」的指標、目標是什麼？如何衡量？
3、每一個模塊有什麼特徵，應該具有哪些功能？
4、模塊之間如何進行交互，約定的統一交互介面是什麼？
5、系統如何保持擴展性、兼容性？任一模塊發生變化了應該如何做到兼容？
6、輸出一份解決了以上問題的產品架構設計文檔，至少包括：詳細的系統架構圖、全部流程圖、數據表定義、介面定義。
7、各個子模塊，基於以上架構設計，給出各自部分更細的設計文檔，同樣包含：架構圖、流程圖、數據表定義、介面定義，還包括運營流程設計等。
系統建模，真的很重要。沒有統一的模型，各自為戰，只會變成烏合之眾，像拼湊組裝的破自行車，框里哐嘡靠慣性往前走，總有倒下的一天。在此，只說從技術性的角度上說建模這件事，暫不涉及模型的落地和日後的貫徹執行問題，這些更多屬於管理和工作機制建設方面的內容。
五、關於基礎數據模型、交易流程模型的一些思考
經驗所限，以上提到的全業務的系統性建模，還並沒有完整操作經驗。挑基礎數據、交易流程這2個子模塊，談一談我的一些心得。
前面提及，基礎數據是個「倉庫」，交易流程是「生產線」，這是從二者的對比中的某一個維度做的比喻。
從「倉庫」的角度來說，基礎數據需要提供更全的「倉儲」，就是各項作為「原材料」的數據，需要全，不能存貨不足，同時需要它是準確的。交易流程，是一個動態的過程，用戶每一次的行為都是一個過程，需要保證響應的速度足夠快，足夠可靠（不能時有時無）。基礎數據的全、准，解決方法是採用足夠全面的數據源，設置合理的刷新頻率、更新機制、變更監控機制等。交易流程的快、可靠，解決方法是設計合理的高並發、高可靠、高性能的技術架構。
換另外的維度來說，電商作為一種服務，由於我們從事的是票務，相對於有形的物質商品，我們更是一種無形商品。任何商品都有售中、售後環節，當出現故障或者投訴時，為了發現、改正問題，需要我們能追溯歷史。相對基礎數據來說，又額外需要對數據的歷史做記錄（曾經賣出過的貨，發生投訴需要能追溯到當時的情況），對交易流程來說，需要對任意用戶的每一次行為，都可以追溯當時的過程。所以基礎數據，需要重視歷史數據的備份、查詢；交易流程，需要有全部用戶行為的日誌記錄。
當發生錯誤的時候，交易流程是「流動的時間」，改正錯誤，立馬就會回歸正道。但是基礎數據的錯誤，很可能導致資料庫被錯誤的數據「污染」，需要清除臟數據的影響。所以基礎數據需要採取措施應對臟數據，辦法有備份恢復機制、批量修改工具、重新刷新機制等。
總結如下表：
終於碼完了！寫完就發了，也沒修改，行文乾癟，不忍卒讀，聊作這一段經驗的總結~
歡迎留言
推薦閱讀：