读芯术DDL就是生产力？为什么我们无法准确估计项目用时？

全文共2500字，预计学习时长7分钟

本文插图
【读芯术DDL就是生产力？为什么我们无法准确估计项目用时？】图源：unsplash就算你是高级项目经理，就算你拥有20年的项目经验，就算你是天才也无法确切地知道一个项目的确切用时。这个问题在软件工程中尤为普遍，但在其他的工程学科中也时有发生。因此，虽然本文主要关注的是软件工程相关问题，一定程度上也适用于其他学科。普遍存在的事实是，软件项目很少能够按时完成。带来的后果是，营销的努力可能会被浪费，客户可能会不满意，压力重重的开发人员可能会编写质量很差的代码来赶deadline ，产品的可靠性岌岌可危。最终，项目可能会直接被取消。已知原因如下：· 错误地时间估计（本文重点）。· 项目开始时需求不明确，之后发生了需求变化。· 过分关注了工作外的细节。· 在研究和架构设计阶段没有花足够的时间，也可能花了太多地时间。· 忽略了第三方集成的潜在问题。· “一次解决”地愿望过于强烈。· 同时做太多项目或其他原因分心（打断完整流程）。· 质量和产能规模不平衡。邓宁-克鲁格效应：纯粹的不确定性or只是数学问题？

本文插图
规定时间内做不完，是不是因为我们过度乐观了呢？人们常常会忽略这个问题，常识告诉我们，在临近最后期限时，任何赶工的开发人员都不会是乐观的。有人将错误的时间估计归因于邓宁-克鲁格效应。但如果只是缺乏经验，高估了自己的能力或是低估了任务所需的时间，经验肯定能缓解这种境况。然而那些拥有近乎无限资源大公司，也常常错过截止日期，所以这个归因是不成立的。大多数开发人员，特别是有经验的开发人员，会认为这纯粹是因为不确定性，计划赶不上变化嘛。我们唯一能做的是，努力满足客户的需求，在事情出错的时候抓紧时间。我们都熟悉工作压力、垃圾代码和挑战截止日期时所造成的绝对混乱。这种焦虑有解决办法吗？这就是我们应对这个问题的最好方法吗？笔者并不这么认为，我试图找到一个合理的数学解释，解释为何所有的“聪明人”都无法估算他们做某件事需要的时间。纯数学解释

本文插图
有一天，我做了一项本该10分钟完成的任务，结果却花了2个小时。我开始思考其中误差的根本原因，思考过程如下：· 我认为这需要十分钟，因为我的脑子里百分之百知道我需要些什么代码。· 完成代码确实只花了我7-10分钟，最后总共用了两个小时，因为我没有预料到框架中的一个Bug 。人们喜欢在项目管理中被称之为“不可抗力” ，即延迟的外部不可控原因。读者可能会认为我的归因不具有代表性。当然，不确定性是这个任务延迟的根本原因是我根本没有猜到Bug的存在，但是这应该对整个项目的延误负责吗？这就是需要去做区分的地方：单个任务不能代表整个项目，反之亦然。人们通常是如何估计时间的

本文插图
通常的分布正态分布存在于我们身边各处，人类的大脑已经对此习以为常。如果你一个月去附近的711大概20次，每次大约五分钟。有时电梯需要维修，必须多等待10分钟，也有可能在下雨，你需要多等几分钟直到雨停。考虑这些情况，你现在觉得去一趟711要花多少时间？还是五分钟吗？笔者的意思是，就算回答15分钟，这个答案也是没有意义的，因为下雨和电梯维修是罕见事件，五分钟可能就是正确答案。如果20次里有18次都只需要五分钟，那么这次很可能就的确只需要五分钟（作为中值），可能性大约有90% 。（在不考虑更复杂代数的情况下）。倾斜即使很擅长估计一项任务的所需时间，也不意味着很擅长估计项目所需的时间。这常常是反直觉的。你肯定已经意识到之前模因中的小图表是一个右偏正态分布。让我们来具体看看：