根據(jù)我多個項目的經(jīng)歷，資源嚴重不足（或人員離職）是最頭疼的問題，需求蔓延和進度表超出100%-300%甚至更多是最常見的問題。而項目進度表是任何可能出錯事件的替罪羊。如果有人胡亂評估，弄錯需求，或者有項目組成員生病了、離職了，這都是進度表的責(zé)任。所以說，項目進度表（Schedule），音譯過來就成了“是個酒”。酒能怡情，也最能傷人。罪不在酒本身，而在于不同的人！
但是，項目進度表又必不可少。它至少有三個作用：
第一，是一個承諾，是對什么時候完成任務(wù)的承諾。進度表在參與者之間提供了一份合同，確定每個人在一個特定的時間內(nèi)要提供什么；
第二，是提供了一種能夠追蹤項目和把工作分成若干個易于管理的小塊的工具，把工作分成小的任務(wù)，能夠幫助團隊更好地理解他們到底需要做些什么；
第三，是鼓勵每個人把自己的工作看做整體的一部分，并且全力把自己的工作和他人的工作結(jié)合起來。只是在實際工作中，我們很容易發(fā)現(xiàn)進度表的第一、第二個作用，我重點說說第三個作用。
如果沒有一個進度表來說明在某個特定的時間和日期內(nèi)必須要完成某些任務(wù)，就不可能讓大家相互團結(jié)和依靠起來。沒有進度表，每個人只會關(guān)注他自己的任務(wù)，而不去考慮他的工作是否會影響別人。在進度表中，有一種心理上的力量，因為它對眾宣布了某人要履行的承諾。
要制作進度表，就必須做估算，而估算是相當(dāng)困難的，這里面既有技術(shù)方面的原因，更有很多不可預(yù)測或我們無法左右的因素在里面。Schedule必不可少，而制作它又有很大的問題，一對極度的矛盾體。如果一個團隊在開始一個項目的時候，就充分了解進度表可能出現(xiàn)問題的原因，并且采取措施去減少這些出錯的風(fēng)險，那么這個進度表就為成為開發(fā)過程中更加有用和精準(zhǔn)的工具。要弄清進度表為什么總做不準(zhǔn)，就必須找出最本質(zhì)的原因。
原因一，倒推法本身就有很大的問題
客戶、市場部門甚至是我們自己在項目前期荒廢了大量時間，而到了后面，眼看著做不完了，就用倒推法來處理。同樣是甲方，有沒有哪個病人對牙醫(yī)說，我下午趕飛機，你兩個小時之內(nèi)把我的牙齒修好。牙醫(yī)不把他罵翻才怪！ 思路都出了問題，結(jié)果能不出問題么？
原因二，我們的估算過程有問題
是該先出需求、概要設(shè)計還是該先出計劃？實際工作中，我們總是在項目還沒有簽合同（快要簽了）就將計劃按照用戶方、監(jiān)理方的要求做好并發(fā)給他們，當(dāng)然這個計劃是包括了工期和大的進度計劃（總體）的。然后是進場做需求調(diào)研，再做設(shè)計。搞得我總是懷疑自己的智商只有60-70，不怪這個世界變化太快，而該反省我反應(yīng)太慢。
原因三，我們的估算方法有問題
經(jīng)常是項目經(jīng)理一個人拍腦袋后的一份文檔，有時候半天就提供出來了。沒有經(jīng)過集體的研究，沒有采用科學(xué)的方法，如PERT、三點估算法，參數(shù)估算法等等?？傊?，一切顯得那么的草率，依據(jù)這樣的結(jié)果做出的進度表誤導(dǎo)了好些人，起到的副作用是顯然的。我們處于一個躁動、功利和狂熱的大環(huán)境中。
原因四，我們喜歡按照固定思維來考慮問題
比如1人1天100行代碼，那么3個人100天自然就是30000（100*100*3=30000）行代碼，打個7折，也有21000行代碼。你看，夠低調(diào)了吧，其實早期我也經(jīng)常犯這類錯誤。有考慮到夏天熱或春節(jié)附近工作效率會低很多么？有將用戶新需求蔓延的風(fēng)險計劃在內(nèi)么？有設(shè)想到關(guān)鍵員
工生個小病請假么？有應(yīng)對員工離職的風(fēng)險策略么？如果這些常見的都沒有考慮，項目延期也是活該！
當(dāng)然，辦法總是比問題多。首先，必須不要盲目的屈從“政治”的壓力，假使技術(shù)團隊足夠強勢，情況會是這個樣子么？這個問題夠大夠廣，還是從技術(shù)層面談點實際的。估算應(yīng)該根據(jù)以前的生產(chǎn)率。估算依賴于程序員、技術(shù)人員對項目目標(biāo)的理解。項目經(jīng)理、程序員應(yīng)該受到信任?？梢远鄠€人從不同角度來進行估算。規(guī)格說明書或設(shè)計質(zhì)量應(yīng)該達到做良好估算所需的程度。既然可以提出問題，就有解決問題的方法。