考拉海购技术支持的前世今生 咨询
程序员文章站
2022-07-12 17:30:26
...
本文来自考拉海购技术支持中心负责人--书渊的分享，想和大家聊一聊考拉技术支持的前世今生，在这个发展历程的介绍当中，大家也可以此对考拉窥一斑而知全豹。当然，既然是聊我们的家常(“黑历史”)，我会从这几年在考拉供应链产品事业部的视角去讲述(请轻拍~~)，并且，也不会就很多过往事项留恋于细致的介绍，只讲下大面上的东西。
技术支持的由来和定位
----------
### 技术支持由来
其实电商公司或者说考拉这个 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 商家履约也是。这是需要做一番最初的整合的(当然，需要假设考拉未来的产品规划依旧保持现状的前提下，未来还是会有诸多调整的，等着拥抱变化，这样带来的好处，一个是让有工作有业务共性的技术支持能够互相帮助互通有无，也让这些同学能在新环境下让自己视野更广阔，了解更多的行业业务背景。
还有就是，可以让我们的团队在考拉更多部门得到更多发声的机会，更多的解决当前的核心痛点，从而让团队得到更良性的发展同时，更好的服务于产技业务团队。
[原文链接](https://yq.aliyun.com/articles/740189?utm_content=g_1000096926)
本文为阿里云内容，未经允许不得转载。
技术支持的由来和定位
----------
### 技术支持由来
其实电商公司或者说考拉这个 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 商家履约也是。这是需要做一番最初的整合的(当然，需要假设考拉未来的产品规划依旧保持现状的前提下，未来还是会有诸多调整的，等着拥抱变化，这样带来的好处，一个是让有工作有业务共性的技术支持能够互相帮助互通有无，也让这些同学能在新环境下让自己视野更广阔，了解更多的行业业务背景。
还有就是，可以让我们的团队在考拉更多部门得到更多发声的机会，更多的解决当前的核心痛点，从而让团队得到更良性的发展同时，更好的服务于产技业务团队。
[原文链接](https://yq.aliyun.com/articles/740189?utm_content=g_1000096926)
本文为阿里云内容，未经允许不得转载。