提前警告，文長，對電商沒興趣的就別看了喔。

　

最近上網看一些 Unity遊戲開發的視頻影片，看到一些影片用很短的時間打造出大致能玩的遊戲原型。

不過從那個設計思路，開發的步驟與實現的成果，大概只有一個感想，遊戲開發好累好複雜。

如果要繼續添加新的功能，或是豐富遊戲內的素材，需要的時間，會很多。

一個人開發的話，一個品質與體驗差不多完整的遊戲，要開發到猴年馬月才能完成吧。

如果要分工，用人力堆，沒有做好架構，很可能會產生溝通協作不良引發的臭蟲。

為什麼就要這麼複雜呢?

就不能數據結構設計好，需要的功能就從設計好的結構定義，由數據自動長出來嗎?

如果每增加一個已知的東西，都需要動到程式碼才能加進去，那個開發效率自然慘烈，品質也會十分不穩定的。

確實用Unity可以快速開發遊戲，只要有想像力，工具本身是沒限制的。

但這工具挺低階的，就像用組合語言在開發簡單視窗應用一樣，會特別累。

所以呢，也可以抄別人的，改一點點然後當自己的，不過如果自己想要的成品和現有可以拿來抄的差距比較大時，剩下大量的修改工作一樣嚇死人。

　

這讓傻蛋想起之前開發一個小的App內獨立電商前後台時的經驗。

一開始，感覺會是很大的挑戰，但實際執行，卻算蠻涼的吧。

　

當時工作的公司是個有點年紀的小電商平台。

公司裡很多年輕人。

這公司很早就在做電商，曾經有點小成功，還進軍大陸，然後被殺得丟盔棄甲回台灣。

一起一落。

回台灣後做醫美的信託票券，這個創新的產品配合之前電商客群，煥發新商機，迎來第二春，但又被收購不成的對手找麻煩，最後兩敗俱傷，不能做醫美的導客信託票券，後面只好改做SPA的票券。

同時呢，又接軌到FB剛開始的廣告費很低性價比很高的新的電商黃金時代，雖然PC轉型手機的調整慢於市場，不過藉由投廣告，這公司又賺了一波吧。

傻蛋到職時是最後一波在走下坡的時候，流量開始加速變貴，之前很賺錢的電商，被Momo與蝦皮等競爭下，自己的平台沒辦法打，變成去人家的平台開店那樣了。

總之這是一個不斷創新，不斷丟掉過去包袱一直掙扎的電商公司，裡面幾乎都是年輕人。

資深點的，曾經在過去的成功扮演重要角色的一些大將好像都和老闆鬧翻跑掉了，所以除了財務與行政單位，其他部分，包括主管在內，基本上全都是年輕人。

而找上門來合作的則是一個社區網路起家的網路供應商。

他們開發了一款免費App來服務他們的客戶，主要是社區管理委員會，讓社區的住戶可以透過App收到包裹通知。

這是主要且實用的功能，當然會多做一些功能來增加用戶黏著度與流量變現，所以App裡可以收包裹外，還可以繳水電費，與很多生活服務資訊的整合。

當然，還可以在裡面賣東西，開商城。

因為免費且深入社區，又是和管理員通知收包裹流程綁在一起，所以是剛需，流量與日活皆有一定規模。

但他們自己開的商城東西賣得不好，對電商也不了解，所以找上當時的老闆，他們合作一起來做這個電商，用生活服務App的流量來變現。

　

當時老闆找傻蛋來開發這個電商平台。

傻蛋的直覺是，為什麼不用之前的電商平台系統稍微改一改就好，有成熟的流程和功能，為什麼要重寫?

那時傻蛋不知道的是，老闆大概已經決定拋棄舊的自建電商平台系統了。

傻蛋剛進公司時，維護舊系統的工程師加一加也有十幾個人，傻蛋是負責與這些都不相關的新專案，架構前後端分離，後端架構全都傻蛋自己搞的，拿上一份工作的經驗再改良一番後拿來用的，不是核心事業流程，所以人手就傻蛋一個人。

算是專案型的傭兵吧，其他人都不接的專案，就給傻蛋接，反正呢，做不起來大概也不會怎麼樣吧，總之當時傻蛋就是一人成軍的。

