網(wǎng)友解答: 程序員一定要懂得寫爛代碼，一定不能把項目寫得太好，要留下坑，一直有bug改，不然做完項目你就失業(yè)了。 網(wǎng)友解答: 初級時間估算假設(shè)我們達(dá)成了時間估算非常重

程序員一定要懂得寫爛代碼，一定不能把項目寫得太好，要留下坑，一直有bug改，不然做完項目你就失業(yè)了。

初級時間估算

假設(shè)我們達(dá)成了時間估算非常重要這個共識，那么我們繼續(xù)看一下如何估算。通常情況下，我們低估所需時間是因為我們想的是「寫出一個原型需要多長時間？」。

但是，交付的東西往往要比原型大多了，你還需要考慮測試、調(diào)試、優(yōu)化所花費的時間。還有開會、訪談、代碼評審，甚至發(fā)郵件都是需要花費時間的。

低估所需時間的另一個原因是意外的問題，這些問題往往不能被充分考慮到，比如 IDE 更新而讓你多花了一天去配置環(huán)境等等。

基于此，我們最好不要太相信所謂的經(jīng)驗和直覺。

Step 1：制定技術(shù)方案

在開始任何一個重要項目之前，你都應(yīng)該有一份技術(shù)計劃或者設(shè)計文檔。這個文檔的目的在于讓別人知道你在做的事情，并能獲得反饋。當(dāng)你注意到其中的技術(shù)細(xì)節(jié)時，你就會更清晰知道具體所耗費的時間，比如把某個庫更新到新版本，可能會多花一天的時間。你甚至還得自己寫一個庫。

顆粒度在這里是很重要的。如果有哪一部分讓人覺得不清楚，要么是你應(yīng)該了解更多相關(guān)知識，要么得把它分解為更細(xì)致的步驟。與此同時，如果一個步驟太細(xì)的話，又可能會太脆弱導(dǎo)致整個計劃無效，所以要把握好這個度。

想要知道你的文檔里應(yīng)該考慮哪些東西，可以看看AliciaChen 的 這篇文章。關(guān)鍵在于跟 PM 溝通清楚，消除有歧義的地方，這樣才不會導(dǎo)致最后要推翻重來。

Step 2：為每一步添加時間估算

文檔里的每一步實現(xiàn)需要多少時間，這往往牽涉到對細(xì)節(jié)的研究（這個是不是已經(jīng)有庫了？）。因此視項目性質(zhì)而言，先做一個簡單的原型可以幫助揭示許多潛在的痛點。

Step 3：追加容錯時間

現(xiàn)在你已經(jīng)有了初步的時間估算，不過還有許多其他需要考慮的因素。

隨時調(diào)試：Bug 難以避免，這取決于開發(fā)者對特定代碼庫的經(jīng)驗以及代碼庫的成熟度。會議和假期：開會或者放假時一般來說是不會敲代碼的，所以真正敲代碼有多長時間？因此時間估算時要好好看看日程表。最終測試：通常應(yīng)該一邊編碼一邊測試，但很多團(tuán)隊在發(fā)布前還需要做集成測試，因此在你的估算中留出這部分的時間。代碼評審：在這個代碼庫中你一般需要進(jìn)行幾輪？每輪需要多少時間？要經(jīng)過多少評審人？留意評審人的日程安排確保代碼評審的時間。

當(dāng)你把交付時間的開銷也考慮進(jìn)去，你就能看到自己的時間估算和項目的實際發(fā)布時間要匹配得多。盡管實際情況可能還會更長，你也可能會因壓力而需要縮短工期。但當(dāng)大家明白你的估算更準(zhǔn)確時，也會更信任你。

Step 4：發(fā)布后評審上期時間估算

復(fù)盤還挺痛苦的，但是回顧能讓你在下一次做得更好。每一個實際與預(yù)期時間不匹配的項目都發(fā)生了什么，找到原因并改進(jìn)它。

總而言之一切在于溝通。提前溝通、經(jīng)常溝通，了解彼此的日程和需求變更。

跟 PM 等相關(guān)參與者的溝通也能讓對方提供可能會影響你估算的重要信息。一位設(shè)計師可能會說這個動畫需要一周工期，干脆砍掉不要了。另一位 PM 也可能補(bǔ)充說這個原型只是對用戶進(jìn)行研究的而已，這次迭代不用處理太多 bug。

對于工程師來說，不要做不切實際的更短工期的妥協(xié)，開誠布公更顯專業(yè)。對于 PM 和其他人來說，尊重這一估算可能需要一個過程，但要知道光靠嘮叨是不可能縮短工期的。

項目時間估算不容易，唯有善于溝通、有同理心以及確定功能優(yōu)先級才可以。