估算是项目管理的起点，是资源分配的前提，这点似乎并无争议。但即使如此，估算的价值也还欠缺一个直接的逻辑支撑。为回答这一问题，我们来看一个现实问题。
在现实中，几乎每天都在上演的故事是：估算不准，工期又被定死，结果是经常加班赶进度。这类场景已经多到了让“软件是一个天生就加班比较多的行业”成为一种共识的地步。
从执行过程来看，在持续赶进度的同时，个人工作意愿会受到负面影响。与此同时由于进度压力，有些基础的东西如函数圈复杂度、代码结构、编码规则等会因为和最终产品功能关联度较低而被忽略。这最终会给后续工作造成障碍，增加内耗。
从结局来看，估算和实际需要偏差较大的情况下，可能有3类不同的结果。
1）工期和质量进行对冲，最终保证工期，但会得到三流的代码。
2）即使忽视部分质量，也无法保证进度，成本超支，延期完成，最终得到三流代码。软件作为一种固化的思维，一旦达到一定规模后，清理和维护凌乱的代码就比重写还困难。在这一情况下，会出现预计人月为5，实际需要人月为10，最终用掉的人月却是15的情形。
3）延期，成本超支等过于严重，项目取消。形象来说就是，浮沙筑高台，用的材料也不好，最终坍塌了。
上面几类情形下，事实上没有赢家，而其核心矛盾在于投入资源与预期目标间的比例失衡。
避免出现上述问题的方法也很简单，那就是让项目负责人对项目的可达成目标与预期目标间的差距有一个清晰的认识，进而进行选择和集中，这就是估算的根本价值。比如，如果估算显示需要15个人月，现实中只有10个人月，那么显然应该调整工期或者削减对应的特征。(www.xing528.com)
估算中究竟蕴含了多大风险
在《与熊共舞：软件项目风险管理》中，作者列出了5项核心风险，它们分别是
●进度安排的先天错误。
●需求膨胀。
●人员流失。
●规约崩溃。
●低生产率。
其中与估算直接关联的“进度安排”位居第一位。这应该是统计了许多项目后的数据，不容忽视。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