而接手這個新電商平台開發任務時，原本的IT，人也走掉超過一半以上了。

剩下來的也幾乎都在半年內就都走光了，他們開發維護多年的舊系統，被老闆拋棄了。

取而代之的，是Oracle併購的NetSuite這個雲端ERP，並配置了幾個新人來做雲端ERP的操作維護寫script的工作，而原本的電商商品上架銷售與活動等等功能呢，則是把資料搬去別的電商開店平台，改用別人的系統了。

當然這是後話，換平台茲事體大，老闆就很堅定的換下去，然後產生一堆衍生的工作，傻蛋之前的外掛型邊緣專案被波及也跟著要改一堆來補新流程和舊系統的落差，換不到一年，又以這個平台品質太差，問題太多為理由，嗯嗯，再換一次，這次換的是更成熟的Shopline平台，廠商不再配合做客製開發了，於是又得委屈求全的改自己的系統去配合平台的現有功能。

搞這些花的時間比傻蛋開發維護這個電商平台花得時間要更多哩。

這個電商平台開發專案，不到半年，大概三個月左右上線，到傻蛋離職前營運了大概一年，系統基本上是正常運作的，就是轉換率奇差無比，沒績效，傻蛋離職後大概一年左右之前的同事有說合作專案被結束了。

既然都結束了就來聊聊這專案的歷史吧。

那時老闆要傻蛋接手這個開發的理由是，這個App很有流量，很有機會。

他的想法是，可以開發同社區越多人買越便宜的機制當作主要訴求，下單購買的人越多，達到門檻所有參與的同社區買家都能得到優惠的及時折扣。

這概念坦白說沒毛病，但會有很多細節需要打磨。

當時本來準備離職的傻蛋就想說再搞看看吧，就開始了幾乎從零打造一個電商系統的旅程。

範圍呢，商品數據由ERP建立，售價與成本在ERP設置，由系統同步過來，負責提供商品後台的素材維護上架，電商主頁與館別頁活動頁的上下架設定，購物車頁與結帳流程，金流串接。

帳務部分，則是訂單需匯回ERP，物流出貨呢，初期借用那個被廢棄的舊系統，最終也是要對雲端ERP做客製開發把剩下流程串完。

基本上面對客戶的，活動營銷的，就是這個電商系統要處理，會計帳務則以ERP為主導，最後直接在ERP做財報，大概是這樣的scope範圍。

金流一開始是串一家叫Tappay的廠商，小公司，與老闆有同校之誼吧，金流是電商這邊串，只把結果透過訂單拋回去給ERP，ERP不能串不想串的就電商系統這裡串啦，客戶服務也是電商這邊處理。

物流一開始是串黑貓，先用舊系統殘餘的部分處理，再慢慢的直接重新串接API，嗯，過沒多久後物流就被換成新竹物流了，嗯，再重新看API規格再重新串接一次。

金流部分則以廠商無法做部分刷退，無法實現同社區同一天檔期買越多越便宜的馬上刷退，老闆又決定換成綠界支付了，再重新串接一次了。

當時綠界的支付需要前端跳轉綠界支付頁面，就使用體驗來說是變差了，也不是API直接串接的，算是技術上的退化，不過當時為了開刷卡3D驗證，來保護賣方與平台的權益(沒開3D驗證消費者可以任意通知取消，開了之後則無法取消需要廠商幫忙處理)，有3D驗證就無法快速結帳，換成綠界體驗差異也就沒那麼大了就是。

換了綠界金流，可以部分刷退了，一開始上線時沒實現的同社區集量折扣的功能是不是要開發上線了?其實傻蛋都先寫好差不多了，最後需求確認再看是否調整調整就能上線的，但直到傻蛋離職為止老闆都還在猶豫，這個功能一直都沒上。

可能是怕失敗，最後的王牌都打了也沒用，留著當藉口吧。

所以傻蛋開發的自有電商系統，自始自終就沒什麼特色，就只是個基本能開賣的電商系統而已，即使後面追加了一些奇怪的團購開團，為會員增加團購主身份在前台提供團購主佣金管理等功能，本質上還是很陽春的電商系統的。

老闆說，第一階段，能上架，能賣，能收訂單，能出貨，能和ERP整合就好，剩下的之後再弄。

　

