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

那么，我們真的要知其不可為而為之嗎？像孟子老夫子說的那般，雖千萬人吾往矣！雖然充滿了風(fēng)蕭蕭兮易水寒的悲壯，但鎩羽而歸的感覺，無疑會一次次挫敗程序員的信心。更重要的是，IPO變成了負值，投資方是否還能夠?qū)㈨椖拷桓杜c你呢？

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

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

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

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

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

讓我們從開發(fā)過程中尋找答案吧!唐柳宗元道：“苛政猛于虎”，我們常常會畏“后期限”如虎，然而殊不知錯誤的開發(fā)過程或方法有時候會比這條“虎”更為兇猛！此外，我們還可以從計劃執(zhí)行、任務(wù)安排、團隊合作等諸多方面找到可以擠出來的時間。這個時候，項目管理者必須像葛朗臺老頭一般，精打細算，珍惜每分鐘項目時間的運用。然而，項目管理者不能因為時間緊促，而像周扒皮那樣半夜學(xué)雞叫，讓團隊成員加班加點，像牲口一般的對待。偶爾為之，或許無傷大雅，然而每日都如此，那么只能說明這個項目已經(jīng)到頭了，趕緊準備失敗的毒藥吧。因此，我們要做到：

1、合理裁減開發(fā)過程。在項目管理過程中，必須執(zhí)行相應(yīng)的開發(fā)流程，例如計劃評審、同行評審、階段評審等。此外，QA會拿著眾多檢查點，每日走查項目組是否在質(zhì)量保證方面存在缺陷。因此，在項目周期緊張的情況之下，項目管理者與QA必須針對項目的實際情況，合理地裁減開發(fā)過程，省去一些不必要的官僚會議以及QA檢查的表面文章。同時，隨之而來的利益則是大量工件，尤其是文檔的減少。如果能夠讓開發(fā)人員能夠從文山會海中解脫出來，謝天謝地，他會成為項目開發(fā)的急先鋒。要知道，世界上所有的程序員都在為文檔的編撰而苦惱。減少文檔不等于說不寫文檔，即使是敏捷開發(fā)，注重代碼與可工作的產(chǎn)品勝過完整的文檔，仍然不會忽略基本文檔的編寫。雖然在對需求和設(shè)計進行分析期間，我們可以考慮用面對面交談的方式，或者在白板上寫下我們的設(shè)計方案，但為了項目沉淀或者產(chǎn)品維護與重構(gòu)，以及考慮成員變化等種種因素，文檔的編寫仍然是項目開發(fā)中不可缺失的重要環(huán)節(jié)。關(guān)鍵是編寫文檔的“度”。敏捷的布道者Alistair Cockburn在其書《敏捷軟件開發(fā)》中寫道：“團隊成員應(yīng)當(dāng)在為將來的使用而超支的成本與未來文檔不足的風(fēng)險之間進行平衡。找到兩者之間的平衡點是一門藝術(shù)……”我對那種形而上學(xué)的開發(fā)過程管理深惡痛絕。為了通過階段評審，我們必須要騰出時間來編寫階段評審文檔，然后請來那些大多數(shù)尸位素餐的評審委員會專家，然后不痛不癢地提出幾個缺陷或錯誤，后一團和氣的結(jié)束會議。顯然，這是一種官僚思想，是集體的資源浪費。即使為了某些辦公室政治考慮，那么項目經(jīng)理也應(yīng)該像牧羊犬那樣，保護自己的團隊成員免受這方面的干擾，像Scrum所要求的那樣。

2、合理的設(shè)定功能優(yōu)先級，并以此制定開發(fā)計劃。這里我們可以玩弄一個花招，即使我們無法在客戶那里尋求到裁減功能的支持，但我們?nèi)匀豢梢栽诠δ軆?yōu)先級方面大作文章。例如將客戶要求的優(yōu)先級高的功能，以及技術(shù)實現(xiàn)必須的高優(yōu)先級功能先行實現(xiàn)，那么，到了后期限來臨之際，即使我們還有一大堆低優(yōu)先級的功能未曾實現(xiàn)，但由于客戶關(guān)心的功能點能夠高質(zhì)量地運行，后的產(chǎn)品雖然沒有完全滿足客戶的需求，但憑借著優(yōu)先級的合理劃分，也可以讓我們在后面的商務(wù)談判中占據(jù)先機。此外，我們還可以信誓旦旦地向客戶承諾，我們會在交付產(chǎn)品之后，繼續(xù)完成剩下的功能�？蛻羰欠裢耆珴M意，誰知道呢？但至少我們交付了產(chǎn)品！以己之見，雖然這個產(chǎn)品不夠全面，但總比交付一個全面的產(chǎn)品，卻錯誤頻現(xiàn)要來得好。

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

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