项目经理如何进行项目工时估算？

一、项目工时估算的重要性

没有计划就没有项目；没有计划控制就没有项目管理。项目计划才是保证项目目标和预期收益达成的手段。因为有了计划才有了衡量和控制的手段，没有计划就没有控制。

而项目工时估算是项目计划制定中的重要环节，其指根据项目的范围、难度、资源等因素，对项目完成所需的时间进行估算的过程。

在项目计划阶段，准确的工时估算可以帮助项目经理和团队成员制定合理的计划和预算，避免延误项目进度。

此外，在项目执行过程中，准确的工时估算可以帮助项目经理和团队成员及时发现和解决问题，避免不必要的成本和时间浪费。

因此，项目工时估算，可以帮助项目经理和团队成员有效地规划和控制项目进度，保证项目按时完成。

反之，如果没有对项目工时进行估算，很容易出现进度延误、工期拖长、成本增加等问题，严重影响项目的整体进展和质量。因此，项目工时估算对于项目管理来说具有至关重要的作用。也是每位项目经理需要掌握的一项基本要求。

二、常见的工时估算方法

既然工时估算如此重要，也是计划中的核心部分之一，那么作为项目经理，我们有必要了解项目实战中常见的工时估算方法。

1、专家判断法

专家判断法是指由有经验的专家根据历史数据、类似项目的经验和技术分析等因素进行估算。

在互联网行业或游戏项目中，项目在初始阶段会进行阶段的划分，也即确定重要里程碑节点，阶段划分之后，会进行一个全局规划，全局规划之后会输出一个里程碑计划。

但全局规划之后，详细的需求并没有很快就输出，为了确保里程碑计划制定的基本可靠性，此时需要先根据需求框架，评估时间，这里的评估方法，通常采用的就是专家判断法。

2、比较法

比较法是将类似的历史项目和目标项目进行对比，据此进行工时估算。同样，在制定里程碑计划，以及项目整体计划的时候，比较法也是比较常用的。

3、三点估算法

三点估算法，在实际项目计划制定的时候，也是用得非常多的。尤其是项目经理在对整体计划进行整合的时候，会根据乐观、悲观、常态三种情况下所需的时间进行估算。这样得出的项目计划是在一个框架内。项目经理在和管理层、及团队达成共识之后，计划在该框架内运行即可。

4、自下而上法

自下而上法(Bottom-Up Estimating) ，是项目管理中最常用项目工时估算方法，亦或者说是用得最广泛的一种方法。

它是将需求分解成任务，再将任务分解为若干个较小的组成部分，从而更准确地计算总工时。其强调的是对项目任务的细致分解和精确的任务估算。当若干个较小的任务都经过精确的工时估算后，再汇总为整体的需求完成工时。

这种方法在互联网和游戏项目中用的非常多，通常用于比较明确的需求中，因为是WBS分解后的更为细致地估算各项任务，各项子任务的工时。

实际项目中，运用这种方法，可以让团队成员更细致地考虑每个任务所需的工时，从而得到更准确的预计工时。这样制定出来的计划，可执行性，有效性也更高的，所以，该方法可以帮助团队更好地规划和安排工作进度，提高项目管理的效率和准确性。

5、参数法

和自下而上法有某种相同之处的另外一种方法，叫做参数法。参数法是通过对项目的各个方面进行分析，建立一定的参数模型，得到工时估算结果。通常是指项目团队成员完成某个任务所需要的时间。

但这个完成的时间的评估，某种程度上是依赖于数据的收集和分析，通常需要使用概率统计方法来进行分析和计算。

换句话说，使用参数法来评估时间，是基于历史数据和经验，并且将多种因素纳入考虑，比如任务的复杂度、技术要求、自身能力、沟通时间、预留buff等，从而确定任务所需要的基本工时。

当具备了一定的数据收集和分析，根据其历史经验，也是可以比较快速地评估出时间。相比自下而上法来说，参数法来说是依赖于数据分析和模型，依赖于经验。

以一个程序员为例，在程序员最开始评估需求、任务工时的时候，大多数的时候是采用自下而上法，当积累足够的经验，变得更加成熟的时候，往往在需求评审完，还没有进行详细评估的时候，就可以预估到该需求大概所需工时。

除了以上介绍的5种工时估算法，其实还有统计学法、类比估算法、点数估算法、计划扑克法、计时法等各种工时估算的方法，而后面这几种工时估算方法，在敏捷scrum中比较常见。

由于在实际项目开展中，我们更多的是运用敏捷的思想，并不是完全套用敏捷scrum的方法论，所以对于敏捷方法论中所提到的工时估算，并没有运用到实际项目中。绝大部分项目，仍然采用的是更为精确的工时估算法。

三、项目工时估算的实际运用

上面已经单独介绍了项目中各种工时估算的方法，但在实际运用中，工时估算的方法并不是单独存在或单独使用，而是将多种方法相结合地运用到项目中。

接下来以一个游戏项目为例，具体介绍下项目工时估算的实际运用。

当项目经理接到一个新的项目时，往往在最初始的时候，老板会要求先输出一个整体计划。亦或者老板没有要求输出一个整体计划，但会对项目经理说，预期在什么什么时间发布。

