經常遇到開發時間預估不准，當然大多數是延期，那麼延期的專案是因為什麼呢一般？
一般情況下是因為我們評估的是直接的開發時間，而且是順利情況、大家都了解需求，沒有任何疑問和阻礙的情況下。實際上，這種非常順利的場景基本不存在。
那麼我們除了正常的開發時間還需要評估幾類時間到你的專案時間預估中。
原因 ：儘量減少大量時間找**，少數時間修**的場景，也能避免改錯位置
時間佔比： 開發時間30%~50%
原因 ：正常開發時間需要
時間佔比：開發時間100%
原因 ：一般聯調是比較佔時間，欄位不一致、各種場景、聯調高效性、來回驗證、產品以及ui的校驗效果
時間佔比：開發時間20%~50%
原因 ：某些不確定需求商榷時間，團隊成員時間空檔不一致，各個職能思考確定
時間佔比：開發時間20%~30%
原因 ：開發完成自測之後，需要對開發階段暴露的問題進行記錄甚至專案中統一優化，避免下個階段的問題重現，個人時間的緩衝期，做下個階段的預研以及本階段可能遺留問題的方案的研究。
時間佔比 ：開發時間20%~30%綜上：一般情況下，我們最少要留出20%的buffer時間，這是最少前提；有風險以及不確定情況，或者追加團隊不熟悉專案，團隊互相不熟悉情況下，建議評估時間為:正常開發時間的150%~200%，以保證在該階段能盡快的磨合，找到合理的開發進度。（如果覺得這樣的評估時間太長，可以將需求量減少，但是需求細化）。
一般情況下，需求評審都會進行詳細的需求評審，評審結束時或者過程中，會對這個可行性進行技術分析，但大多數情況下，給技術可行性分析的時間非常短，而且缺少業務場景條件。更快的情況是，產品以及技術沒有響應的備案一般，也就是說很少考慮同一需求的兩種實現方式。這樣就導致技術可行方案或者給的很粗糙，就說可行，因為看見過，或者概念上覺得可行，沒有**實踐過；或者說不可行，但沒有嘗試過具體方案。
這樣的問題，需要產品在提需求評審之前給技術去做技術預研究，研究通過後再加進需求；作為長期規劃，公司的技術方案應該做定量增量維護，並做技術方案宣講。
注意事項：
如何評估開發時長
在開發的過程中，為了能夠有乙個合理的開發周期，我們都需要去評估一下我們開發的時長，從而給出乙個軟體大致的上線時間，那麼如何進行開發時長的評估呢？對自己開發過程有乙個清晰的規劃，知道每天的具體小目標，專案的大目標 合理的開發時長讓公司領導覺得你靠譜，在開發時長之內完成更是彰顯自己的能力了 設計 研發 ...
客戶端程式員如何評估開發時間
作為ios開發需要知道以下幾個流程 1 準備過程 ui設計圖 api介面討論和設計 客戶端的開發 包括介面 介面除錯 互動邏輯 客戶端自測 移交測試人員 發布 針對上面的迭代中需要的流程 需要估計時間 以上是我在其他 上截下來的圖 是新手和老手之間的對比 作為專案估時 一定要謹慎 不能表面上看著簡單...
如何正確的使用你的時間
你是否時常會焦慮時間過的很快，沒時間學習，本文將會分享一些個人的見解。在工作中我們時常會花很多時間去 debug，但是你是否發現很多問題最終只是你基礎不紮實或者文件沒有仔細看。基礎是你技術的基石，一定要花時間打好基礎，而不是追各種新的技術。一旦你的基礎紮實，學習各種新的技術也肯定不在話下，因為新的技...