生成式AI领域的最新成果都在这里!抢 QCon 展区门票 了解详情
写点什么

为什么你的项目总是延期?

  • 2015-12-29
  • 本文字数:2065 字

    阅读完需:约 7 分钟

公司有个项目需要你来完成,老板让你给出个完成时间。当给出了项目完成的时间线后,你的老板会可能会将其分解为若干步骤,就像你之前所做的那样,然后分析每一步的完成时间,最后将这些时间加起来作为整个项目的时间线。不过,这样做就能确保项目按时交付么?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 小时,那结果就会陷入到“过于乐观”的泥潭中,这与完全没有数据作为支撑的估算没什么两样。

2015-12-29 09:162161
用户头像

发布了 88 篇内容, 共 258.3 次阅读, 收获喜欢 8 次。

关注

评论

发布
暂无评论
发现更多内容

为什么泡泡玛特是一个好生意

lidaobing

28天写作 泡泡玛特

作为社畜,如何做好精力管理

熊斌

精力管理 28天写作

基于网络开放可编程技术构建新一代网络设备运管平台

华为云开发者联盟

运维 网络 运维自动化 金融

自动驾驶到底应该怎么实现?(28天写作 Day4/28)

mtfelix

自动驾驶 28天写作 智能电动车

【Mysql-InnoDB 系列】锁

程序员架构进阶

MySQL innodb 28天写作

新官上任,如何开始你的管理工作(下)

一笑

团队管理 管理 28天写作

HDFS SHELL详解(5)

罗小龙

hadoop 28天写作 hdfs shell

【JS】防止浏览器控制台被直接查看(2)

德育处主任

JavaScript chrome 大前端 js 28天写作

技术干货!HDFS读写原理和代码简单实现

华为云开发者联盟

hadoop hdfs 架构 MRS 元数据

智能合约APP开发|智能合约系统软件开发

系统开发

影响DevOps和DevSecOps采用的7种趋势

啸天

安全 DevSecOps 应用安全

技术人小故事-团队愿景篇-第4段

Ian哥

28天写作

28天瞎写的第二百一五天:为了看片儿折腾 Linux 的故事

树上

28天写作

没有调查,就没有发言权 Jan 12, 2021

王泰

28天写作

SpringCloud 从入门到精通 07--- 订单服务和支付服务注册进Eureka

Felix

在时间的缝隙里打了个盹「幻想短篇 4/28」

道伟

28天写作

hive JOIN操作分析

梧桐

kafka如何做到无消息丢失配置

topsion

kafka 消息不丢失

距离Java开发者玩转 Serverless,到底还有多远?

博文视点Broadview

这5个让人窒息的烂代码,你看完都忍不了

华为云开发者联盟

GitHub 代码 代码注释 null

Python解释器和IPython

程序那些事

Python 数据分析 ipython 程序那些事 Python解释器

智联招聘的微前端落地实践——Widget

智联大前端

大前端

【薪火计划】11 - 学习总结

AR7

管理 28天写作

做视频最大的困难是什么?为什么要保持日更? | 视频号 28 天 (05)

赵新龙

28天写作

我是如何在短期内快速掌握Dubbo的原理和源码的(纯干货)?

冰河

分布式 微服务 dubbo 系统架构 服务治理

甲方日常 83

句子

工作 随笔杂谈 日常

生产环境全链路压测建设历程 27:FAQ 之 业务模型相关

数列科技杨德华

28天写作

微服务该如何拆分?

xcbeyond

微服务 方法论 架构设计原则 28天写作

SpringCloud 从入门到精通 06--- Eureka服务端

Felix

Dubbo 就是靠它崭露头角!

yes

dubbo 后端 RPC

Elasticsearch 核心概念

escray

elasticsearch elastic 28天写作 死磕Elasticsearch 60天通过Elastic认证考试

为什么你的项目总是延期?_语言 & 开发_张龙_InfoQ精选文章