初六的早晨，剛從老家回來，坐在出租屋的陽臺上，陽光燦爛，竟然是北京難得的好天氣。距離上次寫年終總結已經過去好久，打開博客，發現上次寫年終總結已經是四年前的事情。上次寫總結的時候還是在東直門溫暖的辦公室裏，隨着年齡的增長，覺得時間過得越來越快，四年時間，發生了太多太多的事情：有小孩了，換工作了，最重要的，是三十了。三十，意味着很多事情，古人說，三十而立，對我來說，更重要的是有了更多的責任，不僅僅是家庭，工作也如是。
年初負責的第一個項目是配置管理組的運維自動化項目，簡單的說就是將之前手工管理的20多臺機器使用puppet管理起來。想一想，命運真是諷刺，就在一年前，在上一家公司，自己還對持續集成工具不太感冒，不願去學，甚至認爲有些太難：機器環境的管理、構建工具、jenkins、puppet/chef、shell，覺得這些東西太瑣碎，一心只想寫代碼。換了工作，陰差陽錯，先到配置管理組工作一段時間，必須學習這些東西，過程就不多說了，只有一個感悟：很多時候，你覺得太難，只是因爲你不瞭解它。用了兩週時間，將整個puppet環境搭建起來，一切皆SVN，一切皆代碼。
接下來的第二個項目是負責調研搜索新架構的自動化發佈方案，這是跨部門的合作項目，大大小小跨越20多個項目組，這其中還包括了運維同事、測試同事和雲計算基礎服務的同事，調研一禮拜，實際上事前準備了很長時間，僅僅那一週的調研計劃就修改了四版，系統整理了整個新架構的架構方式，和對方領導達成一致，取得他們的支持，瞭解大家的期望：開發同事希望能夠更快更有效率的發佈代碼，測試同事希望測試的代碼與發佈的代碼同源，運維同事希望發佈過程能夠遵從規範可控，當大家對共同的目標達成一致時，方案就順理成章了：持續集成服務器負責一鍵編譯測試打包上傳到包服務器，包服務器保存所有的預發佈包，預發佈包經過測試後才轉爲發佈包，發佈包透過發佈系統一鍵推送到Torca集羣調度系統，Torca完成最終集羣的發佈調度。相比老架構，感覺新架構最明顯的提升是：下載、索引和檢索三大模塊被分離成各自獨立的服務，獨立演進；統一的數據管理平臺，以前追蹤badcase很難判定是哪個模塊處理數據出了問題，現在透過數據管理平臺，數據處理過程被可視化可追蹤；統一的腳本執行系統，所有腳本以及執行過程透明可視化；雲計算平臺，XFS文件系統、Xcube數據庫、Torca集羣調度、mapreduce並行計算，這些服務大大簡化了上層應用的開發。越來越體會到架構的本質：隨着系統的演進，我們需要不斷進行系統的分解，做到服務的獨立演化。當然當時也有困惑：當所有的希望都被壓在新架構身上，畢其功於一役，現網老架構停止開發運營時，項目的風險可想而知。做完這個項目，感悟有兩個：一是機會只青睞有準備的人；二是跨部門溝通一定要找到共同的利益點，一定要多換位思考。
4月份，準備調回項目管理組，去雲計算基礎架構部做項目經理。在配置管理組的最後一個項目是Jenkins的報表系統，只有一週半時間，最開始準備使用scala，考慮到後續維護最後使用了java，好久沒有編碼了，找回久違的感覺：打印出IDE的快捷鍵，搭建開發環境、測試環境和產品環境，jenkins一鍵自動部署，數據庫版本管理，TDD，一週半的時間就上線第一個版本，最後還不得不讚一下jenkins的rest api。感悟是：感謝一期開發時間只有一週半，這使得我們不斷思考到底我們要做些什麼，哪些是我們最緊急最需要的，哪些是錦上添花的，一期上線後，唯一也是最大的好處就是：我們再也不用手動統計和發送構建週報了，每個禮拜一再也不用那麼忙碌了。時間盒，很重要。
終於轉回了項目經理，去雲計算，牛人聚集的地方。首先仍舊是補課：計算機原理、Linux系統編程、C++ primer，一個都不能少。去了沒多久，出現了一起事故：搜索模塊對雲計算SDK的依賴是源代碼依賴，雲計算有5個產品，但是一個產品單獨發佈時與之前的SDK不兼容，一發布就直接導致了大量搜索模塊的無法編譯。正好由我負責來推動解決這個問題，立了一個發佈流程規範化項目：通過規範化發佈流程、增加自動化集成測試，減少雲計算平臺的發佈風險。所有SDK統一打基線發佈，發佈前必須進行自動化集成測試，server發佈時也要與所有SDK版本進行兼容性測試。隨着項目的進行，逐漸融入了這個部門：這是一個工程師文化非常強烈的部門，所有人都在技術上追求卓越，加班到10點以後是非常常見的事情，單元測試覆蓋率令人驚訝的全部達到85%，但是很多同事一聽到規範和流程就頭疼，項目計劃也是比較隨意，延期比較常見，另外因爲之前發佈版本升級比較隨意，也會經常受到上游兄弟部門的投訴，有很多次出現問題，兄弟部門抱怨雲計算平臺不穩定，而仔細檢查後發現很多時候是使用的方式不對，比如查找文件時使用了遍歷。逐漸意識到，部門最大的問題其實是缺少產品運營，大家的關注點全部集中在產品本身上（吞吐量、最大存放文件數、強一致性），或多或少的忽略了用戶。5月下旬，風神項目啓動，項目目標是搭建臺風統一的監控平臺和自動化部署框架，打造一站式的颱風服務。開始在項目中引入項目管理的實踐，WBS是最基本的了，迭代計劃找到開發節奏、回顧、每個迭代結束後都努力向線上發佈版本，實現持續交付，工程上則將開發環境與線上環境進行了隔離。效果都還不錯，但思考更多的還是，我們還應該做些什麼。產品發佈規範化，必須通過自動兼容性測試和周知用戶；集羣環境的修改必須可被審計，暫時不能自動化，那麼先必須周知部門內同事或結對操作；監控有風神項目，但集羣運營、用戶數據、可用率日報也需要發送；開發、測試和線上環境互相隔離；定期和用戶進行主動溝通，瞭解他們的問題。這段經歷的感悟很簡單：產品的核心在於運營，作爲服務部門，我們交付的一定是用戶滿意度而不是產品。
緊跟着，新架構還未上線，組織結構調整來了，喜歡ls的直率：我現在的任務很簡單，就是看到哪裏有山頭就把它給平了，所有人都必須聽我的，所有人的思路必須一致。
在敏捷中國大會發表了演講《百年曆史看管理》，這個session足足準備了2個月時間，重新思考了流程、組織結構和人之間的關係。從20世紀初到40年代，管理科學完成了從無到有的第一個階段發展，這個階段最重要的成就就是將管理作爲一門科學建立起來，發現了管理的三要素：工作流程、組織結構和人，並振聾發聵的告訴所有人：管理是可以學習的。我們可以看到，所謂管理，都不過是在流程、組織結構和人這三者之中進行權衡調節，管理沒有固定模式，只有不同企業根據不同情況在這三者間權衡裁剪罷了。如果說管理科學的第一個階段是在探討如何正確的做事，如何提高工作的效率，那麼50到60年代這二十年管理科學的第二個階段則是在探討如何做正確的事：以顧客爲中心、做事之前一定要想清楚做事的目的。管理至此也終於有了一個完整的定義：做正確的事、正確的做事。從70年代開始，管理科學進入第三個發展階段，在這個階段，首先提出的思想就是沒有銀彈，管理是一門藝術需要柔性，接下來就是流程的內涵開始延伸，不再是單純的工作流程，而是面向顧客，強調端到端滿足顧客需求的整個過程，這個過程在全球化背景下越來越強調企業之間的協調、強調整個面向交付生態系統的協調，業務流程的概念被提出。進入新世紀，不管是更合理組織結構的思考（扁平化），還是對人的推崇（喬布斯、創新）抑或是業務流程效率的競爭（供應鏈），都明白無誤的告訴我們：管理只有恆久的問題，沒有終結的答案。
9月份調整到新的部門：搜搜問問。先負責的是後臺組的項目管理。新團隊，老人只有一個，士氣低下，缺少文檔，上百個服務，光維護就非常困難，重寫計劃。從回顧會議開始，持續改進。這段時間的感悟是：提升團隊士氣的最好方式就是幫助大家成功，任何一點成績都值得鼓勵。我們引入了持續集成和自動化發佈，鼓勵同事做總結和分享；引入了自動化測試，鼓勵同事做彙報，幫助review ppt；積極的讓大家做有態度的程序員，對產品進行思考和反饋，把團隊精神傳遞到部門經理，讓部門經理進行鼓勵。可以自豪的說，後臺組是現在問問最有戰鬥力的團隊。還有一點最重要的感悟是：一定是團隊leader決定團隊是否給力，幸運的是，我們有一個非常優秀的leader。
12月份開始負責部門的社區化運營項目。這和今年工作的感悟是一致的，產品的核心在於運營，這正是我想做的。項目立項一定要有一個NB的名字，我們就叫黑暗騎士。這個項目同樣面對很多的挑戰，目前最大的挑戰還是在於人，團隊的信心目前還沒有建立，年後可能還會有人提出離職，而招人又是如此的困難，所以，上班第二天的第一件事是回顧會議。團隊年前第一個版本發的很有挫折感，需求反覆修改，開發人員都心灰意冷，所以，感悟是：一份優秀的需求文檔是一切合理計劃的起點。
1月份組織了技術中心的部門年會節目，我們原創的小品《非問勿擾》獲得了二等獎。把新人都變爲主角，這也算團隊建設的一部分。
依然在不停思考，對問問來說，我們還應該做些什麼。傳統問答模式作爲搜索引擎的補充是否已經走到了盡頭？SNS的問答模式是否值得探索？與微博是否有更深的整合方式，或者，它們本身就是一種產品的兩種展現方式？新浪微什麼的探索是否還不夠大膽？在移動端，獨立的app沒有前景，如何和微信更有力的結合。
終於到了可以結尾的段落，還有一件事情似乎忘了總結，那就是我們寫了長達四年的那本書《流程的永恆之道-一個工作流和BPM項目的實戰》，什麼也不說了，一個例子來說明爲什麼值得期待：當我們把房管局及各委辦局的數據和流程用BPM全部打通後，客戶卻依舊堅持要手動蓋章走人工流程，BPM實施技術根本就不是瓶頸，瓶頸依舊是人啊。今年上半年一定出版。之所以寫了四年，是因爲寫着寫着總覺得知道的越來越不夠，不斷讀書和補充內容，真是，那時年少，無知者無畏，唉。
2013，黑暗騎士崛起！