似乎无论我的项目是什么，我都能很快完成 80% 的工作。用户和管理人员兴奋地认为事情比计划提前了很多，但剩下的 20% 令人讨厌的工作似乎需要之前 80% 的 4 倍。当我们对项目进行定期检查或站立时，我觉得自己就像一个破纪录的人说：“是的，到目前为止一切都很好，但还有很多事情要做……”
在大多数情况下，我的估计是相当准确的，但我是人。让用户相信最后 20% 的工作确实需要 80% 的时间的最佳方法是什么？似乎越来越多的用户和管理人员相信 IT 很简单，神奇的事情发生在弹指之间……
一般来说，我们确实在我认为相当低的水平上跟踪任务。不一定在创建标签或文本框中，但我们非常详细......我们还跟踪我们对所有任务的估计完成情况，我觉得当您处于项目中间时，这个数字比原始估计更重要.
我认为这归结为用户和管理层的看法。即使他们可能知道要完成的估算，他们仍然会沉浸在对所见事物的情绪和看法中，而估算数字则处于次要地位。这就是我试图弄清楚如何控制或管理期望的原因。
不要在完成后立即向他们展示前 80%。滴灌他们。
即使考虑到霍夫施塔特定律，它也总是比你预期的要花更长的时间
但我离题了。
最好的做法是可悲的经验。SCRUM 方法对某些类型的软件开发非常有帮助，因为它们会不断将发布日期更新为更准确的日期。（关于 scrum 的快速视频）
也许您需要将您正在处理的任务/功能分解为更小的单元，以便安排工作和签到/报告。例如，我的日程表中几乎没有任何单独的项目持续时间超过两天。
然后，不要在 Scrum 中每天都说“我正在为我们的新布偶制作者工作”两周，而是可以说“我目前正在为布偶制作者制作眼睛选择器”。
如果你按照时间表工作，而且你的时间表是准确的（这意味着它们占了 80% 和 20%），那么管理真的不应该有问题。如果他们暗示他们可以减少分配的时间，因为您“几乎完成”，那么请向他们展示尚未实施的规范部分。
我假设您从某种形式的功能规范中工作，该规范详细说明了应该做什么、应该如何表现以及它必须处理的边缘情况。如果是这种情况，那么担心管理层的情绪和看法对我来说似乎很奇怪，他们应该很有能力将规范与您的工作进行比较，或者阅读您的日程安排以查看剩下的内容。
你如何估计工作量？您说“令人讨厌的剩余 20% 的工作似乎比之前的 80% 花费了 4 倍”，但是您是如何得出“剩余 20%”的工作和“80%”是完毕？显然估计是错误的——实际上只完成了 20% 的工作，还剩下 80%。
在软件开发中，很难提前很长时间给出准确的估计。唯一的方法是将工作分成易于管理的小部分（每个部分可能少于 10 小时）。您只能准确估计接下来的步骤。
在 Scrum 中可以找到一些有助于估计进度的实践。在下一个 sprint（一个月或更短）期间将完成的工作范围在 sprint 开始时确定，并对每项工作进行粗略估计。然后在 sprint 之后，团队可以反思完成了多少进展，还缺少多少，估计有多准确，以及是什么让团队放慢了速度。在 Scrum 和其他敏捷方法中，重要的一点是获得关于已完成的工作以及我们在项目中的进展程度的快速反馈。我建议阅读更多关于它们的信息。Ólafur Waage 在他的消息中链接的有关 Scrum 的视频提供了一个很好且快速的介绍。
当涉及到时间估计时，这是我的经验：
如果您不能肯定地说一项任务将花费不到 4 小时，您就无法准确估计它。将其分解成更小的部分并递归地重复。
做出这样的时间估计不是野餐，这需要时间，您基本上必须以可管理的部分来解决整个项目，这意味着对需求的任何更改都会导致时间计划的更改（令人惊讶，不是吗？ )
最大的问题是我们不可能预见到所有的细节（也许，比如说 20% 吧？剩下的 80% 没有估计……） - 正如其他人已经指出的那样，请参阅 SCRUM。
管理层很少“接受”如此详细的时间估算，因为实施起来“需要太长时间”。
然而，由于管理层有兴趣赚取利润，他们也有兴趣偷工减料。因此，您应该根据所涉及的现实生活场景确定可以削减的角落并做出复杂的妥协。在管理层的支持下，你可以通过无所事事来完成最后 20% 的大部分工作（我猜这有点悲哀，但仍然如此）。
因为代表最终产品最后 20% 的最后 80% 工作实际上是在打磨和消除错误并适应变化的需求等。可能有一些有限的第一个版本等，等等，要有创意.
阅读史蒂夫·麦康奈尔 (Steve McConnell) 的优秀著作《快速开发》，该书对 80/20 问题和其他变幻莫测的软件估计有很多话要说。
我认为我不能比Joel对Painless Software Schedules说得更好。
如果您的经理让您减少估算，请按照以下步骤操作。在日程表中创建一个名为 Rick's Estimate 的新列（当然，假设您的名字是 Rick。）将您的估计值放在那里。让您的经理随心所欲地使用 Curr Est 列。忽略你的经理的估计。项目完成后，看看谁更接近现实。我发现仅仅威胁要这样做会产生奇迹，尤其是当你的经理意识到他们刚刚参加了一场比赛，看看你的工作速度有多慢！
有人说，项目前 90% 的时间用于 90% 的工作，剩下的 90% 的项目时间用于剩下的 10% 或工作。;)
在项目开始时取得很大进展是很自然的，因为您只需先完成最简单的部分。此外，如果前 80% 的代码有任何问题，它们通常不会很明显，直到它们全部结合在一起并且您可以实际测试所有代码。
也许作为经验，您应该让人们尝试完成 90% 的应用程序，以便他们看到最后 10% 的不同之处......
我发现了一些对时间估算有很大帮助的东西
我也非常成功地使用它来近似同事的速度，它只需要一些经验观察来了解他们可以多快开发一个功能以及在实际测试之前它会有多好。
80/20 现象的根本原因之一是任何困难的——有时甚至是微不足道的——任务总是会发生意想不到的事情。例如：由于一些过分热心的流程经理，您的软件设计流程要求的文档突然获得了新的模板格式。突然之间，为新版本更新文档不仅仅是一件简单的事情——您现在必须重新构建每个文档，而所有这些文档都需要更多的时间。
我听到的处理此类现象的最佳建议之一是始终将缓冲区子任务构建到项目计划中 - 由Richard Whitehead推荐。每项主要任务都会增加 20% 的时间（或大约在某个地方），并将其标记为该任务的子任务。每个的目的是为该任务“出现问题”时发生的情况提供一些衡量标准。作者承认（我也发现这是真的）管理层通常会尝试删除这些缓冲任务——你唯一的办法是要么坚持自己的立场，要么像 Joel 倡导者那样采取行动（正如@Casey 已经提到的那样）。在实践中，我发现大量的缓冲区子任务通常确实存在，并且在紧张的日程安排中提供了几次帮助。
我发现最好的方法是使计划保持最新，每个任务的完成百分比。这样一来，进展就很明显了。与管理层沟通，他们应该随时了解您的位置。
我认为，如果您正在对一项将 80% 和 20% 捆绑在一起的任务进行估算，那么您的开端就很弱。打破你的估计。把 80% 和 20% 做两个明确的任务；简单的一点和困难的一点，如果你必须的话。
然后，您可以预先为整个工作提供更现实的时间估计，并使生产更容易跟踪细节。
计划时，请考虑到这一点。在估计完成一个子任务所需的时间时，给出“完成”而不是“基本完成”的估计（根据经验估计“完成”需要多长时间。抵制拒绝集成、文档、整理的诱惑，测试，测试后的错误修复，部署等作为将被吸收到其他任务中的小任务。
你最终会得到一个可怕的大估计。但是问问自己这是否与之前项目所花费的实际时间不一致。
尽量提供最准确的估算，并尽可能提高项目的透明度。如果您始终接近您的估计，那应该足以让您的经理满意。请记住，衡量生产力是非常非常困难的。
我认为这归结为用户和管理层的看法。即使他们可能知道要完成的估算，他们仍然会沉浸在对所见事物的情绪和看法中，而估算数字则处于次要地位。这就是我试图弄清楚如何控制或管理期望的原因。
先写算法……然后是 UI。
保持你的时间范围很短。估计接下来几周你会做什么比接下来几个月更容易。考虑将您的项目分解为较短的里程碑。一个月或几个月取决于您要做什么。这基本上就是 Scrum 所做的。然后只最准确地估计你在当前里程碑中要做的工作。当你到达那里并有更多数据可以作为估计的基础时，重新估计下一个里程碑。最后 20% 花费这么长时间的部分原因是，当您知道得不够多时，您可能会提前做出估计。
另外，尝试宽带 Delphi估计技术。这将梳理出更多您可能没有考虑的隐藏成本。
说“是的，到目前为止一切顺利，但还有很多事情要做……”可能不是表达你观点的最佳方式。在听到经理或客户可能会想“是的，还有很多事情要做，但他做这部分的速度如此之快，剩下的肯定是微不足道的”。
相反，请确保确定剩余的工作并安排它们。这样你就可以在剩下的 20% 的项目中显示你应该在哪里。如果花费的时间太长，您的日程安排将显示一个项目落后于日程安排，这应该会提高一些紧迫感。
每周更新您的任务（或多久定期更新一次状态报告）。确定有落后危险的领域，特别是如果其他领域依赖于它们。
我认为最好是承诺不足和过度交付。
如果你的估计是正确的，那么你就占了那讨厌的 20%。你显然没有，这就是为什么它是一个问题。
也许你正试图给他们他们想要的一切，这是不切实际的。也许你没有充分考虑墨菲定律，或者没有给测试、发现错误、然后再次测试等足够的时间。
看起来你应该做更多的风险管理......
如果您始终发现最后 20% 的工作花费的时间是前 80% 的 4 倍，那么可能是时候与自己（或可信赖的同行）诚实讨论您是否让技术债务累积在最初的 80% 中上升，最后它会咬你。
这可能与您可以考虑改变的工作实践有关。
我所知道的减少技术债务的两个最佳实践是编写良好的测试（最好在编写代码之前，但也可以使用后记），以及在每个任务之后进行重构。把重构想象成每顿饭后打扫厨房，而不是月底。