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

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

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

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

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

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

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

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

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

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

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

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