处理可怕的估计

我最近从事的一个项目被建筑师严重低估了。估计至少超出了500％。

不幸的是，在与客户签署估算之后，我才被带入该项目。作为高级开发人员，我很快意识到了功能和技术规范。包含一些巨大的差距和不确定性。

结果，我感到不得不与业务和技术主管召开紧急会议，让他们了解现实。作为开发人员的首要任务，我发现这是一个非常压力和困难的情况。“企业”指责IT不称职，是我收到的一些“子弹”使者。

客户威胁要取消该帐户，但是迄今为止该项目仍未完成，我不再直接参与其中。

这位建筑师在社交上是一个好人，但基于这一事件，他要么完全无能，要么存在巨大的销售/业务压力，影响了他的估算。

因此，作为程序员，您对这种情况有何经验？您会如何建议处理这种情况？

好长的回复，但是，嘿，我最后有一个摘要，所以如果您不厌倦阅读整本书，请跳过摘要！

作为开发人员，我不得不处理几乎所有其他项目的情况，但是直到我进入项目管理后，我才知道如何有效地处理它。对我来说，有效地交易大约有两件事：管理期望和了解估计的工作原理。

首先要提供一个前提，即不能先进行一些尽职调查就提供评估，承诺进行评估或提供任何其他指示评估准确性的想法，这是不道德的。其他人依靠您的专业能力来预测所需的工作量，提供错误的指示会伤害他们及其业务。

但是您必须提供一些东西，在现实生活中，您被拖入即席会议或较晚的项目中，而您的上司可能会清楚地表明，他们希望您马上提出一些数字或评论他们提供的估计值。这就是期望管理的作用。

说明如果您不理解问题并自己计算出数字或给出任何指示是错误的。说他们的数字可能是正确的，您只是自己进行估算练习之前不知道。即使您可能对那里需要什么以及何时什么都有一个很好的了解，还是说您仍然需要一些时间来计算出这些数字。他们可能只希望您提供一个估计值：何时可以提供估计值。一定要提供那个数字。

作为开发人员，切勿对其他人的估计负责（或给出可以被接受的表示），而无需先进行评估。作为项目经理，这是完全不同的事情，因为您实际上对估算过程具有一定的控制权：估算的得出和审查方式，您必须依靠其他人来完成实际工作，而您需要进行确保他们决心。

在无法进行尽职调查的情况下，切勿对评估发表评论。这是道德的。律师或医生将绝对清楚地表明，除非客户（或患者）遵守其规定并首先通过评估程序，否则他们不会给出任何建议。同样，您有权在提出专业意见之前满足您的问题。

第二部分是关于估计如何工作的。我建议研究进行估算的各种方法以及估算过程的工作方式，包括软件开发以外的行业（制造业，金融市场，建筑业）。这会让您知道老板或客户可以合理地期望您做什么，并且奇怪的是，这将有助于对工作量做出更准确的预测。它将提高您捍卫您的估计的能力，并且每次与建筑师或销售人员提供的数字不同时，您都需要捍​​卫这些数字。

通常，它的工作方式是先对估算值进行扫描，以查找外观奇特或相对较大的项目。因此，准备捍卫任何带有“非标准”名称的东西。同时拆分较大的任务，以使所有任务具有相同的数量级，即，如果大多数任务需要2天，而单个任务是10天，则准备进行钻取。

要清楚每个任务中包含的内容，最好是将开发人员测试和单元测试分开，而不仅仅是让开发人员和有人认为它也包括文档。显然，这种方式需要产生相当精细的估计。

接下来钻进。由于要审查长时间的工作分解非常困难，因此您的客户或老板可能会采取不同的策略：专心一点，他们可能会知道一些东西，然后深入研究，直到他们设法使整个估计声名狼藉或对您满意为止答案。整个评估的可信度可能取决于随机样本！因此，您再次需要时间精心准备，仅包括相关部分，排除任何额外内容，或将它们移至“精打细算”部分，并仔细考虑如何捍卫数字。

显然，您可以在方法上保持一致，即根据功能，屏幕数量等进行估算，也可以采用多种方法混合使用，但无论如何都要做好捍卫您选择某种估算方法的准备。还应准备解释为什么您的数字与其他人预测所需工作量的尝试不同。

