本文來自考拉海購技術支持中心負責人–書淵的分享，想和大家聊一聊考拉技術支持的前世今生，在這個發展歷程的介紹當中，大家也可以此對考拉窺一斑而知全豹。當然，既然是聊我們的家常(“黑歷史”)，我會從這幾年在考拉供應鏈產品事業部的視角去講述(請輕拍~~)，並且，也不會就很多過往事項留戀於細緻的介紹，只講下大面上的東西。
技術支持的由來和定位
技術支持由來
其實電商公司或者說考拉這個 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 商家履約也是。這是需要做一番最初的整合的(當然，需要假設考拉未來的產品規劃依舊保持現狀的前提下，未來還是會有諸多調整的，等着擁抱變化，這樣帶來的好處，一個是讓有工作有業務共性的技術支持能夠互相幫助互通有無，也讓這些同學能在新環境下讓自己視野更廣闊，瞭解更多的行業業務背景。
還有就是，可以讓我們的團隊在考拉更多部門得到更多發聲的機會，更多的解決當前的核心痛點，從而讓團隊得到更良性的發展同時，更好的服務於產技業務團隊。
接下來在我們的規劃裏，一個就是工具的升級引入、流程的制定、服務時效的確認，以及推進小二工具整合(規劃中，這個短期來看需要等融合完成後進行了)，大致如下所示(這裏省略了非客服的業務方提出常規問題和業務問題解決的需求給一二線的場景，紅色虛線爲我們未來規劃裏想提的內容)：
我們一起期待下融合後的小二工作臺搭建吧。
作者介紹：
書淵，考拉海購技術支持中心負責人，多年供應鏈產品及跨境關務業務解決方案經驗，現主要參與考拉交易、庫存、商品、訂單履約、跨境關務等多個平臺的技術諮詢以及“考拉融阿”的技術支持體系改革等工作。
本文轉載自公衆號阿里巴巴中間件（ID：Aliware_2018）。
原文鏈接：