四年前我寫過一篇文章：我的第一份外包經歷及所得，四年后的今天再次到了寫年終總結的時候了，巧合的是兩個年份都是做外包。最近幾年寫博客的時間比剛開始工作時少了不少，但依然在堅持，因為我喜歡通過總結來學習。
這是我第二份外包工作，其實第一份外包呢，說實在的做的時間並不長，當時被安排到一家電子商務公司做項目，半年時間后我也就回原公司了，合同到期了。當時本來是有機會直接應聘到客戶公司的，因為客戶公司有個習慣，就是如果覺的外包過來的員工做的還不錯就從外包公司給買過來，招成自己的正式員工，當時也是運氣不太好，大家都知道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或者是普通一名大頭兵，只要公司有你想要的東西而公司也給你這個機會去爭取的時候，就應該努力再努力去嘗試，盡管不一定成功，但過程是最關鍵的，起碼我努力過。