何为计划谬误?
1977年,“计划谬误”一词最先由心理学家丹尼尔·卡内曼和阿莫斯·特沃斯基提出,它指人们低估任务完成时长的倾向。
卡内曼和特沃斯基指出在制定预期计划时,人们倾向于无视历史数据。我们的预期没有建立在历史证据(粉刷房间总是需一个月)上,而是仅关注下一个任务的特点(房间小,不会花太长时间)。
2011年,卡内曼在《Thinking Fast and Slow》书中作了进一步阐释。他认为估计错误常可归咎于以下两个关键因素:
-
没有考虑过去类似任务的完成时间
-
大胆假设不会出现耽误工期的复杂情况
但好消息是如果我们弄懂了低估工期的缘由,那么我们便可以避免掉进计划谬误的陷阱里,制定更加实际的预期计划。
计划谬误与《人月神话》中的片段相似
对于软件项目进度的估算往往会根据项目的紧急程度而得出过于乐观的结果,这一方面是因为所有的编程人员都是乐观主义者,我们往往会认为“这次肯定能运行”或者是“我已经找出了最后一个bug”,另一方面则来源于市场的压力,这种情况在国内环境更甚。我们对于进度估算的第一个错误假设就是:一切都将运作良好,每一项任务仅花费它所“应该”花费的时间。而这个假设往往是一厢情愿的,对于创造性工作来说,创造者常常是在实现过程中,才发现在构思设计时候的不完整性和不一致性,从而反馈到的构思设计上,处理这种问题的时间和复杂程度会随着项目的结构以及任务的大小而呈现非线性增加的关系。所以对于大型软件项目来说,“一切都将运作良好”就是一件概率非常小的事情了。
在软件项目中我们往往用人月这个指标在衡量项目的工作量。但是人月这个指标实际上是一个危险的带有欺骗性的神话。它暗示着人员数量和时间是可以互相替换的。只有在将任务分解给参与人员后他们之间不需要互相交流的情况下,人数和时间才是可以互换的。在实际软件项目中,只要项目具有一定规模,不论是设计、开发、测试、部署各个阶段都会有分解任务给不同人员,而且这些阶段本身也属于一种任务的分解,在不同人员间分解任务就不可避免的引发额外的沟通成本——培训和相互沟通。因为软件开发本质上是一项系统工作——错综复杂的关系下的一种实践,沟通、交流的工作量非常大,它很快会消耗任务分解所节省下来的个人时间。简单来说就是,3个人要干3个月的事情不是说安排9个人就能1个月干完了。而且,在进度落后的项目中增加人手的做法,往往只会使进度更加落后。这就是去除了神话色彩的人月。