一年前离开这个职业的时候，写的。也许会泄露身份（请认识我的朋友，悄我，手下留情，别直接点名）。但是回头看这7年。感慨万千。希望能给正在做技术支持，需要和技术支持打交道的人，或者对这个职业有兴趣的人，有点参考。
一、容易骄傲自大的我
我入行10年，头三年在研发，后面的7年都在做技术支持，现在马上就要离开这个技术支持领域了，心中恋恋不舍，写点东西做总结，也算回忆了。
我是个自视很高的人，有些自大，有些眼高于顶……自己经常给自己的这种自大找借口，你看，我一个工程师，经常和别人讨论问题，结果基本上是我对了，我又对了，还是我对……天长地久， 难免自大起来，常常想，如果有个排行榜的话，TOP10 应该可以排得进去吧。 当然骄傲可以，没点骄傲，不肯努力上进，自然很难做到顶端。但是态度要好，要谦卑，肯放下架子与工程师混成一片的人，这才是技术支持的根本啊。早些时候，性情比较急躁，总是直接上来直接指东指西的，现在，多数的时候，我是解释自己的思路开始， 慢慢解释，我是如何想的，什么现象让我怀疑什么，做这个测试能证明什么，做那个测试能排出什么。
技术支持，说到根本是解决问题的人。作为上游厂商，只有下游的设备商开始大量发货，才有钱赚。在大量发货之前，一切问题，都是技术支持所要面对的。每个做技术支持的，接到的电话，Email， 都是汇报问题的，问题解决的时候，人家才不跟你说呢。没消息，就是好消息。
研发是中规中矩做技术的， 支持呢，是做技术中搞创意。你想想，10个人，奋斗一个月，每人写了5W行代码， 做了一个50W行的大项目，其中有一行代码有问题，找不出来，实在无法，叫你过来看看，你怎么办？代码不是你写的，不熟，全凭人家描述，人家肯定是往正确里描述，要是人家知道哪里有问题，还用叫你来？想通读代码，发现问题， 没有那么多时间让你读一遍，你只能靠经验，靠想法啦。而且，常规的测试方法，人家工程师，也肯定试过了，人家10个人也不是吃白饭的，你的脑子里要没点超越人家的想法，人家连试都不会让你试的。
我是个有创意的人，这些年，有的时候我最得意的不是我的技术有多牛，而是我的想法，非常多非常有创意，哈哈哈，真的很自豪这点。
当然，扎实的技术是一切正确判断的基石，我最大的优点是我很清楚的知道，什么问题，是我的能力范围之内的， 什么是我能力范围之外的， 技术支持，只要能解决问题就是好的技术支持，不需要凡事都是自己解决的，借力是很重要的。
一个好的技术支持，第一必须能够判断哪些问题是自己能够解决的，那些是需要协助的。第二能自己解决的， 自己解决掉。第三自己不能解决的， 给同事以正确的输入，协助同事解决掉。做到此三点，可以打满分。我自打分95， 人么，总有失误，无法满分。
二、什么问题是能够解决的
技术支持是解决问题，但是跟一般工作一样，也是符合80/20规则的。
80%的时间，我都是在回答一些简单的基础问题，请让我借用淘宝体来描述一下，
“亲，请翻到手册xx页，你的问题可以在xx行找到答案”
“亲，英文看不明白？没关系， 我帮你翻译一下，你再看看”
“亲，翻译成中文你也没有看明白？没关系，我给你举个例子”
……
剩下的20%， 才是真正的问题，才是能够用上我前篇说的3个要点的。解决掉一个问题， 成就感是难以言语的，有的时候，我觉得这地球上只有我，才能解决这样的难题……
以前，总是把一句话，挂在嘴边，“中国的客户是最弱的，因此中国的技术支持必须最强”，其实中国的客户不是弱，而是太年轻，放眼望去，做事的工程师，一批比一批年轻，积累不够啊。因此报到技术支持的问题，基本上复杂的，只有现象，没有怀疑方向的。还有一点，中国的客户愿意把芯片用到极致，好处是性价比上去了，坏处是，芯片用到极致，遇到极端问题（corner case)的概率高很多。在中国， 做技术支持是个有挑战性的工作。
回到，题目，什么问题是能够解决的。总有人问我，这个问题，你怎么看，我不知道我负责的那些客户领队，经理，是否问过自己的手下，这个问题，你们怎么看？
凡是能复现的问题，都是可以解决的。不能复现的，如果能保留现场，尚有一线希望。如果不知如何复现，也没有保留现场，只知故障现象的，基本上是无计可施的，能不能解决的，全看运气，如果有其它客户遇到这个问题，能复现，能解决，坐个顺风车而已。
确定复现条件，是问题解决的关键，就这么简单。
简单的一句话，做起来， 比较难。而且，对于我家芯片这种有软有硬的器件，完全是个手艺活，每个问题都是特立独行的。
举个例子，最近的一个问题，客户给的复现条件，是双片对接，从两端打对称的流量，再从另外一片的另外一个接口出。条件虽然清晰，但是不具有可操作性。两片对接的这种方案，怕是这个地球上的独一份，不可能找到参考的平台，而且公司总部也无法搭建类似的环境测试，这是一方面。从另外一方面看，如果是芯片本身的固有问题，一定是单片可以复现的，不需要双片对接，对接的端口是标准的，与谁对接现象都应该一致。因此，我的最初判断，这是一个客户自身板级的问题。 在客户实验室，连续待了将近一周，发现，复现条件可以简化到单片，单端口，与客户软件无关的地步，并且发现问题复现时，在芯片内部的统计计数器上发现有异常值，因此判断为芯片自身问题，最终交给总部研发部门处理。
再举一个例子，目前这个问题尚未解决，复现条件倒是也清晰，且每次都能复现。但是针对复现条件进行的所有排除测试（就是说，例如复现条件有一个是，查表一，则能复现问题，那么排除测试就是保持其它条件不变，不查表一，看看是否还能复现，看看这个问题究竟是否与表一相关），结论是发散的，怀疑点不是减少，而是增加的。这个，理论上，不是复现条件不正确，就是问题是随机的（但是，保持复现条件，每次都能复现，应该不是个随机问题），还有可能是排除测试有错误。最要命的一点是，复现条件与客户现场密切相关，无法提取一个总部实验室可以复现的条件，这样的话，帮忙也无处帮起。更要命的是，客户的负责人，态度让人头痛。
请允许我抱怨一下， 有这么一类负责人，完全瞧不起国内的技术支持，大约觉得我们都是吃白饭的，只有老外能帮得了他， 开口闭口都是让你们总部派人。我不喜欢这种人，简直是一定的。其实，我可以喜欢他们的，因为他们不寄希望与我，我也没有压力，我只需要中规中矩的完成翻译和传音筒的功能就好了，应该是蛮轻松的。无视，轻视算什么，又不影响我每月领工资。但是，他们都是在自误，虽然有的时候是会哭的孩子有奶吃，但是你的分量不够的时候，哭死也不会有人理的。总部派人，一个工程师一周，费用在4W~5W人民币的样子，算算项目的利润，够几周的，何况出问题都是量产前，中国客户的名声不算好，一般不是顺路，这种要求都是忽略的。 你强烈要求总部工程师，我们这些中国的技术支持，就不太肯出力了，反正你也瞧不上我们，我们何必吃力不讨好呢。还有一点，凡是有这种要求的负责人，我发现，大多数都是对问题不了解，对自己工程师没有要求的，他们也瞧不起自己手下的工程师，觉得自己手下肯定是不行的，只能仰仗外援，这样的领导，带出的队伍，也是不行的，出了问题，只想外援，自己是一点力气都不想花，一点钻研的精神都没有。
相反， 另外一类领导，找到你的时候，会很清楚的说，我们遇到什么样的问题，我们试了什么样的方案，做了什么样的测试，排除掉什么因素，但是仍然怀疑问题与什么相关，你看可以怎样排除掉剩下这些怀疑点，或者你看某个行为是否正常。我喜欢和这样的人合作。而且，有这样的领导，他对手下也绝对不是，有问题，直接找外援，而是努力先想想，再问。长此以往，能力就是这样提高的。
三、时间用在哪里是看得出来的
曾经有人问我，你们坐班么？ 我问他，如果我每天过来5分钟，解决掉问题，然后回家睡觉，你会觉得我工作不尽力么？ 相反，如果我解决不了问题， 每天早晨8点过来，跟你一起待到晚上12点再回家，你觉得我工作努力有用？
别说，我还真干过这种来了5分钟，然后就出门逛街的事情，当然头天看了一下午的现象，晚上琢磨了半夜，有了思路。才有的第二天早晨过来，看了一个寄存器，改一个bit，立马药到病除。然后，人家工程师万分感谢的送我出来，还向我介绍哪里逛街比较好。在我来之前，他们为这个问题已经加了一个月的班了。
技术支持的工作，是不能用时间来衡量的工作。大家对技术支持的期望是，用最短的时间解决问题。也不是以解决问题的多少来衡量，最最上乘的技术支持，在设计阶段就帮助客户避开所有有可能的问题，整个项目做下来，一个问题都没有（当然，这种项目只发生在传说中, 我尚未遇到）。
台上一分钟，台下十年功。想5分钟在客户实验室解决问题，办公室里面花的时间绝对不是普通早九晚六。我不知道别人怎么看待工作的， 我也没有特别的志向，我只是希望无论什么时候，都知道自己现在跟5年前比，值得一份更好的薪水。
我也不知道别人是如何平衡家庭和工作的，我知道我的老公对我是不太满意，我不喜家务，不喜做法，也不喜和孩子玩耍，早晨送过孩子之后，就是上班，下班之后，有小时工做饭，打扫房间，晚饭之后，基本上是笔记本不离手。
幸好，我还喜欢旅游，喜欢运动，喜欢尝试一些新鲜事务，否则我是个多么无趣的工作狂啊。
时间用在哪里是看得出来的，有所得，有所失。
四、如何和技术支持打交道
我相信这个话题，才是更多人关心的。请让我分两个部分来说，一工程师如何和技术支持打交道，二项目经理如何和原厂技术支持打交道。
1、工程师
我明白，当一个工程师想起一个技术支持的时候，是他/她遇到问题的时候，我明白，遇到问题的人是心情不好的人，但是你也要明白，你买的是芯片不是去商场买的电视，插上插头就能亮，否则公司也不会付你这么高的薪水来搞开发啦，相信我，农民工兄弟比你便宜，比你更会插插头。遇到问题是正常的，你寻求帮助也是正常的，大家都是工作，发脾气，对谁都没有帮助。
当一个客户告知有问题的时候，技术支持的脑袋里面的第一个问题，是"这是我家产品的问题，还是你家板子/系统/软件/应用的问题？"
因此，作为一个工程师，应当尽量客观的描述，你做了什么，看到什么，你期望的结果是什么，但是实际上的现象是什么。而这些描述，要客观，用代码，寄存器这种通用性的工程语言，而不是单纯的文字语言。
例如，有人发我一封信说，我把XAUI口配好了，然后发流，流量不通，是怎么回事？
这个，基本上上说，我也不知道怎么回事，有用的信息点，除了一问题与XAUI口相关，二问题时流量不同以外，就什么都没有了。
一般，我只能回复，在这颗芯片上XAUI应该是没有问题的，请再查（这个就是说，我认为这个问题是客户板子或者系统问题）。
再举个例子，有人发信说，我用 XAUI_CONFIG API 配置了XAUI接口，参数如下... ... 我读了PCS_register 和MAC_Status寄存器，值为xxx，应该是链路状态正常，这时，我用Smartbit往XAUI 0 发10个64B的包，读XAUI 0的端口统计，发现有收包计数，值如下...，但是读内部统计，发现全为0。这可能是什么问题？
这封信的信息点就多了，客观了许多，虽然听起来还是象客户问题，但是我可以提的建议就多了，一般来说，我会说，XAUI 0的端口统计正常，说明xxx和xxx正常，你应该看看xxx，看看这部分的配置是否正常。
有些大公司，对于客户提交问题，是有格式要求的，听起来有点教条，但是绝对必要。
客观的说，我收到的Email，95％是需要打电话回去，查问详情的。问题描述客观，详细地工程师，这么多年，我遇到的不超过5个。
其实，电话比Email方便，我也理解，中国某些客户，往外发Email是需要权限的，但是，如果我当时很忙，或者在外面，电话里的说的东西，容易忘记，但是如果有follow up的Email的话，就不会忘了。Email有的时候，也会丢失，如果长时间没有响应，再补一个电话。
不是忙得要死的时候，我会在每个周五的时候，给负责的项目经理打一个电话，看看是否有遗漏的问题，同时跟踪一下项目进展。
最后，对于来自技术支持的建议测试。有的时候，我会遇到很不耐烦地工程师，觉得我没有能力解决问题，反而刁难他，让他做这个那个测试。实话，技术支持也不是神，不可能什么都说了现象就知道问题原因的。不同的测试，是用来证明或者排除一些怀疑点的。如果觉得有些测试，不必要，大家可以商量，抱怨，发脾气，于事无补。
2、项目（研发）经理（领导）
让我猜猜，项目经理最关心的问题，1、这是个什么问题 2、什么时候能解决？ 3，怎么知道解决了？
当一个问题，上升到项目阻碍性问题的时候，就不再是工程师的烦恼，而是项目经理的烦恼啦。
也许，项目经理的第一个问题，不是这是个什么问题，而是这是谁的问题？我见过，实在分不清，只好开三方会议的，让两方的技术支持直接PK的。
项目经理，最常要求的是 1、on-site support 2、远程调试 3，开电话会议
on-site support，这个让我头疼的词，我承认，这个方法，往往最有效，问题拖到一定程度，最后一招，就是去现场啦。对于客户来说，扣一个技术支持在手里，技术支持，为了能回家，只得全心全意，贡献所有的智慧，动用所有可用的资源。
但是，前面也说了，去现场是要花钱的，项目不大，不重要的时候，基本上是不可能实现的。去现场，无非是支持工程师可以自己查看状态，看得更仔细，如果自己的工程师可以客观描述现场，让支持工程师如同在现场一样，效果其实是一样的。
远程调试，在中国，大部分情况都是不现实的。 偶尔有条件的，效果真差啊，动一下鼠标，屏幕就花了，半天也看不到，脾气急的同志，根本受不了。
开会，容我说句大实话，没有正确的输入信息，跟谁开会也解决不了问题。有了正确的输入信息，开不开会，都能解决问题。多数的时候，电话会议只是用来安抚心急如焚的项目经理的，并无实际作用。
这么些年，我也见过不少人，靠谱的经理，带的队伍多半非常靠谱。不靠谱的经理，带的队伍也不靠谱。有些擅长提不合理要求的领导，看着挺强势，但是往往他们带的队伍是最弱的。
五、(完结篇) -- 杂七杂八的小秘密
1、 所谓内部文档
技术支持手里是否有客户没有的内部文档？有的。 但是放心，精华部分都在公开文档中。
作为一个客户，一般公开文档中的内容足够， 有些文档，虽未公开，但是按需供应，只要问，就能得到。
作为一个技术支持，最痛苦的莫过于公司不提供任何内部文档，手头资料和客户完全一致，特别是新产品刚刚上市的时候，完全和客户一样，完全一个起跑线， 特别是小公司，根本没有提前培训，哭啊。 但是，技术支持总有机会接触到公司内部的一些设计文档，草稿什么的。 这部分文档，量大有用部分不多。但是，芝麻也得捡啊。
另外，越早的文档，往往内容越多，后期的文档，反而内容少。 我的第一家公司，文档写得好，一看就是架构工程师写的，有理论，有算法，有历史，有设计，但是代码一般。 我现在的公司，文档是工程师写的，有细节，没有理论，但是代码写得好，注释清晰，资深工程师的活。
2、会哭的孩子有奶吃
有人奉行会哭的孩子有奶吃的原则，但是每个技术支持手里/心里都是有个项目排名单的。实在忙不过过来的时候，单子里面排名靠后的，响应时间肯定没有保障。我知道，有的老板，甚至明确的要求不用理会某些项目的要求和问题。
但是，我是受不了同一个问题问三遍的， 如果有人坚持问我，我宁可不睡觉，也把他/她的问题回答了。因此，这个原则，至少在我身上是奏效的。
3、黑名单
工作这么多年，其实跟所有的人，都相处得不错。工作关系么，不对人。但是，至有这么一次，看到一封带有侮辱性语言的Email，如果他抱怨的问题，确实是我的问题，我也能忍了。可他要求我提供另外一家公司的代码说明，我拒绝了，他因而发此信。这个人，我希望今生今世不必再见到他。如果真有狭路相逢的一天，我会以彼之道还至彼身的。
此外，我还有个小小的难以沟通的人员名单，名单不长，一只手可以数过来。只要是名单上的人问我事情，无论他以什么方式提问，我必然以Email的形式回复，且抄送他的同事，老板，我的同事，和老板。因为，我90%的确定，我的回答，他不理解。 其实，我蛮擅长解释问题，化繁为简，把复杂的问题解释得通俗易懂，而且因人而异，对不同的人，采取不同的说服方式。但是，有那么三、四个人，彻底伤了我的心，打击了我这方面的自信，我在他们身上，失败次数太多，因此，每每有交流，一定要保证有第三人参与，保证即使他们不明白，他们公司也有人明白，退一万步，要保证我老板知道我已经正确解释过这个问题了。
4、技术支持工程师的资源
第一重要的资源，当然是身后的强大的研发队伍啦。客户关心的是问题解决，谁会在乎一个问题是技术支持自己解决的，还是他/她找人解决的呢？（我自己在乎，每个问题，即使求助于人，也一定要有所贡献，否则不就成了一个翻译器了么）了解公司内部的人员结构，工作流程，知道哪类问题该问谁，永远是有用的。
第二重要资源，是客户。 手头的客户就是一个个的实际应用案例。两个客户在某个接口上配置完全相同，一个工作正常，一个有问题，正常的那个就是最好的资源了。 中国的客户，让我头疼的同时，让我的经验丰富，往硬件软件系统都懂得的全面手上发展啊。
第三类资源，是同事，说白了，是同事手里的客户资源。一个问题，公司的系统验证部门没有测过，且没有条件测，客户又有问题，难以判断是客户自己板级问题，还是芯片问题，怎么办？先看自己手头其它客户有没有类似应用，没有，就问遍同事，看看有没有类似应用。好吧，实话实说，中国客户，用一个全世界无人用过的功能的情况，基本上是没有的。 因为中国的客户，定位在追随者上，往往在设计阶段就已经确定，有人用这个功能（相当于有人验证过这个功能），才会决策用这个功能，因此出了问题，总是能找个参考的。
5、当你是第一个尝试者
上面说了，这个可能，在中国比较低，但是万事有例外，总是有这种时候，其它客户项目延迟啊，什么的，你就有机会做第一个吃螃蟹的。
别人怎么样，我不知道，我是挺兴奋。 首先，要相信自己的人，功能设计出来，应当能用的。稳住客户，自己努力研究，同时抱紧研发的大腿（你设计的东西，我的客户用不起来，兄弟，你总得给个说法吧）。
6、快乐单纯的工程师
其实，做个工程师， 非常单纯，很容易快乐，凭手艺吃饭的人， 只要手艺好，其它的什么，算是次要的吧。一般的人，对工程师都是多多谅解，例如说说错话，做错事，发错Email什么的。
英文烂一点，凑合能把问题讲明白就好， 聊天的时候木一点，谁也不介意。
说实话，离开工程师的岗位，心中非常恋恋不舍啊
