编辑导读：项目管理能力是产品经理必备的一项重要能力，但是很多人却对它不重视，甚至有些人认为这是项目经理应该具备的能力。本篇文章希望从产品经理日常工作角度，讲述对项目管理的理解和可实操的方法论。

一、产品经理为什么需要项目管理能力

1.1 客观标准：腾讯产品培养体系中的项目管理

上图是腾讯内部关于产品策划岗位的能力模型。可以看到，在比较集中的2-3和3-1职级阶段，对项目管理能力的要求，是明显高于其他专业知识和专业技能的。

1.2 项目管理能力的3点意义

从产品工作内容和工作性质出发，对于产品策划或者产品经理来说，项目管理能力至少有以下3点意义：

1.2.1 【重要性】项目管理是互联网人的基础能力

这点无需多言，在互联网行业中，无论哪个岗位都不是孤立存在的，都无法独自完成项目的闭环，因此必然涉及和人的沟通、对资源的管理、对时间进度的管理。

1.2.2 【必要性】项目管理贯穿于产品经理日常工作

产品经理是项目owner，对项目结果负责，因此产品经理的工作和能力要求之一，就是通盘考虑项目计划并监督项目进程。

有些同学会有疑问，很多公司都配置了专业的项目经理，那产品经理为什么还要关心项目管理呢？对这个问题，要从两点考虑：

首先，并不是所有公司都有项目经理，尤其是初创型公司。在创业团队里，通常由产品经理兼任项目管理。因此对于有创业意愿的同学，提前准备项目管理能力和经验，是对未来的前置准备。

其次，即使公司配置了项目经理，也是有局限性的。项目由业务和资源组成，项目经理的精力集中在对资源的管理，而普遍对业务的理解不深入，要求他们对业务理解和产品一样是苛求。对业务理解最透彻的是产品经理，所以在我们为业务推进而展开的所有活动中，都有项目管理的影子。项目经理把控进度、产品经理把控需求，这才是合理的组合方式。

1.2.3 【性价比】项目管理是少数能快速提升、并应用到实践中的能力

以我们常说的产品力作为对比，包括流程设计、交互敏感度、用户感知等，都是要经过学习和较多的训练才能得以提升的；但是项目管理的方法论相对成型，加上积极细致的工作态度，就能让项目的可控性大大提高。

二、项目管理是什么

2.1 传统的项目管理

项目管理起源于传统行业，是为提升品控而引入的概念和能力模型。

在传统行业中，项目管理定义为：运用各种相关技能、方法与工具，为满足或超越项目有关各方对项目的要求与期望，所开展的各种计划、组织、领导、控制等方面的活动。

项目管理存在4要素，这4个要素互为补充又互相制约，在不同的业务场景里以不同的形式存在，业务和项目不同，4要素的优先级也存在差异，通常表示为下图：

尽管互联网的兴起带来了很多新兴行业，也对传统行业有诸多颠覆，但互联网仍然离不开资源、质量和进度，因此在对质量把控方面，互联网项目管理和传统行业的相似性极大。

2.2 互联网项目管理

互联网讲究短平快，对项目管理的定义也应如此，笔者对互联网项目管理定义为：让正确的人，在要求的时间点，完成要求的事或提供要求的资料，而进行的动作或工作。

对应地，项目管理4要素也要调整，如下：

2.2.1 管理的目标

结果目标：在要求时间点上线。

互联网的第一特点是时效性，因此互联网项目的结果更单纯，最重要的就是时间和进度。为了满足这个结果目标，在项目过程中可能使用各种手段，比如删减需求、加班、忽略边界体验、缩短测试流程等等。

过程目标：项目的执行过程可控或避免失控。

项目执行过程中的风险和异常是不可避免的，人为可介入的最大影响，是在暴露风险后的及时弥补，出现异常后快速制定替代方案，以保证最终的上线节点。

2.2.2 管理的内容

