为什么估时总是不准确？

我最近考虑了关于方案设计中“估时”这块，觉得自己估时也不是很准。 做项目中最难的点且最有价值的点在于 ：
1.自己没碰到过且需要自己去探索的地方。这个地方估算时间是最难的。
2.想往前走，走着走着感觉“水“好深，但往回退 又会浪费很多时间。
--来自同事金鹏的感触

为什么我估时总是不准确？

时间观念

首先，我觉得时间观念在估时过程中，起到的作用是至关重要的。一个时间观念强的人，会把估时当成一种承诺，并想尽办法在既定的时间内去完成任务；
而缺乏时间观念的人，做事拖拖拉拉，没有轻重缓急。

未知事物

一件事情，你越了解，做起来把握就越大。比如同一类项目，你做第一次的时候，可能手忙脚乱；但是做第二次的时候，往往就得心应手很多了。因为你有过一次经验，了解的东西多了。
反过来观察，历史项目中超期的因素，有很大一部分都是因为我们不了解，比如新业务、新技术。
对于新技术，你需要花费时间去学习，而在这个过程中，会遇到很多问题，可能一个问题就能卡住你半天，导致超时。
对于新业务，你需要花时间去了解，这个相比新技术，更加重要，因为一旦出现偏差，可能导致你做的东西不符合需求。这一块的坑特别多。

未知事物这方面，有多重原因：
1、分析需求时，根本没有发现有新的业务和技术

可能需求文档中，就只是一个单词或者一句话，一不小心就被自己略过了

2、开发人员当前的能力和经验具有局限性

设计的方案在自己已知的范围内，确实是最好的；但是实际上可能并非最佳方案

外部资源

如果项目依赖于外部资源(接口、模板)，往往也会成为一个时间风险点。别人跟你约定周一交付接口，结果到了周五才给你，这个时候，一不小心，你就要为此背黑锅了。

分解文档

我们对需求的分析，最终都要汇集成一个分解文档，这个文档是否靠谱，对于项目的进度也很重要。
分解文档经常出现的几个问题就是： 1.不够细致，缺乏可执行性 2.实际工作没有按照文档来进行，做到后面已经无法从文档体现出项目进度 3.没有按照一天 8 小时来估算时间，将晚上的时间也算进去了，导致估算的时间，根本不够 4.你每天是不可能真正有 8 个小时来写代码的，其他项目的 BUG、其他人员的打断等等，都会耗费你的时间

如何才能准确估时？

不要在开发阶段去学习新事物

业务知识与技术，不应该在开发阶段还在学习，应该在此之前，就搞定这部分内容。项目开发强调先紧后松，前期的紧，就是为了充分做好准备工作，去除一切不确定因素。
如果时间紧迫，就不要采用新技术。

你也是产品经理

将你自己当成产品经理，将产品经理当成开发，你给他讲一遍需求，这样能够最大程度的发现你理解上的盲点，屡试不爽。
这个方法非常有用，真的，不骗你。

流程文档

用 xmind 或者其他工具，把自己当成用户，画一遍流程，越细越好。

接口式编程

方案确定后，先编写程序框架，将文件结构、类与类之间的调用关系先写好，这样会提早发现问题，提高分解文档的可行性。