产品策划方案_考拉海购技术支持的前世今生

作者|舒源

技术支持

技术支持

的起源和方向事实上，电子商务公司或考拉，BG，在这个职位刚成立的时候不可能有技术支持。设立技术支持岗位的前提条件通常是这样几个条件(其中1-2个条件可以满足):

业务发展迅速，产品对应的业务规模需要迅速扩大；

产品涉及客户投诉和咨询的频率相对较高。虽然需要技术解决方案和解决方案，但重复性很高。

产品研发人力资源紧张；在其发展初期，

业务和技术责任不明确(个体户电子商务公司放下武器的重灾区)；

工作内容重复性高，沉淀性小。太多的日常技术工作是以单一模式与企业或各种第三方重复沟通，但每次问题都是不同的(从狭义上讲，它不可能是详尽无遗的，从广义上讲，它可以是详尽无遗的)以上

的原因可能不完全，但我认为它们基本符合在80%以上的电子商务环境中招募技术支持来解决这些问题的初衷。这是因为在电子商务环境下，产品研发不仅要了解业务，还要不断积累自己的能力。如果他们经常从事技术咨询解决方案，就会有大量重复的对接工作，没有时间发展。此外，在能量分散的情况下，这些技术咨询的响应时间也相当不确定。

因此，技术支持团队的出现原本是为了解决产品研发的效率问题，提高技术咨询的响应效率。此外，产品研发部门专门负责让大型团队高速运转，解决业务的核心痛点并满足核心需求，而技术支持部门则负责复杂且重复的业务和技术任务，并不断挖掘能够提高处理效率的要点。它可能只是提出想法，也可能想出设计珠江三角洲的想法，并把它交给研究和发展来执行，当然，它甚至可能自己开发一些功能。

在产品研发和技术支持各司其职的情况下，产品研发只需要关注让团队能够快速支持业务发展，而不被一些琐碎的设计分散注意力。即使某些环节的业务操作规程不太明确，技术支持提供的技术咨询也可以相对较快地解决。即使业务流程受阻，或者有新的游戏需要快速支持，而不是反映在原始需求中，技术支持也可以为完美的过渡提供一些简单的解决方案。即使某些功能需要微小的优化和改变，技术支持也将被整合到产品研发的需求中。

总体而言，如下图所示，技术支持团队为产品研发团队提供了足够的灵活性，以支持电子商务业务的“野蛮”增长，因为许多sop和相应的系统设计如果要达到包罗万象的程度，并不是完全不可能的，但是它们将非常费力，并且这些实际上并不影响业务需求的主要目标。

技术支持的“黑人历史”可能有点无聊，所以让我们回到主题——回顾“黑人历史”！

隐约记得，当我1月16日第一次加入考拉时，整个团队有十几名研发学生。当时，两名研发学生负责订单履行和跨境报关。他们不仅每天都要进行系统功能的迭代开发，而且还要不断开新的仓库来监控订单执行的健康状况。最重要的是每天花半天时间回答和处理客户服务问题组中的长期未交付订单等问题。

的到来让他们喜出望外:他们终于可以安定下来做研发了！当然，当时我们有两个人(技术支持):

，主要负责订单执行(主要是报告和问题咨询处理)，

，主要负责仓库WMS系统对接、后台理论库存和WMS库存检查，以及与服务提供商接口和业务相关的各种问题(当时，第三方服务提供商的问题发现和支持能力相对较弱)。许多服务提供商经常带着产品设计问题或使用问题来找我们。后来，慢慢地，我们开了越来越多的新仓库，开了越来越多的新港口，咨询越来越多的订单，并开始检查库存。起初，仅仅依靠手动解决方案和手动的Excel检查是不可能满足要求的。此外，手头的事情总是越来越多(因为正如您前面看到的，我们的支持内容与业务运营非常相关，属于前线运营中的战斗角色。因此，没有人比我们更了解详细的过程，也没有人比我们更了解产品的痛点。当我们回答问题时，我们能够慢慢地提供各种解决方案。)

，在极其零碎的时间内，我们设计并构建了一个订单异常问题自助查询工具，不仅自动通知订单的当前状态，还显示了执行平台上每个节点的时间信息以及当前异常对应的建议处理方法。在库存对比方面，团队开发了自己的库存对比功能，大大提高了每月、半年和全年的库存检查效率。在订单执行状况方面，我们还根据不同的需求编制了各种即时消息和电子邮件，自动生成监控报告，甚至具有通过短信自动通知服务提供商异常情况的功能。