1. 成本：对人或资源的管理。通常是设计、研发、测试工时，图文的物料准备，数据量预估和服务器投入；如果是组织线下活动，还涉及实体物料的准备；
2. 时间：对完成时间和进度的管理，即重要节点的交付情况；
3. 范围：对需求内容的管理。需求梳理和产出是产品经理的本质工作，产品经理对这点是最敏感的；
4. 质量：对需求达成度和实现效果的管理。这是测试同学的工作内容，但是通常产品体验环节，也会对完成质量进行考核。

除了4要素外，在项目中，还有个对4要素均可能产生重要影响的X因素，即风险。对风险的管理质量直接影响目标能否如期达成。前面提到，风险和异常是日常，重要的是在问题发生前的预估、发生时的方案替代、以及解决后的回顾总结，这些都属于风险管理的范畴。

如何管理项目4要素，以降低过程风险、把控整体节奏、并达成终局目标？下面希望通过梳理项目类型、枚举工具和方法，以提供可以快速上手的项目管理方法论。

三、项目管理的类型和阶段

需要说明的是，产品经理不是项目经理，项目管理能力并不是产品经理的专业技能，因此对于项目管理能力的学习和掌握，达到“够用”即可，本片文章的方法和工具，也是根据产品经理的工作内容总结提出，如需了解更专业深入的项目管理能力、亦或是项目经理上岗标准，还需向专业项目经理学习。

3.1 项目的3个类型

笔者将项目分为小需求、大项目和持续型业务。

1. 小需求：在推崇MVP的互联网世界，我们做的大部分项目都是小需求，小需求的目标通常很简单，只要功能点保质保量保时上线即可，通常只涉及公司内部同事，如产品、设计、研发、测试；
2. 大项目：我们常说的项目管理方法，基本都是针对大项目提出的。大项目的目标明确，通常是产品上线或业务需求完成，特点是关联方多、周期长、影响范围广，需要投入较多精力关注每个执行节点的完成情况；
3. 持续型项目：持续型项目是由多个小需求和大项目组成的，目标是持续提升业务的数据指标或用户体验，长尾效应明显。

3种项目类型的关系可以图示如下：

下面是3种类型项目的详细对比：

3.2 项目的3个阶段

任何项目，都可以划分为准备期、实现期和观测期3个阶段。

1. 准备期：顾名思义，准备期的工作是为项目实现做准备，所谓“预则立、不预则废”，前期的准备程度将影响后期实现的节奏；
2. 实现期：这是时长占用最大的阶段，也是最可能出现各种异常情况的阶段。保证各项目成员工作内容和进度的可控性，是这个阶段的重点；
3. 观测期：项目完成后，需要评估完成质量、上线稳定性以及线上效果，此即为观测期的内容。

在不同的项目类型、不同的人员配置下，产品经理对每个阶段的关注点也有所不同。下面将结合具体的3种项目类型，分别阐述项目管理的关键点和实操工具。

四、小需求的项目管理

“得益于”MVP和小步快跑的普及，产品经理的大多数时间，都是规划和管理小需求，以期达到快速验证和1+1>2的效果。

小需求的管理门槛较低，从业半年即可基本得心应手，此处主要介绍小需求在各个阶段的重点关注事项。

准备期：

1. 提前“布局”：无论是否有专业的项目经理，很多互联网公司都有了习惯的需求评审和排期制度。至少需在排期前1-2周开始规划需求，并在排期前1周开始准备物料，比如需求文档、交互稿、视觉稿等；
2. 重点分析对上、下游影响：如果定性为小需求，则影响范围注定是有限的。不过对于发展时间长、功能抽象性弱、产品耦合性重的业务，或者底层的基础服务，在改动之前还是要重点分析可能造成的影响。比如表单填写项，前端每删除一个字段，后端表字段都要相应改动，历史数据和其他调用方也要随之调整；
3. 上线时间的预期和确认：通常情况下，产品经理对小需求有足够的话语权和掌控力，但是对于老板或者业务方明确期待的功能，在需求规划前要明确预期的上线时间，以避免在需求排期和实现过程中各种异常导致的延期，对业务方造成重大影响；

