今天公司裏,一個經驗很豐富的同事在跟老闆開會時預估了開發計劃,然而這個開發計劃的時間讓組內的其餘同事感到一絲不合理。下班的路上,幾個相對來講開發經驗比較豐富的同事便聊起了預估開發計劃的事情;前端
同事A說:預估工時首先依據模塊的技術實現定一個時間,而後再在這個時間的基礎上適當添加一些時間。同事B說:大家前端的來講實現起來相對簡單些,可是後臺就不同了。要開發龐大的數據庫後臺,首先架構的討論就是一個很費時間的過程,須要反覆討論修改。而後纔是結合產品的需求1:1的來預估開發週期;數據庫
聽完以後,想一想本身在預估開發週期時候,僅僅侷限於技術模塊的實現時間,並無將梳理需求探討需求的時間考慮在內;至於開發前期框架的討論、搭建、修改更是忽略掉了。架構
從此在預估工時時:框架
1-技術模塊的實現所需時間;測試
2-討論需求梳理需求需求所需的時間(通常狀況下一個模塊大概須要一天的時間);開發
3-在實際開發過程當中,遇到實際的問題詢問產品更改需求又會耗費必定的時間(通常結合項目在總工時上延時2~3天);產品
4-就是框架的討論時間(用戶量大的前提下才會用到)。後臺
5-測試人員測試、修改bug、及測試環境是否來大姨媽;基礎
綜上所述:預估開發計劃須要考慮上述全部因素,才能制定出不跳票的上線時間!!!bug