最后期限（Deadline）是軟件從業人員必須面臨的最大困難與挑戰，準確地說，它是所有程序員包括項目管理者的可怕夢魘。當堂吉珂德看到郊野之上的數十架風車，風車的翅翼如巨人的胳膊，正耀武揚威地奚落著這位中世紀后期沒落的騎士時，堂吉珂德如勇敢的斗士一般，躍馬而上，用長槍狠狠地刺向風車，換來的卻是長槍折斷，人仰馬翻，最后大敗而歸。沒錯，最后期限之于程序員，正如風車之于堂吉珂德，確實是太強大以至于無法戰勝。

　　那么，我們真的要知其不可為而為之嗎？就像孟子老夫子說的那般，雖千萬人吾往矣！雖然充滿了風蕭蕭兮易水寒的悲壯，但鎩羽而歸的感覺，無疑會一次次挫敗程序員的信心。更重要的是，IPO變成了負值，投資方是否還能夠將項目交付與你呢？

　　風車看起來是不可戰勝的，但如果善于分析風車的關鍵，找到其“罩門”，也未始沒有擊破的可能。例如，我們可以找到風車的樞紐部分，擊破一點即可使其全線瓦解。有時候，最后期限真的是貌似強大，但若能仔細分析，認真對待，也未嘗不可突破壁壘，找到制勝之道。

　　我曾經參與過多個項目的開發和管理工作，坦白說，最后期限總是如內心的毒蛇一般盤繞，始終是揮之不去的陰影。在客戶的聲聲催促中，就像是聽到了定時炸彈最后計時的“嘀嘀”聲。明知炸彈就要爆炸，自己卻無能為力，這樣的感覺令人沮喪。我的一個長處是善于從失敗中挖掘教訓，所謂“亡羊補牢猶未晚”，即使這個項目失敗了，至少在下一次項目中還存在成功的可能。總結下來，大約有如下幾點可以用來對付“最后期限”。

　　1、與客戶協商最后期限。聽起來是一個笑話，如果最后期限可以協商，就不成其為最后期限了。然而，固執的管理者們，為何要未戰而退，卻不嘗試一下可能會出現的萬分之一機會呢？當你充滿絕然的勇氣與神情去面對客戶，以專家的口吻斬釘截鐵地說道：“沒錯，按照您規定的最后期限，我們絕對能夠完成您的要求。只可惜我們卻沒有充分測試的時間。您是否愿意給出測試的時間，這樣我們就能夠交付一件讓您絕對滿意的高質量產品了。”或許你得到的是斷然的回絕，然而如果你能夠合理有效地與客戶協商，仍有回旋妥協的余地。前提是，當你在向客戶倒苦水的時候，千萬不要說產品在最后期限之前無法完成。因為這個最后期限往往是你的市場代表為了拿到項目而做出的一次妥協決定。如果你否決了這一期限，會讓客戶懷疑你所在公司的誠意與能力。關鍵是質量！因為對于客戶而言，時間固然是一個決定因素，但高質量的產品才是最后的關鍵。嘗試與客戶協商，或許你會沖破最后期限的壁壘，看到海闊天空，呼吸一口新鮮空氣。

　　2、與客戶協商功能要點。如果不能從時間上做文章，那么就另辟蹊徑，在功能上奪回你失守的陣地吧。功能總是有輕重之分的，將那些可有可無，或者是客戶不太關注的功能砍去，就等同于你爭取到了更長的時間。想想那些已經投入使用的產品吧，例如微軟的Word。我們可以做一下調查，世界上的所有Word用戶，有多少人全部使用過Word 的所有功能？或者我們從使用概率來分析，產品中還有哪些使用概率不超過30%的非關鍵功能點？找到這些功能點，打印一個清單，然后鼓動你的如簧之舌去與客戶談判吧。或許，你能得到一個理想的結果。