在这样背景下，项目经理如果是带着团队直接开始干活，那这个项目大概率是要延误的。之所以大概率会延误，是因为项目经理并没有带着团队一起对项目进行工时的估算，完全是一种拍脑袋定的时间。这样做出来的计划，没有落地执行性可言。

那具体该如何做呢？

第一、项目经理接到新的项目之后，先详细了解清楚项目的背景和老板的预期，以及管理层期望的目标。通过了解这些，更详细地了解清楚项目的目标，也是为了对项目目标有更深层次的理解。这是属于明确项目的背景和目标。

第二、对项目进行阶段划分，也就是和项目管理层一起，把项目划分为若干个里程碑节点，每个里程碑节点都有其意义和价值。切记不能去为了划分而划分。

第三、阶段划分好之后，也即里程碑确定好之后，项目经理需要和产品人员一起，对每个里程碑进行规划，然后汇总为项目全局规划。

第二、三这两步是属于确定项目的范围。

第四、开始制定里程碑计划。制定里程碑计划，也是要遵循项目管理科学的，也就是说不能拍脑袋。那怎么确定时间评估基本准确呢？

专家判断法、参数法就是有效的选择。具体做法就是，当全局规划好之后，每个里程碑对应的需求，项目经理会拉上开发leader会、以及核心骨干一起，根据需求的情况，以及开发leader，核心骨干以往的经验，初步排一个时间。这个评估出来的时间不是精确的，但用于初步制定里程碑计划是足够的。

当汇总这个时间之后，其他几个版本按照同样的方式，采用专家判断法和参数法，最后得出一个总的时间。假设最后算出来，beta1-beta10，前台总计600人日、后台600人日。

再假设前台共有开发人员20人，后台开发人员也是20人。那么可以推算出，总计完成这个10个版本，66个需求，共计需要30个工作日（6周）。再根据三点估算法，最乐观的情况下是6周完成这些需求的开发，最悲观的情况，则需要考虑版本在各种情况下的风险点，额外增加4周，这样最悲观的时间就是10周。再根据三点估算法，得出一个中位数，8周。

这样一来，得出的里程碑计划，就会有一个目标范围，即6-10周。当拿着这个里程碑计划去和管理层汇报的时候，讲明这时间具体是怎么来的，客观情况是什么，则会更有说服性。下图只是一个实例展示。一个项目的计划制定出来之后，可以根据三点估算法，得出三个时间点。

如此，不仅可以体现项目经理的专业能力，同时，也可以比较好地管理好老板们的预期。当然，还有一点也特别重要，就是在汇报的时候，还需要重点说明最后准确的时间，会依据实际需求输出的情况，经过详细评估后再不断更新。

第五，当里程碑计划得出之后，整个项目团队就有了一个总体的规划时间。虽然是采用了科学的工时评估方法（专家判断法和参数法），但总归不是精确的工时评估得出来的时间。所以，第五步的时候，是需要确定每个版本的具体范围，然后落实产品输出详细的需求文档。

第六、在需求文档输出之后，项目经理可以和开发人员一起进行产品分解结构，将每一个需求都分解成颗粒更细的功能点，以及子功能点。比如下图中，我们一个玩法特性的拆分，可以逐步地拆分到子功能1、子功能2、子功能3。这样拆分之后，是有利于更细致地进行时间评估。

第七，自下而上地对每个子功能进行详细的，精确的时间评估。比如下图的子功能3，就可以进一步地分解为左边的详细任务。

对子功能更详细的评估，则采用的就是自下而上法。在我们团队中，采用自下而上法评估时，还有几个规则：

1）要求具体执行的开发人员，对时间评估的颗粒度要在0.5-2d的时间
2）具体落地可执行的任务，不能超过2d，联调时间除外
3）小于0.5也是可以的，但不能大于2d。如果是大于2d，必须要分解为小于等于2d，而且如果是等于2d，也需要给出合理的说明。比如确实是不能再进一步分解。

在项目推进过程中，采用自下而上法对需求进行工时评估，是可以得出详细的，精确的时间评估。

每个子功能依据此法，可以得出详细的时间，而后汇总成为该需求的完成时间。版本中其他的需求也是如此，最后将所有的需求总时间相加，即可得到整个版本的预估时间（详细的，准确的）。

之所以采用自下而上法来进行需求的详细时间评估，是因为这个方法可以让我们更细致地考虑每个任务所需要的工时，从而更准确地预估工时。

此外，详细的、精确的时间评估，有利于计划的跟进和执行。

而且，对于一些复杂的需求或项目，当功能拆的越细，评估的越准确，也从侧面可以说明团队成员对需求理解得程度越高。

第九，采用自下而上法得出的工时之后，项目经理在进行计划整合的时候，还可以采用比较法，来对该时间进行比较。

这也是项目经理常用的方法之一，因为项目经理本身并不是具体任务的执行人员，非开发专业出身，虽然是相信团队，但必须要核实。

所以，对于单个需求，可以看过往类似的需求评估时间；版本，也可以看历史的版本的总体时间；项目，也同样可以看同级别项目复杂度的时间。

