大话pm｜从 project 看项目管理核心思想-凯发备用官网

本文将从 project 软件的独特视角，强调产品经理需要的项目管理相关思想及其关联知识。

在网上流传着这样一份腾讯产品经理能力模型，暂且不论其真假，但不难发现做一名合格的产品经理需要非常综合的各项专业能力。

而在能力模型中有一项很重要的能力就是项目管理能力，它能在产品的整个生命周期中，帮助 pmer 进行产品迭代的规划、各类资源的整合以及生产进度的把控。

在日常工作中，大部分企业或团队都会选择一些协同软件来进行产品/项目的管理。但在更专业的项目管理领域，项目经理们普遍采用 microsoft 出品的 project 软件来进行这项工作。

本文将从 project 软件设计的独特视角，强调产品经理需要的项目管理相关思想及其关联知识。至于 project 的强大功能及其使用方式，不在本文的讨论范畴中。

1. 越快越好

在 project 中，每一个项目的开始都需要建立项目信息，主要填写的是项目开始日期以及日程排定方式。其中日程排定方式提供两个选项：以项目开始日期或以项目完成日期。

当切换两个选项时，project 会给予用户相应的提示：选择项目开始日期时会提示所有任务越快开始越好，相反选择项目结束日期时会提示所有任务越慢开始越好。

为什么会有这样的提示呢？先设想以下两个场景：

1. 老板制定产品迭代计划，要求从今天起 3 个月内完成产品 2.0 版本的迭代
2. 老板制定产品迭代计划，要求 10 月 1 日完成产品 2.0 版本的迭代

尽管两个场景都是对产品迭代时间的要求，但在第一个场景中老板规定的是开始时间和预算时长，而第二个场景老板规定的则是完成时间。

很显然在日期排定时，第一个场景肯定是以项目开始日期为标准，在 3 个月内越快完成越好；而第二个场景肯定是以项目完成日期为标准，只要能在最后期限前完成即可。

那么问题又来了，为什么在 project 中以项目完成日期为标准时需要越慢越好呢？其实这就对应了项目管理中两个重要的原则：

1. 越快越好原则(asap)：项目中所有的任务都越早开始越好
2. 越晚越好原则(alap)：在不延误其他项目任务的情况下任务越晚开始越好

实际上，大部分的产品迭代或项目管理计划都会以 asap 为标准，因为在有限的预算工期内当然越快越好。但是仍然会有部分产品/项目内容与时间具有明确的关联性，此时就会采用 alap 为标准。

举个简单例子来帮助理解，如下图某产品在 8 月 1 日制定一个 2.0 的版本迭代计划，迭代目标是庆祝国庆特别版本，所以需要在 10 月 1 日当天完成上线。

计划中有三个任务：工期 30 天的开发任务、工期 10 天的测试任务以及工期 1 天的上线任务。

按照 alap 的原则，开发从 8 月 1 日可以开始，但此时在不延误 10 月 1 日完成上线的情况下，测试可以晚几天再开始。而开发和测试任务之间存在一些空白时间，称之为窗口时间，作用主要是用来提供缓冲、规避风险，下文会再次提到这个概念。

也就是说，不论是 asap 还是 alap 都有具体的使用场景。但需要注意的是，两者都不适用某些任务需要在特定日期开始的情形。仍然以上述例子说明，测试任务如果规定必须 9 月 10 日开始，此时就违背了 alap 原则。

事实上，不论是在 project 中还是在日常真实工作中，我们都建议选择 asap 即越快开始越好原则。原因是 alap 原则会带来一个非常麻烦的问题，也就是臭名远扬的帕金森定律。

帕金森定律在项目管理上强调的是：任何任务都会拖延，直到所有可用的时间用完为止。

这里举一个不恰当但易懂的例子——大学生复习效率图(案例来源：酸梅干超人)，非常形象的描述了这一定律：

而 alap 原则允许任务越晚开始越好，导致一切任务都存在拖延的可能性。所以在项目管理中，为了避免帕金森定律，我们首先要遵守第一原则——越快越好原则。

在日常产品迭代中，最常见的方法就是利用越好越好原则，按照研发团队真实情况顺推产品研发进度排期。假如顺推后的完成时间早于计划截止时间，则可顺利进行；假如顺推后的完成时间超过了计划截止时间，此时就应该进行相应的风险处理。

例如利用常见的压缩工期方法，对关键路径上的任务进行压缩处理，直到达到计划要求。下文也会着重阐述如何应对风险，这里暂不展开。

2. smart 原则

大部分产品/项目新人都会存在一个误区：在使用 project 管理产品/项目时，最基本也最核心的操作其实并不是利用甘特图等工具或视图来管理进度，而是利用 project 内置的 275 个预置列来设定好项目目标、分解各级任务以及各任务间的关系。

如下图案例，通过对任务名称、工期、开始时间、完成时间、前置任务这 5 个预置列的创建，我们很容易也很清晰的梳理了整个迭代计划明确的任务内容、任务期限以及各个任务的关联情况。

