【正文】
每天我有多少有效的小時(shí)花費(fèi)在項(xiàng)目任務(wù)上,我可能碰到的任何打斷或突發(fā)調(diào)整請(qǐng)求,會(huì)議,和所有其它會(huì)讓時(shí)間消失的地方。與我們被要求做的許多活動(dòng)相關(guān)的任務(wù)切換的開(kāi)銷,顯著地降低了我們的工作效率。 13. 將培訓(xùn)時(shí)間放到計(jì)劃中 確定你的組員每年在培訓(xùn)上花費(fèi)多少時(shí)間,并把它從組員工作在指定項(xiàng)目任務(wù)上的可用時(shí)間中減去。 14. 記錄你的估算和你是如何達(dá)到估算的 當(dāng)你準(zhǔn)備估算你的工作時(shí),把它們記錄下來(lái),并且記錄你是如何完成每個(gè)任務(wù)的。 15. 記錄估算并且使用估算工具 有很多商業(yè)工具可以幫助你估算整個(gè)項(xiàng)目。它們同樣能夠幫助你避免進(jìn)入“不可能區(qū)域”,即產(chǎn)品大小,小組大小和進(jìn)度安排組合起來(lái)沒(méi)有已知項(xiàng)目成功的情況。 16. 遵守學(xué)習(xí)曲線 如果你在項(xiàng)目中第一次嘗試新的過(guò)程,工具或技術(shù),你必須認(rèn)可付出短期內(nèi)生產(chǎn)力降低的代價(jià)。 17. 考慮意外緩沖 事情不會(huì)象你項(xiàng)目計(jì)劃的一樣準(zhǔn)確的進(jìn)行,所以你的預(yù)算和進(jìn)度安排應(yīng)該在主要階段后面包括一些意外的緩沖,以適應(yīng)無(wú)法預(yù)料的事件。指明一些以前項(xiàng)目不愉快的意外,來(lái)說(shuō)明你的深謀遠(yuǎn)慮。你的估算將永遠(yuǎn)是猜測(cè)。不要讓人們只入不舍他們?nèi)蝿?wù)的完成狀態(tài);使用明確的標(biāo)準(zhǔn)來(lái)判斷一個(gè)步驟是否真正的完成了。努力讓項(xiàng)目在準(zhǔn)確的、基于數(shù)據(jù)的事實(shí)基礎(chǔ)上運(yùn)行,而不是從因?yàn)楹ε聢?bào)告壞消息而產(chǎn)生的令人誤解的樂(lè)觀主義。 這些提示不能保證你的成功,但是它們將幫助你在你的項(xiàng)目上獲得一個(gè)堅(jiān)實(shí)的把手,并且保證你做了所有你可以做的事來(lái)讓項(xiàng)目在這個(gè)瘋狂的世界上成功。 you’re ahead of schedule on that task. But don’t count on it.Tip 9: Plan time for process improvement. Your team members are already swamped with their current project assignments, but if you want the group to rise to a higher plane of software engineering capability, you’ll have to invest some time in process improvement. Set aside some time from your project schedule, because software project activities should include making process changes that will help your next project be even more successful. Don’t allocate 100% of your team members’ available time to project tasks and then wonder why they don’t make any progress on the improvement initiatives.Tip 10: Manage project risks. If you don’t identify and control risks , they will control you. Spend some time during project planning to brainstorm possible risk factors, evaluate their potential threat, and decide how you can mitigate or prevent them. For a concise tutorial on software risk management, see my article Know Your Enemy: Software Risk Management (Oct. 1998).Estimating the ProjectTip 11: Estimate based on effort, not calendar time. People generally provide estimates in units of calendar time, but I prefer to estimate the amount of effort (in laborhours) associated with a task, then translate the effort into a calendartime estimate. This translation is based on estimates of how many effective hours I can spend on project tasks per day, any interruptions or emergency bug fix requests I might get, meetings, and all the other places into which time disappears.Tip 12: Don’t schedule people for more than 80%of their time. Tracking the average weekly hours that your team members actually spend working on their project assignments is a real eyeopener. The taskswitching overhead associated with the many activities we ar