为什么你的项目总是延期?
公司有个项目需要你来完成,老板让你给出个完成时间。当给出了项目完成的时间线后,你的老板会可能会将其分解为若干步骤,就像你之前所做的那样,然后分析每一步的完成时间,最后将这些时间加起来作为整个项目的时间线。不过,这样做就能确保项目按时交付么?SketchDeck 团队对此给出了自己的答案。
虽然这是估算多步骤项目时间线最常见的方式,但如果考虑到项目中相互依赖的过程,你会发现这么做简直就是一场梦魇。这也佐证了为何有如此之多的项目没有在截止日期前完成,因为这些项目的截止日期根本就是不切实际的。
在 SketchDeck,团队通过其按需服务交付了 70,000 小时工作量的项目。一开始,他们发现设定过于简单的时间线(仅仅将项目中每一步的平均完成时间加起来)会低估项目的总完成时间。实际上,设定基于平均完成时间的时间线会将项目的实际完成时间低估 67% 左右。对统计数字的错误理解是导致很多项目延期的重要原因。
我们从 70,000+ 小时的设计项目中学到了什么
设计项目通常是个多步骤过程。项目(比如说设计 Logo、展示、网站等等)是通过一个个步骤来完成的:设计师一开始会做个小样,然后设计一个初稿,最后才是终稿。设计师与客户会对设计的每一步进行反复的沟通与讨论,直到客户对当前设计完全满意了才会进入到下一步。有时,这需要花费很长时间。客户可能需要很长时间(从几天到几个月不等)才会同意一个步骤。你的公司的流程可能就像是这样。
不过,与大多数公司不同的是,我们会精确度量每一步的平均完成时间(“样本”、“草稿”、“最终校正样张”)。这样,我们就可以将每一个这样的步骤的平均完成时间加起来得到项目总的时间线。
不过在实际操作过程中我们发现,自己还是低估了项目的持续时间。为了说明这一点,我们分析了成千上万的客户/设计师交互流程。对于每个项目来说,我们可以计算出这个看似合理的“基于中位数”的估算方法所预测的完成时间。然后再来看看项目的实际完成时间是多少。
对于多步骤项目来说,这种方法将项目从开始到结束的时间线平均低估了 67 个小时。如果看一下具有 3 个或更多步骤的项目,你会发现这个数字会增加到 81 个小时。有 67% 的项目都比基于中位数的估算时间要晚。
如果通过将项目中所有步骤的平均完成时间累加起来来估算项目的时间线,那么拥有 2 步或更多步骤的项目的平均估算时间是 91 小时左右,而多步骤的 SketchDeck 项目的平均实际完成时间则是 155 小时。
原因
人们一直都在低估时间线。研究表明,学生群体会有意且系统化地低估自己完成任务与学术项目的时间、人们也常常会比自己期望的时间晚一周来邮寄自己的纳税申报表。大量的人类心理学怪癖都对这个现象产生过影响。著名的心理学家 Daniel Kahneman 称这种现象为“计划谬论”。Kahneman 认为计划者会忽略掉类似任务所需要的时间;相反,他们会给出任务走向的理想化进程。Kahneman 观察到,了解个案的人们很少会尝试探求这个个案到底属于哪一个统计分类。
平均的问题
对于项目的每一个步骤来说,实际完成时间超过或是低于平均完成时间的几率都是 50%。如果项目有两个步骤,那么这两个步骤的完成时间都超过或是低于平均完成时间的几率就是 25%。如果项目有 3 个步骤,那么这个几率就是 12.5%,以此类推。如果项目有 6 个步骤,那么其中一些步骤超过平均时间的几率就会超过 98%。
精确估算项目时间线的解决之道
为了探索并解决这个问题,我们提供了一系列互为补充的解决方案。这些方案可用于任何类型的项目管理,从图形化设计到火箭船的构建。
根据每个步骤的分布来计算项目时间线
总体的项目完成时间实际上是个分布,这是将项目中每个步骤的完成时间分布组合起来而得到的。一旦掌握了总体项目完成时间的分布,你就会知道中位数时间是什么,以及它为何会变长。
改进所有步骤的完成时间分布
现在,我们知道了项目总体的完成时间与每个步骤的完成时间分布息息相关。你可以重点关注两件事:让每一个步骤更快地完成(即降低中位数完成时间),以及让每一个步骤更加可靠。我们通过一系列手段改进了这两点:
- 流线化内部流程(比如说,谁提出来谁来做,而不是等待别人完成)
- 更短的内部截止日期,从而为客户提出的截止日期预留出足够多的缓冲期
- 根据时区来调度任务,减少协作者之间的延迟
- 及时通知客户,加快其响应速度
当项目延期时,有选择地改进步骤的完成时间分布
既然总体的项目时间线是由每个步骤构成的,因此改进其中一些步骤的完成时间分布会对项目时间线产生积极影响。归功于我们对项目数据所做的细粒度监控,我们能在延期时立刻做出反应,从而让项目管理团队能给予一些支援。我们发现在专门的项目管理时间上多花一小时能够极大地减少中位数完成时间。
希望你的截止日期能够更加精确
不切实际的截止日期对任何人都是无益的,半斤八两的管理手段是非常危险的。如果有数据,那就请好好利用。对于时间线来说,2+2 并不一定等于4。也就是说,一个步骤要花费 2 小时,另一个步骤也要花费 2 小时,但两个步骤加一起可能根本就不是 4 小时。如果你认为就是 4 小时,那结果就会陷入到“过于乐观”的泥潭中,这与完全没有数据作为支撑的估算没什么两样。
本文文字及图片出自 InfoQ
你也许感兴趣的:
- 【外评】电脑从哪里获取时间?
- 【外评】为什么 Stack Overflow 正在消失?
- Android 全力押注 Rust,Linux 却在原地踏步?谷歌:用 Rust 重写固件太简单了!
- 【外评】哪些开源项目被广泛使用,但仅由少数人维护?
- 【外评】好的重构与不好的重构
- C 语言老将从中作梗,Rust for Linux 项目内讧升级!核心维护者愤然离职:不受尊重、热情被消耗光
- 【外评】代码审查反模式
- 我受够了维护 AI 生成的代码
- 【外评】Linux 桌面市场份额升至 4.45
- 【外评】作为全栈开发人员如何跟上 AI/ML 的发展?
你对本文的反应是: