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