沒問題，先做基本的電商流程吧，當時還有舊系統的年輕人主管可以問，同樣的需求以前是怎麼做的，不至於沒電商經驗時自己瞎搞。

第一階段主要是要和ERP數據流程能完整從商品同步過來始，訂單資料回傳終完成一個循環。

傻蛋就從需求分析，然後先設計資料庫的結構，討論前端的畫面該怎麼呈現開始。

用戶前台，身份驗證是合作App那邊負責的，會員資料與身份驗證是透過API接口串接的，使用者介面不用管登入。

前端的頁面功能連結，如果碰到需要登入才能進行的購物車或訂單查詢等功能，就跳轉App的登入連結由App處理登入就好。

所以這個電商，基本上就是首頁，各分類館別頁面，活動頁面，商品詳情頁，是訪客可以訪問的頁面。

點加入購物車與跳購物車列表頁需要登入，然後可以從購物車列表頁勾選結帳，跳結帳確認頁，結帳確認頁最早就是輸入卡號，API串接與驗證，送出就完成訂單了，跳回訂單完成頁，再提供回首頁或訂單查詢頁的連結，就算完成一次交易。

使用者進入首頁，瀏覽首頁上的廣告輪播超連結，或館別分類頁選單超連結，或首頁上直接曝光的商品列表，可以跳商品詳情頁，類似於另一個首頁的館別頁，或是活動頁。

商品詳情頁可以加入購物車，最後在購物車頁可以結帳，詳情頁需要支持階梯售價的商品，購買數量達級距門檻時價格將套用其優惠價格，畫面上要呈現再買幾件的話下一級優惠價值的提示。

同社區集量沒有，但第一版可以用戶一個人自己集量，這個並不算很複雜的電商套路，就順便實現，而這種訂單的折扣也是和ERP那邊約定好科目，事先把折扣項用訂單明細方式處理好，也算是為之後準備吧。

組合商品也順便做一做，一組商品一起購買，可以有優惠折扣，這個需求同樣不是很複雜，ERP直接定義這種商品，這結構也要同步過來，訂單回去ERP時就照其結構，連同組合折扣都放在訂單明細裡。

大概就傻蛋一個人用不到一個月把數據庫弄好，API接口實現好，再一個月把前後台畫面和API串接實現完，然後就上線試營運了。

因為畢竟是有舊電商系統的經驗也有人可以問，所以這個階段沒啥問題。

電商的前台頁面，主要是首頁與館別頁，與潛在的活動頁需求。

這部分傻蛋就直接決定設計，用動態的組合頁面，給後臺自行建立與維護就好。

每個頁面需要不重複的網址相對路徑，前端跳頁時就根據頁面路徑打API來要頁面內容，如果此路徑後臺沒有預先設定的頁面，那就是不存在的頁面請求，前端要顯示404不存在頁面，否則就把頁面於後台設置的內容組件資料回傳給前端，前端動態根據數據把內容給長出來。

包括首頁也是一個動態組合頁，它的路徑就是一個倒斜線/，如果首頁沒配置後臺那首頁內容就404了。

每個動態頁面由組件組成，多個任意組合的組件，由上往下，把動態頁配置的組件一個一個動態render出來呈現就好。

輪播廣告，功能選單，橫向右捲的商品清單，往下無限捲動的商品列表，以及自訂義html editor的所見即所得動態內容區塊，初期就先提供這五種。

建立頁面，透過頁面的路徑設定被跳轉，就能實現館別分類頁，活動頁基本上也同理，頁面自己建，每個頁面要上架曝光的商品，也是後台自己設定就好。

原本有想說未來可以追加線上問卷與一些互動遊戲的組件擴充，不過上線以後這五個組件基本上夠用，原本預留的擴充機制都沒有使用到。

就後台頁面管理的UI設計稍微麻煩點，要用樹狀結構的組件來做頁面結構的呈現，子頁面就放父頁面下面的節點，兩層的樹狀結構基本夠用了，不會亂。

所以呢，新館別分類頁，後來新增的優惠活動頁，以及曾經嘗試的Youtube直播購物的頁面，基本上都是用相同架構實現，基本需求無須技術人員支持，會用就自己後台搞，特例的直播才需要工程師幫忙，在幾乎不改系統的情況下把臨時需求塞進系統流程裡。

