博士毕业有了一份新工作，麻烦的是如何向别人解释这个工作的性质
欢迎点击「中国科学报」↑关注我们！
夏天已到，在MathWorks的工作这样就满了一年。
当有了这样一份新工作之时，一件很麻烦的事情是如何向别人解释这个工作的性质。刚开始被问到这个问题的时候，我还能耐心的解释：“我是去公司里一个专门面向刚毕业的研究生成立的部门。我的职位是应用支持工程师，工作内容分两部分，一半的时间通过电话和Email给用户提供技术支持，同时熟悉产品。另一半的时间可以自由选择公司内的各个组做各种项目。一般工作1-2年的时间内可以找到合适自己的组然后加入进去。”可这样解释也不怎么奏效，因为很少有公司会成立这样的部门，请这么些名校毕业生来当接电话。所以后来也我懒得再去费力解释，就干脆统一回答：“恩，我是客服，就是每天接电话的。”
本来就也想着博士毕业以后去做一些完全不同的事情，当做是人生的另一种体验。特别有趣的是这种体验和之前的经历有着巨大的反差。比如最明显的就是沟通的强度。
博士期间很多时候都是自己在实验室里长期钻研自己的一个很小的领域的很具体的问题，每天也就是和导师，本实验室的同学有着一些交流。然而在现在的“客服”组，每天要面对全世界各地各种用户的各种技术问题，他们来自于完全不同的背景，用我们的工具做着各种很有创意的事情。这就不能让我像以前那样只专注自己做的一小块研究，而是要站在每一个用户的角度，去搞清楚他们到底是在做什么，怎么做，用到了什么工具，出现了什么问题。
很多情况下，用户所做的事情是我完全不了解的，所涉及到的背景知识是我压根没学过的。面对这样的case，我不可能像博士期间做研究那样，去花漫长的时间把自己关在实验室里通过阅读各种文献来搞清楚问题的来龙去脉然后提出一个完美的解决方案。
作为一个“客服”，一大部分精力要用在各种沟通上：首先和用户沟通，明白他们的工作流程是怎么样的，他们需要实现什么功能，遇到了什么困难。然后再和同事沟通，包括“客服”的同事和开发人员，因为工具是我们开发的，所以在公司里总能找到某个领域的专家，能从他们那里得到一些启发。
“客服”组是个规模不小的群体，每天都会这样随机的去某几个人去讨论各种问题，也是很有意思的事情。在”客服“的这一年多里，我一共处理了433的用户的case。已经数不清自己打过多少通电话了。还记得接起第一通电话时的那种紧张感。现在时间长了，我慢慢可以在短时间内感受出来对方的性格，脾气等一系列特征。虽然感觉一年下来英语能力也没进步多少，不过进步的方面是能够把别人的意思听的更清楚，能够把自己意思表达的更清楚。
购买我们技术支持服务的用户一般都是公司里的工程师或者研究员，很多都是Dr，交流起来基本不存在什么障碍。还是像我之前理解的那样，所谓沟通，最重要的是信息的交流而不是语言本身。对于有兴趣申请我们组的同学，我的建议是多注重沟通能力的练习。特别是在讲电话的时候让尽量让对方感觉到你很放松，一点都不紧张，呵呵。
第二个大的反差就是做科研和做技术支持的思维方式。之前做偏理论的研究，最感兴趣的就是理论的正确性和创新性。至于用什么工具来实现，那是相对不怎么重要的事情。平时也懒得去学新的工具，而是把主要的时间用来推公式。因为如果公式对了就基本能发paper了，用什么方法来实现那只是用来进一步验证理论而已。但是搞技术支持是完全反过来的，工具才是最重要的，因为我们的产品是工具，而不是理论。
用户要通过我们工具来验证或者实现各种理论。这就迫使我去学习各种工具怎么使用。在加入客服组的前大半年时间，大家都在集中精力去完成一套内部的练习题。这套题目我觉得可以称之为MATLAB界的“吉米多维奇”。即使每天啥都不干，8个小时就做这些题目，估计也要3个月的时间才能搞定（和做吉米多维奇所花费的精力差不多）。做完以后也谈不上精通，只能说是对（Simulink）各个工具箱的功能有个大概的了解而已。
做技术支持不能只满足于知道一种工具和一套工作流程，而是要不断的学习能够实现同一目标的各种不同的工具组合和工作流程，并且能清楚明白他们的优劣，因为你永远也不知道用户会多么有创意的去使用各种产品（呵呵）。除了我们的产品以外，各种操作系统，硬件的知识也是需要不停的增强。当我们的软件crash的时候，我们需要费一番精力查出是我们的问题还是用户的操作系统的问题，比如有没有安装什么奇怪的软件，有没有更新显卡驱动，各种第三方的动态链接库，Java虚拟机等等。
有一次远程帮一个用户解决Simulink Real-time的问题，他的两台机器之间就是无法通信。通过仔细帮他检查系统的网络配置后发现是防火墙太牛叉了，把所有的通信阻断了。还有一次有个用户使用Coder尝试把M程序转换成C代码然后编译成exe，可是在编译环节总是出现一个谁都没有见过的错误信息。于是我只能在DOS环境里帮他一行行检查.bat文件。最后发现是他的windows path里面有个奇怪的符号。这个case花了两个多小时才搞定，但是能解决棘手的问题总是很有成就感。
工作的时间长了，就会慢慢发现基本上很多问题都是有现有的解决方案的。我们所需要做的就是真正的去认识到这个问题到底是什么，然后去搜索相应的解决方案。现在用各种软件的时候，总是会不自觉的去研究一下所有的选项到底都是干什么用的，有没有设计缺陷，有没有bug。另一方面，一旦看到各种错误信息，总是习惯性的想去搜一下看看到底是怎么回事。包括有同学在朋友圈发了一张电脑蓝屏的图，我也会跟帖分析一下。
学了那么多年的控制，但是越在学校待着，越无法理解控制到底应该怎么用。在一年前，很多招控制工程的公司并没有被我的简历所吸引，这一度让我越发的让我感觉到学术界的控制和业界的控制有着一道明显的隔阂。我也一直想找个机会去业界体验一下到底实际的控制工程是怎么一回事。
这一年的工作让我意识到在控制工程中，控制理论只是的很小一部分，而更重要的是怎么把控制算法实施和应用到实际系统中去。在建模的过程中，是使用MATLAB函数写微分方程，还是用Simulink建模。建模的过程中是使用基本的Simulink模块配以各种S-function或者MATLAB Function等自定义的模块，还是使用Simscape的Physical modeling（Simpowersystems，Simmechanics，Simevents，etc），Stateflow等等。模型搭建好以后怎么进行Hardware/Software-in-the-loop测试，调节，生成c/c++/hdl语言的代码，然后放到各种各样的嵌入式系统上（Arm cortex, R Pi, arduino, FPGA, etc.）运行。运行的时候是使用双精度，单精度，还是fixed-point。
在开发一个大型的控制系统时，常常是多方协作的过程，在这个过程中每个参与方应该怎么保护自己放的知识产权，怎么处理版本不同的问题，怎么导入一些现有的代码。开发模型的同时，又该如何validation和verification等等的问题。在上述每一个环节中，由于各种软硬件使用方式的不当会出现各种各样的错误代码，对于各种各样的错误信息应该如何应对。
在这一年的“客服”经历里，接触了各大汽车行业，飞机行业，航空航天，石油，软件，电子，电子商务等行业的工程师，了解到了他们是怎么使用我们的各种工具，怎么搭建他们的控制系统模型，他们开发系统的各种方式，常用的各种工作流程，和遇到的各种各样的问题等等。这一年的经历我觉得远胜于去一个研发机构负责一个专门的控制系统的研究, 因为那样的话，我的眼界还是会很局限。
在“客服”组的另一半时间，理论上可以加入任何感兴趣的组去参与他们的项目。这方式很适合我这种还不是很明确将来到底想做什么，或者想尝试一下以前完全没有做过的事情。
这里最妙的一点是，你可以自由的去尝试任何你想尝试的工作，去试工。一段时间之后，如果觉得不适合自己，完成项目之后可以全身而退。然后再去找别的项目，体验别的职位，一直到找到合适的为止。我想不到还有其他任何地方可以有这样的自由度。
在这一年的时间里，我先后参与了两个组的两个不同的项目。一个是测试某个工具箱的新的功能，另一个是开发一些分析模型的工具。两个组的风格截然不同，但都让我感觉很自在。虽然这两个组都不是我最终选择加入的组，但是两个组的manger对我的表现也很肯定，在这两边学习的技能在最后的转组面试中都起到了很大的作用。这期间我的manager也一直在给我各种鼓励，在我面对各种机会的时候让我冷静慎重的选择。在不断的思考，自我分析，沉淀之后，我也明确了自己内心深处真正想做的是什么。
最后，我还是非常喜欢现在公司的氛围。可能也是自己比较幸运，一直以来遇到的各位manager人都很好，对我的帮助也都很大。更重要的是在这里我感觉不到什么seniority。这里鼓励各种沟通，各种问问题。经常的需要对别人写评语，合理的意见都能够得到表达。看到别人对自己的评价也能一直敦促自己不断的改进。
下周开始，我就要正式加入控制系统组作为一名Controls Systems Engineer, 我将致力于维护和继续开发ControlSystem Toolbox和相关的工具箱。这是经过一年的探索之后在整个公司里找到的最适合我的工作，所以我觉得很幸运。今后我将尽自己绵薄之力，把学术界更多更先进的控制算法做成产品，帮助工业界解决更多复杂的问题，从而拉近控制领域学术界与工业界之间的距离。希望能和控制领域的朋友们保持联系。
此文来自科学网姜宇博客