# 如何有效地预估工作量

在实际开发过程中，难免要对自己手头的工作进行工作量预估，其实笔者一开始预估工作量的时候总是感到没谱，往往会得出过于乐观的结论，也就是所谓的“程序员的乐观”，老鸟程序员经常告诫我们说：“宁可多算一周，不可少估一天”。过于乐观地估计工作量，不仅会让自己疲于赶进度，还会连累其他的开发伙伴。所以本文就着重讲一下如何行之有效地做出正确的工作量预估。

由于笔者能力有限，本文只讲单个开发者的情况，如果是团队leader进行规划的话，要考虑的东西只会更多，笔者也没有团队规划的经验，就不在此强答了。

# 第一步：读懂需求，细分步骤。

对需求一知半解就盲目地进行开发是是非常危险的行为，轻则遗漏细节，重则全盘皆错。很多开发者都不怎么重视这一阶段，觉得只有开始做之后才能逐渐地理解需求，其实不然，这一阶段要求对需求全貌有一个把握，把整个需求的难点和耗时的点给找出来，方便开发时认真对待。

对于大部分需求，都能找出明确的步骤划分。比如我要做一个表格展示页，用来展示一些从后端取回的数据，那么就可以将之划分为编写页面和集成后端接口两个部分，而且根据自己以往的开发经验，还能大概知道哪里比较耗时，哪里还需要进一步地了解。

# 第二步：把握轻重缓急，优先估计熟悉部分。

无论项目复杂与否，肯定有些部分是自己最熟悉的，那么我们就优先从这些地方下手，根据以往的开发经验，确定一个时间点A，并将此确定为开发的第一阶段。

# 第三步：肢解生疏需求，消灭项目盲点。

除却熟悉的部分，下面就是真正的耗时耗力的阶段了，不熟悉的部分可以有三种形式：对技术细节不熟悉、对具体需求不熟悉和对团队协作过程不熟悉。

不熟悉的技术细节。这时要单独估算学习新的技术知识所需的时间，根据未知知识与自己已有的储备知识的不同疏离程度，要分配不同的时间段B，比如对于前端来说，如果要学习的部分属于后端范畴或者是自己没有接触过的算法部分，那么就要相应的预估长一点。
不熟悉的需求细节。如果拿到的需求文档有些部分语焉不详，自己就要长个心眼，把与制定需求的人沟通的过程也要估算在内，划定一个时间段C。
不熟悉的协调过程。这种情况一般发生在刚接触新项目时，自己对项目的管理规范等等不熟悉，这时也要将沟通时间估算进去，划定时间段D。

经过以上一番考虑，基本上就可以确定出一个比较具体的时间范围了。一定要切记，很多时候团队leader让成员估算开发时间时，最关心的往往并不是某个人能不能及时把手头的工作做完，而是如何分配，使得所有成员能够在指定的时间内完成一整个任务。所以错误的预估工作量和耗时，很可能会延误和其他人员的对接，造成整个项目完成时间的延后。

注：以上文字整理自笔者与某位年长十年的程序员的聊天记录，可能不适用于某些开发情况。