而商品詳情頁就是後台商品管理撈ERP同步過來的商品資料後，維護商品文案，然後就完成了。

商品的可賣量有點忘了，最早是預期一律由ERP那邊控制，電商銷售系統只負責同步就好，臨時追加可賣量要去ERP改追加進貨，再去後台按手動同步，但ERP那邊沒那麼好客製，加上不是那麼重要，好像簡化成後台隨便key追加或減少可賣量吧。

所以流程就是去ERP建立商品，成本與售價，每天排程同步或剛建或剛改的商品手動去後台按同步，然後去電商後台商品管理設定商品素材，設定好後就看要在那些頁面曝光，就去頁面管理把曝光商品的組件裡設定要新上架的商品就好。

可以透過API查詢可以上架商品的頁面組件，在後台上架頁可以快速選擇上架位置，不用再離開跳到頁面管理去上架。

上架完成後商品於前台就會曝光了。

需要增設館別分類頁，需要調整館別功能連結，也都可以後台自行維護就好，後台核心就這個了，其他的訂單報表查詢，客服問題單處理則是相對簡單的功能不用說明。

前台收到訂單後，後台另一個主要流程就是訂單處理，因為ERP暫時不能幫忙串金流物流，初期先克難提供一些物流格式的訂單匯出，人工下載下來拿去物流平台上傳，成為系統操作者的每日SOP一部分。

而前台的用戶呢，就看進入時的路徑，透過API取得那個路徑的動態頁面設定，然後根據收到的資料呈現畫面，瀏覽其他頁面或商品，最後就是加入購物車與結帳，查看訂單出貨狀況，這一塊要串接物流API，初版的陽春電商就這樣而已，照老闆要求的只先做最基本功能。

　

試營運可以透過自訂義組件弄成類似活動頁，提供一些看起來優惠，還後上線賣。

沒啥訂單，用戶沒事不會來你的電商買別的電商平台買得到的東西。

售價基本上都差不多，偶爾會有少量的商品價格可以比Momo低一些，但新平台沒有信任基礎，一點點價差也不足以做為購買的衝動理由，所以第一階段任務完成，但結果不如預期。

老闆用電商行業常見的轉化率來估計可能的收入，實際上的轉化率遠遠低於行業平均值。

這樣傻傻的賣不是個事。

所以傻蛋就慫恿專業負責的主要行銷去和老闆建議，要開發優惠折扣活動的功能。

而這個優惠活動呢，照之前的思路，自然也是後台自己設定，而不用像舊系統每次活動都要IT處理。

怎搞?

活動頁基礎需要一個自訂路徑頁面，那個頁面就是活動頁。

而活動的本質，則定義為一個活動代碼都要設一組活動優惠規則。

活動名稱與生效起訖時間，對應一個活動id。

剩下來是動態的部分，活動有兩組設定，一組是活動適用條件限制的設置，另一組是符合活動規則時能得到的活動優惠獎勵設定。

這兩組都可以設定多組動態條件。

如定義一個叫做新會員身份，註冊未滿七天那樣，就可以配置僅限新會員的優惠活動。

訂單結帳金額滿指定金額才能適用，而是最常見的限制條件設置，這個自然也必須支援。

可以額外設置兩組互斥的商品條件，僅設置的商品才適用此活動，與所有商品都可適用但排除指定設置商品不適用優惠規則。

每個會員只能參加的次數也是限制條件，只能參加一次的再套用活動優惠結帳後，同會員就不能在之後的訂單看到與使用這個優惠活動，這也是常見的需求。

想得出來的條件也可以加進去，合理就能做，設定的全部都會用來作為用戶結帳，同時有多個活動都適用時，根據當時討論，只允許同時選擇一個優惠活動來使用，所以這些設定條件就是後端在結帳時提供用戶選擇優惠活動清單時的計算依據，不符合的就不顯示或顯示訂單金額還差多少才能適用某個優惠活動。

符合條件時能得到的優惠是另一組必須配置的條件。

最常見的就是固定金額折扣與訂單金額比例折扣，提供折扣是由這兩種是二選一。

當然可以追加一些額外條件如折扣比例但不超過上限金額，不過實際上不是那麼必要，所以沒有做，最常見的活動就是訂單滿額折固定金額或照比例打折這樣的組合，配置適用商品規則就了事了。

