四年前我写过一篇文章：我的第一份外包经历及所得，四年后的今天再次到了写年终总结的时候了，巧合的是两个年份都是做外包。最近几年写博客的时间比刚开始工作时少了不少，但依然在坚持，因为我喜欢通过总结来学习。
这是我第二份外包工作，其实第一份外包呢，说实在的做的时间并不长，当时被安排到一家电子商务公司做项目，半年时间后我也就回原公司了，合同到期了。当时本来是有机会直接应聘到客户公司的，因为客户公司有个习惯，就是如果觉的外包过来的员工做的还不错就从外包公司给买过来，招成自己的正式员工，当时也是运气不太好，大家都知道2008年的经济不太好，客户公司年末的时候对招聘进行了暂时的冻结，为此我只好回外包公司了，至于到客户公司的半年我的所得可以从我之间的文章中查看。
总有些人对外包公司的印象不太好，面试时一听到外包项目就非常没兴趣,下面是我认为的一些缺点。
外包公司的缺点
1：外包公司的员工没有归属感。
像我2008年进第一家外包公司，除了办理入职到了趟公司，然后就安排到客户公司工作了，这期间除了每月发工资，基本和原公司没有任何关系，同事大多也是客户公司的。其实也不尽然，像我现在的工作，虽然也是外包，但我们是一个大团队一起到客户公司，从规模上讲相当于一个小部门了，有大领导有小领导，当然你包括我们这些大头兵，编职还是比较建全的，你周围的工作环境中除了客户也能每天见到自己公司的同事，这相对要好很多。
2：外包项目累
这点也分情况，比如我2008年做外包时，一点也不累，从不加班，项目也不会紧张到加班,可能是安排的比较合理吧，也可能是公司不希望员工加班，因为加班也是有成本的,况且加班的效果也不一定就特别好。但我今年的项目就特别需要加班，这都是各方面原因造成的，所以外包项目累也不能以一概百，需要注意的是我们其它项目组的同事一般情况也不加班，也只是少数项目才会加班。况且加班也不是无偿加班，是可以调休的。
3：外包项目是一些边边角角的项目
有些外包的项目的确是这样，核心的部分一般都不会找外包来做，大多都自己公司内容的人来研发，但这也只属于一部分，像我今年做的项目，就是客户公司比较核心的业务系统,个人认为取觉对我们在客户心目中的信任程序。
其实到了2009年初，由于我的第一个客户公司突然有员工离职，所以我得到了客户公司的邀请，于是我又如愿以偿的回家的客户公司，二年后，由于我个人职业规化我选择了离开客户公司，这次再次选择了外包公司。
外包公司的优势：
1：外包公司机会相比传统公司多
传统的公司都是一个萝卜一个坑，上面人不走，你升职的机会相对比较困难，或者说你去尝试另外一种职位的机会相对要小。比如做为一个程序员要想往PM转型，传统公司是比较麻烦的，外包公司就不一样，只要有项目你也许就有机会，有时外包公司的特点就是赶鸭子上架，如果你有碰巧正好有些经验，你也许就成功了。
2：外包公司比较容易增加知识面
在外包公司中，你可能会接触到不同风格不同性质的项目，有的项目也许在技术上能提高你的，有的项目也许在管理方面能提高你，总之就是知识面会丰富一些，当然你也不能指望这样你就能成为一大拿，这只是入门，是否用的好还是要靠自己不断的努力总结。
3：外包公司能够增加人际关系
程序员的圈子一般会比较小，相对于其它一些行业，如果是做外包项目的话，其实你相当于同时时间进了两家公司，因为你的合作伙伴除了你本公司的同事还有客户公司的同事，如果客户公司的同事质量好的话，对你本身将是事半功倍的效果。比如我现在的客户公司就有一位能力非常强的架构师为我们的项目做指导，这是我们的荣幸。
我的职业梦想
我的职业梦想是做一名优秀的软件架构师，但架构师在IT行业中也分很多种，我是属于偏向技术解决方案类型的，到今天所在的公司应聘的也是我心仪的职位，但进了公司其实发现和我想的有一定差别，按我的理解就是他们招聘的更像是一位技术Leader,说的直白点就是一般的高级程序员，好在本人一向擅于沟通，最终领导给了我带领小团队做项目的机会，这里的带领其实也不是真正传统意义上的PM角色，简单点来讲就是啥都做，只不过比起纯粹的程序员多了一份工作内容，就是和客户沟通，比如需求呀，解决方案呀，进度控制呀，等这些做完，我也会再次变成一个程序员和其它成员一起开发代码。尽管和我心目中架构师的工作有差异，但有机会学习一些项目管理的知识，也是值得的。事实证明我还需要积累更多的项目经验，才能成为一名架构师，甚至成为一个出色的架构师。
我在2012年中比较有收获的地方：
1：沟通能力
来这家公司之前，我是从来没有带过团队的，尽管积累了两年多基础架构经验，对项目开发有很多自己的想法，但谈到项目管理还真是经验不足，以前是程序员，工作单纯，接触的人也少，所以沟通表达方面远差于PM，既然领导给了这样的机会，我也就需要努力再努力，下面是几条我对于面对不同客户的体验：
a):有些客户很忙
客户有的时候同时会负责好几个项目，所以他们的时间不可能完全放在和你合作的项目上，有时一些问题需要得到他们的确认，但他们又太忙，没有太多时间给你直接答复，这样就会使你的工作进展受到影响，下面是我曾经使用过的方法：
方法一：发邮件
将自己的问题整理成邮件发给客户，希望他在有空的时候能回复你，不可能一有问题就直接找他去。
方法二：如果没回复隔一段时间再发邮件提醒
有的时候，客户不一定按你的希望，一收到邮件就能回复你，有时需要多次提醒，但最好提醒的次数不要太多，我一般就提醒一次。
方法三：打电话
如果邮件不回，就打电话，一个有责任心的客户他是不会介意在他下班后接听你的工作电话的。
方法四：直接在他工位上等
如果客户由于时间太饱满，而经常爽约的话，就直接下狠招，到他工位上堵他去，这个办法不能经常用。
b):客户喜欢你给他出主意义
谁都希望自己的工作轻松，但轻松的前提是有人为你分担，同样客户也希望你为他想一些方案，他负责确认。如果你能在这方面做的足够好，和客户的关系才会迅速建起来。
c)：先听客户的想法
对于有些你不太确认的问题，不妨先听听客户的意见，然后再发表自己的看法，谁的想法都不一定是完全对的，也不一定是完全错误的，不要一听到你认为不对的地方就完全否定别人的想法。
d)：并不是所有客户你都能将关系处理的很好
是否能将客户将关系处理好，取决于很多方面，这里我认为比较重要的有两点：你的能力以及你如何面对客户自身的工作方式。个人能力的高低是建立信任的关键，但客户的工作方式，工作特点，性格习惯对你也非常重要。如果客户对技术没有任何的了解，那么你不需要花过多时间去和他讨论技术，反而应该去和他讨论有共同语言的领域，你需要将他不明白的地方用最简短的表达方式与他沟通。如果客户对技术有了解，那么这是你的福分，你可以在技术上提到多种方案供他选择，共同语言多了自然合作起来就容易很多。有些客户只注重结果不注重过程，他也不会有太多时间花在讨论上，所以就全凭你自己经验了。总之不同的客户需要采用不同的对待方式，我的体验是建立可靠的客户关系难，能够一直维持下去是难上加难。
我今年接触过三个客户，其中两个算是成功的，至少个人认为如果是100分的答卷，应该在80分左右，其中有一个失败的体无完肤。如何与客户沟通，我得到了公司很多同事的帮忙，这里非常感谢他们。
2:善于利用客户
其实有些客户在某方面的才能也许比你强，你可以充分利用他的优势来为你解决部分难题，比如说如果客户对于需求分析特别强，做项目分析及项目计划时，可以让客户多参与，多提供意见。如果客户技术能力强，那么在项目解决方案问题上可以多多听取他的看法。
比如我们为客户公司做项目时，他们会安排一个海外的架构师协助我们，既然有如此技术能力强的人帮忙，如果不充分利用那是多么的可惜呀。一个人能力再强，能做多少事呢，能将一个项目全部搞定吗？还是需要大家的共同努力才行。
3:尝试教会其它人
最近的项目我们采用的是mvc4以及entityframwork5,项目组成员都需要现招，现在招人不好招呀，如果招的人都满足我们的技能要求更是难上加难了，为此我招聘了一些基础不错，学习态度良好的员工，这样如何让他们在短时间内学习他们以前不熟悉的技术是我的主要工作，还好由于我有写博客的习惯，所以我能写出来我也就能教他们，事实证明效果还是可以的。
4:第一次在项目中大规模采用自己的东西
之前讲过，我来这家公司前已经积累了两年多基础架构经验，有如此如此多自己的想法，所以非常想将自己的经验应用在新公司的项目中。
a):全新的符合客户公司风格的代码生成器
其实呢之所以自己搞一个代码生成器，也是巧合，和客户合作一项目，发现他的代码是用一个工具生成的，觉的挺好玩的，于是本想让客户给我研究研究，估计是出于保密也没给我看，但我本人好奇心强，不让看就自己做一个吧，如果我的生成器比他的好用岂不很有意思，当然我不可能从零开始开发一个代码生成器，于是从网上搞了一个开源的基于T4模板的生成，按我自己的要求重新重构了一次，修改了生成器本身不少BUG，客户一看从此放弃自己以前花钱开发的产品了，后来再次和客户全作项目，我有了第一次机会，在实际项目中应用自己重构的生成器。
b):entityframework repository模式
也是在客户以前项目基础上重构的，在此项目之前我也没有任何entity framework相关的经验，但重构后的模式非常好，客户也将以前的项目的部分代码按我的方式做了调整，下面是一些我之间写的总结：
c):js模板开发
这里说的模板开发，其实主要就是起到规范js开发规范，同时提供一些通用解决方案，这几年中我陆续写了一些，虽然还有些不太完善的地方，但比起不规范起来还是要强不少，总之仁者见仁吧：
5：头一次全新设计一个系统的数据库
尽管我已经工作七年了，但是谈到从开始到结尾全新为一个系统设计数据库今年还是头一次，今年有三个项目需要这样做，这其中我的同事以及客户都给我很大的帮助，也让我有机会在项目中应用我对数据库性能优化的经验，在系统上线前就应该考虑到，而不能等出了性能问题再去补缺。
a):化繁为简
我们有一个业务场景查询数据的逻辑比较复杂，且这些表的数据量也比较大，最终我们的做法是生成一个用于存储计算结果的辅助表来解决，这样系统只需要访问我们的辅助表就可以，而不用写很复杂的数据库语句去查询了。当然这也是付出一定代价的方案，只要是在可接受范围之内又能解决紧要问题的方案就值得尝试。
b):创建合适的索引
以前写过一些关于数据索引的文章，这次正好运用在亲自设计的数据库系统中，效果还是相当不错的。
下面是几篇今年写的关于数据库相关的文章：
下面还有几篇，也许对你有帮助：
我在2012年中未达到预期的方面：
1：英语能力
由于我们的项目是海外项目，为此会和国外客户进行一些需求方面，技术方面的沟通，但本人英语水平太差，特别是口语，基本是一句也不赶说，当然hi,hello,good by之类也还是勉强能说的，就不多说了，你们明白的。如果我的口语能跟上，也许帮助更大，总之英语学习是个老大难呀。虽然公司后来安排一个英语老师每周给两小时培训口语，但项目太忙大多情况下都没时间去，谈何学习呀。
2：项目管理
我的如下缺点是比较失败的，但尽管自己心知肚明，但实际要想完全避免难度那是相当大呀：
a):性格比较急躁
现在比以前已经好了很多了，但当项目面临工期延后的时候，总会因为一些事和成员急，比如我认为一些不应该出现的错误而被我发现了，特别是一些重复发现的错误。
b):容易按自己的标准去衡量别人
这点其实是很多人的通病，但每个人的情况不一样，技术强项也不一样，如何站在另外一面去考虑问题是比较困难的。
总结：
引用我以前一位总监对我说的话，如果你觉的你的公司还有你想要的东西你就留下来，否则才会去考虑换环境，无论我在公司是架构师还是PM或者是普通一名大头兵，只要公司有你想要的东西而公司也给你这个机会去争取的时候，就应该努力再努力去尝试，尽管不一定成功，但过程是最关键的，起码我努力过。