　　不幸的是，你碰到了一個極其頑固的老古董客戶，就像那些整日呆在辦公室里無所事事，卻有著鷹隼一般銳利的目光，專以折磨人為樂的奴隸主監工一般。他們不會聽取你的友好協商，而會像孩子一般，關閉上兩只耳朵，只是抱著手里的玩具使勁搖頭，即使你遞給他的玩具可能會更漂亮更好玩，他仍然會固執地抓住自己的玩具死死不放。現實世界中，我們總會碰到這種情況，我們會在客戶那里碰得頭破血流。那么，我們該怎么辦？

　　讓我們從開發過程中尋找答案吧。唐柳宗元道：“苛政猛于虎”，我們常常會畏“最后期限”如虎，然而殊不知錯誤的開發過程或方法有時候會比這條“虎”更為兇猛！此外，我們還可以從計劃執行、任務安排、團隊合作等諸多方面找到可以擠出來的時間。這個時候，項目管理者必須像葛朗臺老頭一般，精打細算，珍惜每分鐘項目時間的運用。然而，項目管理者絕對不能因為時間緊促，而像周扒皮那樣半夜學雞叫，讓團隊成員加班加點，像牲口一般的對待。偶爾為之，或許無傷大雅，然而每日都如此，那么只能說明這個項目已經到頭了，趕緊準備失敗的毒藥吧。因此，我們要做到：
　　1、合理裁減開發過程。在項目管理過程中，必須執行相應的開發流程，例如計劃評審、同行評審、階段評審等。此外，QA會拿著眾多檢查點，每日走查項目組是否在質量保證方面存在缺陷。因此，在項目周期緊張的情況之下，項目管理者與QA就必須針對項目的實際情況，合理地裁減開發過程，省去一些不必要的官僚會議以及QA檢查的表面文章。同時，隨之而來的利益則是大量工件，尤其是文檔的減少。如果能夠讓開發人員能夠從文山會海中解脫出來，謝天謝地，他會成為項目開發的急先鋒。要知道，世界上所有的程序員都在為文檔的編撰而苦惱。減少文檔不等于說不寫文檔，即使是敏捷開發，注重代碼與可工作的產品勝過完整的文檔，仍然不會忽略基本文檔的編寫。雖然在對需求和設計進行分析期間，我們可以考慮用面對面交談的方式，或者在白板上寫下我們的設計方案，但為了項目沉淀或者產品維護與重構，以及考慮成員變化等種種因素，文檔的編寫仍然是項目開發中不可缺失的重要環節。關鍵是編寫文檔的“度”。敏捷的布道者Alistair Cockburn在其書《敏捷軟件開發》中寫道：“團隊成員應當在為將來的使用而超支的成本與未來文檔不足的風險之間進行平衡。找到兩者之間的平衡點是一門藝術……”我對那種形而上學的開發過程管理深惡痛絕。為了通過階段評審，我們必須要騰出時間來編寫階段評審文檔，然后請來那些大多數尸位素餐的評審委員會專家，然后不痛不癢地提出幾個缺陷或錯誤，最后一團和氣的結束會議。顯然，這是一種官僚思想，是集體的資源浪費。即使為了某些辦公室政治考慮，那么項目經理也應該像牧羊犬那樣，保護自己的團隊成員免受這方面的干擾，就像Scrum所要求的那樣。

　　2、合理的設定功能優先級，并以此制定開發計劃。這里我們可以玩弄一個花招，即使我們無法在客戶那里尋求到裁減功能的支持，但我們仍然可以在功能優先級方面大作文章。例如將客戶要求的優先級高的功能，以及技術實現必須的高優先級功能先行實現，那么，到了最后期限來臨之際，即使我們還有一大堆低優先級的功能未曾實現，但由于客戶最關心的功能點能夠高質量地運行，最后的產品雖然沒有完全滿足客戶的需求，但憑借著優先級的合理劃分，也可以讓我們在后面的商務談判中占據先機。此外，我們還可以信誓旦旦地向客戶承諾，我們會在交付產品之后，繼續完成剩下的功能。客戶是否完全滿意，誰知道呢？但至少我們交付了產品！以己之見，雖然這個產品不夠全面，但總比交付一個全面的產品，卻錯誤頻現要來得好。

