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

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

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

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

一、三个原则 1. 越快越好

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

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

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

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

老板制定产品迭代计划，要求 10 月 1 日完成产品 2.0 版本的迭代

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

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

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

越快越好原则(ASAP)：项目中所有的任务都越早开始越好

越晚越好原则(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 原则会带来一个非常麻烦的问题，也就是臭名远扬的帕金森定律。

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

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