如何正確評估開發時間

前言

常常遇到開發時間預估不許，固然大多數是延期，那麼延期的項目是由於什麼呢通常？

常見問題

部分時間未考慮

通常狀況下是由於咱們評估的是直接的開發時間，並且是順利狀況、你們都瞭解需求，沒有任何疑問和阻礙的狀況下。實際上，這種很是順利的場景基本不存在。

那麼咱們除了正常的開發時間還須要評估幾類時間到你的項目時間預估中。

• 需求熟悉時間以及代碼定位

緣由 ：儘可能減小大量時間找代碼，少數時間修代碼的場景，也能避免改錯位置

時間佔比： 開發時間30%~50%

• 開發時間：（正常時間）

緣由 ：正常開發時間須要

時間佔比：開發時間100%

• 先後端聯調以及ui矯正

緣由 ：通常聯調是比較佔時間，字段不一致、各類場景、聯調高效性、來回驗證、產品以及ui的校驗效果

時間佔比：開發時間20%~50%

• 等待時間以及與產品肯定時間：

緣由 ：某些不肯定需求商榷時間，團隊成員時間空檔不一致，各個職能思考肯定

時間佔比：開發時間20%~30%

• Buffer 時間

緣由 ：開發完成自測以後，須要對開發階段暴露的問題進行記錄甚至項目中統一優化，避免下個階段的問題重現，我的時間的緩衝期，作下個階段的預研以及本階段可能遺留問題的方案的研究。

時間佔比 ：開發時間20%~30%

綜上：通常狀況下，咱們最少要留出20%的buffer時間，這是最少前提；有風險以及不肯定狀況，或者追加團隊不熟悉項目，團隊互相不熟悉狀況下，建議評估時間爲:正常開發時間的150%~200%，以保證在該階段能儘快的磨合，找到合理的開發進度。（若是以爲這樣的評估時間太長，能夠將需求量減小，可是需求細化）。

最終目的 ：讓項目估期具備可參考性；給出團隊合理的磨合期以及總結緩衝時間。

技術可行方案沒有細化

通常狀況下，需求評審都會進行詳細的需求評審，評審結束時或者過程當中，會對這個可行性進行技術分析，但大多數狀況下，給技術可行性分析的時間很是短，並且缺乏業務場景條件。更快的狀況是，產品以及技術沒有響應的備案通常，也就是說不多考慮同一需求的兩種實現方式。這樣就致使技術可行方案或者給的很粗糙，就說可行，由於看見過，或者概念上以爲可行，沒有代碼實踐過；或者說不可行，但沒有嘗試過具體方案。

另一個問題就是不論是否可行，整個技術團隊是沒有技術架構或者成系統性的技術方案的，大多數人都是拍大腦，或者百度，或者不知道問誰。

這樣的問題，須要產品在提需求評審以前給技術去作技術預研究，研究經過後再加進需求；做爲長期規劃，公司的技術方案應該作定量增量維護，並作技術方案宣講。

注意事項：

• 切忌過後反饋，說技術可行方案沒有作出來，要知道前端在產品複雜性以及不肯定性上是不少的，在沒有作過尤爲公司總體沒方案的時候，沒法作可行性分析的，也沒法給出具體方案或者回復可以實現。因此最終建議就是：將問題置前。
• 涉及前端交互，實現細節要足夠細化，不要開發階段去確認細化
• 測試以前，對不肯定的方案，隨時準備備案方案或者砍需求，這點是容許的
• 報風險時間置前，若是開發開始或者任何過程有可能致使項目延期或者需求沒法實現的時候就報警，不要等加班能實現或者存在僥倖心理

更多

更多內容等我更新哦，若是以爲文章不錯，歡迎加粉或者收藏個人站點：damobing.com