了解估计不足的明显迹象：

• 从模板复制了常规的常规任务（良好的估算值特定于手头的任务）。

• 粗略的估计（即，任务超过几天）。

• 在项目早期或由可能不真正了解需求或工作的人进行的估算。

• 除实际人员外，其他人编制的估算

• 估算值含糊不清（不清楚包含和同样重要的是什么）。

• 任务量级的实质性差异。

在没有实际了解实现细节的情况下评估他人估算和钻取数字的实践。当您在没有确凿证据的情况下要求确认别人的估计时，这将有助于您的索赔多花费一些时间。

总结一下：

• 在您有机会进行尽职调查之前，请不要对此事做出任何可怕的估计。

• 一开始要讲清楚，不要让任何人以其他方式认为这件事，并将您的沉默解释为达成协议的标志。

• 了解各种估算方法如何工作，它们的实际应用和优点，包括这些外部软件开发。

• 准备捍卫您的估计。

• 了解如何评估其他人的估算值，这样您就不必致力于非常不准确的数字。

预测未来是不可能的。要求预测（“估计”）只是在麻烦。每个人都这样做，每个人都弄错了。

您对“超出500％”的判断可能与建筑师的估计一样错误。毕竟，“ ...到目前为止，该项目仍未完成...”这里没有事实。

没有人知道“正确”的答案。直到完成，没人会知道。

甚至在完成之后，“原始”估算（有或没有变更控制）也可能与实际完成的任何事情都不相关。

估计是一个陷阱-这是一个操纵游戏。您不会赢，无法收支平衡，甚至无法退出游戏。

编辑

处理不好的估计；一个“遗留”的估计似乎是错误的。

在那里。您不同意别人的估计。他们要么忽略了您认为必要的内容，要么 他们的工作范围与您不同，或者他们的生产率不同。同样，如果估算的不仅仅是工作量，则成本基础也不同。所有这些都是有争议的。因此，对导致估算的细节提出异议。不要质疑总数- 摘要中没有真实的信息。争议作为估算基础的各个细节。找出他们在想什么。

您的假设和他们的假设一样有错误的可能性。同样可能。

当要求估计。

1. 你会错的。

   1. 它们在于工作范围。

   2. 您不知道团队的生产力。

   3. 任何涉及新技术的陈述都是错误的。

2. 您不能只添加填充来随机覆盖这些内容。您实际上不知道也没有“估计”的依据。这只是猜测。克服它。

规则1：由于您只是猜测，所以要以较小的增量进行猜测。

在任何“估计”的情况根本问题是不是预测未来。在超过一两周的时间内，您无法做到任何准确性。将您的预测限制在您拥有直接和即时详细知识的时间范围内。例如，下一个版本。

最基本的问题是-通常-您的购买者或客户的决策。问题不是“成本是多少？” -还不完整。问题是“投资值得吗？” 真正的问题更多是围绕“成本/收益比是多少”和“什么时候应该停止支出，因为更多的投资不会产生更多的回报？”这样的问题。这些才是真正的问题。

规则2：以事实信息为决策者提供支持。

敏捷方法可以为大多数人提供最好的服务。第一个版本-从现在开始的一个月-将耗时5人×4周，它将产生功能X来弥补每天损失100万美元的损失，功能Y来解决每周失去20万美元的机会。您对正在做的事情有详细的了解，因此这种预测很有意义。之后的发布有些模糊。

从现在开始一年后的发布到未来为止，任何预测都只是一个随机数。未来6个月内不要流汗任何细节，只需使用简单的经验法则即可。

当他们询问TCO是什么时，您必须诚实。“总成本发生在您停止支付开发费用时。在停止支付之前，您将永远产生成本。”

真正的问题是“您要解决哪些问题？” 或“您正在寻求什么新机会？” 和“那值多少钱？”

规则3：使软件的成本低于应解决的问题。

如果您不太清楚问题所在，那么将根据估计来进行估算。尽量避免这种情况。

论概率。除了使疾病或事故恶化之外，软件开发的任何部分均不受实际概率的约束。“风险”简直就是糟糕的管理。通常形式为“我们没有考虑业务需求A或技术B的复杂性”。通常是“随着我们对问题或技术的了解越来越多，我们更改了时间表”的形式，这种形式被称为“范围蠕变”。