基于对任务基本项的设置，project 会自动生成任务的甘特图，为后续的进度管理提供强大的工具支撑。也就是说 project 的核心仍然在于对各目标任务的管理，这恰好就是目标管理中 smart 原则的核心思想。

对于 smart 原则，这里简单描述为：目标必须是明确的、可衡量的、可实现的、具备相关性的以及有明确期限的。

而该原则映射到项目管理中，仍然具备可实施性：计划/项目/任务必须是明确的、可以有具体的成果来衡量的、是可以实现的、相互间具备关联性的以及具有时间限制的。

其中 project 预置列中的前置任务，主要用来设置任务间的依赖关系，它是对关联性最佳的实践：

总结来说，在产品/项目管理中为了更好的完成产品/项目最终目标，我们应该遵守第二原则——smart 原则。

3. 黄金三角原则

尽管 project 的定位是一款优秀的项目进度管理工具，但它仍然提供了强大的资源管理和成本管理功能。

在进度管理中，通过各任务的分解与规划，可以完成项目范围及时间的设定；而资源管理和成本管理则约束了整个项目所使用到的人力资源与材料或工时成本。

从日常使用 project 进行管理工作时不难看出：

• 任务越多，成本越大，时间越长
• 成本有限的情况下，需要缩短工期或减少任务
• 时间一定的情况下，需要增加成本或减少任务

一旦出现这样的情况，在 project 的状态列中都会给予相应的告警提示。例如上方的案例，可以直观的看出实际成本比预期成本要高，此时就不得不推迟或取消某个任务来控制成本。但推迟或取消某任务后又会影响整体计划的目标结果。

在项目管理专业领域中，这种情况就对应了由范围、时间和成本组成的黄金三角形。在这个三角形中，不论对哪一边的调整都会影响另外两边。

如果我们想要高质量的完成一项产品/项目计划，就一定要考虑到这三者的平衡。不仅要保证范围符合既定目标，同时也要保证时间与成本符合项目要求。也就是说，我们应当遵守第三原则——黄金三角原则。

1. 基准思维

除了 1.2 节中提到的使用误区外，还有一个新手常犯的错误：他们在所有任务分解与资源安排等基础工作结束后，直接就进入项目开始阶段。尽管他们每天会根据实际情况更新进度，但遇到异常情况也没办法进行分析判断或控制措施，直到计划遭遇不可逆转的整体延期才意识到项目失败。

出现这样的问题，是因为没有利用好 project 的一项重要功能——设置基线。

基线顾名思义就是基准线，它是在项目计划完成初期用来保存任务分解结构、工期安排与资源分配情况的一个重要工具。原则上，基线不会随意变更，如果有变更按照 pmi 的规定必须要走严格的变更控制流程。

它的作用在于，当项目真正启动后保证项目各方面严格按照初始计划进行，同时在出现偏差情况时提供鲜明的提示和明确的分析思路，防止一些可能的风险导致项目整体失控。

通常使用基线时分为四个步骤：

1. 设置基线：当计划按照既定的安排确定后，以此为标准设置基线；
2. 记录进度：每天根据实际项目进展情况记录真实数据，供与基线比较；
3. 分析偏差：如果实际进展与基线出现较大的偏差时，根据记录数据分析根本原因
4. 纠偏措施：通过分析明确原因后，针对性的进行纠正措施，保证项目回到正轨

值得强调的是，项目实际情况与基准有偏差是一个很常见的现象，重要的并不是防止偏差的出现，而是如何利用基准思维去规范、约束和纠正项目计划，保证项目顺利完成，这才是我们要掌握的核心思想。

这里还要补充一点，基准思维不仅仅可以运用在项目管理领域，其他各个行业或环节中都可以灵活运用。比如在需求分析环节，可以设置需求基准，保证后期在需求变更时有一个标准参照，防止需求出现大的范围偏差。除此之外还有产品基准、测试基准等等。

2. 风险思维

从 2.1 节继续延展，通过基准思维我们可以对偏差进行分析。从分析过程和结果中，往往可以识别到项目整体上的一些风险，从而针对性的进行预判风险和处理风险等应对方案。

这就要求，我们需要具备风险思维。它是帮助产品/项目管理者们分析风险、规划方案以及处理风险的最佳工具。

其实在项目管理专业领域，风险管理是一个大的命题，例如 pmi 的风险管理流程足够完善和健全，但过于繁琐，不太适用大多数实际场景。如何预防进度失控以及如何纠正进度失控场景，才是大部分产品/项目管理者们关心的问题。

回顾 1.1 节，提到的两个概念。第一个是越慢开始越好原则，该原则在乐观情况时会出现一些窗口时间，来提供任务间的缓冲，但在悲观情况下会带来帕金森定律。

那么如何既能有缓冲时间又能克服帕金森定律呢？方法就是使用关键链法。

关键链法强调的是，所有任务都要遵循越快越好原则，以最快速度完成，但要在任务路径的末端设置好项目的缓冲时间。其实说白了就是在项目初始排班时，就应该考虑到延期风险，来主动设置缓冲时间来预防。