　　3、提高會議效率。無論是傳統的軟件開發方法，還是敏捷方法，在軟件開發過程中，不可避免要召開各種各樣的會議。畢竟軟件是人開發的，而且是組成一個團隊的人開發的，因而交流成為必然。我并不反對召開這樣的會議，相反，我很樂于參加這樣的會議，因為這樣可以讓我的口才在全體同僚面前得到充分地展示。然而，會有多少的寶貴時間淹沒在這樣的夸夸其談，或者口沫橫飛之中啊！與其要求團隊成員加班加點，還不如提高會議效率。我很認同Scrum對于會議時間的明確規定。例如Sprint的計劃會議保持在4個小時，而評審會議和回顧會議則保持在2個小時左右。至于 Scrum的每日例會，更是短小精悍，只有15分鐘。是誰發明了“站立會議”這個名詞呢？發明者完全就是一位天才！改傳統的枯坐會議為站立會議，就可以收住那些夸夸其談、口若懸河的家伙了。在我的一個團隊里，就有這樣一個家伙，總是啰里啰唆，講了半天也說不到重點。我每次看到他要發言，我就有頭暈的感覺，甚至有一種沖動，想用膠布封住他的嘴。不過，在我主持會議的時候，我常常發現會議成員看我的眼神，有幾分熟悉。會議之后仔細思考，發現他們看我的眼神，和我看那個家伙的眼神竟然驚人的一致！Larry L. Constantine在《人件集》的“因地制宜”篇中寫道：“如果想要團隊工作獲得最大成功，會議的主持人和記錄者都應該以局外人的身份參加討論會。……作為整個團隊的最高負責人，項目領導者應該積極參與團隊中的討論和工作，而不是對工作指手畫腳。……會議應該是在一種中立的氣氛下進行。……另一方面，……陷入無休止的爭論中，這時候，最好由項目領導出面中止爭論，暫時地放開當前的話題，或者很偶爾的，如果話題已經進入了死鎖狀態，那么就由領導做出一個仲裁。”

　　4、合理安排人手。通常在我們面臨最后期限的壓力時，第一想到的是加班，然后閃入腦海中的念頭則是增加人手。加班策略素來為我所唾棄。以每人每日的生產效率來看，雖然加班可以延長工作時間，但長期的過度疲勞必然會降低生產效率，如此以時間換來低下的效率與團隊成員的抱怨，完全得不償失。在長期積怨的情況之下，開發人員會產生一種破罐子破摔的思想，心里認為反正都要加班，那么在正常上班情況下，反而會“磨洋工”，敷衍搪塞項目經理安排的工作。那么增加人手呢？且不說這會增加項目成本，我們還要考慮團隊的新兵需要多長時間才能上戰場？業務培訓、團隊磨合是新增成員必然存在的兩大痼疾。如果沒有處理好這兩個問題，不僅不能提高開發進度，反而會有拖慢或者打亂原有開發節奏的危險。另外，如果添加的新手不幸是一個刺頭或者“害群之馬” 呢？需要明確的是，往往在項目經理提出增加人手的情況下，項目經理并沒有親自挑選新成員的權利。這些新成員要么是閑置的，要么是其他團隊轉過來的，要么是新招聘的。考慮前面兩種情況，你覺得這樣的成員能夠達到及格乃至于優秀的幾率會有多大呢？如果是新招聘的，那么拜托，趕快在心里多念幾遍“菩薩保佑”吧。總體而言，如果項目經理沒有挑選新成員的權利，最佳的選擇是非到萬不得已不要添加成員。所謂“萬不得已”，即是無論如何改進，如何協商，如何提高效率，都無法達成既定目標的情況。

