为什么说你对项目工期的预估都是错的

你有没有试过复原魔方,但始终搞不定?在一次乘坐长途客车的途中,我试了几次,但无一成功,着实深受打击。后来我听说有些孩子可以在很短时间内搞定!这怎么可能!

无法预料的复杂性

作为一个程序员,当你开始一个新项目时,由于种种原因,通常并不会特别清楚如何实现它。但作为一个专家,而且以前已经做过几个类似的任务,所以要么你自己想办法搞明白怎么做,要么找找看谁知道再咨询一下,或 Google 一下。

通常情况下,直到你掉进去,你才知道你已入坑!

比如这些情况:

  • 你需要用新框架、新库重新实现某个功能。
  • 你打算用到的一个库跟你以前用的不大一样。
  • 你一直熟悉的API无法实现部分预期功能。
  • 你用到的框架与单元测试和集成测试不一样。
  • 你原以为新框架中的某个模型是单例模式,然而它并不是。

预料外的估时复杂性

“你帮我估计一下这个任务的工时吧?”,你的老板问你。还记得你没搞定的魔方么?如果让你再来一次,你觉得你多久能搞定?

“啥?两天?”,“但是我们上一个工程师只要几个小时就搞定了!你绝对不能花费这么长时间。”

确实有种算法你可以学习一下,稍作练习,就可以帮你很快解决魔方的问题。但是你现在还不知道这算法,而且也没有任何迹象表明你一定会找到正确的算法,即便能找到,也未必仅仅花你两天时间。

累加复杂度

任务越多,你就越容易陷入这种窘境,也就是说,如果你不尽量延长你的预估时间,你几乎无法保证按时交付。

我们不妨简单算一下,就能看的更明白。就算你是个经验丰富的程序员,仅有 5% 的可能会遇到预料外的复杂情况。如果你接手一个新项目,并把它拆分为 10 个小任务…

1 – (1 – 0.05) ^ 10 = 0.40

即:你有 40% 的可能碰到一个复杂任务,你对该项目的所有预估就都吹了。

在《为什么项目基本都在延期?》这篇文章中,有更多数学证明和超过 70,000 工时的项目指标讨论这个论题,看看有没有你感兴趣的?

创造性和重复性任务

Einstein trying to estimate a project

Einstein trying to estimate a project

问题已经深入到需要很多思考的任务,以及一些你已经具备经验的常规任务之间的区别了。

在《论软件行业的规模不经济性》一文中,从生产率角度,就这种差异性进行了非常有意思的讨论。对于创造性任务,工作量越大,单个任务耗时越多;而重复性任务正好相反,它们通常可以在一定程度上自动化。

这么看来,貌似根本没有办法估计创造性任务,连可供参考的经验都没有。猜猜看,爱因斯坦需要多久才能完成物理大统一理论的发现?

你能做的最多就是基于历史指标来估计,然而对软件开发或者股市,这都没有太大价值。

本文文字及图片出自 伯乐在线

余下全文(1/3)
分享这篇文章:

请关注我们:

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注