里碰得頭破血流。那么，我們該怎么辦？

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

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ù)完成剩下的功能。客戶是否完全滿意，誰知道呢？但至少我們交付了產(chǎn)品！以己之見，雖然這個產(chǎn)品不夠全面，但總比交付一個全面的產(chǎn)品，卻錯誤頻現(xiàn)要來得好。

3、提高會議效率。

無論是傳統(tǒng)的軟件開發(fā)方法，還是敏捷方法，在軟件開發(fā)過程中，不可避免要召開各種各樣的會議。畢竟軟件是人開發(fā)的，而且是組成一個團隊的人開發(fā)的，因而交流成為必然。我并不反對召開這樣的會議，相反，我很樂于參加這樣的會議，因為這樣可以讓我的口才在全體同僚面前得到充分地展示。然而，會有多少的寶貴時間淹沒在這樣的夸夸其談，或者口沫橫飛之