在网上流传着这样一份腾讯产品经理能力模型，暂且不论其真假，但不难发现做一名合格的产品经理需要非常综合的各项专业能力。
而在能力模型中有一项很重要的能力就是项目管理能力，它能在产品的整个生命周期中，帮助 PMer 进行产品迭代的规划、各类资源的整合以及生产进度的把控。
在日常工作中，大部分企业或团队都会选择一些协同软件来进行产品/项目的管理。但在更专业的项目管理领域，项目经理们普遍采用 Microsoft 出品的 Project 软件来进行这项工作。
计划中有三个任务：工期 30 天的开发任务、工期 10 天的测试任务以及工期 1 天的上线任务。
按照 ALAP 的原则，开发从 8 月 1 日可以开始，但此时在不延误 10 月 1 日完成上线的情况下，测试可以晚几天再开始。而开发和测试任务之间存在一些空白时间，称之为窗口时间，作用主要是用来提供缓冲、规避风险，下文会再次提到这个概念。
也就是说，不论是 ASAP 还是 ALAP 都有具体的使用场景。但需要注意的是，两者都不适用某些任务需要在特定日期开始的情形。仍然以上述例子说明，测试任务如果规定必须 9 月 10 日开始，此时就违背了 ALAP 原则。
事实上，不论是在 Project 中还是在日常真实工作中，我们都建议选择 ASAP 即越快开始越好原则。原因是 ALAP 原则会带来一个非常麻烦的问题，也就是臭名远扬的帕金森定律。
帕金森定律在项目管理上强调的是：任何任务都会拖延，直到所有可用的时间用完为止。
这里举一个不恰当但易懂的例子——大学生复习效率图(案例来源：酸梅干超人)，非常形象的描述了这一定律：
基于对任务基本项的设置，Project 会自动生成任务的甘特图，为后续的进度管理提供强大的工具支撑。也就是说 Project 的核心仍然在于对各目标任务的管理，这恰好就是目标管理中 SMART 原则的核心思想。
对于 SMART 原则，这里简单描述为：目标必须是明确的、可衡量的、可实现的、具备相关性的以及有明确期限的。
而该原则映射到项目管理中，仍然具备可实施性：计划/项目/任务必须是明确的、可以有具体的成果来衡量的、是可以实现的、相互间具备关联性的以及具有时间限制的。
其中 Project 预置列中的前置任务，主要用来设置任务间的依赖关系，它是对关联性最佳的实践：
总结来说，在产品/项目管理中为了更好的完成产品/项目最终目标，我们应该遵守第二原则——SMART 原则。
1.3 黄金三角原则
尽管 Project 的定位是一款优秀的项目进度管理工具，但它仍然提供了强大的资源管理和成本管理功能。
在进度管理中，通过各任务的分解与规划，可以完成项目范围及时间的设定；而资源管理和成本管理则约束了整个项目所使用到的人力资源与材料或工时成本。
从日常使用 Project 进行管理工作时不难看出：
- 任务越多，成本越大，时间越长
- 成本有限的情况下，需要缩短工期或减少任务
- 时间一定的情况下，需要增加成本或减少任务
这里可能很多人会有疑惑，为什么需要考虑资源可用？
设想这样的场景：一个工时类资源例如开发工程师，数量有限而且只能在特定时间可用。如果将其中一个开发工程师在同一时间段内分配两个或两个以上的任务，就会造成他的过度分配。此时就需要通过资源优化技术来保证资源分配的合理性，例如常见的资源平衡方法。
而 Project 提供的资源日历不仅限制了资源的可用范围，而且在资源分配后提供了不同的视图供我们参考。例如下图的资源使用情况非常清晰的告知产品/项目管理者资源分配出现了异常：
所以说我们不仅要会使用资源日历，还要充分理解其背后运用的相关原理，这样在使用的时候就会有明确的功能目的。
3.3 关键路径
在日常产品/项目管理工作中，有一个很常见的场景：当整体项目计划排定后，管理者会在计划中标注好哪些任务至关重要或者哪些任务不能出现延误。
这个场景在 Project 中可以很方便快捷地用突出显示功能来直接显示整体计划中的关键任务路线。而在项目管理领域，这种方法其实叫关键路径。
至于关键路径的专业定义、计算和查找方式，并不是本文的重点。这里我们可以简单通俗的理解成，如果项目整体计划中有一条任务路径发生延期，必然导致项目的整体延期，那么这条路径就是关键路径。
例如从上图一个简单的迭代计划中可以看到，五个任务中 APP 接口对接任务一定要在后台接口开发任务和 APP 页面开发任务结束后开始，但是后台接口开发任务完成时，APP 页面开发任务仍未结束，此时后台接口开发任务有 2 天的窗口时间。
如果后台接口开发任务发生了 2 天以内的延期，其实并不会造成项目整体延期。但假如 APP 页面开发任务延期了，则必然会导致项目整体延期，因为它并没有窗口时间。同理 APP 接口对接、测试以及上线任务都属于关键路径。
学会使用关键路径方法的意义在于，既能告知团队成员计划包含的风险来提前做好预防应对方案（风险思维），也能给未来项目正式开展后提供明确的参考基线（基线思维）。
总结
至此本文已近尾声，正如文章开篇所说，做一个好的产品/项目管理者，不仅需要一个好的工具，更需要掌握项目管理的核心思想，也就是本文提出的 323 法则——三个原则、两个思维和三个工具。
需要补充说明的是，本文抛弃了大多数文章或书籍使用的大段理论阐述方式，而是从 Project 软件出发，运用真实使用案例来引出其功能设计背后蕴含的项目管理思想，这样能让我们更容易地去理解，同时也能给产品/项目管理新人们带来一些实际的工作思路。
本文从选题到完稿时间接近一个月，由于项目管理体系之庞大，导致本文一度超过万字。但为保证文章的高度可读性和实用性，在审稿时删减了半数内容。这也是为什么文章很多地方看起来避重就轻的原因，例如并没有介绍关键路径具体的计算方式，也没有说明资源平衡的专业方法。
但也正因这样的不完美，才有持续学习的动力，既要是 Product Manager 更要是 Project Manager。