而是一組而非一個優惠條件，可以擴充如提供贈品，贈品可以是實體商品也可以是虛擬點數或折價券等等，又或是常見的免運，所以常用的就是滿額免運加折扣的簡單活動，設定好活動辦法，維護活動頁與上面適用的活動商品，就可以上了。

活動產生的折扣則一律用活動折扣的科目塞訂單明細，讓訂單金額帳是平的，和客戶實收的金額等於商品價格扣掉優惠折扣項，數據要對才能吃進ERP。

這些規則的設定，傻蛋就用偷懶的json文字欄位存在數據庫欄位裡面，算是不嚴謹的設計。

缺點是比較複雜不可靠，有人亂改數據庫的設定值而非透過設定好前端透台寫死的UI選擇對應的值，就會出現不可控的錯誤。

好處是要加新需求或調整設計，就比較快，就是活動的條件和優惠，認知的包袱會小很多。

不這樣偷懶的話，都做正規化的數據結構設計，數據表的數量會增加非常多，看到上百甚至數百個數據表，想快速掌握整個數據結構，就會很難聚焦，有新需求就不得不慢慢來了。

前端就是購物車進結帳頁那個時機點呼叫的結帳前數據的API要多回傳判斷過可以適用選擇的活動數據供畫面挑選，選擇要使用或手動輸入活動代碼要使用時再另外提供一個接口，再檢查一次當前訂單與活動的適用，並試算出這個活動套用的優惠折扣項金額讓前端呈現，訂單結帳時傳套用的活動序號並寫進訂單紀錄與折扣項寫進訂單明細。

至於會員的訂單查詢，訂單明細可以查出套用的優惠活動名稱與實際優惠折扣金額在明細，就照數據呈現就好。

所以行銷就可以搞活動了。

當時主要的伎倆就是，每週一次和App那邊討要一次對會員的廣告推播權力。

當時是蠻無腦的，對所有會員推播，推播由App方提供API接口給我們調用，我們後台提供UI來設定行銷活動的推播，基本上就是做一個自訂活動頁的超連結與推播訊息文字，讓App對所有會員做廣告推播，套路大概就是這樣。

用戶收到推播點擊會打開App，跳到活動頁面看到上面的活動素材與上面的商品列表，有興趣的會點進去看商品，看會不會點加入購物車衝動購物一下那樣。

就結果來說，對數十萬，後面甚至破百萬個會員帳號短時間內做廣告推播，流量上是有的，相較平常流量，這時候流量會暴衝到平常的百倍以上，但訂單還是很少就是了。

傻蛋是建議老闆不要對所有會員推播，與提供用戶一些自主權如勾選興趣主題，符合主題的才收推播，但被打槍，老闆的邏輯就是流量乘轉化率等於業績，用戶體驗什麼的根本不重要，所以呢，每週一次的廣告推播就是系統壓力測試的時間了，轉換率連萬分之一都不到，App的負評到是增加不少。

老闆非常有自信與堅持，也只能無奈了。

而最早幾次的推播，系統是有掛點過的。

無法服務而出現502的錯誤。

是系統架構不能撐得住這種流量嗎?用PHP開發的API扛不了流量嗎?

是有這個可能的，畢竟這個技術與架構本來就不是專門給高併發的後端用的吧。

但傻蛋查詢寫進db的API請求log，卻發現一件事，系統服務崩潰時，大部分的API回應時間基本上仍是維持穩定，僅微幅變慢，只有和App端做身份驗證的那個接口出現大量請求超時，或整整30/60/90秒才回傳成功。

這是怎樣?

最後確認其實系統的壓力沒問題，問題在於身份驗證的JWT的處理太耗CPU資源，與我們配合的App端的身份驗證接口忙不過來，動態追加長出新pod來應付瞬間流量的機制又沒用，導致大量請求都在排隊等待，資源都被耗在等待外部API調用，最後才死於502服務不可用。

之後在集中推播前讓對方提前多開幾個身份驗pod的資源，服務就正常了，流量確實較高與CPU使用率可以增加到50%以上，但服務正常，每個api的請求回應處理時間和離峰時間差距也不大。

