众所周知，产品经理和项目经理的岗位职责是有区别的，但有些公司的产品经理在规划产品的同时，偶尔也要承担一些项目经理的工作。阿静结合市面上的项目管理流程和自己公司的情况，来聊聊产品经理如何进行项目管理。

总理：“这个要求必须满足。我不在乎它如何实施。它将于明天推出。”

开发GG：“如果你连项目管理都做不好，怎么启动项目呢？”

上述对话虽然是一句玩笑，但也体现出了项目管理在项目周期中的重要性。

众所周知，产品经理和项目经理的岗位职责是有区别的，但有些公司的产品经理在规划产品的同时，偶尔也要承担一些项目经理的工作。阿静结合市面上的项目管理流程和自己公司的情况，来聊聊产品经理如何进行项目管理。

接下来阿菁会从2W1H，What、Why、How的角度来给大家介绍项目管理。也就是什么是项目管理？为什么要做项目管理？如何做项目管理？

另外：附上本文的框架，以节省时间。如果有兴趣，可以继续深入阅读；如果没有，谢谢来访。（文章最后有阿菁为小伙伴们准备的知识图谱，有兴趣的可以看一下）

1.什么是项目管理？

在了解项目管理之前我们首先要明白各位PM天天讲的“项目”到底是什么？

项目是为了创造独特的产品、服务或成果而进行的临时工作。

那么，什么是项目管理？

百度百科解释：

项目管理是将管理知识、工具和技术应用于项目活动，以解决项目问题或满足项目需求。

所谓管理，包括五项主要任务：领导（）、组织（）、雇用（）、计划（）、控制（）。

影响项目管理的因素有很多，阿京将其总结为六个要素：质量、进度、成本、范围、组织和客户满意度。

简单地说，项目管理就是使项目能够按照预定的时间和计划（包括质量、成本等）顺利进行的标准化过程。

项目管理的流程大致可以分为几个步骤：项目立项→项目规划→项目实施→项目监控→项目收尾。下面将进行详细的讲解。

2.为什么需要项目管理？

首先明确一下范围，本文提到的“项目”指的是互联网产品项目。另外，对于职业项目经理来说，产品经理更注重服务于项目管理层面的需求，包括需求的传递、评审、落地，同时追求更高效的跨部门沟通协作。

2.1 整合资源，推进融合协同

项目是多个部门甚至多个组织/公司的协作开发，即集成和协调。以软件开发为例，它涉及产品、设计、前端开发、后端开发、测试和运营等多个角色。项目管理可以有效地整合来自多方面的资源，并更有效地利用它们。

2.2 减少不确定性，确保进度可控

项目进行过程中可能会出现各种不确定性（错误、延误、修改等）。项目管理可以更好地确保不确定性尽可能可控。

2.3 记录工作内容，使项目清晰、合乎逻辑、一致

项目管理的核心是将工作内容记录下来。人的记忆是有限的，项目过程中涉及的计划、人员安排、项目变更等信息量巨大，而且往往有多个项目并行开发，此时项目文档的作用就更加凸显。

可以使项目人员的思路更加清晰，逻辑性更强，一致性更强，同时在项目完成后，相关项目文档可以作为项目评审的有效依据。

概括而言，项目管理就是满足项目经理对项目的需求和期望，对项目在质量、范围、进度、成本等方面进行总体控制。

3.如何进行项目管理？

项目管理涉及的方面很广泛，概括起来可以分为项目管理的原则、方法、技术，即方法和工具。

前面提到的项目管理流程（这个过程也是PMP所涉及的完整过程）：项目启动→项目规划→项目执行→项目监控→项目收尾。

在这一部分中，阿静会把这些流程逐一分解并描述出来，以便大家能够更清楚地理解项目管理的概念和流程。

3.1 第一阶段：项目启动

不管什么项目，成功与否，背后都有其诞生的原因：市场推动、资本推动、领导主观、多方调研后的决定……等等。本文主要关注项目管理，因此对项目诞生的原因就不做过多分析了。

那么，在项目启动阶段我们应该做什么呢？

运用3W1H分析思维来思考：