　　兵貴在精而不在于多。關鍵在于知人善用，以及合理調度。一個項目經理在組建自己的團隊時，必須要了解自己成員的人格特點與技術特點。在理想狀態下，如果項目經理具有挑選成員的權利，會具有更大的成功率。如果項目過大，那么必須建立層級式的組織架構，而在劃分出的各個小組中，卻應該以扁平的平等架構為最佳。這樣就能夠自由而不失于集中，平等而又不至于缺乏效力。當然，具體的組織架構應依據企業文化、產品性質、開發規模、團隊成員特點等各個因素綜合考慮，不能死搬硬套。在安排人手時，要注意對技能型人才和管理型人才的使用，注意對領域專家和系統架構師的使用，注意對開發人員和測試人員的使用，注意對編檔人員、 QA、配置管理員的使用。此外，還需要養成從容不迫的心理，即使最終期限火燒眉毛，迫在眉睫，仍然要保證對架構的設計、對編碼的測試以及合理考慮產品性能、可用性和產品質量。

　　5、開發環境的保護與基礎設施的維護。兵家云：天時、地利、人和。沒有一個好的開發環境，很難想象開發人員能夠高效率的工作。開發環境必須是相對獨立，又利于交流與溝通的工作室。具體的說，項目組的工作環境必須拒絕項目無關人員的干擾與破壞，但卻無阻于項目成員，特別是同一小組成員的交流。此外，會議室的數量非常重要。我在管理一個項目時，竟然常常為尋找會議室而東奔西走，將大量的時間浪費在會議準備上。此外，服務器、客戶機、網絡、打印機、白板、卡片，以及開發工具和軟件，例如IDE開發環境、版本控制工具、Bug管理工具等，都需要在團隊建立之初就要準備好。對于計算機、網絡和相關工具，則必須保證在項目開發期間的穩定性、暢通性。我曾經在項目開發中，因為網絡中斷、病毒侵襲以及服務器壞掉從而破壞了 SVN的版本管理等諸多突發事件，讓我在本來就緊張的開發時間里，犧牲了不低于三天的時間，真是讓我抓狂不已！所以說，一個好的網絡管理中心、一個好的配置管理員，在關鍵時刻，可以抵得上半打高效的開發人員呢。如果你在項目開發過程中，頻繁遭遇這樣的問題，我的忠告是，趕緊準備換一家公司吧。

　　6、合理控制需求變更。需求變更是軟件開發必然遭遇的暴風雪，也是導致“沒有銀彈”的淵藪。傳統的瀑布開發模型在項目后期遭遇需求變更時，只能束手無策，但RUP與敏捷方法卻能夠坦然面對需求的變更，Kent Beck甚至在敏捷開發中提出了擁抱變化，真是足夠勇敢與足夠信心的宣言啊！在軟件開發中，若要應對軟件開發，一般的做法是合理設計，以求系統與架構具有足夠的可擴展性；其次則是采用迭代的開發方式，通過定期甚至是短周期地交付可工作的產品，以印證需求與實現是否一致。同時，在項目中通過引入客戶的積極參與，使得項目組與客戶的交流能夠暢通無阻，從而避免因為隔閡而導致需求分析產生的誤差，以及需求變更無法及時提出。此外，利用原型快速開發方式，可以盡快地交付一個無具體實現的產品框架或原型，以驗證業務規則、業務流程以及客戶對GUI的要求。然而，需求變更絕對不能無休止地進行，這會導致迭代的永無眠日。即使是敏捷開發，我們仍然要設定客戶委托事項的基本線，一旦超出這一基本線，變更委員會（CCB）或其他擔負這一職責的角色就必須提出異議，與客戶協商或探討這種變更是否是必須的。控制需求變更的一個實踐是，獲得客戶對分析出來的功能點的書面確認。雖然在發生變更時，客戶的意見甚至可以無視這種書面文章，但至少可以在與客戶的談判中搶得先機。根據Mark Lines所說，通過變更控制的增強還可以降低項目風險。確實如此，在與客戶談判中，我們要學會說出“拒絕”兩個字。當然，在對需求變更做出決定性意見之前，必須分析判斷這樣的變更是否合理，是否必要，或者優先級高。一種折中的辦法則是，欣然承諾此次變更，但需要延遲最后期限，或者放在下一次版本迭代之后。