但是，当时我们遇到的问题和挑战比上面列出的要多得多。可能会有许多与清关、发票的提取和退款、可追溯性问题、申报合规性问题等相关的不一致的税费问题，以及与仓库操作相关的问题，如订单交付、订单标记、包装、称重、异常取消、发票等。提货、采购、盘亏、盘盈单据伴随着库存不一致、责任判断、价格、超卖、数量等问题，以及各种服务提供商系统和专有系统中的一系列误操作问题...还有仓储费和运费对帐、包装材料费用对帐、付款对帐等。在仓库物流系统，以及各种新的发挥方法支持学生追求供应链管理和班级业务单位的创新

2年017之后，考拉开始计划启动WMS(泰坦)的研发。由于各种组织需求，原供应链产品团队中负责上游供应链和订单执行的子团队和当时负责仓库配送研发的子团队被分成两个不同的部门——供应链产品部门和仓库配送客户产品部门，以使他们各自在各自的专业领域更加精简。当然，仍然有必要保持合作经营的合作伙伴关系然而，当时与跨境海关有关的职能，如国际总部程序、港口至仓库的进出申报和账簿，由于这一历史原因被分为两个部门。当时，在跨境产品方面更有经验的产品经理去了仓库和客户分销产品部门。在那之后，供应链产品部门没有任何在跨国模式方面非常有经验的产品专家。

的历史也很幸运。在17年后的几年里，跨境产业发生了迅速变化，几乎每隔半年就有一项新政策出台。在此期间，我们的小型技术支持团队(大约3或4人)已经一次又一次地承担了跨境考拉产品的产品规划或核心解决方案规划(主要涉及走出该地区的整个过程)，并有许多成功的项目。更重要的是扩大新的海关领域(其中许多有不同的流程)、海关总署的三阶背书项目、pop商户申报合规项目、分销和多平台合规申报、海关对账平台、后期全环节监控平台、考拉跨境先知平台、商品备案中心、跨境配额银行建设(代表客户支付和超限额预收等功能的底层载体)，以及许多其他解决和优化各流程中问题的小型项目，此处未列出。此外，这些只是在跨境生产线上取得的成就，我们在其他领域没有这些成就。对我们来说，

一直是团队成长和建设的理念——主动填补职位空缺，而不是给自己设限从业务的角度来看，我们需要成为一名全面的技术工程师，能够解决当前的实际问题，谈论需求和实现需求，提供数据分析，还能在同一天给他们一些小工具，帮助他们与海关谈论业务联系，帮助他们与服务提供商一起拆卸和优化他们的产品，并在出现操作错误时采取补救措施。当然，我们还有很多功能...

特别值得“哔哔声”。对于自主经营的电子商务系统来说，太多的东西必须自己去拿，量变导致质变。例如，下面的实际场景比较了菜鸟海关平台和考拉对某个问题的处理:

有很多类似于上面的场景，考拉仍然背着很重的货物。< br>

在我们与业务部门交谈之前，我们经常对产品职责不明确。然而，我不认为这是一个普遍适用的案例。原则上，我们只是做了适当的工作安排。然而，招聘一名在跨国工作方面经验丰富的产品经理实在太难了。这是一种特殊的情况，我们的资源非常有限——我们可以调动更少的资源，我们必须为此做些什么。然而，实际上，我们的中心地位从未改变。

技术支持的定位

实际上说了这么多，你应该对我们有一个基本的了解——什么样的技术团队需要技术支持，那么技术支持需要深化这个产品所涉及的业务技术然而，无论是在考拉还是在阿里，BG和BU主要服务于相应的产品研发部门。我们的核心目标是帮助产品研发合作，为业务部门提供最佳服务，并帮助业务快速增长。没有必要犹豫考虑太多的细节，否则投入产出比是非常不科学的。这些坚硬的骨头被慢慢咀嚼，然后逐渐改善，我们会弥补它们所缺少的。

技术支持的发展方向在

加入阿里之前，我们主要将团队人员分为三部分:

一线主要从事客户服务咨询，重复性较高，系统操作简单。其主要指标是重复性工作量和一线过滤后的质量

综合问题。一线团队领导负责，团队领导需要做一些业务沉淀和输出，第二行排序知识库

主要是为我们的解决方案提供技术支持(虽然我们在考拉的组织结构中没有这样的区别，我们在团队中有这样的定位和安排)，主要是接收一些个性化的业务需求(你知道的，一切)，可能涉及产品、解决方案或一些简单的开发支持等。每条

线的核心检查点或工作要求如下:

经过与新品零售和蚂蚁金服的高级技术支持学生的多次沟通，我们发现我们的定位几乎完全相同！请参考蚂蚁在技术支持和保证以及解决方案工程师这两个技术支持方向上的立场。

我很高兴当时我们老板给我们的团队同学的定位和给我们的成长空间与阿里技术支持的定位非常一致和准确。即使现在，随着考拉技术支持的合并，它也不会影响我们最初的意图。合并仅仅是组织结构与集团的比较，这样更容易步调一致，避免独立的现象。