没有学习东西和改变范围的可能性。可以肯定的。

论规划。有“计划”和“估计”。计划构建什么是一回事，最好用清单或依赖图表示。“估计”所需的努力是基于不可知的因素。

“计划”是普通的良好管理。

“估计”需要不可知的知识。要准确地“估计工作量”，您必须对产品具有源代码级别的洞察力，并且必须知道哪个人将键入该源代码以及个人将犯什么错误。由于您可能不知道，因此任何估算都一定是错误的。而且经常会误导点，因此毫无用处。

如果估算超出500％，并且该项目仍在进行中，则估算有什么价值？

没有。它所做的只是使人们不高兴。但是无论如何，该项目还是取得了进展。

由于没有人能看到未来，因此正确估算并没有任何意义。使其有用，帮助人们做出决定。

保持短暂。尽快交付价值。创建一个计划，使客户可以随时取消该项目并仍然有价值。

不要让计划成为项目中唯一的“神圣真理”。可交付的功能是神圣的。其他所有事物都应随着交付成果的变化而变化。

不要让计划超出其创造的价值。

如果没有足够的时间，则没有足够的时间。无论如何，没有神奇的解决方案可以完成项目。我认为您已经做了说明。原来，他们必须找出困难的方法。通常情况就是这样。希望架构师和管理人员已从错误中吸取教训，并且不再犯错误。如果在管理层太无知以至于无法听取您的论点并采取适当的措施的情况下照常做事，那么寻找其他项目或其他公司可能是个好主意。

“开发人员是手工业者，而对手工业者来说，最糟糕的事情就是让他交付a脚的产品。” 来自某处的著名语录，但我不记得来自何处。

诚实应该始终得到尊重。我当时正处于“建筑师的构想”的接受端，当开发人员向我提出有关整个解决方案无法正常工作的可怕消息时，我们来到了业务部门，进行了艰苦的交谈。然后，开发人员提出了一个新的估算值，该估算值包含80％的功能，但他按时交付了预算。

开发人员如实地与他们交谈，承认他的公司的短处以及像狗一样努力工作，从而赢得了业务部门的青睐。在过去的7年中，我们一直为这个人工作，因为他一直很诚实。

整个场景是如此罕见-大多数时候，业务部门认为您是无法交付的白痴。您需要找出那些不这样做的客户，因为从长远来看，您将获得更多的收益，而不是想要取悦那些只想把您当成一个混蛋的克里丁人。

对于不了解其领域的建筑师，请避免像瘟疫一样躲避他们。我曾经有一位导师曾经苛刻地与我加强合作：“这是。不是。是为了。练习！” 他只会容忍错误，只要您尽早纠正，改正并且再也不会犯错。允许非技术人员，经验不足的人与客户保持联系的公司，因为他们可以“沟通”，因此应倒闭。

我曾经面对过这种情况。项目用完了，这是因为业务更改了需求，并且存在沟通空白，高级管理层希望按时完成该项目。更糟的是，正在从事该项目的一个人被拉出以填补另一个具有更高优先级的空白。

我的团队整夜都在完成项目。一夜深夜，大约在凌晨3:00（我连续工作19个小时），我给我的经理发了电子邮件，要求对此进行处理。

第二天我们开会（只是开发人员）。整个团队都参加了一个周末，甚至在项目完成之前就对其进行了测试。很少有人会加入团队进行快速修复。最后，我们能够在整个团队（不仅仅是项目团队）的努力下交付项目。对于其他项目，我们遵循相同的过程。

整个团队（即使他们不参与该项目）也测试了该应用程序并帮助快速修复了错误。

注意：我的团队由大约25个人组成，这些团队又有从事不同项目的子团队。

我唯一的建议是“与经理交谈。请务必告诉他们项目不能按时交付。也请给他们其他选择。经理总是希望婴儿能按时交付，无论如何:)”

尽管企业通常不喜欢事情花的时间比预期的长得多的事实，但他们宁愿花更少的时间。您越早告知某人真​​正需要花多长时间，每个人都可以更快地针对这种情况进行计划。尽管最初可能是艰难的时期，但从长远来看，它将变得更加容易。只是第二次就做对了，并建立了偶然性。

让我在与您的管理层打交道时强调一个关键点：经理们喜欢解决方案。

