PMP指的是项目管理专业人士资格认证，它是由美国项目管理协会（Project
Management Institute(简称PMI)）发起，严格评估项目管理人员知识技能是否具有高品质的资格认证考试。是国际上也包括中国在内的对专业项目管理人士的一项认可，国内持证人数超过了30万，那么产品经理是否有必要学习项目管理知识，甚至通过报考证书的方式去倒逼自己完成这项任务呢？
我觉得答案是肯定的，我相信大多数产品经理在平常的工作中本身就包含了部分项目管理的工作，我个人也是在产品经理这个岗位上深耕了5年多。大部分产品经理日常最多的工作不外乎收集需求、设计原型、编写PRD文档、需求评审，监督上线等，在我没有接触PMP之前，我从来没有想过这些日常琐碎的工作其实已经被包含在整个项目管理体系中，并且被总结成了非常经典的五大过程组，10个知识领域，49个过程。在公司内部一些小型的项目中，甚至没有项目经理的角色，产品经理兼职项目经理的角色，产品项目的边界越来越模糊。
在5月份报培训班后，我并没有根据常规的安排在9月份进行考试，而是跟着两届班级持续学习了6个月，在12月份参加了考试。我认为比拿到证书更重要的是你在这个学习的过程中实实在在理解了书的内涵，可以和老师讲的内容融会贯通，并将其能够运用到工作中才是真正吸收掌握了其中的。
整个PMP的内容都可以总结为五大过程组，10大知识领域。五大过程组分别是启动阶段、规划阶段、执行阶段、监控阶段、收尾阶段。10大知识领域分别为整个管理、范围管理、进度管理、成本管理、质量管理、资源管理、风险管理、采购管理以及相关方管理。事实上很多方法我们已经不知不觉用在了工作中，只是没有形成系统的方法论。下面我将举例说明项目管理知识在产品研发中的运用。
1|范围管理
说到范围，项目和产品的范围还是有所区别的。产品的范围是不确定的，众所周知，一款产品（这里指软件产品）上市后总是会经过很多的迭代升级，每次的迭代升级中又会包含产品功能或服务的变更，可能是对范围的增加、可能是减少、也可能是改变。但是项目的范围却是明确的，有明确的范围基准，才能形成项目验收阶段的可交付成果。
那么相同之处在哪呢，就是范围都是来自于需求，做产品的时候我们可能对需求更熟悉一些，我们通过竞品分析或用户研究等方式得到产品的需求，形成需求池，对需求池进行管理，比如筛掉伪需求，利用工具诸如卡诺模型等对需求进行分析，排出优先级形成待办列表在每一次的计划版本中去实现。项目定义中的需求也是一样的使命，只不过形成的是需求跟踪矩阵，最终需要实现的需求是项目的范围。
在产品进入开发阶段时，产品经理或技术经理往往需要将功能需求拆解成利于执行地工作包，便于在系统中指派给个人，这里实际上用到的就是项目管理知识体系中的WBS（Work Breakdown Structure）分解结构。当然我们在拆解任务的时候需要遵循一定的原则：1）WBS要遵循MECE原则，即对一项工作进行分解时，要做到不重复、不遗漏的分类，子工作之间要相互独立，所有的子工作要完全穷尽；2）WBS要遵循SMART原则，即一项工作的分解要具备具体（Specific）、可量化（Measurable）、可实现(Attainable)、相关性(Relevant）、有时限(Time-bound)五个条件。每一项工作都必须要有部门和人负责，必须要有主要负责人员。每一项工作都要具体到个人，而不是分配给几个人组成的小组；3)项目的每一个阶段应要能区分不同的责任者和不同的工作内容，应有较高的整体性和独立性；4）可视化原则，可以分层看到每一项细化的工作；组件可以移动位置以利于编排WBS；5)能够符合项目目标管理的要求，能方便的应用工期、质量、成本、合同、信息等手段；6）WBS不要太多层次，以四至六层为宜，最低层次的工作包的单元成本不宜过大、工期不要太长。又是一年年末，下图是举办年会的WBS分解示意。
2|进度管理
提到进度管理，相信大多数产品经理都很熟悉，产品要准时上线，离不开有效的进度管理，但是在工作中又无可避免会遇到坑，比如明明一个任务估了2天工时一干干了5天，明明一个月才能干完的模块领导非要2周上线等，这几乎是经常遇到的事情。学了项目管理知识后才发现实际上如何进行有效的进度管理，以及如何应对进度延误的情况也都是有章可循的。
项目管理体系中，加快进度有两种方式：赶工和快速跟进。其实不难理解，我们平常最常用的加班和增加资源都属于赶工。而快速跟进是将正常情况下按顺序进行的活动或阶段改为至少是部分并行开展。而这两种方式都是有代价的，赶工意味着增加了人力成本好理解，而快速跟进则因为本来依次开展的并行开展，那么一旦前序任务不通过测试返工时则会造成后续任务关联返工，增加了项目的风险。看到这，产品经理们在收到不合理工期要求时，就可以有理有据的向提出方阐明由此带来的影响，一味的接受只会给团队和自己带来更大的坑。
那是不是进度就不可商量呢，也不是的，项目管理体系中还提到了两个资源优化的方法，其中一项是资源平滑，其本质是在关键路径上的赶工，是非常值得推崇的一种压缩进度的方法。给大家举个例子就知道了，比如一个任务拆成了如下A，B两个子任务，按照第一幅图的资源安排，完成任务的时间很显然需要6天，也就是关键路径是B。我们通过将A任务的其中一名资源挪到B任务上，此时B任务缩短至4天就可完成，A任务延长至2天完成，总的工期还是关键路径B，减少为4天。这就是资源平滑的含义，如果产品经理对各项任务的依赖关系以及关键路径有良好的认知，完全可以充分利用资源，排出更为合理以及压缩工期的进度表。
还是以年会筹办简单为例，合理的安排各项并行任务，才能在元旦之前完成整个的筹备事宜。
3|质量管理
说到质量管理，在项目管理知识中有两个概念，一个是质量保证，一个是质量控制。这两者的区别在于质量保证注重过程，通过监督整个开发的过程来确保最终产品质量。而质量控制注重结果，通过检验交付成果来确保产品质量。实际上在软件产品开发中，质量保证和质量控制都不可缺失，测试人员进行黑白盒测试是从质量控制（QC）的角度来确保软件质量，而贯穿始终的比如我们开发人员在做的单元测试，需求变更的审核流程等属于质量保证（QA），大点的公司甚至有专门的QA部门来指导和影响开发流程及质量。
作为产品经理，可能不直接参与质量管理的具体工作，但是每个产品就像产品经理的孩子一样，最关切的还是父母，所以产品经理无论是在开发前、开发中还是开发后都应该始终关注把控产品的质量。开发前，理所当然要准确的把控需求，开发中要始终监督UI设计完成度，前端开发与设计稿之间的完成度，以及提交测试后的测试完成度。开发后仍需及时关注用户反馈，不断地进行打磨优化。
下面就质量保证分别提出几种办法，质量保证：1）专家培训，通过培养团队成员的专业素养来提高任务执行率。2）流程化，不断提高规范化水平，把经验和教训固化在流程中。使得产品质量不依赖于人，而是依赖于流程、制度、规范。当然流程也需要迭代更新。3）复用化，尽量把公共功能做成模块，便于大家重复调用。避免每次重新开发引起的新问题。4）评审化：请专家对技术方案，思路进行评审，在编码之前找出可能的问题。质量管理大师戴明博士说过：质量是设计出来的。可见编码之前的设计方案是非常重要。设计时就埋下的缺陷隐患在后期是很难解决的。设计不好的软件就像体质不好的人，后期再多的调理也收效甚微。
其他的内容像相关方管理，沟通管理等知识在产品研发的过程中也相当重要，产品经理时常需要与众多的干系人协作沟通，包括用户、开发、老板等，如何识别他们的需求，权力，参与度？这些知识在项目管理体系中也有所涉及，本文不详细赘述，在这次备考过程中，拓宽了眼界。以前也跟很多项目经理打过交道，有时候会认为项目经理似乎很舒服，不需要操刀干活，学完以后才知道项目管理水多深，好的项目管理体系会让团队事半功倍，相反坏的项目管理会导致项目延期、团队气氛低下、失去领导信任等问题。虽然现在大多数公司还是设置产品经理和项目经理两种岗位的，但我个人认为工作还是有很多交叉点，如果想成为一名优秀全面的产品经理，项目管理能力必不可少。
网友评论