Skip to content

Latest commit

 

History

History
executable file
·
85 lines (47 loc) · 6.21 KB

20180313-工程师如何向技术支持请求帮助.md

File metadata and controls

executable file
·
85 lines (47 loc) · 6.21 KB

从事嵌入式技术支持工作10年了,工作中经常会收到客户请求支持的情况。如果能够到问题现场进行处理,那还比较好说,但常常由于条件的限制,大部分支持都通过电话和邮件进行。客户常常会在邮件中强调问题非常关键,小则影响交期,大则影响订单,希望尽快解决。但是,通过他们的邮件,却很难做到很快解决。

1. 列举场景

  • 场景1

    客户邮件说,产品的xxx功能出问题了,不能工作,现在问题很急,请尽快帮忙解决。

    相信客户在反馈这个问题前,自己已经做了分析和研究,解决不了才请求帮助。问题是做了哪些工作决口不提,一味的强调急而不提供更多上下文信息,无助于技术支持的分析。为了解决问题,还需要进一步确认,中间的反反复复反而耽误了更多的时间。

  • 场景2

    客户反馈某某产品在第三方进行认证,但是某项测试不过,时间很急,请尽快解决问题。

    曾经遇到的客户有这样的,自己都不清楚测试的情况,包括如何测试,为什么失败,成功是怎样的等。收到问题直接转发给技术支持。然后技术支持收到问题后,问起测试的情况,三不知~~然后又拉锯一般进行三方沟通了解情况……

  • 场景3

    有客户问“Linux kernel memory 具体的作用是什么?”

    这样的问题,本身跟平台没有什么关系,属于开源领域,自行百度或谷歌一下,很容易就弄清楚。但是不太愿意动手,希望能够拿到现成的答案~~其实我回答这些问题,能回答的直接答,一下子回答不上的无非也是先搜索一下,整理后再反馈。

2. 换位思考

以上的情形,出发点都是工程师自己,他对这些场景可能比较了解熟悉,觉得没什么好描述的,直接报问题就好了。但在对方看来,这样的邮件没有任何有用的信息,无助于问题的解决。要解决问题,需要更多的信息。

换个角度,如果有人向你反馈技术问题,你最希望他提供什么信息呢? 我觉得最重要的有两点:

  1. 日志

    相信我,日志说明一切,千言万语,顶不住一份详细的log。大凡问题出错,第一反应都要检查log信息。有了log信息,就可以开始分析了。

  2. 如何复现。

    通过提供复现的步骤,技术支持可以很快了解问题是如何发生的,也能够尽快搭建平台验证问题。如果整个操作太复杂,最好能够简化一下复现的步骤。如果技术支持把时间花在搭建平台上,甚至卡在平台搭建上了,你的问题自然迟迟得不到解决,不光浪费别人的时间,也还浪费你的时间。

简单来说,如果别人找你帮忙处理问题,当然是提供的资料越全越好。有人想找你帮忙,却又不提供齐全的资料,会是什么情况?有句话叫做与人方便,就是给自己方便,也是这个道理。

3. 如何提问

请求工作前有些准备工作需要做,绝对不是拿到问题就问。提问前建议先自行分析下问题的原因,不清楚的可以先百度或谷歌搜索一下。有些问题并没有那么复杂,通过搜索引擎很容易就可以解决。

描述问题也要分清主次,去掉纷繁复杂的细节,只写必要的操作。试想,大家都很忙,谁有兴趣去长篇累牍的看那些无关紧要的细节~~

对问题的描述包括:

  1. 什么现象
  2. 如何复现
  3. 问题相关资料

这里啰嗦一下问题相关资料。

如果有日志,最好尽量提供详细的日志信息。如果是测试相关的问题,那测试步骤、测试要求都尽量弄明白,减少反复确认的情况。

有些问题单纯通过分析日志无法解决,可能还需要向提供硬件测试平台。在提供硬件平台时,尽量提供一套完整的环境,包括电源,遥控器,串口和各种转设备等,也需要预先写入测试程序。以串口为例,不要认为串口到处都有,很容易找到,其实不一定,因为各家串口设计都可能不一样。有时候就因为设备不成套,对方可能需要花很多时间才能建立环境,这样的时间花得不值得。

4. 其它事项

4.1 谦逊有礼

技术支持所在方一般是供货商,可以说你是买家,是顾客,是上帝,技术支持为你解决问题理所当然。但是,谦逊有礼是做人的基本原则,不能因为是顾客是上帝,就忘记了这一点。那种喜欢骂人或者指使别人必须如何如何的言语最好不要写在邮件里,相信我,这样写没有什么用。记得,是你求人,不是人求你。

4.2 及时反馈,有始有终

还有一类特别常见的现象是,有问题时非常积极的邮件沟通,寻求解决方案。一旦技术支持提供了解决办法,就很久都没反馈,或者解决了不反馈,直到问起来才说问题已经解决了。

良好的沟通,需要及时的反馈,有始有终。

5. 我是如何提问并请求帮助的?

最后说下我是如何请求帮助的。

有些情况下,客户反馈的问题我自己也无法解决,此时就需要请求研发部门帮忙调试。

前期先从客户那里搜集并整理问题相关的信息,尝试自己搭建平台并想办法调试,确认自己无法解决的情况下,写邮件给相关的研发人员求助。邮件内容包括:

  1. 问题出现的环境,包括平台,各种代码的版本
  2. 清晰的问题描述,什么现象,错误是什么,以及如何在参考平台上复现问题
  3. 已经尝试过的各种调试和解决方法
  4. 附上调试的日志和相关的规格书、规范等
  5. 列举我的一些疑问

通常,对方在收到邮件后通过日志和错误描述,能够对问题进行初步分析,简单的问题已经可以解决了。如果不行,对方还可以根据描述提供的环境和步骤尝试在参考平台上复现。

这样就避免了不清楚问题和环境带来的反复的邮件确认。例如:第1次问有没有log;第2次问运行环境;第3次问如何复现;第4次邮件确认双方现象是否一致……一圈下来,可能一天甚至几天时间就过去了。