說，“15個月? 瘋了吧?我們要在8個月內(nèi)生出”。當(dāng)然，這樣談判是無法促進(jìn)事成的，而且即使得到一份8個月的進(jìn)度表，我還是告訴你一個小秘密：這是不可能實現(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ù)四個月就能完全搞定。軟件團(tuán)隊可能甚至?xí)?/span>受這個挑戰(zhàn)，因為這使他們看上去像英雄(那個海象隊有多厲害?他們每個周末都來工作!)這能行的，是吧?再想想吧。有一部完整的文獻(xiàn)論述了“加班不會使軟件更快產(chǎn)出”。Edward Yourdon，作為軟件企業(yè)家和該文獻(xiàn)的作者，稱這種項目為“死亡行軍”。
軟件開發(fā)者花費大量的腦力勞動。即使是最好的程序員，也很少有能堅持幾小時以上的高強度腦力勞動。另外，他們還需要休息一下大腦。這就是為什么你好像總能撞到他們在上網(wǎng)或玩游戲。
強迫他們投入更長時間坐在電腦前，并不會轉(zhuǎn)化為更多的產(chǎn)出——即使會，那都將是劣質(zhì)的產(chǎn)品。當(dāng)軟件開發(fā)者的大腦完全發(fā)燒，他們幾乎做錯多過做對，寫出無法使用的代碼，或者引入大量的bug。而如果你真的禁止他們上網(wǎng)，玩多人游戲，強迫他們在正常的睡眠時間繼續(xù)寫代碼，好吧，他們可能會開始離你而去。死亡行軍不是造成項目延期和預(yù)算爆炸的唯一條件，但絕對是充分條件。
如果以上是使你項目失敗的方法匯總，那么怎樣做到萬無一失呢?首先，你要招聘一個巨星級人馬。在FogCreek，對于一個全職崗位，我們傾向于審核大約400個候選人。因為最優(yōu)秀的開發(fā)者擁有十倍于“一般優(yōu)秀”的創(chuàng)造力。
其次，讓開發(fā)者給出細(xì)粒度的時間預(yù)算。是的，讓開發(fā)者去預(yù)估制作一個新應(yīng)用需要花多長時間，是不容易的。這就是為什么他們要在每個項目之前作出可靠的藍(lán)圖。
一旦你有時間表在手，不要嘗試提前截止日期。如果項目不能在你能諒解的時間內(nèi)完成，解決方法不應(yīng)是去交涉一個“好聽的”時間表，而應(yīng)該是爭取更多資源，或者推遲上線，或者拿掉一些功能。
最后，鼓勵你的員工按合理的工時，一周干40小時。我是說真的。除了偶爾為截止日期而沖刺，我們在Fog Creek都是一天8小時工作制。在技術(shù)的世界里，應(yīng)該將一個大項目看成是一次馬拉松，而非一次短跑。
我覺得讓人員在不同崗位上輪換有助于消除不可替代性，但我是謹(jǐn)慎地安排這事，并且在時間表里加入額外的三周給新人以學(xué)習(xí)新代碼，和額外的一周給舊人去教新人。
當(dāng)項目正在進(jìn)行時，你會多次被誘導(dǎo)而想重新分配工作。但你要謹(jǐn)慎地重分配。所換的新人需要花不少時間去駕馭原作者的代碼。