实现期：

如果前期的物料准备完全、需求文档规范完整、需求评审细致有效，那么实现期需要产品经理介入的工作很少，更多是开发、测试的工作内容，比如开发需要根据需求文档编码、测试根据需求内容编写测试用例和完成测试等。

但是如果开发和测试对业务熟悉度不够，还是建议产品经理在实现期多体验、多发现问题。

观测期：

在需求上线后，重点关注内容完成质量和需求效果，具体包括：

1. 版本质量评估：需要测试、产品经理和项目组其他成员共同体验线上产品；
2. 用户体验反馈：找种子用户或者其他同事体验新功能，能快速收集反馈意见并第一时间调整；
3. 核心数据监测：用户体验反馈存在主观性和微观性，而数据是客观和宏观的；产品上线后，从宏观层面观测核心数据的变化情况，可以帮助我们发现更深层次的问题。

五、大项目的需求管理

前文提到，大项目存在周期长、关联方多等特点，大项目的项目管理难度理应更大，也需要引入更多的项目管理工具和手段。

5.1 准备期

在这个阶段，需要完成以下工作：

1. 确定项目目标和里程碑
2. 完全模拟实现期和观测期的实现过程、异常流程、评估标准
3. 对1和2中的全部内容，在项目关联方中达成一致

对工作内容进一步拆分，可以分为物料准备、对内沟通、对外同步3部分。

物料准备：

为更好地管理项目4要素和潜在风险，至少需准备以下资料：

1. 宏观(管理范围、 时间)：里程碑视图、甘特图
2. 微观(管理全部4要素)：工作拆解表
3. 风险预估(管理风险)：风险点预估和预案准备

工具1：里程碑视图。

该资料的重点是展示全局视角；说明在何时、有何项关键产出；主要阅读对象是项目组全体成员、外部关联方和上层老板。

绘制关键点包括：

1. 抓大放小：因为阅读对象广泛，所以不能说明项目的各个细节，对关键里程碑做重点标注即可；
2. 重点标注关联方多、存在外部依赖的节点：这些节点既是重要里程碑、也是潜在风险点，提前曝光，有利于全体成员对关键节点的重视。

工具2：甘特图。

这是项目管理的经典工具，也是展示宏观全局视角的工具；说明当前在项目的哪个阶段、已经/正在/即将执行哪些子项目；主要阅读对象是项目组全体成员、外部关联方和上层老板。

绘制关键点包括：

1. 子项目拆分细致、MECE：尽管同属宏观型工具，但甘特图不能抓大放小，或者说在甘特图中，不存在“小分支”，每个子项目都是做充分的展示。一方面是因为甘特图的目的是观测所有子项目的进度，另一方面，也是展示项目组所有成员工作产出的机会；
2. 明确责任人和里程碑：除了子项目内容，甘特图的重要意义是明确每个子项目的责任人和交付日(即里程碑)。

工具3：工作拆解表。

这是微观视角的工具，是管理范围、质量和进度的重要工具；目标是让项目组每位成员清楚具体的工作内容和完成标准；阅读对象是项目组成员。

不同项目的工作内容和拆解方式存在差异， 不过注意点大同小异，主要包括：明确关联方和外部角色的工作内容；涉及人员分别确认并达成一致。

工具4：风险预估。

这是本篇文章中，实操难度最大的工具。风险预判需要结合业务目标、行业现状、项目人员组成、外部依赖等多个条件综合分析，而且不同业务的差异巨大，十分依赖对行业、业务和公司的了解认知。这部分内容完全足以单独命题写作。

这里简单罗列几种常见的风险点：

