本文來自考拉海購技術支援中心負責人--書淵的分享，想和大家聊一聊考拉技術支援的前世今生，在這個發展曆程的介紹當中，大家也可以此對考拉窺一斑而知全豹。當然，既然是聊我們的家常(“黑曆史”)，我會從這幾年在考拉供應鍊産品事業部的視角去講述(請輕拍~~)，并且，也不會就很多過往事項留戀于細緻的介紹，隻講下大面上的東西。
技術支援的由來和定位
技術支援由來
其實電商公司或者說考拉這個 BG ，剛開始成立時是絕不可能就有技術支援這個崗位的。技術支援崗位誕生的前提往往有這麼幾個條件(滿足其中1-2個即可)：
1、業務發展迅速，産品對應的業務規模需要得到迅速擴張；
2、産品涉及客訴、咨詢相對頻繁，雖需要技術解決、解答，但是重複性高；
3、産品研發的人力資源緊張；
4、發展初期的業務、技術職責不清(自營電商躺槍的重災區)；
5、工作内容可複制性高，可沉澱性少，日常太多技術工作是與業務或者各種第三方重複溝通，模式單一，但是每次問題不一(狹義來說不可窮舉，廣義來說可窮舉)。
以上這些原因，可能并不全，但是我想一定基本符合 80% 以上的電商環境下招聘技術支援來解決這些問題的初衷。因為，在電商環境下，産品和研發既要懂業務，又要不斷沉澱自己的能力，如果頻繁都在做技術咨詢解決方案的工作，還有茫茫多的重複性對接工作，沒有時間成長，并且，精力分散的情況下，這些技術咨詢的應答時效，也是相當沒有保證的。
是以，技術支援團隊的出現，剛開始其實是為了解決産品研發的效能問題和提高技術咨詢的響應效率問題的。而且，産品研發專門負責讓大團隊高速運轉，解決業務的核心痛點、做好核心需求，而技術支援則負責複雜而重複的業務、技術任務，并不斷從中挖掘可以提高處理效能的點，可能隻提思路，也可能想好了思路設計 PRD，交給研發去實作，當然甚至還自己研發一些功能。
在産品研發和技術支援各司其職的情況下，産品和研發隻需要專注于讓團隊快速支撐業務發展，不再分心于一些細枝末節的設計，即使某些環節的業務SOP并不十厘清晰，也可以通過技術支援提供的技術咨詢得到較快速的解決，即使業務流程阻斷的，或者有新玩法未在原先需求中展現而需要快速支撐的，技術支援可以提供一些簡單的解決方案完美過渡，即使部分功能需要小優化和改動的，技術支援會彙總整理成需求給到産品研發。
總的來看，如下圖所示，技術支援團隊為産品研發團隊支援電商業務“野蠻”增長提供了較為充足的柔韌性，因為很多 SOP 及對應的系統設計如果要達到面面俱到的地步，不是說完全不可能，但是會非常費功夫，而這些實際是不影響業務需求的主要達成目标的。
技術支援的“黑曆史”
前面說的可能相對枯燥了點，那就回歸正題——回顧下“黑曆史”！
依稀還記得 16 年 1 月剛入職考拉的時候，整個團隊内就十幾個研發，當時就 2 個研發同學負責訂單履行和跨境通關申報，每天既要做系統功能的疊代開發，還要不斷開新倉，監控訂單履行健康情況，最關鍵的每天要花半天時間解答和處理客服問題群裡的訂單長期未發貨問題等等。我的到來，讓他們特别喜出望外：終于可以安下心來做研發了！當然，那時的我們(技術支援)，就兩個人，一個主要負責訂單履行(主要是申報和問題咨詢、處理)，一個主要負責倉庫 WMS 系統對接、背景理論庫存和 WMS 庫存的核對以及一些各種和服務商接口、業務相關的問題(當時的第三方服務商的問題排查支援能力相對很弱，經常很多服務商産品設計問題或者使用問題也來找我們，後來慢慢的，我們新開的倉庫越來越多，新開的口岸也越來越多，訂單的咨詢量也越來越多，庫存的核對等工作開始變的多起來，剛開始純靠人工解答、人工 Excel 核對的方式，已經沒法滿足了，而且手頭的事情總是在滾雪球似的增加(因為前面大家也看到了，我們的支援内容，非常和業務營運相關，屬于奮戰在一線營運的角色，是以沒人比我們更清楚細節流程，沒人比我們更清楚産品産生的痛點，我們在解答問題的時候慢慢已經能夠提供各種解決方案了)，并且在極其碎片化的時間裡，在客訴咨詢解決方面，我們自行設計和搭建了一個訂單異常問題自助查詢工具，不但自動告知訂單目前所處狀态，還顯示在履行平台上各個節點的時間資訊，以及對應目前異常的建議處理方式；而在庫存比對方面，團隊内自行研發了庫存比對功能，極大的提高了每月、半年、全年的庫存盤點效率；在訂單履行健康度方面，我們自行根據不同需要，也編寫了各種自動生成監控報表的IM消息、郵件,甚至也有異常情況自動短信通知服務商處理的功能。
不過，那時的我們，遇到的問題和挑戰，遠比上面列的多，可能每天會有非常多的和通關相關的稅費不一緻問題、撤單退稅問題、溯源問題、申報合規問題等等，以及和倉庫作業銜接相關的可能是訂單發貨的、訂單打标的、包材的、稱重重量的、取消異常的、發票的……等等，提貨、采購、盤虧盤盈單據伴随的庫存不一緻問題、判責問題、價格問題、超賣問題、數量問題，還有一系列各種服務商系統、自營系統上的誤操作問題……還有倉儲物流系統的倉費運費對賬、包材費核對、支付對賬等等等等，還有追求創新的供應鍊管理業務同學、類目BU同學的各種新玩法支援。
2017 年以後，考拉開始計劃投産 WMS (泰坦)的研發，由于各種組織上的需要，讓原先的供應鍊産品團隊中的負責供應鍊上遊及訂單履行相關的子團隊和當時負責倉配研發的子團隊分開形成了兩個不同的事業部——供應鍊産品部和倉配客産品部，為的是讓各自更精益于各自擅長的領域，當然，依舊需要保持協同作戰的 CP 關系。不過當時跟跨境關務相關的國際頭程和港到倉入區、出區申報、賬冊等功能，就因為這個曆史原因，被劃分到了 2 個事業部，而當時對跨境産品較為資深的産品經理去到了倉配客産品部，供應鍊産品部之後再無對跨境模式非常資深的産品專家。曆史也非常造化弄人， 17 年之後的幾年時間裡，跨境行業的變化及其迅速，幾乎每小半年就有一個新政策，在此期間，我們的技術支援小團隊(大概三四人)一次又一次承擔了考拉跨境産品(主要是出區整個流程相關)的産品策劃或者核心解決方案策劃，成功的項目很多，比較重要的主要是拓展新的海關關區(每個關區流程很多是不一樣的)、海關總署三單加簽項目、 pop 商家申報合規項目、分銷及多平台合規申報、關稅對賬平台，到後來的全鍊路監控平台、考拉跨境先知平台、商品備案中心、跨境額度庫建設(代付、超限提前攔截等功能的底層載體)等等，還有很多為了解決、優化各種流程中的問題的小項目這裡不再一一列舉，而且，這隻是在跨境這塊的産品線上所取得的成績，在其他領域我們也有不小建樹。
對我們來說，一直以來的團隊成長和建設思路是——主動補位，不給自己設限。在業務眼中，我們需要成為一名全棧技術工程師，可以解決目前實際問題，可以聊需求和實作需求，可以提供資料分析，也可以當天就給他們實作一些小工具，還能幫他們去跟海關聊業務聊對接，也能幫他們去跟服務商撕逼優化他們産品，還能在操作失誤時做好善後措施，當然，我們還有很多功能……
特别值得“哔哔”的是，對自營電商體系來說，太多東西得自己兜着，而量變導緻質變，比如下面的一個實際場景來對比菜鳥關務平台和考拉針對某個問題的處理方式：
類似上面這種情況的場景有很多，考拉依舊負重前行。
之前我們和業務方溝通的過程中聊的，經常和産品出現職責不清晰的情況，不過這個我覺得本身不屬于一個通用的放之四海皆準的一個案例，原則上我們隻是做适當補位，不過确實當時真的太難招到一個對跨境十分資深的産品經理了，這是特殊場景之下産生的，并且我們擁有的資源也十分有限——能調動的資源少，還得幹成事。但是，實際我們對自己的中心定位從來沒有改變過。
技術支援的定位
其實前面說了那麼多，大家應該有對我們有基本的了解了——什麼樣的技術團隊，需要技術支援，那技術支援就需要深耕這一塊産品技術所涉及的業務。而不管是在考拉也好還是阿裡衆多 BG、BU 也好，基本上大多是為對應的産品研發部門服務的，我們的核心目标就是幫助好産品研發一起，給業務部門提供最好的服務，幫助業務獲得快速增長，不必畏首畏尾考慮太多細枝末節的東西，或者說投入産出比極不科學的東西，這些硬骨頭，我們事後慢慢啃，逐漸再改善，而這當中缺什麼，我們就補什麼。
技術支援的發展方向
之前沒加入阿裡之前，我們對團隊内部的人員主要就是分三塊：
1、一線主要做重複性更高的客服咨詢處理，簡單系統營運，他們的主要名額是重複工作量和品質
2、經一線過濾後的綜合性較高的問題，由一線小組長 Cover ，并且小組長需要做一些業務沉澱和輸出，整理知識庫
3、二線主要為我們的解決方案技術支援(雖然我們在考拉的組織架構裡沒有這樣的區分，但是我們在團隊内部确實有這樣的定位和安排)，主要接收業務的一些個性化需求(你懂得，啥都有)，可能涉及産品、解決方案或者一些簡單的開發支援等等。
每條線的核心考察點或者任職要求在于：
後來跟新零售和螞蟻金服這邊的各位較資深的技術支援同學經過了不少溝通，發現其實咱們的定位幾乎完全比對！可以參考下螞蟻這邊對技術支援與保障和解決方案工程師這 2 個技術支援方向的定位。
我很慶幸當時給團隊中的同學定位，以及我們當時的老闆給我們的成長空間，與阿裡系的技術支援定位十分的一緻和準确，即便是現如今，随着考拉技術支援的合并，也并不影響我們的這一初心，合并隻是組織架構上和集團更容易步調一緻的對标，避免各自為政的現象，但是我們的核心 KPI 依舊需要和各個所服務的業務産技團隊保持一緻，工作重心沒有發生根本性變化，隻不過融入大阿裡後，技術支援需要和産品研發、測試一起，對産品的品質嚴要求、高标準，作為價值觀一樣的存在，留在腦海裡，但這不代表我們的主要工作是抓安全生産：
目标具體解釋：
1、兩個核心：奧大制定的以使用者體驗作為新形勢下考拉事業部的唯一KPI，以及範禹強調的保證考拉“安全生産”這兩點核心，将是每一個技術支援工程師需要貫徹到腦海裡的理念，并作為在日常工作中單獨需要更新的一條主線。
2、兩手抓：一手抓業務硬核：技術支援既需要在日常的工作中不斷去主動了解工作相關的業務(這其中包括業務現狀、業務痛點、業務改善方向以及目前的業務變更裡程碑)，成為業務的好夥伴。
一手抓技術硬核：技術支援也需要在日常的工作中不斷提升自己的産品思路和技術解決能力，成為産技的好夥伴。
團隊發展及人員成長
在跟考拉前台技術支援組合并前，我們在為考拉供應鍊産品、跨境關務平台、訂單履行中心、商品及庫存中心等幾個供應鍊相對核心的領域服務期間，學到了很多交易、跨境以及物流供應鍊相關的内容，我們團隊的業務能力、産品設計能力以及研發能力在這期間也得到了很多鍛煉，每一個成員都在忙碌的工作中樂此不疲，至少沒有彷徨過，因為我們把路子走廣了，沒有脫離實際。從我們的團隊裡也曾走出去過開發、測試、産品，隻不過在工作的過程中，發現他們有了新的目标，但是技能都是在這期間得到鍛煉的。
過往的缺陷與不足
其實作為一線技術支援來說，一套好的工單系統和知識庫平台非常重要，以往我們在網易的時候，太多的溝通方式為拉群溝通和私下溝通，雖然也有簡單的工單系統，但是問題點很多：
1、問題分類不科學且無對标
2、問題對應的處理(服務)時效(SLA)沒有對焦
3、沒有明确的工作流概念，全靠人工更新和轉派， backup 對象也靠人工聯系
客服的工單系統和技術支援的工單系統，各自為政，客服按自己的了解對各自異常進行了歸類，然後遇到這些類别的問題會線下咨詢技術支援，技術支援沒有很好的問題統計沉澱，也沒有很好的工作流，并且處理時效存在很多 GAP ，客服對客戶的承諾處理時效和技術支援實際心裡了解的問題處理時效完全不對标，導緻無謂的問題重複回報催處理——當然，這個問題主要困擾前台技術支援多一些，原先的我們在供應鍊時所遇到的問題往往都要棘手的多，大家對時效有較為”寬泛”的預期，在背景供應鍊裡，我們對工單不敏感，但是對每個問題所涉及的業務方，其實是缺少很好的 SOP 以及這些 SOP 對應的小二處理平台。
除了工單系統和小二處理平台以外，我們還經常遇到缺少資料抓手，太多的情形下，業務開發在設計的時候基本隻考慮業務實作，但是對技術支援在其中所産生的有益作用（比如異常處理的介入等等）并沒有進行合理的埋點，這在我們的每一次季度總結中比較受傷，雖然自己也通過很多手段近似的用腳本去做了這樣的統計工作，但是總體來說，效果并不是很理想，至少還難成體系。
不過，加入阿裡懷抱後，看到了很多的工具，雖然很多工具我們還沒法完全接入，但是至少讓我們看到了很多的曙光，我對未來還是期待的。
翻開新篇章
合并後的首要事項，當然是需要做人員的調整和支援内容的融合，因為原先做自營供應鍊和平台供應鍊就有存在着不少共性，做供應商直發和做 pop 商家開放平台也存在不少共性，商家商品、庫存與自營商品、庫存也存在諸多共性，自營履約和 pop 商家履約也是。這是需要做一番最初的整合的(當然，需要假設考拉未來的産品規劃依舊保持現狀的前提下，未來還是會有諸多調整的，等着擁抱變化，這樣帶來的好處，一個是讓有工作有業務共性的技術支援能夠互相幫助互通有無，也讓這些同學能在新環境下讓自己視野更廣闊，了解更多的行業業務背景。
還有就是，可以讓我們的團隊在考拉更多部門得到更多發聲的機會，更多的解決目前的核心痛點，進而讓團隊得到更良性的發展同時，更好的服務于産技業務團隊。
接下來在我們的規劃裡，一個就是工具的更新引入、流程的制定、服務時效的确認，以及推進小二工具整合(規劃中，這個短期來看需要等融合完成後進行了)，大緻如下所示(這裡省略了非客服的業務方提出正常問題和業務問題解決的需求給一二線的場景，紅色虛線為我們未來規劃裡想提的内容)：
我們一起期待下融合後的小二工作台搭建吧。
作者資訊：書淵，考拉海購技術支援中心負責人，多年供應鍊産品及跨境關務業務解決方案經驗，現主要參與考拉交易、庫存、商品、訂單履約、跨境關務等多個平台的技術咨詢以及“考拉融阿”的技術支援體系改革等工作。