如果您有问题要去管理（例如，估算是非常不现实的），请事先努力为解决问题提供替代方案。例如，您可以进行帕累托分析（80/20规则）以了解系统的价值，可以优先考虑切割功能（至少从第一个版本开始），以专注于具有最大业务价值的功能，您可以寻找替代品（开源项目等），这些替代品可以替代系统的自定义部分，等等。

毫无疑问，一个5磅重的袋子不会装满25磅的沙子，但是帮助您的管理人员吸收您不愉快的信息的一部分，就是提供您是一个忠诚的盟友的证据。

您可能对我之前写过的这篇IEEE文章感兴趣。这里是重点。

• 导致项目失败的最大因素之一是过于乐观的估计。
• 估算值过低的一个重要原因是高层要求尽早交付的压力太大。
• 另一个是实施期间的范围变动，而无需重新评估这些估计。

首先，我将非正式地与有问题的建筑师交谈，并通过他的估算列出您所遇到的问题，并尝试说服他问题出在哪里，以及解决问题所花费的时间。

然后，我尝试去找您的直线经理/项目经理，与他/他们讨论。

归根结底，架构师给出了ESTIMATES，因此它们可能会发生更改，有时可能会进行大量更改，只要他们意识到了这一点，便可以制定替代计划，例如将产品推向市场。阶段，减少其功能或其他方式。

归根结底，一旦您完成上述操作，就不再是您的责任。

您绝对不应该直接去拜访客户或建筑师老板，这只会加剧不良的感觉，几乎总是会引起一些责备。

您可以做的最好的事情就是从您（而不是您本人）的错误估计中学习。要学习的一件事是，永远不要让实现想法的人以外的人来估计它需要多长时间。程序员的速度可能相差一个数量级，因此估计其他人几乎是不可能的。