1. 法律风险：产品或者功能是否符合法律法规要求，如果不符合，则只能另寻他路、没有任何商量的余地。常见于监管属性强的垂直行业，比如银行、保险、证券、视频、图文内容等；
2. 道德风险：是否符合普世价值观和社会通用道德标准，如果不符合，则可以考虑修改产品流程或功能点。比如轰动一时的“顺风车社交”就是触碰了社会的道德要求；
3. 公关风险：和道德风险类似，也是触碰了普适的认知，甚至可能引起大范围的非正面讨论。对这类风险，可以前期准备应对话术和处理预案。比如像素级模仿友商、大数据宰熟等；
4. 技术风险：指现有的技术能力可能无法实现产品功能。比如创业公司的资金有限，则不太适合做大数据量的存储；再比如“根据手机壳颜色更换壁纸”这类明显缺少技术可行性的产品方案；
5. 合作方风险：这是最常出现的风险、也是最难完全预估和预案的。合作方有不可替代性、无法提前准备多个“备胎”；对于合作方内部的工作流和体系制度，我们也无法完全了解。如果项目涉及外部合作方，需要更频繁沟通和了解、甚至引入社交手段，以尽可能降低合作方“掉链子”的风险。

对内沟通：

对内沟通的目的是保证项目组内各成员对工作内容和要求的确认，通俗地说，是让项目组成员“签字画押”，以增强责任感和项目认知度。

项目参与人员较多，因此有效且高效的手段，主要是会下和会上结合的方式：即和每位负责人分别沟通细节，并在项目讨论会和立项会上完成同步和确认，最后以会议纪要的形式输出公式。

对外同步：

对外同步的目的有3点：首先是信息同步，保证项目计划的透明；其次是向上管理，让更大范围了解认可项目价值；最后是增强项目成员认同感，协助扩大各位成员的影响力。

5.2 实现期

在这个阶段，需要根据项目里程碑核查各子项目进度和交付物质量，重点观测延期情况和外部依赖项进展，周知关键里程碑和延期影响。

在准备充分的情况下，实现期的主要工作内容是日常跟进、问题解决和进度同步。

1. 日常跟进：包括资料内容的及时更新、交付物质量评价、各子项目进度跟进；
2. 问题解决：重点是对异常情况的影响和替代方案评估，如在无法解决时，需及时“借力”、上升问题处理级别；
3. 进度同步：包括建立同步机制并定期周知，比如早会周会制度、项目日报周报、关键问题影响的周知等。

5.3 观测期

观测期的重点工作是观察线上稳定性、监测运行数据。在确定结果符合预期后，需要及时输出“结项邮件”。

5.4 小结

大项目是有实操难度的，但也有比较成熟的工具和方法论，除了上述内容外，还要多“唠叨”几句：

1. 前期准备至关重要，决定项目可控性
2. 宏观资料抽象，微观资料具体
3. 关键结论可回溯，周知同步利己利人
4. 问题升级不可怕，在关键节点借力

六、持续型业务的项目管理

在持续型业务里，小需求和大项目的管理方法论都适用，此外，还对产品经理自身的专业能力提出了更高要求，即对产品力的要求，包括但不限于：对业务的理解、版本规划能力、市场和用户分析能力、自我能力等。

持续型业务的管理和数据提升，更侧重于产品专业能力的提升，也希望在后面单独专题讲解。

七、一些碎碎念

重要的事情总是要多重复几遍，除了各阶段的工具和注意事项，还有些贯穿项目管理始终的意义和通用方法，与君分享、以期共勉。

重要性方面：

1. 项目管理的价值在于充分利用社会分工带来的红利
2. 好的项目管理是提高每位成员的效率和影响力，这也会更大程度地提升项目owner的影响力

方法论方面：

1. 无法在别人的脑子里装进思想，但是可以装进去目标
2. 产品经理的项目管理，最重要的阶段是准备期
3. 靠谱的项目管理 = 细致、专注、勤奋 + 适当的方法和工具

#专栏作家#

李小新，人人都是产品经理专栏作家。腾讯产品经理，专注于数据指标增长、中后台建设等领域

本文系人人都是产品经理翻译团队 @李小新  原创发布，未经本站许可，禁止转载。

题图来自Unsplash，基于CC0协议