又到一年寫總結的時候後。工作這些年，年年雷打不動一篇總結讓初初參加工作的這一天刻在我的腦海中。到現在我已經記不得戀愛紀念日了，卻依然知道在冬天到來的第一天敲下過去一年工作的點點滴滴。
似乎在每個總結開篇都會說，我不是個努力上進的人，太多的隨遇而安讓我的工作起伏並不大。我媽總是在電話裏嘮叨讓我去大城市，進大公司，對此我只能沉默。這篇總結對於那些初出茅廬打算成就一番事業的同學們是個反面教材。另外現在的心境也是工作多年後纔有的，並不合適剛參加工作的同學們，你們看我前幾年的總結比較有共鳴。
今年在工作上有些人事變動，我的工作也有點點轉型。這篇總結分爲個人工作，團隊管理兩方面。
1。個人工作
去年年末，我被分配了一個很棘手的項目。這個模塊要說不工作吧它基本符合設計要求，要說工作吧用的不怎麼順手。我的任務就是把它”調”成用的順手的功能模塊。這個”調”聽起來很簡單，但是一看模塊內部的構造，各個函數間的關係我就傻了，這一”調”可是傷筋動骨阿。很倒黴的是，這種任務如果做好了功勞不是很大，因爲不懂技術的人都覺得是小調整；要是做不好麻煩就大了，本來模塊可以完成功能的。這一改要是引入新的bug不就是做無用功了麼。
對於這種任務除了自認倒黴之外，只能加倍小心了。老話說”不破不立”，我改原有代碼改的噁心了一狠心推倒重來。好在年底時間上沒有那麼緊，完工的質量也還好。
真正進入2010後我的個人工作比較零碎，大部分是基礎的搭建。比如一些設計數據庫，寫公共函數，還有就是在原有設計上面的優化。要說這些東西多考驗一個人的技術我個人認爲還真沒有，但是非常考驗技術人員對於業務流程的熟悉度和對於需求的前瞻能力，這些都是經年累月的經驗積累分不開的。
另外今年佔我個人工作比重非常大的一部分就是寫文檔。我的文檔本來還可以給自己看或者同組人員還都算是清晰明瞭的。但是今年的很多文檔是面對售前和售後的，對於語言結構的要求都高了很多。我需要寫的文檔包括閱讀售前的商業需求，翻譯拓展爲技術需求；在功能實現後寫描述總結類的文檔給售後和售前。本來這個任務不落在我身上的，但是很不幸我遇到了個對產品不熟悉且不給力的經理。於是我光榮的承接了”筆頭子”工程，在不斷的鍛鍊以及被別人咬文嚼字的挑剔後提高了不少。目前雖然還會信心不足，但沒有剛開始那樣慘了。
面對win7 64bit的快速普及以及我們用到的一些軟件的更新換代，我明年的主要任務就是爲我們產品全面更新到.net搭一個比較堅持的基礎。然後帶領團隊對產品進行全面重組升級。也許就是所謂的架構吧。OO思想我是有的，但是架構沒有什麼理論基礎。歡迎各位看官介紹架構類的書籍和工具
2.團隊管理
年初的時候人事變動，我的職責範圍除了開發之外還兼代一個三人小團隊。
我這個三個夥伴都是男人，比我大(最大的已經40好幾了),比我有經驗。面對這三個個性人材，如何確立威信是個難題。最簡單的方式是經理幫我立威信，但是我經理這人初爲領導恨不得把我們幾個組長的管理權都收歸己有根本指不上。
在那幾個月我就覺得自己腹背受敵。組員領了任務就沒了下文，我不說話他們比我還沉默。沒轍，我只能更積極的跟他們更新情況，經常詢問進度，詢問是否需要幫忙，提醒一下他們可能想不到的關聯問題等等。我們每兩週開個進度會議，討論一下”過去時”，”現在時”，”將來時”。聽組員發發牢騷，抱怨一下上面管理鬆散的問題。除此之外還可以把開發上的困難來小組討論一下，在技術上面他們三個經驗豐富經常能給我帶來靈感，受益匪淺。在流程上，他們各有各的習慣但是既然是一個整體就要步調一致，團隊的操作流程在慢慢改進中更符合整體的開發習慣。
大概經歷了3個月吧，在組員面前我算是站住腳了。我們之間的交流，和開發節奏配合的不錯了。我分配的任務，做出的決定可以被理解和接受，出現的問題也可以及時討論。
總結一下做小組長這類費力不討好的工作大概就要秉着”爲人民服務”的宗旨，組員需要的信息我及時提供，遇到的困難及時支援，不理解的事情耐心開解。讓他們覺得可以從我這裏得到理解和支持然後專心致志地投入到代碼的汪洋大海中去。我覺得我是幸運的因爲我所付出的這些，他們也在回報給我。比如我們提的建議需要寫報告去彙報，我寫好後組員都會認真閱讀並補充自己的意見，讓報告更容易被通過等等。現在我們是一個合作愉快，高效運轉的開發小組。
對我來說有個不給力的經理最大的困擾就是信息流到他那裏就斷了，需要傳遞給其他部門的信息傳不出去；需要的需求和反饋到不了我們這裏。爲此在年初的幾個月我經常和另一個組長互相發牢騷(我們經理手下就三個組長). 那段時間我覺得我就是個被負面情緒吹起來的氣球，直到有一天氣球爆炸了。我看到天高雲擴，老天給我這麼好的鍛鍊機會就被這些負面情緒攪得看不清未來。我咬牙跺腳調整工作態度。
既然經理不給力，咱自己發力吧。於是我開始直接給售前寫郵件，當然這些都郵件都要抄送經理一份，不然在他心裏該留下陰影了。和售前接上頭才發現他們那邊也着急，因爲客戶也不知道自己要什麼，貪心的客戶恨不得我們的系統一上馬他們那馬上就裁員一半。這，怎麼可能呢。售前那裏傳來的需求就好像高考的考綱一樣簡練，我就是日讀千遍也讀不出個鳥來。只能按照自己的理解結合對產品和客戶的熟悉程度一點點把大的需求切割劃分成小的可操作的需求，然後做成樣品，寫好報告反饋給售前。那段時間每週四不管自己陷在代碼裏面多深都得把自己拔出來閱讀”考綱”，主謂賓，定狀補的分析客戶隱藏在短短詞句背後的意圖。每週五都是一週 “成果展示”，把進度預測等等寫好發到售前。很長一段時間我的工作是正常工作時間內寫代碼配合其他組員完成任務，加班時間寫文檔。有的時候郵件發到售前那邊石沉大海，那隻能再下一週發郵件的時候提一下，要是還沒回音就打電話過去，跟個催命大媽一樣。要說一下我們售前是兩個大哥也是剛加入對於產品瞭解不足，有的時候我寫了一堆報告配上屏幕截圖他們都不一定能徹底明白，只能通過電話，遠程等等手段。這種情況在我們不斷的改進交流方式下慢慢變得好起來了。幸運的是我對於”考綱”的理解和判斷在大多數情況下還算準確，沒有返工的情況發生。
通過種種我覺得作技術的和非技術人員說的不是一套語言，我們拿一個需求看到的就是類，模塊，函數等等扒皮剔骨的分析，他們看到的更是業務流程，增值效益等等有血有肉的活動體。後來我就去學習了一下工程管理，脫離技術層面的籠統的工程管理，比如工程週期，工程進度，資源分配等等。這些雖然和我的日常工作聯繫不大，但是跟非技術人員打交道上面幫助還是非常大的。因爲我能夠更加理解在一個軟件產品或者解決方案中他們關注的信息是什麼，我們作爲技術人員用什麼方式傳達這些信息才更有效。
這樣說太籠統了，舉個例子比如某個功能的改進，在這個改進未實施的時候作爲技術部門我們一般都會說技術上可以實現，希望瞭解到這個改進具體在哪些方面幫助到客戶那些哪些操作流程。然後闡述一下這個改進在可執行上面大概的預算(人力+時間)，預計什麼困難。最終以什麼形式呈現在客戶面前，同樣的改進是否在其他相關功能上實現，如果出現困難我們需要什麼樣的後備方案等等。這些還可以進入到很多深入討論。
今年可算是我工作以來最糾結的年頭了，在尋找有效溝通方式上我不斷嘗試新的方法，有意識的根據不同的人說不同的話。再不是當初剛參加工作那個隨性而爲的小丫頭了。參加很多的會議，跟不同的人打交道讓我看到了職場上那些微妙的關係。見識了部門間表面合作實則互相推諉，見識了跟上面大包大攬反過頭壓榨自己員工的領導，見識了見好處就上見困難就躲的虛僞。我也更加小心翼翼的保護好自己(估計還是沒保護好我還是太直率)和我的小組。這一年我也妥協了很多，有的時候雖然不是自己的責任但是如果自己多做一點可以給整個團隊帶來更多的利益我也會犧牲自己的時間去做。不會爲一些事情爭論而是相對平心靜氣的尋找一種平衡利益的解決方法。也許這就叫做成熟吧。
雖然這些種種寫下來就讓觀者覺得好多無奈，但置身其中調整好心態，把每一個無奈都當作一個考驗；把別人的不作爲當作鍛鍊自己的機會；把和每一個人溝通當作一種積極的嘗試。工作還是挺美好的，更何況我有那麼有趣的同事一起戰鬥。
工作之外，我今年的生活算是最平淡得了吧。單位和家兩點一線，還沒去過太遠的地方。沒買過什麼大件商品
今年冬天去趟西藏，圓我一個小小的願望(12月23—30在西藏，求被揀，站短聯繫)
最後還是那句話
低頭做事，擡頭做人
過幸福的小日子 :)
