软件项目估算永远不准怎么办？钱少时间紧未必是坏事

软件的估算，不管是整个项目的估算，还是某个具体交付任务的估算，都是世界难题。完成一个任务实际花费的时间总会超过计划花费的时间。但是作为客户、用户或业务，他们需要我们提供估算，以便确定一个项目的预算和交付时间。一方面我们面对一个项目，里面充满着巨大的不确定性，另一方面客户、用户或业务需要确定性，这对矛盾如何破解？如果这对矛盾无法破解，是否可以转移矛盾？

本场将通过实际经验分享，在估算不准确的情况下，钱少时间紧的项目如何也可以实现客户、用户或业务与 IT 的双赢。内容包括：

为什么软件项目估算永远不准
客户、用户或业务的预算和时间一定是固定的
钱少时间紧的限制并非坏事，如何利用这些限制，直击核心痛点，善用有限的预算和时间

软件项目估算不准确的原因

摘自李笑来的《把时间当朋友》第二版第 54 页：

错误估算任务所需时间，是最常见，也是最致命的错误。在时间领域有一个与墨菲定律同源、貌似悖论的侯世达法则值得牢记：

完成一个任务实际花费的时间总会超过计划花费的时间，就算指定计划的时候考虑到本法则，也不能避免这种情况的发生。

大家是不是有似曾相识的感觉。

为什么人们总是错误估计完成任务所需要的时间呢？因为大多数人在执行任务之前忽略了一个重要的步骤，那就是分辨任务的属性——它是熟悉还是陌生的？

有些任务是你所熟悉的，即以前曾经做过的。在这种情况下，正确估算时间是很容易的。

然而，有些任务是你陌生的，那么在执行过程中就必然会遭遇各种所谓的“意外”。其实它们根本不是意外，只不过是因为你对任务不熟悉，它们才成了“意外”。

很不幸，软件项目每次都在实现不同的目标、完成不同的东西，每次都是陌生的，充满“意外”，所以无法准确估算所需要的时间。

对用户来说，估算就是承诺

前面说了，软件项目由于每次不重样，估算无法准确。

但客户、用户并不会理会这些。他们的要求很简单，我提了需求，你告诉我要多少钱、花多少时间，我觉得 OK ，你就去做。

对用户来说，估算就是承诺。

但这样的后果也是显然易见的。

大家可以想象一下，在充满各种意外的项目执行过程中，原来的估算很快就会失效。但是由于估算被当成了承诺，项目经理习惯做的肯定就是粉饰太平。

而这种事情并非项目经理会这样做，项目经理也会一直过问 BA 、开发、测试等人员的进度，各角色也做过自己任务的估算，同样会被当成承诺，被问到的时候，也会粉饰。

但纸终究包不住火，这样下去项目一定会在最后时刻翻车，导致无法挽留的后果，所有干系方全盘皆输。

这不是项目经理和交付团队的无能，而是一种保护自己的应激反应。

训练有素的项目经理会试图及时管理估算不准确的问题，一旦发现有超预算或超时的苗头、原定的范围有变更，或者发现范围假设有误、发现了自己原来不知道的事情，就会启动变更流程。但在传统项目管理中，这个流程非常重，相当于重新立项，项目组也必须暂停交付支援，进行重新估算。这种费时费力的事情肯定是不到万不得已不做的。

限制未必是坏事

既然估算永远不准，又会被当作承诺。所产生的后果一定钱少时间紧，这个死结能破吗？

答案是肯定的，但我们需要一点创新的思维。有句话说的好，所谓创新，就是改变主要矛盾。

举个例子，需求与资源，永远是一对矛盾。面对无限的需求，一个思路是增加资源，招更多的人。但这也会极大地增加管理成本和难度，也无法保证人员素质和交付质量。另外一个思路是，把现有资源当作限制，倒逼用户对需求进行有效的价值和优先级排序，实现价值驱动交付，精耕细作，确保质量。这就改变了主要矛盾。

对于前文提到的问题，我们的思路一定不仅是提高估算的准确性，提高估算准确性可以在一定程度上缓解问题，但并不能完全解决问题。

估算是否精确，不应该成为一个考核点，因为这既不公平，也没有意义。

有一天和同事吃饭，我们聊到愚公移山。一个有趣的结论是，由于愚公移山这个“项目”并没有期限，因此它无所谓成功与失败。所以，无限时间、无限资源并不代表能带来成功。很多成功恰恰因为有限制条件。

阿波罗登月计划，一个很重要的成功因素就是有一个明确的目标和不可改变的期限。对于复杂项目而言，严格的期限意味着取舍。

当年，美国总统肯尼迪对于登月任务提出的目标是：“在 60 年代结束之前，要把人送上月球，然后再安全地返回地球。”

有了这个清晰的目标和期限，在项目推进过程中，管理者们思考的角度就变成了某个考量是会保证进度还是会拖延进度。一些更高级的技术、更复杂的实验，就算再有价值，如果没法保证那个期限，就会被搁置。