这样是有利于把计划制定地更加有效，也更有利于执行。

第十，每个需求，每个版本都可以采用专家判断法、参数法、自下而上法、比较法、三点估算法等相结合的形式，制定出切实可落地执行的项目计划。

所以从这十点也可以看出，掌握项目工时估算方法，灵活地使用项目工时估算方法，对于制定一份科学、客观、合理、有效的项目计划，起着非常重要的效用。

四、如何应对项目中的工时估算出现的偏差

项目计划的制定是一个科学，严谨的过程，因为项目工时估算的方法，是一个科学，严谨的方法。

但我们会发现，在实际项目开展过程中，会出现不同程度的工时估算偏差，有时会出现工时估算过长，有时会出现工时估算过短。这两种情况都会对项目计划的落地执行带来影响。

当出现这两种情况时，有可能是对项目工时估算的方法掌握不够彻底，但也有可能是没有很好地运用项目工时的估算方法。当然，也有可能是来自于第三方，或者甲方，或者老板的压力。

但无论是哪种原因，作为项目经理，我们必须始终要坚持的就是，为了更好地进行工时估算，需要通过不断的实践和总结，探索出一套更为精细化的管理方法。

比如建立科学的工时估算制度；比如建立起进行工时估算结果的追踪和分析的体系；比如不断优化和调整估算方法等方面。

那么，作为项目经理，如何应对工时估算过长和工时估算过短这两种常见的情况呢。

第一，当项目出现工时估算过长时。通常有两种情况：

其一是在项目计划整合的时候，项目经理发现工时估算过长，这个时候，可以采用比较法，以及再次运用专家判断法，拉上开发leader和核心骨干再次对齐确认，以便确保评估的时间是经得起推敲的。

对于这种情况，我们项目现在执行的过程时，时间的评估会经过至少两次审核，才会最终给到项目经理这边。

其二，是项目已经按照制定的计划在执行了，项目经理自身发现工时评估过程，或老板挑战工时估算过长。

对于这种情况，我自己的做法是，既然现在已经按计划执行了，就仍然按计划执行，但项目经理要做好数据的追踪和分析。这样有利于下一次的比较。

如果是老板挑战，那么可以先了解清楚老板的预期和背景，然后找leader协商，并和具体执行人达成共识，重新调整时间。对于这种做法，要特别得小心，不要让团队误以为是老板在压时间。

第二，当项目出现工时估算过短时。该如何应对：

其一，要评估判断是否是由于客观原因造成的。比如需求不清晰，或对需求的理解不够导致设计方案考虑得不全面；比如新增需求，或者需求蔓延，或者需求镀金了，导致时间评估不够；比如由于合作人员所导致等。

这些都是客观的原因，通常情况下，只能先额外再增加时间了，然后项目经理需要做好数据的追踪和分析。这个记录主要是用来做后面的根因分析，并从源头解决问题。比如如果是需求不清晰导致时间评估过短，那么就要从需求输出源头抓起，是重新梳理下需求输出流程，还是强化需求输出确认。不同的根因，所采取的策略都不一样。

其二，评估判断是否是主观因素主观原因导致工时评估不足，通常是和个人能力，经验有关。那么作为项目经理，为了确保项目顺利执行下去，通常也是先额外增加时间，同时，需要和老板做出客观的说明。这里的说明并不是和老板沟通，否定团队成员的能力，而是从团队成员的能力梯度，需求的复杂程度来客观的说明情况。

此外项目经理为更好地建立自身的影响力，遇到这种情况时，要切实地相信团队成员，在需求最后完成时，带着团队成员一起进行复盘，帮助其总结经验，并告诉他们采用科学的工时估算方法。

项目计划能力是每位项目经理必须掌握的实战能力。要制定一份优秀的计划，项目经理必须掌握项目工时估算的常规方法。项目工时估算作为制定项目计划的核心环节之一，是最基本的工作。

在实践中，项目计划的准确性和可靠性直接来自于项目工时估算的精度。这说明项目工时估算在项目实践中的重要性。

因此，每位项目经理都必须掌握常用的工时估算方法，并通过不断地学习与实践加强对工时估算的理解。在实践中，经常进行复盘、总结，从而不断提升项目管理水平。

8月起，《项目管理知识体系指南(PMBOK指南)(第七版)》将成为中国大陆地区PMI认证考试参考资料。与上一版相比，《PMBOK指南(第七版)》有较大调整，首次提出了项目管理的 12 项原则和8个项目绩效域，构建了一个专注交付成果、更全面的项目管理知识体系框架。它将帮助从业者更好应对当下灵活多变的环境，选择正确的项目管理方法（预测型、敏捷或混合型）来完成工作交付价值。

《PMBOK指南(第七版)》的中文版和英文版书籍已正式引入中国大陆地区，并将从2023年8月起，成为项目管理专业人士(PMP)认证考试等PMI认证的考试参考资料之一。

新版考试题目为180道题；
考试时间为230分钟；
题型将包括单选题和多选题，多选题将说明需选择几个正确选项。