第三話按照原計劃是要寫寫平常心的，因爲飛躍計劃要交作業，所以就改爲寫自己對項目管理的一些經驗總結，剛好前一段時間那些年我們一起追過的女孩很是流行，這一話的名字就叫做那些年我們一起做過的項目。
我的第一個項目是在2005年，那是一家市場佔有率前三的本地化翻譯公司，公司的信息部門只有兩個人：老大和我，我們一起開發公司內部的協同辦公系統。要解決的問題很簡單：由於公司發展迅速，以前單純依靠紙質單據和郵件分派和追蹤任務已經越來越讓項目經理和財務不堪重負，迫切需要將這些工作給自動化。系統的技術架構也很簡單： jsp+javabean+mysql。沒有專門的開發計劃，基本開發流程是這樣的：每週一我們訪談一個業務部門經理，瞭解他的需求，週中開發，開發中有任何問題都可以直接找業務經理，週五的時候系統上測試環境，再和業務經理坐到一起看一下是否滿足了他的需求。系統就一直這樣不緊不慢的開發着，老闆辦公室就在我們身後，一有時間老闆就會和我們一起使用該系統。整個開發過程只有一個細節讓我印象深刻，就是對任務估算工作量時，不管我估算多少，老大都會給我乘以3，一次要給業務表單增加一個字段，老大問我需要多長時間，我說不就是增加數據庫字段嗎10分鐘，結果老大給了我半天時間，老大說，增加字段確實只需要幾分鐘，但打開編輯器需要時間吧，集中注意力需要時間吧，改完了啓動系統測試需要時間吧，測試完了和業務經理確認需求需要時間吧，我們估算的是完成整個事情的時間而不僅僅是編碼的時間。
這個項目完成時獲得了公司上下的一致好評，從公司老闆到業務經理，每個人都非常滿意，而讓我感到唯一遺憾的卻是身爲IT人員竟然從來都沒有加過班。
回想起來，這個項目之所以成功固然是因爲技術簡單和系統不復雜（我們甚至都不需要 SVN，完全依靠腳本同步代碼），但最重要的還是持續交付和持續的用戶反饋，老闆和業務經理每週都能看到新功能的上線，這增強了他們的信心，同時反饋幾乎每天都在進行，並且他們很快都能看到這是否是他們想要的。
第二個項目在2006年，這一年我換工作了，因爲當時我認爲不加班的程序員不是好程序員。新公司在上地，是一家做協同辦公業務平臺的公司，最開始去的是項目部，一開始很爲業務平臺這個概念着迷，因爲當寫程序時最先不是寫代碼而是用代碼生成器生成代碼，並且生成完的代碼馬上可以運行！第一個項目是豐田公司的銷售管理系統，我們創新的使用了當時最熱的Ajax技術，我們完全是用技術熱情加上週末時間完成對原有功能的 Ajax增強，這個項目獲得了用戶極高的評價，因爲當大多數web系統還在使用點擊 /刷新的方式進行交互時，我們卻可以直接拖拽完成操作了。如果在當時，我會認爲是技術的創新讓項目獲得了成功，但是現在，我會用漸進式增強這個詞，即只有在完成用戶所需要的核心功能（什麼叫核心功能，即缺少這個功能系統不能工作）後纔開始對系統用戶體驗、性能進行漸進式優化。
第三個項目是在公司的平臺部，這裏部門經理正準備對原有的業務平臺進行重寫，原先業務平臺的技術框架是：jsp+struts+ojb+sqlserver，新的技術框架定義爲： ajax+freemarker+webwork+spring+hibernate。這讓我興奮，因爲新的技術框架幾乎是當時最流行的技術。加部門經理共有三個開發人員（所以溝通一直不是問題），老大使用project來管理項目，每個人負責一個模塊，估算以周爲單位，最初計劃是 5個月交付，功能直接就是老平臺的翻版換的只是技術實現，但是 5個月後進行測試和項目試用時卻發現了大量缺陷，最後幾乎用了半年時間纔將缺陷收斂，產品發佈計劃延期半年。回顧這個項目，需求沒有進行詳細的分解和評審導致實現與需求不一致 似乎是項目延期最重要的問題，然而更深的思考卻是我們需不需因爲技術原因開始新產品的開發，在不影響用戶使用的情況下對原業務平臺進行漸進式增強是否更加合適。即我們在啓動項目時更多關注的應該是用戶價值（只有有用戶價值用戶纔會買單公司纔有收益）。
第四個項目是我負責的，這個項目幾乎是上一個項目的翻版，重寫公司的工作流產品：支持更多的工作流模式，更易集成的api和管理界面，唯一不同的是這個項目採用了很多敏捷裏的實踐：持續集成、單元測試、站會、迭代，但這些實踐均不影響這個項目最終的失敗。同樣是該不該重寫這個項目的問題，在公司資金鍊緊張、時間要求緊、新產品相比競品沒有突出特性的情況下，這個項目從一開始就決定了失敗。如果沒有特別充足的理由就不要重寫產品，這幾乎成爲我目前最重要的一條原則，尤其要從公司全局的角度看待產品不能侷限在技術。現在，只要誰一說到要重寫產品，而給出的僅僅是技術原因，我就會兩股加緊，冷汗直流。在對項目完全負責的情況下，我另一點深刻感受就是人的重要性，對團隊中的每個人員，作爲leader 你都需要知道他的需求是什麼，沒有人願意做機器人，在一次對某一技術方案簡單粗暴拍板後，一個核心技術人員流失了，這成了壓垮這個項目的最後一根稻草。
08年底去了一家新公司，新公司採用敏捷實踐。第一個項目很成功，幾乎是敏捷項目的一個成功範例，需求分析、迭代、持續集成、結對、客戶 showcase、持續交付，項目甚至提前半個月完成。唯一美中不足的是項目二期時新團隊由於一期文檔很少帶來了很多困擾。突出的感受是：團隊人員有了角色、有了分工也就有了流程。現在，到了一個新的部門或中心，第一件事情往往就是梳理項目開發流程，定義出每個人的角色，職責不清是互相埋怨之源。
第二個項目是諮詢項目，略去不表。第三個項目是分佈式團隊，一部分團隊在國外，一部分團隊在國內，最開始一切順利，但在上線前一個月遇到了嚴重的性能問題，陷入了一片混亂當中，所有人都不知道我們離上線還有多遠，還有哪些工作需要完成，優先級都是什麼，項目經理甚至自己都失去對整個項目的把控，她不知道項目上線究竟需要滿足什麼條件，於是一次次在等待國外團隊優化後的測試結果，於是一次次的測試結果不滿意，於是項目在一次次的下週二上線的空頭承諾中成了整個公司的笑柄。這個項目回顧起來就是團隊遇到挫折時放棄了計劃，迭代沒有了，故事牆沒有了，所有人都在等待，而項目經理爲了不讓開發人員被公司收回還不得不想一些優先級不高的任務給團隊完成裝着我們很忙。教訓就是，任何情況下都不能放棄計劃，計劃是項目之本。其他包括團隊能不分佈式就不要分佈式，如果必須分佈式那麼一定要從架構開發任務上進行隔離，儘量減少兩個團隊之間的交互（很多項目經理進入到部門之後推進項目制，其實也是同樣的原則，團隊大了就要拆解，產品代碼多了也要模塊化，儘量減少團隊之間、模塊之間的交互，做到能夠各自獨立演進和發佈）。儘早進行實際環境的測試，越早越好。測試越早進行越好，測試環境越貼近產品環境越好，這一原則什麼時候強調都不過分（我們上線前的測試才發現嚴重的性能問題）。
第三個項目是幸運的，因爲他們有錢，能夠等待，在多等待了大半年後系統終於上線。而第四個項目就沒有這麼走運了，這個項目是一個在線 saas CRM系統的重寫，而且有着強時間約束（如果半年不能交付，將錯過該系統客戶每年做預算的窗口期），看吧，又是重寫，又是時間約束，這幾乎總預示着它厄運難逃。表面上看項目是在一次中期的架構重寫中崩潰了，重寫耗去了團隊太多的時間，而由於對未知領域知識的不正確估算（需要學習）再次令項目雪上加霜，項目目標又不能變化，要在六個月後上線，但更深層的原因還是項目開始之前沒有決策正確，真的要重寫產品嗎？老產品確實界面很醜、一些功能沒有，但這些不能漸進式增強進行嗎，一定要重新開始嗎？重寫使用新團隊，他們對該業務領域並沒有經驗，過去系統遇到的坑他們不清楚，他們的計劃因爲少考慮了一些情況是否顯得過於樂觀？這個項目的其他問題包括項目計劃一直沒有發生變化，儘管所有人都認爲在規定日期到來之前不可能交付，但這個日期卻沒有發生變化。最後不得不說這是一個技術強大的團隊，一切都做到了自動化，甚至部署產品環境也是一鍵完成，但是這些在項目目標失敗的情況下顯得黯然失色。而客戶貸款做這個項目則讓很多團隊成員良心不安。
來到騰訊，來到soso，最重要的收穫是對運維有了新的認識，以前曾經認爲devops就是自動化部署，全功能團隊，現在發現它關乎架構：一條搜索的badcase是否能夠很快找出錯誤的原因？是抓取失敗，是索引時丟失，還是相關性排序不好？關乎監控和報警，我們能否很快從監控中定位出原因？關乎組織結構，前臺開發，後臺架構，基礎架構，運維測試團隊都是分離的，如何協作才能使團隊合作的成本最低而整體利益最大化？
回顧往事，保爾柯察金說：如何才能不虛度光陰，只有爲共產主義奮鬥終身；柯景騰說：唯有沈佳宜讓我懷念；而我想說的是：
- 做任何項目之前一定要想清楚爲什麼要做這個項目，一定要想清楚這個項目的價值是對用戶和公司的（尤其需要跳出站到一個比較高的層次看項目），一定要想清楚項目的約束（時間約束、人員約束）,不僅是項目開始之前要想，過程中要不斷回顧；；
- 項目任何時候都必須有計劃，對所有干係人透明；
- 項目一定是持續交付和持續反饋的，不允許黑盒出現；
- 測試和運維一定要儘早介入；
- 從每個團隊成員的角度出發關注所有人的利益實現共贏。