　　7、預先評估風險。風險無處不在。Cockburn將軟件開發形容為攀巖或者穿越沼澤，已經充分說明了軟件開發過程中的風險。孫子兵法云：夫未戰而廟算勝者，得算多也；未戰而廟算不勝者，得算少也。先預先著失敗的可能，方能夠謹慎地做好各種準備，考慮各種風險以及驅避措施，方能夠最大可能地取得勝利。軟件開發的風險有很多，其中至關重要的是進度風險、技術風險、需求變更風險、成員變動風險。

　　軟件是可以度量的嗎？看起來是，因為已經有了很多方法來完成軟件的度量。從控制學的理論來看，你無法控制那些你無法度量的。因而軟件度量對于控制軟件開發而言，就成為了關鍵。軟件度量甚至因此成為了一門學問。然而，我可以肯定地說，軟件的度量不可能準確，尤其是對進度的把握而言。即使一個項目的開發周期看起來是如此的充裕，以至于感受不到最后期限的壓力，我們仍然要對軟件進度的控制采取如坐針氈的謹慎態度，即使這樣在某些人的眼中，我成為了持懷疑論者，或者悲觀主義者，我仍然愿意背著這樣的名身惡意地懷疑項目時間不夠。原因有二。其一是我們的工作量估算無法做到精確，即使是經驗豐富的天才程序員，在估算項目的整體工作量時，都會出現偏差。是的，我們采用了分而治之的方式，對功能進行分解，從最小單元來評估工作量。但我們無法估算各個功能單元之間存在的各種顯式和隱式關系，以及各種非功能性需求帶給項目的影響。其二，我們無法事先完全預知開發過程中的各種風險。我們得為這種風險買上一份保險，這樣才不至于在風險真正產生時要我們自己來買單，或者追悔莫及。

　　關于技術風險，最佳方式莫過于事先進行技術預演。不要揣測，或者從理論上去推導。在這個過程中，我們可以應用經驗，但最保險的方式還是對系統中的核心問題以及關鍵問題進行研究，創建技術原型。它才是規避技術風險的定心丸。

　　成員變動風險是最難以預知的，因為人是最難以通過數據分析得出正確結論的動物。人的心理太復雜了，因此在軟件業中還專門誕生了“人件（Peopleware）”這門學問。在我們進行項目開發過程中，誰知道有多少人會因為各種各樣的因素，而萌生去意呢？此外，正所謂“人有旦夕禍福”，我們總不能預測哪些成員會在開發過程中生病或者失戀吧？若要解決這個問題，一個辦法是“結對編程”。雖然提出這一方法的目的并不是為了應對成員變動的風險，但事實上這種互相協作的方式確實能夠將成員離開所造成的損失降到最低。以我的經驗，要發生那種編程開發的一對都離開項目的情形，實在是少之又少。還有一種辦法則是Constantine提出的“交叉培訓”。在其《人件集》的《穩步提升的質量》一篇中，他提出“將交叉培訓納入項目的組織形式中，……是最有效、最有影響的辦法之一。這種方法同時也增加了工作透明度。通過增加團隊中面對面工作的機會，團隊成員間自然也就增加了相互學習的機會”。此外，他還提出 “在團隊中進行軟件開發角色輪循，也為成員增加了實踐的機會，可以幫助大家掌握更多的技巧和知識。”這里固然在說培訓，但它帶來的結果是讓團隊中各個成員都能夠了解彼此的工作，這就能夠彌補因為某些成員離開項目帶來的空白。

　　這里同樣牽扯出一個話題，就是關于團隊的培訓。我的理解是，即使最后期限泰山壓頂，也千萬不要節省團隊培訓的時間，除非你的團隊已經熟悉了項目開發的所有領域知識，以及解決領域問題的所有技術知識，同時，這個團隊已經固定不變的合作過三個項目以上，因而團隊成員已經達到了一個微小動作就能夠心領神會的境界。有這樣的團隊么？或許有，不過我還沒有看見。