比方说，当时登月计划采用的燃料就是煤油、液态氢和液体氧，而不是更先进但未成熟、研发周期长的固体燃料。

明确的期限和有限的资源，为设置优先级提供了有力的依据。

1991 年，李安准备拍摄电影《推手》时，预算只有区区 300 万人民币，作为新手的他专门请了独立制片人来帮他控制预算、严控进度。在这种严格管理下，《推手》顺利地在 18 天内完工，投资方开心，也一举树立了李安在电影界的地位。这个独立制片人的作用，就是限制李安必须在预算范围内，对天马行空的想法进行取舍，确保进度与完成。

反观早年卓别林和其他几个著名导演，因为要摆脱好莱坞的制片人制度，一起创办了一家独立制片公司，里面都是导演这样的艺术家，没有专业制片人，不受预算约束，完全按照创作意愿来拍电影。

在这种“无拘无束”下，公司被一部叫《天堂之门》的电影制作搞垮了。该电影原始预算是 700 多美金，最终花了 4400 万美金，超支六倍多，票房却只有 400 万美金。

可见，限制并非坏事。利用好限制，反而可以把资源集中到核心目标上，实现最大价值。

把估算的结果作为限制

我们来看看软件项目估算到底确定了什么？它确定了预算（包括所需要的资源）和期限。

传统项目管理是以资源、期限和范围作为铁三角。理想模式是，这三者都不能变。出现意外时，范围不能变，然后通过增加人手或加班、延期和牺牲质量来弥补。

我们知道所谓敏捷模式，或者价值驱动交付模式是，资源和期限不变，范围可调，围绕着项目的核心目标，对范围进行持续地合理裁剪，让最有价值的部分先上线，产生效益并获得反馈，后续进行持续交付。

今年我们部门在预算上，也从过去的需求驱动型预算变成供应驱动型预算。

过去，只要业务部门有充足的预算，我们就照单全收，然后据此制定招聘计划。结果是如果某一年业务部门特别有钱，IT部门规模就需要快速扩张，招聘任务艰巨，培训也跟不上，同时要兼顾好几个大型项目，应接不暇，一地鸡毛。

今年，我们以现有的人员加上合理的人员规模增长作为预算，倒逼业务部门基于这有限的资源对项目进行取舍，确保我们能在有限的、高价值的项目上深耕细作。

实例：让 MVP 先跑起来

最近有一个项目，核心系统是一个定时发送报表的系统。系统需要配置定时发送时间、频率以及生成报表所需要的复杂参数。

过去，这些配置需要IT来做，每次配置都是一次正式发布，需要走标准的交付流程，业务觉得这样太慢，他们要求我们做一个UI，把这个功能开放给他们，让他们自己来维护，省却繁琐和冗长的交付流程。

为此，业务部门利用了一个特别预算来立项，因为这个特别预算是千载难逢的机会，过了这村没那店。在立项时，除了上面提出的核心需求外，也顺带提了十几个针对这个系统的其他需求。

结果这个项目仅需求就谈了一年多，没有什么实质进展。后来这个烫手山芋来到了我手上。

我和对接的业务人员明确说，这个项目剩余的预算已经不多了，而且我们的人手也很紧张，我们不会像以前那样再花几个月谈那十几个需求的设计文档，然后花几个月开发所有的需求，这样做到明年年底也未必能上线。

我们要先谈哪些需求是 MVP （最小可用产品），然后先做 MVP 的设计、开发、测试和上线，剩下的需求等 MVP 上线后再说。而且 MVP 应该只解决核心痛点，也就是允许用户自行配置的需求，不涵盖任何其他非核心痛点的需求。

由于 MVP 相对简单，范围可控，我们可以承诺在今年内把MVP交付上线。这既能保证交付能在预算内完成，又保证了今年内这个期限可以把对方的核心痛点给解决了。

业务答应了这个约定。

这个项目剩余不多的预算和时间，反而成了我们和用户谈判的有利筹码。这里博弈的重点是，不管对方提出了多少需求，核心痛点，也就是更快地完成报表定时发送配置，才是对方最急迫要解决的问题。在预算、时间和资源都非常紧张时，对方必须放弃不现实的期望，做出选择。

总结

软件项目的估算永远不会准确，完成一个项目实际花费的时间总会超过计划花费的时间。我们不应该紧盯如何提高估算的准确性这个伪命题，而是转换主要矛盾，把估算确定下来的预算（资源）和期限作为限制条件，围绕着项目目标，管理用户持续调整范围，实现价值驱动交付，并通过持续交付不断满足核心痛点和获取真实反馈。

本文首发于 GitChat，未经授权不得转载，转载需与 GitChat 联系。

阅读全文: http://gitbook.cn/gitchat/activity/5d5aa902f854f21d5e0cb272

您还可以下载 CSDN 旗下精品原创内容社区 GitChat App ， GitChat 专享技术内容哦。