如果抓錯瓶頸，那怕換成不同的技術如Java與Go，就算再增加水平擴展的架構支持，也是做白工的。

實際上，當時的流量，傻蛋的鳥鳥的後端程式，只用一台4CPU的GCP虛擬機器搭配一個1個 CPU的最低規格雲端數據庫與aws的s3儲存放圖片與前端js與css就夠用了，即使是在狂發廣告推播的時候。

和想像的不一樣。

和App的配合，曾經有開放一個接口給對方App首頁調用，獲得我們後台配置好的要在對方首頁推廣的六個商品，並實驗放App首頁商品廣告成效。

結果對方的調用並沒有做緩存機制，每次打開App進其首頁就會調用一次，導致那個接口被調用的次數在API的呼叫log次數異常的高，是無謂的效能浪費，但那幾天的紀錄大概也曝露出這個App實際的大概日活流量了，平日估計大概也就近十萬而已，這樣的流量用上述的硬體規格效能上就沒問題，讓傻蛋想實驗更複雜的高併發架構的藉口都沒了的說。

當然，本來的系統架構就有做一些優化，前端調用API傻蛋都會監看瀏覽器的網路呼叫，看有沒有沒寫好的重複呼叫等等，甚至調用API時的非必要的預檢請求，那個preflight request，也想方設法的從架構面上排除掉了，使用者打開這個電商網站就是下載服務器端的首頁，首頁的頁面需要程式資源js與css在打包時都把路徑改到s3雲端儲存了，圖片也都放s3，圖片與檔案資源的下載流量就讓aws的CDN去扛，服務器只負責API的調用以及排程任務的執行，再加上一些本地緩存機制，效能壓力還真的是不大。

而轉化率極低，就系統收集到的數據來看，大概不能怪到傻蛋寫的系統上，就必須找其他原因。

App商店裡超低的評價和超多的負評，抱怨廣告太多不重視用戶體驗這條線索是不能使用的，老闆那邊走不通，所以只能另外想辦法。

老闆也確實交辦很多改善的方向，如增加付款方式的貨到付款，提供Apple Pay與LinePay甚至ATM付款的支持，看看轉化率與業績會不會改善。

而一開始的訴求，同社區同商品同檔期大家一起買可以集量累積折扣，則被老闆以各種理由迴避，一直沒有執行，即使為了這個換了一次金流，理論上的技術障礙已排除，還是沒進行。

再然後，老闆似乎就發現了一個新真理，台灣電商已經不能玩了，就是打不贏Momo那些大的平台的，放棄治療，然後再讓我們轉型做社區電商，找小團媽來培訓，在這個小電商平台上用之前的基礎設施來做開團的團購，讓團媽幫忙拉生意與分享佣金，全新流程全新商業模式。

初期就不用改系統，用之前的動態頁面配置要團購的活動頁，針對同一個社區的會員發團購推播幫團媽推廣，然後準備一些只在團購頁上架的優惠團購商品，這些商品結帳就視為團購訂單的績效。

然後團購頁另外套用之前為了做直播電商額外擴充的一個克難機制，動態頁面可以配置頁面有獨立購物車，在該頁面時商品列表會額外曝光加入購物車，加到的是僅限該頁面的購物車而不是共用購物車，提供在那個頁面加購物車後直接結帳的操作，團購頁的商品點擊改為彈出視窗不要跳轉，這樣從後台開母團到前台團購主開子團，團購頁面接單成交後佣金計算全部一條龍系統化，這個需求是有點囧，但也是非常快就完成上線了。

更之前的直播電商則是去找那個阿榮嚴選合作，在Youtube上開直播，把直播的網址放到頁面的自定義組件用iframe顯示，下面就是放這場直播可以購買的商品列表，短時間用原本的組合頁克難湊一個直播電商出來，過程就真的超尷尬，因為沒時間評估與實現觀眾留言互動的功能，就看直播主唱獨角戲那樣在賣他們的挪威鯖魚。總之就是一頭熱做這個試哪個，問要不要把細節做足點，老闆都有很果決的決策，有就好，不用幫忙宣傳導流，也不用設計互動功能，試試就好。

結果自然是沒啥訂單，可以說是試試就逝世那樣。

