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

全文共2500字 , 预计学习时长7分钟
读芯术|DDL就是生产力?为什么我们无法准确估计项目用时?
文章图片
图源:unsplash就算你是高级项目经理 , 就算你拥有20年的项目经验 , 就算你是天才也无法确切地知道一个项目的确切用时 。 这个问题在软件工程中尤为普遍 , 但在其他的工程学科中也时有发生 。 因此 , 虽然本文主要关注的是软件工程相关问题 , 一定程度上也适用于其他学科 。 普遍存在的事实是 , 软件项目很少能够按时完成 。 带来的后果是 , 营销的努力可能会被浪费 , 客户可能会不满意 , 压力重重的开发人员可能会编写质量很差的代码来赶deadline , 产品的可靠性岌岌可危 。 最终 , 项目可能会直接被取消 。 已知原因如下:·错误地时间估计(本文重点) 。 ·项目开始时需求不明确 , 之后发生了需求变化 。 ·过分关注了工作外的细节 。 ·在研究和架构设计阶段没有花足够的时间 , 也可能花了太多地时间 。 ·忽略了第三方集成的潜在问题 。 ·“一次解决”地愿望过于强烈 。 ·同时做太多项目或其他原因分心(打断完整流程) 。 ·质量和产能规模不平衡 。 邓宁-克鲁格效应:纯粹的不确定性or只是数学问题?
读芯术|DDL就是生产力?为什么我们无法准确估计项目用时?
文章图片
规定时间内做不完 , 是不是因为我们过度乐观了呢?人们常常会忽略这个问题 , 常识告诉我们 , 在临近最后期限时 , 任何赶工的开发人员都不会是乐观的 。 有人将错误的时间估计归因于邓宁-克鲁格效应 。 但如果只是缺乏经验 , 高估了自己的能力或是低估了任务所需的时间 , 经验肯定能缓解这种境况 。 然而那些拥有近乎无限资源大公司 , 也常常错过截止日期 , 所以这个归因是不成立的 。 大多数开发人员 , 特别是有经验的开发人员 , 会认为这纯粹是因为不确定性 , 计划赶不上变化嘛 。 我们唯一能做的是 , 努力满足客户的需求 , 在事情出错的时候抓紧时间 。 我们都熟悉工作压力、垃圾代码和挑战截止日期时所造成的绝对混乱 。 这种焦虑有解决办法吗?这就是我们应对这个问题的最好方法吗?笔者并不这么认为 , 我试图找到一个合理的数学解释 , 解释为何所有的“聪明人”都无法估算他们做某件事需要的时间 。 纯数学解释
读芯术|DDL就是生产力?为什么我们无法准确估计项目用时?
文章图片
有一天 , 我做了一项本该10分钟完成的任务 , 结果却花了2个小时 。 我开始思考其中误差的根本原因 , 思考过程如下:·我认为这需要十分钟 , 因为我的脑子里百分之百知道我需要些什么代码 。 ·完成代码确实只花了我7-10分钟 , 最后总共用了两个小时 , 因为我没有预料到框架中的一个Bug 。 人们喜欢在项目管理中被称之为“不可抗力” , 即延迟的外部不可控原因 。 读者可能会认为我的归因不具有代表性 。 当然 , 不确定性是这个任务延迟的根本原因是我根本没有猜到Bug的存在 , 但是这应该对整个项目的延误负责吗?这就是需要去做区分的地方:单个任务不能代表整个项目 , 反之亦然 。 人们通常是如何估计时间的
读芯术|DDL就是生产力?为什么我们无法准确估计项目用时?
文章图片
通常的分布正态分布存在于我们身边各处 , 人类的大脑已经对此习以为常 。 如果你一个月去附近的711大概20次 , 每次大约五分钟 。 有时电梯需要维修 , 必须多等待10分钟 , 也有可能在下雨 , 你需要多等几分钟直到雨停 。 考虑这些情况 , 你现在觉得去一趟711要花多少时间?还是五分钟吗?笔者的意思是 , 就算回答15分钟 , 这个答案也是没有意义的 , 因为下雨和电梯维修是罕见事件 , 五分钟可能就是正确答案 。 如果20次里有18次都只需要五分钟 , 那么这次很可能就的确只需要五分钟(作为中值) , 可能性大约有90% 。 (在不考虑更复杂代数的情况下) 。 倾斜即使很擅长估计一项任务的所需时间 , 也不意味着很擅长估计项目所需的时间 。 这常常是反直觉的 。 你肯定已经意识到之前模因中的小图表是一个右偏正态分布 。 让我们来具体看看:【读芯术|DDL就是生产力?为什么我们无法准确估计项目用时?】