工作总结及思考 2011/07/11- 2012/07/11

工作一年，时间为轴回忆并总结下工作内容以及自己的思考若干。

七月，我带着毕业的小伤感以及对于新生活的期待开始在亚马逊的路程。一个月的时间， 熟悉团队，公司内部的各种基础设施，基础编程工具，花费了我大量的时间。作为非计算机专业毕业的学生，我对于很多计算机应用方面的知识了解非常有限，比如如何管理不同版本的软件，如何将自己的代码发布到生产环境中，如何处理软件间的依赖关系等。很多东西不明白，所以经常有挫败感，尤其是看到身边的同事游刃有余的处理团队内外的工作，自己羡慕，也着急去追赶。记得有一天在公交车上，和一个在公司干了半年多的中国员工闲聊，当时就觉得什么时候我也能赶快有六个月的经验，能像他一样真正自如的上手工作。现在想想，当时急的挺可爱的，也许人只有对自己的第一份工作会如此的投入和用心。另一方面，组里的同事们非常友善，有一个美国老头编程几十年了，算是C++方面的大牛，但是人完全没架子，每天早上见面都会和我聊聊美国社会的各种八卦，有时也扯扯自己的家长里短，让我很快在公司里产生了一点融入感。其他几个同事也是有问必答，能感觉到他们希望我能够迅速成长起来，提高这个团队的工作效率。所以，无惊无险的度过了最初的磨合期，之后经理有意识的分配几个规模和影响力较小的项目让我来做，让我加深对于现有系统的理解。由于组里的代码都是C++，所以基本上自己得从头开始扣C++的使用方法和相关的调试工具，这些东西虽然繁琐，但是并不难，慢慢的自己越来越多的了解了自己组内的业务逻辑，也逐渐的把自己的代码部署到生产环境中去，有贡献的感觉很好。从此，下班走出公司的时候，回望天空星光和楼内灯火，我真真正正的感觉自己属于这里。

大约三个月之后，我就开始带上了传呼机，美国称之为oncall，就是员工每个月有一周需要24小时待命，来处理公司内部的紧急事件。 刚开始oncall的时候压力非常大，有一次半夜被传呼之后，自己没有办法解决问题，只能把导师和经理叫起来一起处理，很尴尬。还是时间，过了很长很长的时间，大约在我第三次oncall的时候，我终于可以独立解决了一个sev-2级别的问题。但却没有感觉到多少自豪，更多的是宽慰和释然。之后就是顺风顺水，接触更多的项目，接触更多的知识，设计模式，数据仓库，单元测试，整合测试，系统故障调错和优化等等，很开心的是感觉的自己一直在学习很多东西而不是原地打转，也很惶恐因为觉得自己不懂的东西太多太多。慢慢理解了为什么越牛的人，反而越谦虚。因为你见识了领域的广大，才明白自己能够掌握的渺小。懂或者不懂，内行人一问便知，所以在不懂的领域，倾听比扯淡更重要。

慢慢的，有了更多的时间，有了更多的余地，自己开始思考如何不满足于完成任务，开始从整体上思考如何让自己的工作真正解决问题。思考来源于和导师的一次对话，他的原意是："problem is hard, solution is easy". 翻译过来就是，搞清楚你要解决的问题是困难的，解决问题相对来说是容易的。当然，这话谈论的是在IT领域内，并不适用于其他行业。在亚马逊内部，每一个组都有明确需要解决的问题，比如promise组就是负责给出送货时间的估算，GPI就是来跟踪所有的库存状况。针对这些最重要的问题，我们的软件工程师花费大量时间写出软件系统来解决问题并自动化这些流程。所以明确问题很关键，一旦你搞混了自己需要解决的问题，那之后的解决方案就是错上加错。所以我来反思我们组（Fulfillment Exception Management)解决的问题，却也突然觉得挺迷糊的。感觉干了很多活，完成很多别人派过来的任务，但自己却不知道这些需求是为了什么，解决了什么问题，说明自己对于工作的理解还差很多，说白了，就是做了高级点的脑力执行劳动。后来自己梳理了下思路，本质上，我们组处理的问题就是，由于大规模计划和配送订单难以避免的出现问题，我们需要提供完善的方案来弥补这些异常造成的用户体验缺失，同时驱动相应的内部流程处理这些异常。而进一步去考虑为什么我们的内部的计划配送系统会出现问题，这个问题的复杂度就已经超过了我目前所能了解的范畴，不过我相信这一定是更高级领导经常思考的部分。在以后的工作中，我也一定要多问多思考，多问问自己外部的需求的动机是什么，和我们组解决的问题是否相关，争取全面透彻的搞懂供应链这点事儿。