那么也存在少数工期极为紧张的情况，即使按照越快越好原则，仍然会导致项目超过预期截止时间，此时就是提到的第二个概念压缩工期。

压缩工期主要是压缩关键路径上的任务，至于什么是关键路径，下文详细说明。其实压缩无非就是三个常用方法：

1. 减少任务：适当缩减或砍掉造成延期原因的任务，可纳入后期迭代计划中
2. 增加资源：适当增加人力资源，合理均摊工作量，协同快速完成任务
3. 多方并行：本来按计划执行的任务，允许并行执行，减少任务间等待时间

这就是本文强调的风险思维中两个重要概念——工期缓冲和工期压缩，也正是解决如何预防进度失控以及如何纠正进度失控的核心。

1. 甘特图

project 中最核心的视图莫过于甘特图，就连 project 的 logo 中都带有甘特图的样式。

甘特图是一种表达项目进度与时间之间关系的图形，其画法和图形元素并不是本文重点。需要强调的是，基于上述的三个原则和两个思维，再配合使用甘特图，能非常便捷高效的进行项目进度管理工作。

例如基于越快越好和 smart 原则，甘特图可以展示每个任务间的紧前紧后关系；基于基准思维和风险思维，甘特图可以直观的展示进度偏差，提高识别风险的效率。

可以说甘特图不仅仅是 project 的核心功能，更是项目进度管理的必备工具。

2. 资源日历

从上述内容可以明确的知道，project 的核心功能其实就是进度管理。那么在工期的设置和任务的排班上，日历功能必不可少。

在 project 中，不仅仅可以直接选择标准双休日历，还可以在标准日历的基础上设置更多例如法定节假日、6天工作制或大小周交替等等不同类型的日历，完全可以满足我们日常工作中出现的各种场景需求。

不仅如此，project 在日历功能上还充分考虑了工时类资源的可用性。具体体现在我们可以给不同的工时类资源设置不同的工作日历，最大程度的保证在项目排期时资源是可用的。

这里可能很多人会有疑惑，为什么需要考虑资源可用？

设想这样的场景：一个工时类资源例如开发工程师，数量有限而且只能在特定时间可用。如果将其中一个开发工程师在同一时间段内分配两个或两个以上的任务，就会造成他的过度分配。此时就需要通过资源优化技术来保证资源分配的合理性，例如常见的资源平衡方法。

而 project 提供的资源日历不仅限制了资源的可用范围，而且在资源分配后提供了不同的视图供我们参考。例如下图的资源使用情况非常清晰的告知产品/项目管理者资源分配出现了异常：

所以说我们不仅要会使用资源日历，还要充分理解其背后运用的相关原理，这样在使用的时候就会有明确的功能目的。

3. 关键路径

在日常产品/项目管理工作中，有一个很常见的场景：当整体项目计划排定后，管理者会在计划中标注好哪些任务至关重要或者哪些任务不能出现延误。

这个场景在 project 中可以很方便快捷地用突出显示功能来直接显示整体计划中的关键任务路线。而在项目管理领域，这种方法其实叫关键路径。

至于关键路径的专业定义、计算和查找方式，并不是本文的重点。这里我们可以简单通俗的理解成，如果项目整体计划中有一条任务路径发生延期，必然导致项目的整体延期，那么这条路径就是关键路径。

例如从上图一个简单的迭代计划中可以看到，五个任务中 app 接口对接任务一定要在后台接口开发任务和 app 页面开发任务结束后开始，但是后台接口开发任务完成时，app 页面开发任务仍未结束，此时后台接口开发任务有 2 天的窗口时间。

如果后台接口开发任务发生了 2 天以内的延期，其实并不会造成项目整体延期。但假如 app 页面开发任务延期了，则必然会导致项目整体延期，因为它并没有窗口时间。同理 app 接口对接、测试以及上线任务都属于关键路径。

学会使用关键路径方法的意义在于，既能告知团队成员计划包含的风险来提前做好预防应对方案（风险思维），也能给未来项目正式开展后提供明确的参考基线（基线思维）。

至此本文已近尾声，正如文章开篇所说，做一个好的产品/项目管理者，不仅需要一个好的工具，更需要掌握项目管理的核心思想，也就是本文提出的 323 法则——三个原则、两个思维和三个工具。

需要补充说明的是，本文抛弃了大多数文章或书籍使用的大段理论阐述方式，而是从 project 软件出发，运用真实使用案例来引出其功能设计背后蕴含的项目管理思想，这样能让我们更容易地去理解，同时也能给产品/项目管理新人们带来一些实际的工作思路。

本文从选题到完稿时间接近一个月，由于项目管理体系之庞大，导致本文一度超过万字。但为保证文章的高度可读性和实用性，在审稿时删减了半数内容。这也是为什么文章很多地方看起来避重就轻的原因，例如并没有介绍关键路径具体的计算方式，也没有说明资源平衡的专业方法。

但也正因这样的不完美，才有持续学习的动力，既要是 product manager 更要是 project manager。

本文由 @ iamxiarui 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自unsplash，基于cc0协议