为什么要启动该项目（项目成立）——为什么 项目目标是什么——什么 项目参与者——谁 如何启动项目——如何

3.1.1 为什么要启动该项目？

项目启动的标志是项目核准，因此，这个问题可以转化为：项目为什么要核准？

惩罚分为大项目和小需求，大项目主要指一个项目从0到1的完整开发，比如一个电商系统APP，或者一个产品里的某个大的功能，比如淘宝里的会员系统等，小需求指系统中的一些版本迭代。

项目设立的目的是为了让项目的目的和脉络更加明确。

3.1.2 项目目标是什么？

不同类型的项目，不同的需求导致项目目标也不同，有的项目是为了满足上级需求（质量不高），有的项目是为了开拓市场（质量中等，开发时间短），有的项目是为了提升产品体验，有的项目是为了产品激活和新客户，有的项目是公司的战略部署等等。

只有明确项目目标，才能合理安排项目、配置资源。

3.1.3 谁将参与该项目？

需要考虑两个方面：谁与项目直接相关，谁与项目间接相关。

对于互联网项目来说，项目提出者一般是领导/老板/产品/客户，项目执行者是开发团队：产品、设计、测试、开发、运营等都与项目息息相关。

通常在项目启动后，阿京会把项目参与方（包括提出需求的一方和开发团队）召集到一个小组，对项目做一个简短的介绍，这样项目参与方就知道他们是项目的参与者，有时间提前做好准备。

3.1.4 如何建立项目？

在项目启动阶段，线上会成立小团队，线下通常会有个“项目启动会”，向项目参与人员讲解项目的由来（为什么做）、谁来做（项目参与人员）、怎么做（用什么框架、什么设计规范等）、项目目标（快、准、狠等）、项目大概的开始和结束时间等。

主要目的是向团队领导灌输项目启动的概念。

3.2 第二阶段：项目规划

项目上线之后，并不是立刻投入开发，产品同事更多的是先明确项目需求，准备需求文档，然后调度开发资源等，也就是项目规划阶段。

3.2.1 工作任务分解

任务分解就是将任务不断分解，直到无法再分，然后根据任务估算工期、成本，同时将责任分解到个人，每个人领取固定的文件，在固定的节点完成相应的工作任务。

我们通常叫它WBS（Work），工作分解结构。当任务被不断细分的时候，整个项目的抗风险能力就会更强。

对于工作任务来说，可以分为两种类型的项目：

无论项目大小，都是由数量不等的需求组成的，也就是我们所说的需求池。确定项目目标和功能后，需求池就有了基本的框架。

我们要做的就是从需求池中选取一些需求放入项目的1.0开发计划中，然后按照预先确定的顺序排列起来（不可能一次性完成所有需求）。

（1）分解方法

分解工作的方式有多种：按照产品功能模块分解、按照产品平台类型分解、按照实现过程分解、以及多种分解方式的结合。

比如产品需求是搭建一个商城，那么可以分为APP端、小程序端、Web端（如果需要那么多平台的话），这个是按照产品的平台类型来划分的；

各个端的负责人员有各自的差异和相同点，APP端分为开发、IOS开发、后端开发；小程序端分为前端开发和后端开发；Web端也分为前端开发和后端开发。

其次，对于某个平台，按照功能可以分为会员模块、积分模块、订单模块、商品模块等，每个模块又可以进一步细分为更细的功能，例如会员模块可以分为会员权益、会员信息等。

（2）工具

如果要分解工作任务，可以借助 、 等工具进行整理分解，根据个人喜好选择合适的即可。分解工作任务是比较重要的一步，分解清楚了，后续的优先级安排、任务规划调度才能准确无误。

3.2.2 任务优先级安排

前面的工作任务分解完之后，接下来就是对这些杂乱的任务进行优先排序，先开发哪个功能，后开发哪个功能。

有很多种方法可以确定优先顺序：按产品功能、按紧急程度等等。

（1）按产品功能分类

按功能划分产品的前提一般是按照功能优先级排序，前提是项目有足够的时间。

不太容易理解？我举个例子，我们开发一个小程序商城，里面有商品模块、订单模块、配送模块、退换货模块等，那么顺序应该是先搭建基础商品模块和订单模块，然后再搭建配送模块和退换货模块。

