項目管理是一個非常復(fù)雜和系統(tǒng)性的工作，一個項目的成功往往能帶來巨大的經(jīng)濟效益，一個項目的失敗也可能浪費大量的人力物力。中培偉業(yè)《IT項目管理最佳實踐》培訓(xùn)專家王老師根據(jù)自己多年的工作經(jīng)驗，就項目管理失敗的原因談了自己的看法。王老師指出，項目失敗的原因，有技術(shù)上的也有管理上的，以下是導(dǎo)致項目失敗常見的5個原因。

錯誤一：采用平庸的開發(fā)團隊

軟件設(shè)計是有難度的，而且不幸的是，很多自稱程序員的人確實不能勝任軟件設(shè)計。盡管這是項目失敗的首要原因，你也不曾從官方的失敗報告中得知。在所有的行業(yè)，軟件業(yè)，物流業(yè)，或者客服業(yè)，人們對同事的無能都太過寬容。你從來都不會聽到有人說“我們團隊沒有足夠的智慧來完成這件事”。為什么要這樣傷人的心呢？顯而易見的，如果這隊分得了任務(wù)的人員并不擅長這份工作，他們的工作會日復(fù)一日，日復(fù)一日……等等……但軟件卻沒有做出來。你也不用太擔(dān)心 HR 會阻撓你招聘一班廢物。在大多數(shù)的案例里，我向你保證，HR 對此毫無建樹。

錯誤二：按周來定目標(biāo)

假設(shè)你想改造你的廚房。你請來的師傅已經(jīng)搞過很多廚房，而且不作詳細藍圖就能估算出這項工作的成本。但軟件開發(fā)者是在制造前所未有的東西。如果前所已有，他賣張拷貝的光盤給你就行了。因此，粗略的估計是不可能的。他們需要在寫代碼之前做好詳盡的計劃。無論你是客戶還是開發(fā)經(jīng)理，你的責(zé)任就是確保開發(fā)人員帶著詳盡計劃來開展工作。當(dāng)你向開發(fā)人員詢問計劃時，他們大多數(shù)人可能只會給你一份把進度按周來劃分的時間表。這看似非常合理，但其實不然。如果你讓軟件團隊提交一份大粒度的時間表(大是指需要兩天以上的工作)，那么你可以認定他們沒有考慮到所有需要實現(xiàn)的細節(jié)，而這些細節(jié)將會積累，導(dǎo)致延期。

錯誤三：為截止時間而談判

還有什么比按周劃分軟件項目更糟糕？就是要求團隊承諾大大地提早完成工作。根據(jù)我的經(jīng)驗，大多數(shù)開發(fā)者都會樂觀地接受你的暗示并參與討價還價。然后你會得到一份友好的協(xié)定時間表，但卻無法按時執(zhí)行。

試想以下情況：海象媽媽會在懷孕 15 到 16 個月后，生出小海象。你可能會叫海象媽媽保證在 15 個月內(nèi)做到，而她也說沒問題。或者你說，“15 個月？瘋了吧？我們要在 8 個月內(nèi)生出”。當(dāng)然，這樣談判是無法促進事成的，而且即使得到一份 8 個月的進度表，我還是告訴你一個小秘密：這是不可能實現(xiàn)的。你可以取得一份 11 個月的時間表，但你還是要等 15 個月，因為小海象就是要 15 個月才能出產(chǎn)，有時甚至 16 個月。

錯誤四：均分任務(wù)

這里有一個破壞項目的好方法。列出人們需要做的所有工作，然后給重新均分給各人。如果 Mary 有太多的工作，就分一些給 John。這聽起來完全合理，使得你不會被質(zhì)疑。但我向你保證，時間一長肯定會出現(xiàn)問題。那是因為當(dāng)一個開發(fā)者去替代另一個時，我們有理由假設(shè)效率降為十分之一。John 將會花費無數(shù)小時去搞清楚 Mary 其實已經(jīng)熟悉的那部分代碼。而且 John 改 bug 也不及 Mary 快，因為 Mary 才了解所有的陷阱在哪里。

錯誤五：工作到深夜

讓我們假設(shè)有個項目要每周工作 40 小時，連續(xù)六個月才能完成。如果你讓所有人每周工作 60 小時，那么持續(xù)四個月就能完全搞定，軟件團隊可能甚至?xí)邮苓@個挑戰(zhàn)。

然而現(xiàn)實是　　軟件開發(fā)者花費大量的腦力勞動。即使是最好的程序員，也很少有能堅持幾小時以上的高強度腦力勞動。另外，他們還需要休息一下大腦。這就是為什么你好像總能撞到他們在上網(wǎng)或玩游戲。

強迫他們投入更長時間坐在電腦前，并不會轉(zhuǎn)化為更多的產(chǎn)出——即使會，那都將是劣質(zhì)的產(chǎn)品。當(dāng)軟件開發(fā)者的大腦完全發(fā)燒，他們幾乎做錯多過做對，寫出無法使用的代碼，或者引入大量的 bug。

一旦你有時間表在手，不要嘗試提前截止日期。如果項目不能在你能諒解的時間內(nèi)完成，解決方法不應(yīng)是去交涉一個“好聽的”時間表，而應(yīng)該是爭取更多資源，或者推遲上線，或者拿掉一些功能。

當(dāng)項目正在進行時，你會多次被誘導(dǎo)而想重新分配工作。但你要謹慎地重分配。所換的新人需要花不少時間去駕馭原作者的代碼。我覺得讓人員在不同崗位上輪換有助于消除不可替代性，但我是謹慎地安排這事，并且在時間表里加入額外的三周給新人以學(xué)習(xí)新代碼，和額外的一周給舊人去教新人。

最后，鼓勵你的員工按合理的工時，一周干 40 小時。在技術(shù)的世界里，應(yīng)該將一個大項目看成是一次馬拉松，而非一次短跑。