时隔16年Jeff Barr重返10.23-25 QCon上海站,带你看透AI如何重塑软件开发! 了解详情
写点什么

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

  • 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:162426
用户头像

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

关注

评论

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

明道云帮助外贸行业实现数字化管理

明道云

构建多架构镜像的最佳实践

xcbeyond

Docker arm docker image xcbeyond 1月月更

JavaScript 基本数据类型转换

编程三昧

JavaScript 前端 1月月更

用Java实现线段树

CRMEB

Linux之cal命令

入门小站

关于jiami货币--《香帅中国财富报告》摘录(6/100)

hackstoic

投资

vue 作者在2022-2-7起宣布 vue3 正式作为默认版本

你?

C/C++开发方向如何选择?坚持C++还有意义吗?

赖猫

c++ Linux 服务器

在线XML转CSV工具

入门小站

工具

微信业务架构分析 & 学生管理系统架构选型

AragornYang

架构训练营 架构实战营

【网络安全】详细记录一道简单面试题的思路和方法

H

网络安全

第七周作业

lv

《腾讯云原生在线技术工坊》实践体会

穿过生命散发芬芳

腾讯云 云原生 1月月更 实践体会

音视频开发学习:HLS 协议详解

赖猫

c++ 音视频 ffmpeg HLS 音视频开发

使用 React 和 Next.js 构建博客

devpoint

React nextjs 1月月更

PDF 文件如何转成 markdown 格式

汪子熙

markdown PDF pdf.js 1月日更 1月月更

(1-18/18)推播式营销vs.集客式营销

mtfelix

300天创作 2022Y300P

(1-19/19)市场和销售分别该怎么干

mtfelix

300天创作 2022Y300P

🏆【Alibaba中间件技术系列】「RocketMQ技术专题」系统服务底层原理以及高性能存储设计分析

码界西柚

RocketMQ 阿里巴巴‘ Alibaba技术 Apache RocketMQ 1月日更

微信业务架构图 & 学生管理系统架构设计

阿卷

架构实战营

冬奥探秘:那些隐匿在冬奥中的“绿科技”

脑极体

ReactNative进阶(三十):Component、PureComponent 解析

No Silver Bullet

​React Native 1月月更 Component

ReactNative进阶(二十八):ES6 Symbol 用法

No Silver Bullet

React Native symbol 1月月更

大白话讲解JDK源码系列:从头到尾再讲一遍ThreadLocal

慕枫技术笔记

后端 1月月更

测试工程师的职场发展二三谈

老张

自动化测试 解决方案 职场发展

ShardingSphere JDBC 分库实现多数据库源

Java 数据库 分库分表 Apache ShardingSphere

kali权限提升之本地提权

喀拉峻

网络安全 信息安全 提权

22 Prometheus之Docker监控简述

穿过生命散发芬芳

Prometheus 1月月更

Go len() 函数是如何计算长度的?

宇宙之一粟

Go Go 语言 1月月更

低代码实现探索(二十九)混合式低代码

零道云-混合式低代码平台

电商秒杀系统架构设计

AHUI

「架构实战营」

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