（2）按紧急程度分类

如果按照紧急程度来划分，按照时间管理的四象限，其顺序为：紧急重要>紧急不重要>重要不紧急>不重要不紧急，但前提是功能划分是可行的。

比如下个月要上线商城分销功能，但是商城的产品体系还没有建立起来，那么不管有多急，也要先把产品体系建立起来，然后再去建设分销体系。

任务优先级的安排更多的是将两种或三种分类方式相结合，以精准排列任务的优先级，最大化开发效率。

3.2.3 任务调度

完成任务分解和任务优先级安排之后，接下来就是任务调度（项目不能无休止的进行下去）。如上文所说，可以利用、等工具列出项目功能点和优先级，然后和开发人员沟通，针对每个功能点进行项目调度。

通常一个项目都有一个总体的时间，例如2020.5.1-2020.9.1。所以为了能够按时交付项目，项目排程是非常有必要的，因为项目过程中会有大大小小的变更，排程就是为了把控项目整体的进度。

3.2.4 风险控制

在项目管理中，尽量把风险放在首位，确保风险可控。（这个很重要，也会考）

无论项目管理做得多么好，项目风险总是存在的。有些风险可以消除，有些风险可以预防。阿菁将项目风险分为以下几类：

（1）提出要求的一方没有监督项目进程

在项目需求匹配的初期，需求方只给出了一个需求文档，之后产品同事就开始规划项目。在项目的规划、设计、开发阶段，需求方并没有完全参与（没有一步步确认）。结果有可能在项目完全完成并提交给需求方后，需求方却指出项目不是他想要的，需要大修改改，甚至推倒重来。

那么此时的问题就是巨大的，无论从成本还是从项目影响范围来看，无疑是晴天霹雳。

所以在项目的每个步骤（需求匹配、设计稿、程序后台建表、测试等）最好都和需求提出方进行沟通确认，避免后期项目出现大的返工和更改。

（2）要求不明确

明确项目需求是产品人员的工作之一，深挖需求是必须的。只有明确了所有需求，设计人员和开发人员才能顺利进行设计开发，自然需求文档的修改就会少一些。需求不明确也会导致返工和调整，虽然短时间内可能可以实现，但也容易降低设计人员和开发人员的工作积极性（不断的返工很容易让人疲惫）。

所以产品同事需要提升发现需求的能力，有些需求提出者无法完整描述自己的需求，特别是传统行业的需求提出者，这时候产品同事的作用就非常重要了。

（3）任务规划不合理

上面已经提到了任务规划，包括任务分解、优先级安排、任务调度，任务规划不合理的原因是这三部分中的一个或多个出现了问题。

举几个不合理规划的例子：项目预计工期是五个月，给开发人员三个月的时间，这在任务时间安排上已经是不合理的，如果此时PM不安排任务优先级，或者优先级安排有误，那么项目肯定会延期。

（4）请求方改变请求

提出需求的各方通常有以下几个角色：领导、运营、市场（用户）、销售、甲方、PM等。

需求的变更可能是由各种不可控因素引起的，也会增加开发难度，延长工期。有些需求的变更可能是因为PM在初期没有考虑清楚，当框架搭建好后，如果又增加了新的需求，开发人员很难做出更改。

（5）技术风险

技术风险主要在于开发者，在项目立项时往往会进行技术评估，在立项会议上，参与项目的技术人员会在了解项目情况后进行技术选型、技术难点讨论，如果涉及到对接第三方接口，还会审阅第三方接口文档，此时会综合判断第三方接口提供的功能是否能达到预期功能。

技术阶段评估之后，后续的开发可能会推翻之前的技术评估，也有可能因为前期的误判，导致在实现某个功能时遇到瓶颈，甚至可能在技术层面出现延误，导致工期延长。

3.3 第三阶段：项目实施

3.3.1 各段过程跟踪

在开发过程中，项目经理往往需要按照前期制定的调度计划（包括前面提到的任务规划调度、工作任务分解、优先级调度等）来跟踪设计进程、开发进程、测试进程，这就是项目管理。一个项目短则一两个月，长则一年半。

