前言
经常遇到开发时间预估不准，当然大多数是延期，那么延期的项目是因为什么呢一般？
常见问题
部分时间未考虑
一般情况下是因为我们评估的是直接的开发时间，而且是顺利情况、大家都了解需求，没有任何疑问和阻碍的情况下。实际上，这种非常顺利的场景基本不存在。
那么我们除了正常的开发时间还需要评估几类时间到你的项目时间预估中。
- 需求熟悉时间以及代码定位
原因 ：尽量减少大量时间找代码，少数时间修代码的场景，也能避免改错位置
时间占比： 开发时间30%~50%
- 开发时间：（正常时间）
原因 ：正常开发时间需要
时间占比：开发时间100%
- 前后端联调以及ui矫正
原因 ：一般联调是比较占时间，字段不一致、各种场景、联调高效性、来回验证、产品以及ui的校验效果
时间占比：开发时间20%~50%
- 等待时间以及与产品确定时间：
原因 ：某些不确定需求商榷时间，团队成员时间空档不一致，各个职能思考确定
时间占比：开发时间20%~30%
- Buffer 时间
原因 ：开发完成自测之后，需要对开发阶段暴露的问题进行记录甚至项目中统一优化，避免下个阶段的问题重现，个人时间的缓冲期，做下个阶段的预研以及本阶段可能遗留问题的方案的研究。
时间占比 ：开发时间20%~30%
综上：一般情况下，我们最少要留出20%的buffer时间，这是最少前提；有风险以及不确定情况，或者追加团队不熟悉项目，团队互相不熟悉情况下，建议评估时间为:正常开发时间的150%~200%，以保证在该阶段能尽快的磨合，找到合理的开发进度。（如果觉得这样的评估时间太长，可以将需求量减少，但是需求细化）。
最终目的 ：让项目估期具有可参考性；给出团队合理的磨合期以及总结缓冲时间。
技术可行方案没有细化
一般情况下，需求评审都会进行详细的需求评审，评审结束时或者过程中，会对这个可行性进行技术分析，但大多数情况下，给技术可行性分析的时间非常短，而且缺少业务场景条件。更快的情况是，产品以及技术没有响应的备案一般，也就是说很少考虑同一需求的两种实现方式。这样就导致技术可行方案或者给的很粗糙，就说可行，因为看见过，或者概念上觉得可行，没有代码实践过；或者说不可行，但没有尝试过具体方案。
另外一个问题就是不管是否可行，整个技术团队是没有技术架构或者成系统性的技术方案的，大多数人都是拍大脑，或者百度，或者不知道问谁。
这样的问题，需要产品在提需求评审之前给技术去做技术预研究，研究通过后再加进需求；作为长期规划，公司的技术方案应该做定量增量维护，并做技术方案宣讲。
注意事项：
- 切忌事后反馈，说技术可行方案没有做出来，要知道前端在产品复杂性以及不确定性上是很多的，在没有做过尤其公司整体没方案的时候，无法做可行性分析的，也无法给出具体方案或者回复能够实现。所以最终建议就是：将问题置前。
- 涉及前端交互，实现细节要足够细化，不要开发阶段去确认细化
- 测试之前，对不确定的方案，随时准备备案方案或者砍需求，这点是允许的
- 报风险时间置前，如果开发开始或者任何过程有可能导致项目延期或者需求无法实现的时候就报警，不要等加班能实现或者存在侥幸心理
更多
更多内容等我更新哦，如果觉得文章不错，欢迎加粉或者收藏我的站点：damobing.com
