如何准确预估项目完成时间

如何预估项目完成时间?

预测总是一个难题,当项目经理顶着上级期限式需求时,常常询问自己的程序员一个纠结的问题:”何时能完成?”或者”最晚什么时候能完成?”程序员们往往哑口。而有些开发组的绩效是和预估挂钩的，这并非对程序的不自信，实际上预测项目时间从来都不是一件容易的事情。

作为程序员你需要仔细分析你的项目才有可能得出与实际花费时间相近的答案:
这里我介绍一些我的经验和我所了解到的一些理念.

过长时间的预估和过短时间的预估的背后

完成速度往往被高估
而对于某些挑战性的问题，预估时间过长可能意味着方案不可行。

往往高估完成速度的背后:

有项目经理认为预估时间与实际完成时间的关系是：

t预*pi=t实

背后的逻辑是人们会忽略某些时间项.接下来我们将看到一些容易被忽略的时间消耗项:

• 预估消耗在调试的时间-自动测试的重要性,健壮性.
  不受控的代码精灵将会变成魔鬼,事实上你会花费N倍时间在代码的调试上。回忆最近你所经历的一次糟糕的排错经历，谁能确定那里的代码一定没有问题呢?
  这时你的代码就变成了魔鬼,而解决之道就是编写测试代码.
  事实上当你编写完毕你的测试用例的时候,你已经完成了工作的一半.大部分潜在的问题也在这个过程中被监督也解决而不是爆发在后期.
  这样我们便减少了耗费在调试上的时间.

• 面临需求容易变动的项目时
  抽选出核心的技术框架将会成为首先的任务,将变与不变分离。
  这似乎是老生长谈,但需求变动对项目的时间的消耗不容忽略.

• 当涉及技术难题时,取决于难题能否被攻克
  对难度的预估.有些难题在现有条件下可能是难有解的.比如跨领域难题.缺乏相关技术专家,或者数学难题之类.
  这种方案要及早鉴别出.要么找替代方案,要么创造条件.

• 项目实现逻辑异常复杂时
  从最小功能入手,注重框架的联通性.
  我们应该想:实现一个可用框架需要多长时间呢?

一个例子是，微软内核ntoskrnl.exe才不到10M，而C盘里面的扩展性辅助性，兼容性措施却达到了G级别。

一步一步，关键的脚印。每一步都成了，总的也成了。

• 找到项目的关键和最低要求或者基本要求,筛选他们.
  每个项目都有自己的独特要求和侧重点。比如安全项目要求足够的稳定性，而设计数据库项目保障数据安全和快速恢复以及并发是首先考虑的点。围绕核心需求进行搭建，这才是真正耗费时间的重头。

• 当涉及新技术时
  这往往取决于团队成员，当引入新技术时有没有预研，比如使用新的编程语言，这往往对团队是一个巨大的挑战，特别是具有跨语言学习经验人数比例不高的情况下。还可能引入困扰人且耗费时间的BUG。
  所以给新技术分配一定的时间是必要的。

有效的估算

程序员与项目经理 有效的估算项目时间的方式是：

首先不是问何时完成最终完美的任务。而是讨论本项目的第一个具有里程碑的目标是什么？它的实施时间都由哪些组成？是否存在提前结束任务的路径？

我将举几个例子:

逆向时间预估

逆向者的工作是具有挑战性的工作之一，在前期将花费相对较多的时间。结果可能是可逆或者毫无头绪。

BUG修正时间预估

对于一些前瞻性的技术方案，BUG存在短期无法解决的可能，所以好的时间预估应当告知该项,而难以重现的BUG向来是个难题，即使是容易重现的BUG的排查也需要一个缓冲时间：
1 排查清楚问题的时间。有可能无法解决。1天
2 针对原因探索技术方案？天0-1
3 方案实施《—-》测试？天0-1

项目开发时间预估

递进的汇报将是有效的。
每项小计划不应当超过一定时间比如5天,否则容易出现无效的估测.

项目需求分析项目评估 已经用时 1天
项目设计 预计用时 2天
项目实施 预计用时 2-3天
项目调试与测试 预计用时 1-2天

常见进度沟通问题

项目经理和程序员之间沟通项目进度时常出现的问题是:

前者有可能忽视项目实施问题的时间弹性,将时间推给程序员决定,造成代码实施者的两难。
解决之道是不妨说出自己的底线:我们的项目只有在什么时候之前上市才行,我们的项目如果晚于什么时间会违约,我们的项目在最短时间内完成将拥有充分的优势.告以实情,而非打哑谜,更有助于问题的解决.

作为项目经理如果你了解项目完成时间总是在变化的，就意味着,当使用KPI对项目进行考核，更恰当的方式是不使用绝对完成时间做考核，因为根本不存在准确的完成时间。

作为程序员，应当更理性的估测并改进项目时间，成长就是这么一步一步走出来的。

加快进度会被鼓励和奖励。此外应当在任务的实施过程中按照情况 随时 调整 进度。