估算三“不”原则
估算三“不”原则
先偷偷拍脑袋，形成一个内心中的估算结果；
进行科学估算，得到一个估算结果；
调整参数，最后科学估算结果符合拍脑袋结果；
科学估算结束！
尽管估算并不精确，但是用估算做计划是没有问题的。而如果要求团队根据不精确的规模估算结果，承诺开发完成时间（上线时间）就不对了，这是因为这：
可能会让估算变得非常保守：当团队明白估算会被当成一个承诺时，团队往往会倾向于自我保护，放大估计值，这也很容易理解。以前，我的老板，软件工程大师Ivar曾经说过，他会把他的初步估计乘上一个π，来给出一个承诺；
可能会伤害信任：由于得到了保守的估算（承诺），一些懂开发的业务人员就会质疑为什么会要这么长时间，开发会给出一个表面上的技术原因，但是不信任的种子已经埋下了。有些业务部门甚至逐渐会派生出专门和研发讨价还价的组织，这就是我们常说的“合同游戏”了；
可能会损害质量：如果强行让研发人员按一个乐观估计去承诺可以按时完成工作，这时如果研发团队不够成熟，他们就很可能为按时交付而放弃质量标准，这样会按时交付一个低质量的产品，这往往会损害商誉。
软件开发是一个复杂的信息发现过程（用户要的是什么？如何才能实现？实现的质量如何？等等）。这个过程中不断有新信息被发现，整个过程是一个高度动态的。在这个过程中，利用估算信息进行微观管理是一个费力不讨好的事，下图就是一个我个人不太认同的例子，用甘特图去微观管理每个开发测试的任务及依赖关系。
因此，我不建议领导关注计划达成率等微观进度指标，这个和把估算当成承诺是一个意思，也会产生上述负面作用的。
上面我们说了估算三“不”原则，下面我们就根据两种不同场景，介绍我们建议应如何应对估算不准确的挑战：
大型项目开发 49 30730 49 15231 0 0 5165 0 0:00:05 0:00:02 0:00:03 5164
大型项目的特点是有一个明确的计划上线时间点和一个初步的需求范围。在这种项目的开发过程中，我们建议利用用户故事和相对估算技术，快速框定项目范围，按业务优先级排定计划，迭代交付，下图就是我们之前辅导的一个敏捷快速启动项目。
尽管估算不准确，但是它足以帮助团队根据业务优先级和初步估算工作量，选择尽可能合理的方式排定迭代计划，先启动开发，并在迭代过程中不断根据实际研发进度来进行调整。在这种项目当中，真正的关键在于让领导接受“确保上线时间，但需求范围可调”的原则，通过不断调整需求范围来确保准时上线。
另外,也需要项目研发过程中，不断用看板和累积流图来实施透明研发进度和风险，进一步强化业务和研发的信任关系。
2. 已有系统维护：
对于系统维护工作，其主要特点是需求不定期到来，没有明确的上线时间点要求，但是都希望尽快上线。这时估算可以作为一种团队沟通手段，你认为工作量大，我认为工作量小，为什么呢？ 我们谈一下看看是不是大家理解有出入。
但对于这种系统维护工作，不应该用计划完成率指标来管理团队，否则，上面说的估算当承诺的坏处就都找上们来了。国外目前有一个思潮：“No Estimation”运动，如果大家感兴趣，可以点击阅读原文链接进行延伸阅读。
在系统维护工作当中，我们建议可以考虑用统计指标来替代基于估算数据的计划完成率指标，即统计端到端前置时间分布情况（根据每个需求从提出到上线时间画出下面的图形）
这样我们可以计算出“在85%的情况下，团队可以在多长时间内完成一个功能”，我们把这个指标称为“85%需求交付时间”。团队不需要再进行估算，而只需不断优化去改善这个指标即可。业务部门则可以直接使用这个指标和需求紧迫程度去计划一项工作应该何时启动。
在软件研发过程中，需要整个团队尤其领导需要转变思维方式，从确定性思维转向不确定性思维，上面这个思路的变化类似于从经典物理学进化到量子物理学、统计物理学，这方面后续我们再专文阐述。
希望这篇文章可以帮助各级领导初步理解不确定性思维，统计思维，更多精彩内容请长按一下二维码，关注我们的微信公众号：互联网plus管理新范式。
回复：看板方法，进一步了解看板方法
回复：CFD，进一步了解累积流图
[1]https://en.wikipedia.org/wiki/Software_development_effort_estimation
[图1]http://www.techwell.com/2013/09/mastering-black-art-software-project-estimation
[图2]http://teamgantt.com/blog/2014/03/how-to-use-gantt-charts-for-your-agile-project/
[图3]http://www.applitude.se/tag/scrum/
[题图]http://www.simplilearn.com/useful-pmp-terminologies-article