我感到您的痛苦...我不确定如何处理所有这些挫败感:(

https://stackoverflow.com/questions/541873/developing-on-for-a-moving-target

过去，我不得不与项目经理打交道，他们大幅度削减了估算，以达到销售部门认为客户愿意付款的数字。经理认为，乞求宽恕比征求许可更好。

这就是开发人员学会估算的原因，因为他们知道自己会被经理削减。因此，如果您将估算值加倍并加上30％，则很有可能获得合理的计划。

客户总是希望它更便宜，如果您以合理的价格来拜访他们，他们会拒绝它并要求您削减成本或他们走路。但是，如果您走得太高，他们只会走走而无需讨论（“我们会考虑并与您联系”）。

这是一个管理期望的游戏。

问题不是最初的估计数超出了–这是管理层不相信您。

促使管理层做出决定的最佳方法是：

1. 用证据概述问题，以予以支持；和
2. 提供多种解决方案供他们选择（从最不喜欢到最喜欢）。

对于（1），实施Scrum并根据不可靠的估计值跟踪实际情况很好地支持了您的主张。

对于（2），我的选择之一是“与客户端一起开发优先功能列表（又称Scrum中的Product Backlog）”。在固定价格或高度官僚的组织中，这将是棘手的，但这是可能的。

希望有帮助！

我（因为我相信几乎每个编码的人）都同情。我的上一家公司对此非常糟糕-销售人员会进来并出售一个项目，然后您进来，查看估算，然后大笑。

正如汤姆（Tomh）所说-一天只有很多时间。即使你不睡觉。

我认为三件事。

大多数时候，您只需要管理客户的期望并保持透明即可。直截了当地说出您可以做的事情，并展示您已经完成的工作-所有这些。如果您对需求的要求过于粗暴地分类（如Totophil所述），则尤其如此。如果他们可以看到您必须做的工作量，那么他们可以看到估计有多糟糕。如果他们看到生产力和进步，那对我来说是最重要的。

我认为，除了管理期望并在工作负载中保持透明之外，另一个重要的事情是范围管理。在肛门/进攻性纳粹与掩盖自己的尾巴之间有很大的距离。当有人想要这个额外的功能时，请同意！然后给他们多少时间，将添加到项目中一个相对准确的估计这样做的好处是，不仅（或下一个版本。）不恶补自己进入另外80小时工作周-你在这一估计有些垫太可能赶上另一个。

祝好运！

切勿在未看到或理解之前采取任何措施。如果客户或您自己的mgmt不愿意负担那么多费用，那么他们就不会让您成功。

这是（通常是）无法理解细节，数据以及它们在整个正在构建的应用程序中如何相互作用的信息。假设是要提出问题，而不是提出问题，寻找答案并确定一切。

我经常对客户说的一件事是，如果您要吊死我，至少让我用自己的绳子吊死自己，或者用我的枪支和子弹射击我，而不是别人。

最终有很多人试图解决这个问题，这对他们来说将变得更加糟糕。

不切实际，计划不周和缺乏远见可能是整个组织范围内的问题的信号，在这种情况下，您最好习惯或继续前进。

首先，考虑一下您可能高估了项目范围。销售人员和架构师倾向于夸大其解决方案。不要以面子为准。他们可能希望您提供的金额少于他们向客户承诺的金额。

我在这里所要做的就是花费我所拥有的时间，并尽可能地明智地度过。找出客户的优先事项并兑现这些优先事项。十分之九的客户会很高兴自己的首要任务得到了满足，而忽略了80％尚未完成的工作。

您要做的最后一件事是召开紧急会议并指责人们邪恶。你说：

“让他们知道现实”

但是现实只是一个意见！放松，做你的工作，并花你的期政治资本的重要事物给你。喜欢，促销，更多的钱，更多的假期。

您的老板为您努力为客户努力工作的促销是有意义的。您不代表客户而烦恼。

要记住的一件事是，估算不包括范围爬升或不可避免的延迟（或基于客户表示您将以某种特定格式提供的信息之类的，客户未给予您的问题）。

我们已经了解到，每当其中一种情况发生时，都会推后估算和/或到期日期。添加新功能，获取新的估算值和新的截止日期。无法在约定的日期提供所需信息，请获取新的截止日期。提供信息，但使其不完整或不正确，或以其他方式使其不符合承诺，发送新的估算值和到期日期，更改商定功能的要求，获取新的估算值和到期日期。停止处理项目，因为客户希望您将工作放在更高的优先级，发送新的到期日（并且可能会有新的估计，因为如果项目长期搁置将有追赶时间）。

如果原始估算值来自开发团队之外，而他们并未对此提出建议，那么当您获得原始估算值时，请准备自己的估算值（在您认为将要执行的所有任务的详细级别上，要高得多）细节，而不是给出的估计数），并立即将其提供给整个环节，并询问您应该削减哪些内容才能达到给出的估计数。

如果答案无济于事，现在我们已经对问题进行了更深入的研究，请坚持要求客户告知新的估算。如果管理层仍然坚持说客户只会支付X个小时，请询问他们谁将支付其余的开发时间，因为向您描述的工作不能少于您的估计。事实证明，该公司愿意承担重任并自行支付工时。

如果他们不愿意从中获利，他们不会告诉客户他们需要更多的时间，并且公司也不会支持开发人员对销售的详细估算。“我们认为客户会继续努力为了赢得该项目”的估算，您正在参加一个死亡游行项目，您最好的选择是尽快离开。您可以指出，与您花了他们同意支付的50个小时，甚至还远远没有完成您真正需要的500个小时相比，客户会更高兴地知道该项目将花更长的时间。提醒他们，过于乐观的估算是项目失败的最大预测指标之一。它不适用于这些类型的公司，但是如果您重复多次，最终可能会陷入困境。

我还将考虑估算的细化。我的意思是“据我所知，这个项目将花费X个工时”。20-30％之后，我将重新估算，依此类推。

毕竟文件下载器如何估算？它不断地完善它。

我认为没有足够的估算者没有充分重视以下事实：“估计是您要求我做数学，并猜测是用一种有用的方式预测未来”，而“我们所做的承诺与我们对数学所做的承诺完全不同。做出估算；我们可以同意做一些愚蠢的工作，同意我们认为我们可能无法完成的事情，但是这些都不能真正改变解决方案的数学原理”和“我们可以做的开发方法不大一批功能A将在日期B之前完成，从而大大降低了失败的可能性”

据估计，许多人都使用谈判语言。他们需要的语言来表述数学和谈论的不确定性数学。

估算者无能为力，无法使现实转向谈判他的商人的意愿。他唯一的工作就是让他们停止尝试。