從頭開發一個電商系統的日常大概就是上述那樣，基本上是商業模式與客戶關係那有問題，但老闆挺堅定的，要過很久才會有新的想法來推翻自己過去的固執。

就好比社區集量團購，傻蛋認為應該一開始或早期準備好就要上，但老闆的理由是立刻刷退超重要，所以要往後放，等之後才為這個理由換金流。

換完金流後呢，重新討論需求，立刻刷退還是有其他問題，前面已結帳的人自然是先刷折扣較低的金額，後面集量結帳的馬上就用集量後的當前優惠等級結帳，但還要考慮訂單取消等等問題，情況還是比較複雜的，所以呢，好像也可以把回饋往後延，用可無限制條件折抵消費的點數回饋來作為集量達門檻的社區集購優惠就好，不是非要馬上用信用卡刷退處理喔。

早知如此又何必大張旗鼓換金流呢?

然後當時的這個電商是兩個公司合資合作的方式，App那邊有對方的企業文化與做事的習慣，基本上呢是較穩健保守，沒傻蛋的老闆那麼跳，有些需要合作的機制就開會開很多次都沒結論，等於是卡住。

這個電商系統只有疫情口罩緊缺的時候，調來的五百組口罩在一個晚上的推播有陸續收到訂單，沒秒殺，但一個晚上也算賣完了，平時都是訂單寥寥的狀態，銷售的毛利用來付超精簡的運營團隊薪水都不夠的。

總之就是，就結果來說有點瞎，但過程中小團隊靈活的合作，努力在老闆的強勢領導與現實的困境努力求生存的工作經驗，還是有點意義的。

整個專案執行傻蛋從開始參與有一年多的時間，但同時還在處理公司另外一個電子票券核銷，因為舊電商平台換成新的Saas平台的轉移相關一堆事，大概佔了有一半的工作時間吧，基本上，還是算閒的吧。

因為人員超精簡，後端就只有傻蛋一個人全包，順便帶前端新人，除了老闆以外沒什麼內部溝通成本，而系統都設計成可複用的靈活結構，且隨時掌握最新的需求走向，往往可以在需求大致形成共識的時候就掌握好系統的概念，然後近乎馬上就把後端接口準備好，雖然有各種無奈，但過程大致上都在掌握之中，倒是有點成就感。

系統快速開發會有Bug，自然還是有一些的，不過絕大部分都在傻蛋監控自己的API的log紀錄時提早發現，大部分都還沒被發現回報就偷偷的修好了。

　

而很可惜的就是行銷的策略。

老闆是廣告與流量的狂信徒，他曾靠這個賺了點錢，對客戶體驗與尊重消費者與廠商的需求徹徹底底的不屑一顧，對深入發覺用戶的需求來做針對式的行銷沒興趣。

實際上電商轉化率超低，但傻蛋曾幫行銷小編做了個受眾包的小功能，讓他可以去撈訂單資料與查詢系統的一些資訊，然後從系統資料找出一些受眾組合，針對精心選擇的受眾組合，準備專門的小活動小優惠做聚焦的推播廣告，轉化率雖然也沒有非常高，但和平常無限趨近於零的轉化率卻已是天差地遠了，只發少少的推銷資訊都能加減拿到幾個訂單，而狂發幾十萬上百萬的推播也可能就十張訂單，其實用心行銷還是有效的。

這個專案一開始規劃之初傻蛋原本就想在這個地方發力，預先設計了可自定義的會員標籤與產品標籤群組，可以為會員與產品靈活貼上幾種類的自訂標籤，可以使用這些標籤來當公式的變數來搜尋會員與商品，並把介面都封裝在Postgres的function裡，實作是很複雜的動態組SQL，複雜到傻蛋不會想再開發第二次，但有完成功能的測試，用方便的輸入參數介面，可以實現靈活的標籤找人與找商品，如找最近7天有查看購物車，或一個月以內訂單消費金額在指定金額以上的會員等等，也不用擔心漏建索引效能有問題，因為是同一組數據表用同一套索引不可能漏。

所以只要根據行銷自己的需要，自訂需要的標籤，再於API接口實作補上這些標籤被收集紀錄的機制，就能靈活的分析消費者行為來做應用，保存在自己家的關聯式數據庫想怎麼應用都很方便。