，但我们的核心关键绩效指标仍然需要与我们所服务的业务生产和技术团队保持一致，并且工作重点没有根本变化。只是在集成到大阿里之后，技术支持需要与产品研发和测试一起牢记在心，对产品质量有严格的要求和高标准，因为存在相同的价值。但这并不意味着我们的主要工作是围绕安全生产:

目标具体说明:< br>

两个核心:新形势下考拉事业部唯一基于奥地利大学制定的用户体验的关键绩效指标，以及范宇强调的确保考拉“安全生产”的两个核心，将是每个技术支持工程师心中都需要贯彻的理念，作为日常工作中需要单独升级的主线

双手:

单手业务硬核:技术支持不仅需要在日常工作中积极了解与工作相关的业务(包括业务状况、业务痛点、业务改进方向和当前业务变化里程碑),还需要成为一个好的业务合作伙伴

一手抓技术硬核:技术支持也需要在日常工作中不断提高产品思维和技术解决能力，成为生产和技术上的好伙伴。

团队发展和人员增长

在加入考拉前台技术支持团队之前，我们在为考拉供应链产品、跨境海关服务平台、订单执行中心、商品和库存中心以及供应链的其他相对核心领域提供服务的过程中，学到了很多关于贸易、跨境和物流供应链的知识。在此期间，我们团队的业务能力、产品设计能力和研发能力也得到了大量的培训。每个成员都喜欢繁忙的工作，至少没有犹豫，因为我们走了一条宽阔的道路，没有偏离现实。

也走出去开发、测试和生产我们团队的产品，但在工作过程中，他们发现他们有了新的目标，但他们的技能在此期间得到了培训。事实上，作为一线技术支持，一个好的工单系统和知识库平台是非常重要的。在过去，当我们在网易的时候，有太多的沟通方式是团队沟通和私人沟通，虽然也有一个简单的工作指令系统。但也存在许多问题:

问题的分类不科学，对

问题没有相应的处理(服务)时限。没有对

的关注，也没有明确的工作流概念。这完全取决于手动升级和转移。备份对象还依赖于与独立的

客服工单系统和技术支持工单系统的手动联系。客户服务根据他们自己的理解对他们的异常进行分类，然后在遇到这些类型的问题时离线咨询技术支持。技术支持没有很好的问题统计沉淀或者很好的工作流程，并且有很多GAP处理时间限制。客户服务对客户的承诺和技术支持对问题处理时限的实际理解完全不一致，导致不必要的问题被反复反馈和催促——当然，这个问题主要困扰前台技术支持。我们在供应链中遇到的最初问题通常要困难得多。每个人对时间都有一个相对“宽泛”的期望。在后台供应链中，我们对工作订单并不敏感，但每个问题所涉及的业务方实际上都缺乏一个良好的标准操作程序和一个与这些标准操作程序相对应的小型处理平台。除了工作单系统和小型2处理平台之外，

还经常遇到数据处理能力不足的问题。在太多的情况下，业务开发在设计时基本上只考虑业务实现，但是对于技术支持的有益效果(例如，异常处理的干预等)没有合理的嵌入点。)，这在我们的季度总结中相对较弱。虽然我们已经用很多方法对脚本做了这样的统计工作，但总的来说，效果不是很理想，至少很难形成一个系统。

然而，加入阿里的怀抱后，我看到了许多工具。虽然我们不能完全获得许多工具，但至少我们已经看到了许多曙光。我仍然展望未来。

开启新篇章。

合并后的第一件事当然是人员的调整和配套内容的整合，因为原来的自营供应链和平台供应链有很多共同点。做供应商整顿和做流行商家开放平台也有很多共同点。在商业商品、库存和自营商品、库存、自营表演和流行商业表演之间也有许多共同点这需要一些初始集成。当然，在考拉未来产品规划保持不变的前提下，未来仍有许多调整要做，等待迎接变化。这样做的好处之一是，具有共同业务特征的技术支持可以相互帮助，并帮助满足彼此的需求。它还能让这些学生有更广阔的视野，更多地了解新环境下行业的商业背景。

还意味着我们的团队可以在考拉的更多部门获得更多的发言权，以及针对当前核心痛点的更多解决方案，从而使团队能够得到更良性的发展，更好地服务于生产和技术业务团队。

我们计划的下一步:

是工具的升级和引入、流程的制定以及服务及时性的确认。

促进了small 2工具的集成(在计划中，这需要在短期内集成完成后进行)。

大致如下(这里省略了第一行和第二行中非客户服务业务方提出标准问题和业务问题解决要求的场景，红色虚线是我们希望在未来计划中提及的内容):< br>

我们期待一起构建集成的small 2工作台< br>

更精彩

识别二维码进入企业应用中心

今晚把这个发给你的老板，好事就会发生！

游鱼如何有效承接和处理用户纠纷？

9阿里云企业应用中心升级体验“简单创业法”！< br>