同时，在实际的项目开发过程中，往往不只有一个项目在运行，可能会有多条产品线、多个项目并行开发（也可能涉及不同的开发人员）。也就是说，一个开发人员/设计人员/测试人员可能同时负责多个项目，项目A完成了15%，项目B完成了35%……因此，项目数量之多、无序性之复杂，更需要科学合理的流程跟踪。

可见，项目进程是否得到妥善的跟踪，对于最终项目产出的质量也是至关重要的。

3.3.2 阶段性输出文件审查

在整个项目生命周期中：

目前太多的PM局限于各种文档模板，追求文档的完整和美观。但这里阿菁想说的是，文档存在的意义，是为了让项目更加规范有序。

文档只是一种传递信息的媒介，之所以选择文档而不是口头交流，是因为文档能更好地保存和记录信息，只要能达到目的，这一点明确，文档的具体形式和风格就不那么重要了。

好的文档是最适合您的公司和业务需求的文档。

3.4 第四阶段：项目监测阶段

3.4.1 例行项目会议

提到了项目进程跟踪的重要性，那么问题来了，如何跟踪一个项目呢?其中比较重要的措施之一就是定期召开项目会议。

项目会议可以分为每日站会和周会，除了管理项目之外，还可以管理项目中各个角色的开发状态。当然这里的管理不是指传统意义上的经理，这是因为在互联网行业，产品经理/项目经理可以算是总负责人，是产品的灵魂人物。（自我宣传哈哈哈）

（1）每日站立会议

在日常站立会中，不同的角色需要关注不同的点。

1）产品经理可以通过项目仪表盘全面了解各个项目当前的进度以及与预期的差异，重点关注各个项目的整体进度是否符合项目原定的计划。

2）设计师的关注点在于当前项目的页面数量和美观度。由于设计涉及很大的主观性，设计出来的产品是否能满足目标用户（用户/产品/甲方等）的要求，目标用户提出要求后能否按期完成，是否可以增加修改时间。经常会出现设计师花两周时间完成设计稿，却花一周以上时间修改优化设计稿的情况，这种情况必然导致项目延期。

3）对于开发人员来说，相对要复杂一些，除了关注不同项目的不同进度，还需要关注每个单体项目的进度。整体进度是否与项目计划一致；功能模块是否按照优先级完成；开发过程中是否有瓶颈；如何解决；如果无法解决，是否与产品经理商量，看是否有 Plan B 等等，这些也是开发人员在日常站会中需要汇报和讨论的问题。

4）测试人员关注项目完成情况，是否需要进行早期的模块测试；项目整体是否完成，测试进度是否按计划进行等。

每天整体站立会议时间控制在5-15分钟之间，速度和效率是重点，避免无意义的会议。

我要说三遍：不要开毫无意义的会议！不要开毫无意义的会议！不要开毫无意义的会议！

同时，站立会通常安排在每天下班后半小时，原因是在上班的前半个小时，大家可以回顾昨天完成的任务，规划今天的任务，讨论遇到的困难，这样也能让站立会更有意义，正式的每日站立会并不推荐。

（2）每周会议

周会和每日站立会议的区别在于关注点并不在项目本身，需要尽量远离各个项目的细节（避免陷入细节讨论而浪费时间），从宏观的角度考虑整体的项目进度和情况。

3.4.2 项目周期内的日报和周报

上面说了，有每日站立会议，也有周会，同样，也会有日报、周报。如何写好日报、周报是一个老生常谈的话题，很多大佬都有自己的分享，这里就不提了。

日报、周报对于每个岗位来说都极其重要，但不同的岗位写日报、周报的方式却完全不同。日报、周报在一定程度上是写给自己看的（但其实很多时候是需要发给上级审核的），一旦成为任务，可能就变成了应付的局面，到时候就没什么意义了。

3.5 第五阶段：项目结束

3.5.1 工程师自检

当开发人员完成代码后，需要进行冒烟测试，然后才能交给专业测试人员。

程序员进行自测，进一步检查自己编写的模块，可以使模块的逻辑更加清晰，加深对模块的记忆，最大程度地保证各个模块程序编写的正确性。

3.5.2 设计师自检

