规划你的职业生涯:驾驭你的“职场布朗运动”(5)

　　幸运的是，另一名HR再一次致电给我，试图说服我加入Motorola。她当时说“你一旦加入Motorola，以后离开时所看到的就是HP或IBM这样的大公司”，也正是这句话打动了我。之后的经历证明，加入Motorola是很正确的一个选择!

　　2006年7月6日，我正式入职Motorola杭州研发中心。加入的初期是大量的内部培训，培训内容包括技术方面的、流程方面的和英语。Motorola有着成熟的企业文化，通过培训可以让工程师很快地融入企业，使人行事象是Motorolan(摩托罗拉人)。在经历了约半年的培训和学习后，2006年底，我开始参与WiMAX产品线上的CLA中间件软件项目。

　　尽管我在CLA项目上没有具体的工作(比如，没有缺陷修复工作会分配给我，也没有新的特性开发工作会挂在我的名下)，但对整个团队所从事的技术工作都得负责。我的日常工作主要是设计方案评审、代码审查、帮助或带领团队解决技术难题等。

　　在CLA项目上工作了一个月左右，2007年春节之后，我被第一位派到Motorola的芝加哥研发中心做为期二个月的现场技术支持。之前尽管在公司有过英语培训，但要很好地听与说还是存在很大的障碍，加上芝加哥那边一起工作的是口音较重的印度人和巴基斯坦人，挑战可以想象。在芝加哥研发中心除了做现场技术支持，还得为后续人员的到来做铺垫。比如，租好房子、车子，准备好生活所需的一些家当(当时因为预算有限，我们住的是公寓，还得自己烧饭)。那段时间虽然因为语言的问题倍感压力，但在全英文的环境中，我的听说能力进步也明显。之后差不多每年一次的出国，见到以前认识的外国同事，总会有人对我说“Your English is getting better”。对于自认为英语听说能力不行的同仁，请记住我的职场第二十一感悟：英语的听说能力只要有合适的环境，并勇于张嘴练习的情况下能快速地提高，不必担心。

　　CLA软件在技术上属于运行于Linux操作系统上的一个中间件，它存在多个进程用于帮助通讯设备网元(包括WiMAX基站和接入网关)实现网管功能。由于软件架构的特点，使得CLA团队不时会碰到由于其他团队没有用好CLA而产生的技术问题，这类问题开始大多难以定位是属于CLA的、还是不属于CLA的，因而查错过程很低效。在CLA项目的后期，我希望通过引入新的软件设计方案帮助团队提高软件的查错能力，并改善软件质量。引入新设计需要增加很多代码，如何让管理层不担心由此而引入更多的缺陷是我着力这事时首先要考虑和解决的问题。

　　在这种背景下，我在CLA项目引入了单元测试，寄希望于通过单元测试提高新增代码的质量，以使管理层更具信心而获得他们强有力的支持。最终结果表明，在新增了近一万行代码的情况下，代码在最终发布后总共只发现了一个软件缺陷。这个项目上的工作经历让我第一次真正尝到了单元测试的甜头，在《专业嵌入式软件开发》一书中，就单元测试方面的内容很多源于我在这一项目上的成功经验。我在CLA上新增设计中的AED(Abnormal Exiting Detection)功能，在我离开CLA项目之后，还帮助团队发现了很隐蔽的多线程问题。当通过AED功能发现这一问题的同事高兴地跑过来对我说这个功能管用时，我的高兴劲写满了整张脸。这个项目的经历，也让我更加坚信我的职场第二十二感悟：在软件开发活动中，应设法通过有效的技术途径去解决工程困境。

　　2009年初，Motorola杭州研发中心迎来了一个重量级项目 — WiMAX产品线的接入网关ASN-GW，我被安排到该项目，角色是软件开发架构师。初期我的架构师一职只是杭州研发中心单方面的角色安排，而非全球性的(当时该产品由美国、印度和中国三个研发中心共同参与)。

　　在ASN-GW项目上与我一同共事的经理，是曾在Motorola美国研发中心呆了近十年、后来临时转到国内来工作的华人李亮(后面简称亮，习惯了)。他之前在美国工作时做过架构师、软件发布经理(Release Manager)等职，是一个对技术很有敏感度的管理者(我前面提到过的两位有技术敏感度的管理者之一)。我在此之后的成长，完全离不开他的支持与信任，以及他为我所创造的职场发展环境，能与他共事让我倍感荣幸和感激。

　　我从亮身上学到的第一个内容是如何与美国管理层打交道。总体说来，Motorola在软件开发管理方面很是四平八稳，其管理存在两大特色，一是争夺项目的所有权(Ownership)，另一个是质疑(Challenge)。前者使得各团队职责清晰，不容易出现突发问题或状况找不到负责人;后者使得团队在工作中有所作为，不至于让人浑水摸鱼。在面对美国团队的质疑时，我以前看到的大多管理者都很紧张，总想一味地达到美国方面的要求，但亮在这方面的表现却明显不同。他告诉我们(包括Team Lead)，“如果美国提的要求不合理，直接与他们‘掰’”。后来我认识到，美国方面做事其实很讲逻辑，只要我们对于他们所质疑的问题能给出合理的解释，很多异常事件根本就没什么大不了。我的职场第二十三感悟：不要用沉默的方式一味地迎合别人的要求，据理力争或许才是作为的表现。

　　参与ASN-GW的呼叫处理子系统的开发工作后，整个团队经历了大约半年的成长痛苦。痛苦的根源，一是对WiMAX无线接入技术相关的国际标准不熟悉，另外则是对ASN-GW产品的现有实现不了解，而且产品的复杂度的确很大(其中一个技术指标是：必须达到99.999%的容错能力)。在半年的痛苦期中，我很重要的一个工作职责是帮助团队成长，作为亮这类管理层与基层工程师间的桥梁。比如，为团队起草《开发者指南》和《测试指南》这样的文档，且要求和引导工程师通过文档化的形式沉淀经验与教训，以便提高工作效率(虽然文档化方法的实施过程需要我不断地提醒，但这一方法被证明在这种时期很有效);我也会在例会上毫不留情地指出工程师的哪些行为影响了工作效率。我的职场第二十四感悟：流程、文档的作用，不只是引导我们做完事，更能规范我们的行为和帮助培养工作习惯。

　　亮在项目进展的过程中，一直向美国方面主张杭州团队必须设置架构师一职，也正是由于亮的一再争取，美国方面最终努力地帮助我向这个方向发展，不断为我分派属于架构师工作的任务(如更新产品架构模型、参与需求管理、参与系统设计文档的评审、完成新特性开发工作评估等)。亮那时告诉我，我应是杭州研发中心第一个真正从事架构师工作的人。

　　刚接触架构师方面的工作时，其实还是不大自信的，尽管我那时掌握了软件架构师所需的基础技术技能(比如，我的软件设计能力很强、UML从1998年开始接触加上之后的持续学习所以功底也很好)，但对于软件研发管理方面的内容，以及WiMAX无线接入技术知识的系统性认识还是相对单薄的。那时与美国同事接触下来的感觉是，他们的综合能力都很强，似乎随便一个人都知道如何做架构师，不少人有做GSM、iDen和CDMA产品的经验，而且长期工作于无线接入技术领域。随着更多地参与架构师方面的工作，不仅逐渐建立了自信，对Motorola的软件研发管理也有了更为深入地认识与理解。所看到的不仅仅是产品技术本身的复杂度，更有开发活动运作管理方面的复杂度。最终，我成为了整个ASN-GW产品的架构师。

原文转自：http://www.ltesting.net