我从 2015 年 8 月入职 LeanCloud，从事技术支持岗位到 2019 年，是团队中第一个技术支持，在这段工作中经历和思考了很多，希望能够将这些经历总结下来沉淀知识。
学习技术并回答问题
刚进公司的时候，只是自学了一年的技术，根据自己的喜好写了一个 iOS 的 App，顺带补充了一个朋友的部分后端代码。由于学习过程是根据目标去 Mooc 上寻找相应的课程，有什么问题解决什么问题，以至于对前端和后端这两个单词没有任何概念，正是因为对这两个单词没有概念，使得我立志在 LeanCloud 学遍公司所有技术，最终目标是替代当时的 CTO 俊文的地位😁。
我阅读了公司所有的对外用户文档，并把文档中的示例代码挨个跑一遍，用 iOS 跑完之后再用 Java 在 Android 上跑一遍，再用 Node.js 跑一遍，期间发现了不少文档中的错误，就将它们提出来记录到 issue 中让小伙伴们去解决。在这个过程中，有一个小伙伴发给了我一篇让我受益颇深的文章：《提问的智慧》，这篇文章教会我如何和同事及客户沟通，并贯穿我的职业生涯思想。遗憾的是我已经忘了是哪个小伙伴将这篇文章发给我的，真该请他吃顿饭。
工作的前几天并不知道如何回答用户问题，最常干的一件事就把问题链接发给相应的工程师，请他们帮忙回复用户并从中学习，最终梳理出了回复用户问题的基本步骤：
- 询问用户的问题是什么，现在的结果和预期有什么不一致。
- 请用户粘贴相关请求的日志和代码。SDK 打印日志真的是一个很棒的行为，可以帮助我们迅速获得更多信息。
- 尝试对用户的行为进行复现。
在第三步中，如果能复现问题：发现是使用方式上的问题，告诉用户如何修改代码就可以了；发现是 bug，就要反馈到内部进行修复。刚开始不能很准确的判断 bug 是前端还是后端行为，找对口人时总要绕一圈，随着经验的增多，也就能很快判断出到底是哪里的 bug 并直接找到对接人。
如果是不能复现问题就比较麻烦了，需要自己想尽办法联想找出用户疏漏的部分，自己模拟猜想的场景进行复现并反复和用户沟通；还有一种调查方式是查询服务端日志，但很多 SDK 层面的问题在服务端中的日志是找不到的。内部调动技术支持及工程师一起调查难以复现的问题，这付出的人力成本太高了，后来平台给每个应用上线了自己的日志供用户自己查询，省去了工程师的时间，但在技术支持这一侧依然会和用户反复沟通并猜想重现。
开发工单
在进入公司的时候，公司正打算对工单系统进行改造，写工单的工程师欠缺人手而我又希望能学习一下，就加入一起写。在这个过程中对 JavaScript 的 Promise 进行了实践，后来大家又把它改成了 async await。当时在写工单的时候没有很多的代码嗅觉，就按照前辈的写法和封装方式照葫芦画瓢写出来，也就是前辈写的好，那我写的就不错，如果前辈写的不优雅，那我抄过来的葫芦同样也不优雅，慢慢的貌似有了一丢丢判断代码写的好还是不好的感觉。
在开发工单的过程中，我提出了一个重要需求，就是对大家回复工单的时间进行计时。在 LeanCloud 技术支持标准中有提到：
工程师应该保证用户的问题在合理的时间内得到解答，工作日内工单的平均响应时间最长不应超过 4 小时。当遇到需要较长时间确认并解决的问题时，由工程师和用户在工单内自行沟通时间。
为了达成声明的时间，内部需要对工单回复时间进行统计，由计算机提供统计结果来判断服务是否符合标准。除了 bug 和故障类等难以控制解决时间的问题之外的所有问题，由技术支持督促内部满足 4 小时的回复标准，后来达到标准这一行为逐步成为了大家的习惯。
与同事交流
工作一段时间后，发现大家的所在的职位不同，对工作优先级也就有不同的考虑，例如对技术支持来说，解决用户的问题优先级是最高的，对后端工程师来说，确保稳定高性能的系统的优先级是最高的。当技术支持面临用户问题时，工程师在思考严肃的技术问题，这个时候怎么办？大家都是第一次做人，难免有上头的时候，技术支持作为用户和内部的桥梁，到底应该怎么做？
在最初的一年到两年中，我私下和很多工程师有过或多或少的沟通或抱怨，大家的回应都很有意思，都纷纷出谋划策或表示一定好好支持，让我最忍俊不禁的是天勇笑着和我反复强调：”其实吧，就是心情不好”。最终通过这些手段缓解了问题：
- 对于不紧急的问题，记录到 issue 中，请工程师每天清理一遍。这个方案是丹神提出的，他在离职之前一直做的很好，敬佩。
- 对于紧急的问题，需要技术支持修炼自身，充分说服工程师这个问题为什么紧急，可以从战略层面讲，可以从数字层面讲，总之想法设法去证明这个问题很重要且紧急。有一点产品经理的感觉在里面了😝。
- 两者无法调和的，升级到俊文那里。
走到第三步的问题很少，我猜想一部分原因是大家是一个比较小的团队，彼此之间打打闹闹熟悉又信任，在这种氛围基础上很容易自行沟通解决问题。在沟通时也会遇到不少次工程师没有回复的情况，也不知道那时候是脑袋缺根弦还是太过于信任，从来没有往不好的地方想过，总觉得大家太辛苦了顾不上回复我，但是我的问题真的很重要，所以只好去你的工位或者给打电话找你了🤣。
全面思考如何做好技术支持
我对用户提出的问题非常熟悉了，熟悉到用户说一句话，我就可以把后面的所有可能性在大脑里面过一遍，然后迅速判断出最可能发生的问题，在预判中解决问题。到了这种程度，还有什么是我可以做的吗？我在 Google 上翻找了很多和 tech support 相关的文章，又重新翻了大学里面的管理课，总结得出技术支持属于售后服务的一部分，售后服务可以分为主动型和被动型。一直以来我回答用户问题都是属于被动服务，即用户抛过来问题，我被动接收解决掉，但那些用户没有抛出来的问题呢？我能不能化被动为主动呢？到底怎样才能全面做好技术支持呢？现在团队里面不止我一个人了，是时候做一个整体的技术支持纲领了。
这篇纲领初稿写出来后请管理层及工程师团队给出建议，再反复修改，最终涉及到技术支持整个团队的目标、个人成长路线、衡量标准以及行为指导规范等信息。我在这篇纲领中提出化被动为主动，要主动去联系用户，了解我们产品做的好和不好的地方并加以改进；要调查每个用户的特点，基于共性的基础上去开发用户体验更好的产品。
拜访客户
我记得前几次去客户那里，自己紧张到说不出话来，幸好有产品经理大毛一起前往，他的健谈化解了尴尬的气氛，我在旁边乖乖听着记录问题就可以，但之后大毛由于自己的工作内容就不再参与拜访活动了，我只好硬着头皮自己上。为了做好拜访工作，我每次在去之前都做大量的准备工作，并计划自己的行为以及发言，把行为一步一步写到笔记本上。
首先要全看一遍用户过往的工单和消费，确定用户主要使用的产品和过去遇到的问题。对于用户正在使用的产品自己要再次熟悉一遍，并确认该产品近期出现的问题和最新的发布；对于用户过去遇到的问题，了解问题的来龙去脉，确保不会再次发生同样的问题。在这个过程中，如果发现技术支持很难解答用户的问题，需要工程师沟通的，再去找主要产品相关的一个工程师共同前往。
以上资源准备工作做好之后，再在笔记本上模拟自己当天的行为，感觉这对于外向健谈的人来说应该是很不可思议的行为。笔记本上的内容如下：
- 查看用户在哪座城市，那座城市近期的天气怎么样，发生了什么事，行业内的大佬有什么新闻。在笔记本上写几个暖场的发言，最好的暖场是客户公司内大佬的最近动向。
- 正式自我介绍，确认客户现场几位人员的工作岗位，他们是写 iOS 的还是 Android 的？他们谁是管理层？
- 用客户在 LeanCloud 过去遇到的一些问题引出提问，询问客户最近的使用体验，是否又遇到了相同的问题，有没有新问题，当场给出解答。不能当场给出解答的，记下来内部讨论后通过邮件给出答复。
- 询问客户在一开始接入 LeanCloud 时感觉不方便的地方，记录下来用于改进产品。
- 询问客户未来的发展，讨论 LeanCloud 能够给与客户哪些支持。
- 结束会议。
随着拜访的用户增多，我渐渐地能够替代工程师回答很多深度问题了，这样只需要我一个人就可以解决客户现场的绝大部分问题，不需要工程师抽出宝贵的时间参与进来了，但我们仍然希望工程师能够到现场和客户进行深度交流，于是后面的拜访依然会询问相关的工程师，由工程师自行决定是否一同前往。同样随着拜访客户的熟练度增加，我逐渐不需要再在笔记本上做如此详细的行为指示，工程师都是很直接的，第一步的暖场绝大部分情况下都会省略直入主题。
在拜访客户的过程中，也发生了一些趣事，比如在某个客户的会议室里面，有一个直男工程师进来看到我和市场部的同事，开口就说：”他们公司居然只派了两个妹子来！”，后来公司的小伙伴开玩笑说我应该当场和他比比技术能力，我也开玩笑回应到，他是我们的客户我得怂着点，他要不是我们客户，哼，我肯定我当场，我依然也不能怎么样啊！🤣
在拜访客户的过程中也去了很多城市，每个城市真的有自己独特的文化氛围。北京还是有一些等级制的感觉的，上海的客户对待拜访行为最开放最好约，成都是个新兴城市但是总觉得技术产业上还需要追赶北京上海，深圳广州的客户会时不时蹦出来几句粤语。
转岗
在技术支持的工作过程中，我发现共性需求的产品可以有排行榜、好友系统、游戏对战系统，后面基于个人兴趣转去做了游戏云产品经理，再后面总觉得对自己的技术水平不满意，又跟着后端工程师维护数据存储系统，这些会在其他工作总结中写到。