由于做的是新产品，客户服务正处于一个组建过程中，所以会被拉去做一些技术支持的任务。回想过去几十次的技术支持任务，总结、思考一下。
一、面向客户
技术支持是一种面向客户的任务，客户服务可以分为一线（On-site engineer）、二线(On-call support)和三线(Engineering Support)，虽然一般都会有On-call在场，Engineer是起主导作用的。
具体来说，技术支持活动需要了解：
- 客户的系统部署
- 客户的系统使用模式
- 客户的客户使用模式，有没有负载、负载是多少。
这些知识对于刚刚工作的人、或者说对于一个刚刚开发的新产品来说，还是比较有用的。刚刚开始接触客户环境的时候，我也经常会去思考产品设计中对客户场景做的假设是不是成立。
二、面向用户
客户的定义比较空泛，通常是一个公司或者一个部门。真正的用户可能就是它们里面的一个工程师，这个工程师可能有各种各样你想不到的需求，比如说：
- 机房里没有可用的显示器、机房里没有可以直接连到服务器的网络等等
- 工程师（DataCenter Operator）远程工作，不能进入机房
- 工程师只有3，4个小时的维护窗口
最妖怪的一次就是，工程师把blackberry放到服务器的USB口充电，然后安装服务器的时候blackberry很悲剧地被当作一个磁盘格式化了。
三、时间管理
技术支持任务一旦出现，就极有可能是是最高优先级的，这个时候老大也只能把技术人员从开发任务中拖出来。任务完成之后，开发任务就被拖后了。其实不知技术支持会拖后开发进度，无数的事情都可能会拖后开发进度，老板开会、领导巡视、个人请假，所以需要借助这样的机会培养时间管理的能力。
做好（有强干扰情况下的）时间管理，需要做到：
- 开发进度留有余地，用于应对干扰、技术难题攻关等
- 做好沟通交流，出现进度不一致，及时跟相关人员（Stake Holder）沟通，有时需要重新计划。
四、反馈环
技术支持任务其实是一种非常有效的获得反馈的机会，如果思考以下的问题，可能会有不一样额收获：
- 为什么会出现这样的问题? 是用户操作的问题还是程序逻辑的问题？
- 为什么需要工程师去做技术支持？如何才能让客服甚至客户自己解决问题？
- 程序逻辑有没有需要改进的地方？比如特定的场景没有覆盖到？
- 技术支持的流程有没有需要改进的地方？比如重要客户的重要活动应通知工程师Stand-by，而不是到时候抓人？
- 测试是不是也有需要改进的地方？为什么这个没有在测试中发现？