产品经理能力模型之-App 项目管理

在很多互联网公司内部，并没有专门项目经理这个岗位，通常是由产品经理兼任，在这种情况下，产品经理懂得一部分项目管理技能就显得非常重要。

项目管理现如今也是一个热门的学科，因为无论公司大小，或多或少都需要做项目，所以优秀的项目经理也就显得炙手可热。那么作为互联网公司的产品经理，如何才能做好项目管理呢？笔者不才，有幸拜读过项目管理的专业指南 PMBOK， 并通过PMP认证，因为本身也是产品汪，所以力图将互联网产品经理和项目经理这两个岗位结合并阐述工作流程与方法，不足之处、欢迎斧正。

需要说明的是，产品经理和项目经理的英文简称虽然都是PM，但是这两者有着本质的区别，说严重点，如果不是因为没有常设项目经理岗的原因，这两个职位其实是互相对立的。我所理解的产品经理与项目经理，他们有如下区别：

1. 说高大上一点：产品经理关注的是市场、用户和需求，他是一款产品升级迭代的驱动者；是凭借敏锐的市场嗅觉、高效的用户需求洞察能力带领团队始终向前的指引者...等等。 说通俗一点产品经理就是会上吹牛逼，私底下求爹告奶说要改需求的产品汪 :(...

2. 项目经理：项目经理的核心工作或者说最高目标是确保项目在预定的项目预算范围内，准时、保质、保量地完成项目并交付。项目经理是最痛恨需求变更的，因为一旦需求变更将造成项目范围、成本、进度的变化，也就会导致项目无法在预定的时间内完成。

所以说，产品经理和项目经理是一对与生俱来的冤家对头，但是互联网的产品经理却需要很好的将这两个水火不容的的角色融会贯通，拿捏有度。所以，不得不佩服当下的产品汪们，真的得多喂点口粮，衷心道一句："赶紧吃吧，吃完这顿指不定有没有下一顿呢，杀红眼的程序猿们正拿刀等着你呢..."

言归正传，笔者就试图将这两者结合起来，并阐述互联网产品经理在实际项目管理中可以遵循的工作流程。

项目管理的5大过程组：启动、规划、执行、监控和收尾，下面将以一个App开发项目为例：

一、启动阶段

按照PMBOK的描述，启动阶段要做的的事情是：制定项目章程、确立项目经理、识别干系人；在互联网项目管理实践中，最显著的标志就是项目立项，项目立项意味着项目组的正式成立并在公司层面承认项目的合理、合法性，同时也为项目经理（产品经理）有效推动项目进程提供保障。

在这个阶段，产品经理对需要做的产品得有一个大概的轮廓，并做到如下：

1. 面对老板：能讲故事，纵向对比，告诉老板前面有多大一块蛋糕，及这块蛋糕可以花很少的钱就能吃到，并且你有信心比竞争对手出手更快。

2. 面对上级：能吹牛逼，横向对比，告诉上级，这个产品如果做成了，它将在公司如何在众多产品线中脱颖而出，以后升职加薪都是so easy的了！

3. 面对团队：能画饼，你要想做出一款优秀产品，激发团队的激情是最少不了的，所以如何画好一张饼，就显得非常重要。这不是整天吹牛逼能够做到的，要的是以身作则，用数据说话，要求别人的同时，更要严格要求自己，这体现在输出高质量的原型和需求文档，关于原型和需求文档，本节不做详述。请参考产品经理能力模型的需求收集文章。

说服上面三个角色的人物才能保证项目的顺利立项，从而开始实现自己用产品改（ji）变（xu）世（ban）界（zhuan）的梦想。

二、规划阶段

PMBOK指南中，对于规划阶段的主要内容定义很复杂，需要制定项目管理、范围、进度、成本、风险、沟通、干系人等13个管理计划，在互联网项目管理实践中，可能并不需要涉及如此广泛的内容，所以笔者取其中重要的进行阐述。

按照重要紧急程度进行排序：

2.1. 项目范围管理计划

项目范围管理计划，就是输出高质量的产品需求文档和原型，这点请参考：需求收集方法

2.2. 项目进度管理计划

项目进度管理计划的核心是创建WBS(工作分解结构)和WBS词典（工作分解结构说明书）

在这个阶段，产品经理需要召开项目需求分解会议，在这期间项目组核心成员（产品经理、UI/UE/UX，iOS、安卓、后台）必须将理解产品需求列为最高等级（重要且紧急）的工作，由产品经理将产品原型（最好是已经完成UI设计的原型）展示给所有项目组成员，并详细讲述产品的核心流程、功能架构、信息架构，最好的需求分解会议，应该是产品经理结合用户使用场景进行阐述，务求让UI/UE/UX 理解用户使用场景从而设计出符合用户习惯的界面和交互风格；让前端（iOS、安卓、web）开发出用户符合要求的交互和产品界面；让后端主动思考相应场景下应该如何更好处理数据，例如：何时采用文字呈现合适采用图文呈现；为减轻手机电池压力，何时向app发送网络请求才能既不浪费手机电量又保证服务器正常运转等等。

2.2.1 创建WBS(工作分解结构)

保证需求被充分理解之后，需要将需求分解成单个的工作包，工作包的要求是尽可能细，最好能够做到每个工作包的完成时间都不得超过一个工作日，超过的必须再次分解，直到分解成能够在一个工作日内完成工作包，撰写格式如下：

工作分解结构填写表

2.2.2 绘制项目进度网络图

在所有核心成员根据PRD和产品原型，提交各自的工作分解结构之后，产品经理需要将其汇总，并绘制项目进度网络图，样例如下：

项目进度网络图

绘制项目进度网络图的意义：让项目经理从整体上把控项目进度

如何绘制这张图？它就是根据团队成员提交的WBS工作包的前置任务和工期得出的。例如这张图的工作包B，它的前置任务是A，也就是说，任务B开始必须依赖于A才能启动否则无法进行。根据这些工作包的依赖关系，我们可以就可以绘制这张项目进度网络图。我们再根据每个工作包的工期，可以计算出整个项目的关键路径。比如这张图，假如每个工作包的工期都是 1 个工作日，那么这个项目的关键路径就是：“开始->H->C->D->E->结束”。关键路径是什么鬼？它是项目从开始到结束的耗时最长的一条工作流程，它决定了项目的工期。所以说绘制项目进度网络图的意义在于：

1. 他可以让产品经理清楚的知道项目将在何时完工，这时你可以拍着胸脯跟老板说我保证能完成任务或者拿出数据告诉老板，你说半个月就要完成，你怎么不去屎呢。

2. 产品经理应该重点关注关键路径上的工作包完成和反馈情况，因为它们中的任何一个工作延期都将导致项目延期

3. 项目如果需要提前完成，那也必须是对关键路径的工作进行赶工才能达成效果

2.2.3 绘制项目进度计划表（甘特图）

项目进度网络图它能告诉你项目将在什么时候完工，但是却不能有效的管理项目进度。因为我无法从项目网络图中获悉现在项目进展到何种程度，哪些工作完成哪些还没有开始。这时，我们就需要用到项目进度计划表（甘特图）来呈现了。

产品开发进度表(仅作示例)

项目进度计划表详细记录了每项工作的任务顺序和完成情况。通过它，产品经理可以实时了解项目的进展情况。

三、执行阶段

项目执行阶段就意味着项目正式进入开发实施工作。这个阶段，产品经理的主要工作将围绕把控项目进度，确保产品按时交付上了。对于执行阶段的工作，建议给项目组成员每人分发一张项目进度计划，时刻提醒自己什么时间将要完成什么事情。

这里解释一下之前为什么说要让每位核心成员将工作包分解到1个工作日以内，因为项目组正常每天早晨都会召开晨会，那么这就意味着每位成员在每天都有工作被完成，这对于激励/监督项目组成员来说是非常有利的。对于项目组成员来说：他们每天看到有工作被完成，会自然而然的产生满足感并且激励他们保持高度紧张感。如果一个工作任务安排时间过长，那么工作被延误将是必然的事情。对于产品经理来说：高度细分的工作任务，将极大的提高项目进度估算的准确性，同时督促未完成的工作及时完成。因为对比每天应该完成的事情和每周应该完成的事情，前者的紧迫感无疑更强烈。

3.1 项目晨会

对于项目组晨会，建议紧紧围绕以下议题展开：

1. 每位成员更新昨天完成什么任务？用了多少时间？未完成的话，估计还要多久？

2. 每位成员更新今天将做哪些工作？

3. 有哪些工作需要其他同事配合？

注：晨会必须避免讨论问题，只用来更新状态，保证在15分钟内结束。即使必须讨论也应该是晨会结束后单独沟通，防止浪费团队其他成员时间。

产品经理需将上述信息记录并更新到项目进度计划表内，实时把控项目进度进展。预测项目是否延期并采取相应措施（增加资源或赶工）。

3.2 开发/测试阶段

通常一个项目组就是iOS、android、后台、UI、测试和产品经理（项目经理）。针对app产品，后台和app的交互都是通过api来完成，所以应该先让后台写好相应的api并编写假数据，这样可以方便app端顺利开展工作。

测试的工作应该深入到开发的整个过程，必须要求开发设定好里程碑，而且里程碑设定的原则最好不能超过一周，每发布一个里程碑，测试必须开始介入并完成测试用例，同时反馈给相应开发人员，避免因为开发周期过长导致对代码的熟悉程度降低，修改bug的效率下降。

3.3 需求变更

一旦涉及需求变更，这时候PM的角色应转变为产品经理，需求的变更应按照严格的需求变更流程来管理，由产品经理提出并提交正式的变更申请，项目组评审，评审通过后修改产品需求文档和产品原型，进入开发执行阶段。

3.4 评审会议

在项目执行阶段，需要召开众多会议，除了每天晨会和周会，每完成一个项目里程碑时，需要由产品经理召开里程碑会议。由负责完成里程碑主要工作内容的负责人展示交付物，并由团队成员评审是否达到里程碑规定的要求。未完成的则计入下一阶段工作内容。demo的展示方法有多种，iOS端可以使用Airplay完成投影，方便团队成员观看。

在每个里程碑评审会议上，每个团队成员都应发言并阐述本阶段的做的好与不足的地方，只对事不对人，目的在于时刻提醒团队分析总结经验教训，这样才能更快、更好的成长。

四、项目收尾

项目收尾阶段意味着项目结束，但并不意味着这部分工作不需要做。相反，项目收尾的工作的重要性不亚于项目的规划阶段。在整个项目阶段过程中，不可避免会遇到众多的问题，如：风险、变更、失误、沟通不畅、合作不顺等等问题，这就需要项目组在项目收尾时做项目总结，总结整个项目过程中的经验、教训、不足和值得学习的地方。

项目总结如果仅停留在形式上和流程上，那真的是非常可惜的，因为这其中的成长和经历是一笔不可多得的财富，如果不记录下来并在今后的工作中加以改正，就将永远的失去。同时，总结也是整个团队成员系统性整理思路的过程，可以在更高的层面上看待这个项目。而不是仅限于自己的工作内容。这样也有利于项目团队成员成长和提高。

同时，项目的总结也不应该局限于项目收尾阶段，笔者的建议是把项目分为若干个阶段（可以使用里程碑），在阶段结束时就应该做一次阶段性的总结，以免在项目收尾时发生遗忘。