傻蛋是這樣自己規劃設計的，底層也做差不多了，然後呢，老闆就說，行銷工具要配合外部廠商，外部廠商的後台工具有UI可以拉流程，做數據串接自動發推播與Email，那個UI他很喜歡，所以如果要自己做自己收集控制，就要做出一樣的後台UI，不然就用廠商的。

喔喔，所以就用廠商的吧，總不至於吃飽太閒做產品吧?

然後就是前端串接整合，並把所有會員資料，商品資料都往廠商那邊倒。

廠商的後台頁面速度慢，很卡，至於行銷自動化，只有後來有做一些同樣無腦的會員發推播或EDM廣告，使用這工具的又是另一個團隊，對電商專案幾乎都沒幫上什麼忙。

就這樣，這個App有一定的流量，但流量的品質不夠優，無法無腦收割，應該是需要深入經營客戶關係才能開發出商業價值的，但那個老闆就是視客戶體驗為無物的很特別的價值觀吧，所以小團隊在那就拖著，平常就先處理老闆交辦的事，再找看看有沒有機會繞過老闆得到市場的成功那樣的掙扎著。

喔，後來老闆又找來一個他的同學，這同學和老闆的性格又不一樣，這個基本上就是管理控，控制狂，繁文縟節，又沒擔當，感謝他，要傻蛋寫沒人看也沒用的文件，惹毛傻蛋了，就順勢辭職了。

這工作畢竟沒有創造市場價值，然後雖然一個人做好幾個人的事，公司營運不理想，薪水剛進去時談的不高想等勝任後再說，但公司那時候基本上是虧損經營的也不好提加薪，時間都浪費在上面，能脫身也是好事吧。

　

好了，這個冗長的回憶其時沒太大的意義。

純粹是碎碎唸罷了。

主要想表達的是，如果系統設計得靈活與貼近使用者需求，其實可以很省事。

動態自訂組合頁面的設計就滿足了使用者大多數的需求，所以IT不需要做一堆重複的事，平常就是行銷自已去建畫面，上下架商品就好，需要新頁面都自己建，只要網址路徑要約定好一些規則，不要亂設重複或會造成麻煩，不要沒事找事。

另外很多可以擴充的細節功能，談需求時往往會被放大，這也要那也要，開發曠日廢時，而實際上呢，如果第一線直面業績生死，根本不會去提那些瑣碎細節的需求的，傻蛋預留的開放彈性空間，大部分都沒用上，夠用就好，而實際上永遠會有更重要的事要做，大概只有做平台產品才會去開發大量又細緻的功能，那可以用來吸引使用者當賣點吧。

而後端的核心就是資料結構，為了滿足商業需求，靈活是很重要的，傻蛋開發的API接口，名義上算是restful的web api，但實際上，是用web api來做類似rpc的請求。

為什麼要曝露資料結構給API接口，為什麼前端需要知道資料結構，要去根據對資料結構的理解去自行調用這些接口?

其實照需求的流程，照合適的使用者體驗設計畫面流程，提供接口給前端用就好了。

類似mongodb的document，可能在數據庫是個一對多的兩個關聯數據表，一個join查詢出來，然後再針對查詢結果處理一下，就是和文件數據結構一樣的格式回傳給前端，這種結構前端要設計樣版呈現也方便。

如果要配合業界慣例，來讓設計更為符合MVC或MVP或MVVM的設計模式，又或讓實踐是標準完美的restful設計或是graphql的設計，同樣的需求，傻蛋估計需要超過一倍以上時間與心力才能完成，而邏輯概念的複雜度也會增加許多，因為會變成業務邏輯要遷就設計模式，而不是開發設計去滿足業務面最緊迫重要的需求。

為了使用者的需求，以行銷的思維來做事，和為了自己的優越感，把供應商與消費者當韭菜，用推銷的心態來做事，會形成差別很大的做事風格與文化氛圍。

老闆的思維方式是最重要的，當個員工，和老闆思維方式不能適配，想要逆天，太難了。

至於一開始抱怨Unity開發遊戲實在太低階與低效，需要自己做架構設計，來設法讓開發可以避免耗時的大量重複工作，能編數據出來讓數據自行把功能長出來，這個呢，就，有點離題了，隨便寫寫，大家就隨便讀讀吧，若讀得到最後你肯定很閒，哈哈!