UI验证是由UI设计师进行的，验证当前系统UI是否能达到预期的效果。

UI验证是当前页面UI还原度的重要证据，UI验证是检测当前页面在UI图像层面上是否能达到视觉效果，以及开发人员是否按照UI设计人员的界面要求去实现的重要标准。

3.5.3 产品经理自我评估

产品验收是产品经理在项目交付前检查最终需求是否与程序开发一致的过程。

产品经理的验收是对系统整体流程的检查，也是对当前系统的总体检查，在验收过程中需要综合UI验证以及测试结果来确认验收后产品经理是否可以交付系统。

3.5.4 测试工程师测试

测试工程师需要进行功能测试、性能测试、兼容性测试、压力测试、回归测试等，这些都属于测试工程师的职责范围，这里就不再赘述。

3.5.5 项目结案文件

一个项目完成后，需要对项目文件进行归档，包括但不限于项目需求文档（PRD）、验收文档、测试报告、数据库设计文档、项目实施总结报告、产品使用说明书等文档。

文档原则上涉及项目生命周期内的所有文件，PM需要在项目过程中对其进行合理的分类保存，以供后续项目迭代、评审。

各个公司所需的具体文档级别有所不同，因此作为产品，您只需要找到一个平衡点。

3.5.6 项目评审

项目评审是每个项目中极其重要但又容易被忽视的一步。

项目评审四个步骤：收集问题、分析问题、讨论问题、解决问题。

4.项目管理应注意的几点 4.1项目成员的控制

项目管理是由人来管理的，因此“人”在项目过程中尤为重要。

“水能载舟，亦能覆舟。”如果说项目是舟，那么人就是水。人推动着项目的进展，但有时，也会导致项目的失败。

作为项目经理，不仅要关注项目本身的状态，还要关注每个团队成员的状态，包括效率，情绪等各个方面。

这点很难阐述，也没有具体的方法论，需要朋友们自己去亲身体验。（有兴趣的可以和阿静讨论）

4.2 合理运用项目管理工具和方法

市面上的项目管理工具有TAPD、Jira、等，项目的规模、公司的流程、人的性格都会带来项目管理的差异。

项目管理的目的是明确项目经理应该关注的一点：在规定的时间内保质保量地完成项目目标。因此，在这个结果面前，用什么方法论、用什么工具都是相对次要的。

不要过于迷信工具和方法论，它们的目的都是为了更好地帮助项目经理完成项目，提高项目管理的效率。

4.3 做好项目延期的准备

作为项目经理，当然希望项目能够按期、保质、保量地完成。

但由于种种原因，事情往往不能按照计划顺利进行，因此，从一开始我们就需要做好项目延期的准备，并针对风险制定应急计划，避免慌乱。

如果由于人员效率或者外部原因导致项目延误，可以适当调整需求，对比较困难的需求用不同的方式来实现。

比如：在开发平台时，如果没有时间开发客服功能，可以考虑对接第三方客服，如果还是来不及，就弹出客服联系方式，以备临时应急。一个功能按照复杂的流程开发可能需要几个月，但按照简单的流程可能只需要几个小时就能完成。

然后，项目持续时间还取决于需求的复杂程度。控制这个平衡点是产品经理的工作。

最后的想法

“不想当将军​​的士兵不是好士兵，不想管理项目的项目经理不是好项目经理。”

一个好的PM，在做好产品规划的同时，还需要兼顾一些项目管理的工作，哪怕团队中存在项目经理的角色。

项目能否顺利进行，取决于是否有良好的项目管理。

项目管理不只是理论，需要在实践中不断调整。由于项目状态、个人所处公司环境不同，每个项目的管理方式也不同。阿静只是希望从自己的经验和感悟中，能给大家一些启发，灵活运用在自己的项目中。

也希望各位产品朋友在跟自己的团队成员说“明天上线”的时候，大家的反应不再是“什么鬼”或者“没办法”，而是“没什么大问题”或者“肯定可以”。

希望上线不要再出问题了。（阿菁祝大家看完本文一切顺利~）

另外：我附上了我为的朋友编辑的项目管理知识图，他们可以保存和索赔。

作者：一个热爱产品的普通人，产品经理。