本文将从 Project 软件的独特视角,强调产品经理需要的项目管理相关思想及其关联知识。
在网上流传着这样一份腾讯产品经理能力模型,暂且不论其真假,但不难发现做一名合格的产品经理需要非常综合的各项专业能力。
而在能力模型中有一项很重要的能力就是项目管理能力,它能在产品的整个生命周期中,帮助 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 原则会带来一个非常麻烦的问题,也就是臭名远扬的帕金森定律。
帕金森定律在项目管理上强调的是:任何任务都会拖延,直到所有可用的时间用完为止。