logo标签列表

如何创建准确的工时估算？

project-managementproject-planningestimation
23

  • 您在项目计划和新项目的小时估算方面有什么经验？

  • 您采用的方法是什么，为什么会或者不会适用于您？

  • 有没有需要考虑的最佳实践？

7个回答
21

估算任务

我尝试使用的原则（并非总能如愿）是：

  • 逐步细化
  • 三点估算法
  • 风险分析

逐步细化

在进行估算时，重要的是以正确的粒度进行估算，并不断细化和添加任务，直到您对估算感到自信。很多时候，估算会突出一个冗长而关键的路径任务，这可能需要更多的细化和风险分析。

风险分析

试图弄清楚每个任务的风险所在（有没有需要等待的时间？有没有缺乏知识？竞争对手是否可能抢先一步等等）有助于确定您对估算的信心，从而确定如何处理这些估算。风险分析还有助于确定是否需要进一步逐步细化。

三点估算法

为每个任务（包括设计、开发、测试和故障修复）指定最佳、可能和最差情况的估算值有助于风险分析和计划。可以使用这些估算值来计算命中特定成功百分比所需的最可能耗时。结合其他相关任务的信息和风险分析，项目经理可以将风险和其他已知因素（如系统测试）纳入估算中，以获得更可靠的估算。

当然，估算粒度也很重要。对于大多数任务来说，估算小时并没有意义。在软件中，通常使用天数最为适宜，但有时可能需要几周或几个月（例如如果您正在外包工作块）。选择一个对项目中所有任务都有意义的时间粒度（我通常在需求捕获和功能规范阶段使用天数，然后在了解更多有关任务及其子任务的情况后，每半天进行一次估算）。

结论

这三个元素互相影响，因此往往需要对每个步骤进行多次细化。例如，在需求阶段尝试一次，然后在功能规范阶段再次尝试，最后在设计规范阶段再次尝试。

估算是一种学习技能，你做得越多，就会越来越好。当你了解自己不知道的内容时，风险分析会得到改善；当你了解自己已知的内容时，三点估算会得到改善；当你经历设计过程的每个步骤时，逐步细化也会得到改善。

如果你有时间，在完成任务后重新审视你最初的估算，看看实际时间与你的三点估算和项目计划相比如何。如果有区别，请查看时间损失或收益的原因，并尝试从中学习可以应用于未来项目的知识。

估算不应该成为一项令人生畏的任务-我总是感觉在进行估算之后对我的工作了解更多了而不是更少了。

9
7

关于这个问题，在《实用程序员》一书中有一些很好的信息。他们建议您使用适当的时间单位，而不是估计130天，建议估计为6个月。他们还建议集中处理最重要的任务，并避免基于子估计进行估计。

个人认为，将任务分解成易于理解的块以正确估计它们是有用的。如果任务太大，就会有太多的细节可以隐藏未考虑的问题。通过集中处理更小的块的详细信息，您可以更成功地评估潜在问题。

2
你的问题是一个NP-Complete问题:) 有许多算法用于估计，但它们总是只是猜测，从来不准确，而且许多算法需要很长时间才能执行。忘记小时估计，使用Scrum或其他敏捷框架。在项目开始时进行以小时为基础的估计只是对人们撒谎。
直到你要构建功能并在进展中不断更新这些估计之前，不要进行基于小时的估计。
不要忘记在你的估计中包括测试时间。
1

实践，实践，再实践。在你不断提高估算能力的过程中，为了保险起见，要进行过度估计。当然，如果你是一名顾问，这可能会让你失去业务。如果你害怕失去业务，可以低估，但要知道你将会在自己的空闲时间/底线上弥补额外的工作时间。

1

回复：

如果你害怕失去生意，可以低估价格，但要知道你将会在自己的空闲时间或底线上弥补额外的工作时间。

与其调整向客户呈现的工作时间，不如降低你的小时费率。这样至少能给客户增加价值的印象。

LM

0

记录在你实际项目中花费的时间，这将有助于你计划下一个项目，PSP/TSP 提供了一种方法来实现。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接