跳转到主要内容
Chinese, Simplified

在这篇文章中,我们将探讨“不确定性锥”如何影响数字项目,以及如何利用它来改善协作,并构建更好、更快、更便宜的东西。

在复杂的数字项目中,为固定范围估计固定费用的模型会让团队面临潜在的失败。虽然项目利益相关者可能在项目开始时就清楚地了解期望的结果,但没有人可能在一开始就知道每个项目的细节。

相反,通过详细的发现过程或产品路线图参与,项目利益相关者通过合作建立共识,直到前进的道路变得清晰。

用项目管理的话说,在项目谈判和更好地理解确切规范之间的这段时间被称为不确定性锥。如果处理不当,可能会对您的项目造成严重破坏。

一个破碎的过程

承担固定投标固定范围项目的机构会让自己和他们的项目走向失败。当出现超出范围的请求时,无论这个想法有多好,他们都必须推迟,以遵守预算或时间表。

当客户被告知可能提高最终产品质量的新想法将产生额外成本或推迟目标截止日期时,他们会感到沮丧。在这种情况下,客户和代理机构就最佳潜在结果进行合作的自由度是有限的。这是RFP存在问题的众多原因之一。

一次又一次,项目团队以信守合同承诺的名义,在创造力和质量方面妥协。这种限制意味着代理商只能制造出满足客户和最终用户需求的平庸产品。

更糟糕的是,许多客户陷入了一种“一口咬定”的心态。他们不会试图根据收集的数据来随着时间的推移改进产品。这浪费了更快实现目标的宝贵机会。为什么不从一开始就努力争取最好的结果呢?在保持截止日期和预算的同时,是否可以采用协作、创造性的方法?

如果项目利益相关者愿意共同承担一些风险的话。

不确定性的锥

预算和时间表通常基于特定的项目要素。因此,客户编写详尽的RFP,概述尽可能多的项目变量。数字机构——或者任何从事大型项目的服务提供商——通过提前估算来补偿。

这次谈判耗费大量时间和资源。此外,它通常会产生不准确的结果。招标机构的报价通常是实际实施成本的四倍。

不确定性锥概念起源于20世纪50年代工程和施工管理的互联网之前。然而,它在很大程度上适用于今天的数字项目。前提是任何项目在其生命周期中都有一个不断减少的不确定性范围。

Graphic illustrating the Cone of Uncertainty

An example from Agile in a Nutshell shows how the Cone of Uncertainty impacts estimate variability and project workflow.

不幸的是,在大多数数字项目中,团队都是在最不确定的时期提前完成所有财务和合同谈判的。这是一个重大问题。

虽然详细的规格很有帮助,但提前完成每一项任务、功能和设计要求会限制构建更好产品的自由度。事实上,一旦每个人都卷起袖子投入到这个项目中,伟大的想法就会出现。探索研讨会带来了精彩的新功能请求。用户体验会议会带来在谈判过程中可能没有考虑到的客户见解。但是双方已经同意了他们的条件。

“不”的文化

这种固定出价固定范围的方法建立了一种基于消极性的项目文化。通过不断努力维持范围、预算和法律义务,各机构别无选择,只能温和地拒绝未事先讨论的请求。建立信任和相互尊重的关系将更好地为项目利益相关者服务。

当然,您可以将所有的新想法放在“第二阶段”列表中,以便以后实施。但是,如果其中一些想法能够从根本上改变项目的成功潜力呢?为什么不接受不确定性的锥,承认你并不了解一切呢?双方可以重新确定功能和预算的优先级,然后共同努力,追求对所有人都有更高价值的东西。不幸的是,这不是很多项目的运作方式。

如果你接受在学习新事物时产生的所有伟大想法,你也必须接受一个不断变化的范围。不确定性的锥决定了这一点。否则,你会有一个大象大小的项目,范围膨胀,但盈利能力下降。此外,每当有新的想法出现“对不起”时,人际关系就会变得紧张

用敏捷拥抱不确定性

多年来,我们一直在写关于敏捷方法的文章。当项目有意义时,我们会雇佣他们。它们并不完全适合每个项目,但在范围更大的项目中效果良好。敏捷方法要求通过不断的用户研究和测试,将项目分解为可管理的小块,并内置反馈和协作机制。

敏捷公司权衡可变性,并致力于首先实现最高价值的可交付成果,而不是提前做出承诺。这些高价值的可交付成果首先解决了最大的问题,并在项目后期留下较小的挑战,因为时间和预算可能会更紧。这有助于他们降低风险,并利用不确定性对每个人都有利。

更重要的是,敏捷项目要求业务关系建立在相互信任和承诺提供最佳解决方案的基础上。

具体来说,敏捷要求团队致力于:

  • 定期沟通时间、预算、反馈等。
  • 持续的动手协作和共享学习
  • 在最有意义的时候延长或停止项目的自由

让敏捷在商业中发挥作用

时间构成了你的生命,所以浪费时间实际上是一种缓慢的自杀。

--Jeff Sutherland,《Scrum:在一半时间内完成双倍工作的艺术》一书的作者

Jeff Sutherland在其著作《Scrum:The Art of Doing Twice The Work In Half Time》中,告诉了一家软件公司的故事。(Scrum是一个用于管理产品开发的迭代和增量敏捷软件开发框架。)在萨瑟兰的故事中,软件公司和客户都是赢家。项目详情如下:

软件公司提供了一份项目估算,明确表示他们包含了所有的未知因素,这些未知因素可能会影响时间和可交付成果。

该公司将首先使用敏捷方法来关注最高价值的交付成果。这些可交付成果将以商定的增量提供,以推动计费。

客户可以随时取消项目,只需支付相当于整个项目一小部分的终止费。

在萨瑟兰的故事中,该公司估计该项目可能需要20个月的时间。通过专注于最高价值的可交付成果,该公司仅用了四个月就交付了客户所需的东西,因此客户停止了该项目。客户采用这种方法节省了大量资金。软件团队只完成了他们预期的一小部分工作。该公司收到了20%的项目终止费。这增加了利润率,并打开了团队进行其他项目的时间表。

在下一个项目中拥抱灵活性

采用这些做法的公司将建立长期的客户关系。预算、时间和期望都得到了管理。然而,两党都没有做出最终无法兑现的承诺。客户可以更快地获得更高质量的数字解决方案。用户很高兴。数字机构更好地管理盈利能力。信任得以维持,人际关系得以发展。每个人都赢。

如果你想了解更多关于迈向敏捷过程的信息,请阅读我们的文章《如何从瀑布过渡到敏捷方法》。更好的是,下载下面的敏捷白皮书。

原文地址
https://www.mightybytes.com/blog/cone-of-uncertainty/
本文地址
Article

微信

知识星球

微信公众号

视频号