在很多时候,互联网公司的产品经理还需要兼任一部分项目经理的角色,需要整体把控项目的启动、计划、执行和监控、以及项目收尾等工作,活脱脱又变身成为了一名项目经理。
关于产品经理和项目经理,之前网上有个说法:
一个公司有了产品经理就不需要项目经理,只需要配备一个懂技术的技术统筹就可以了,如果一个公司有了项目经理,就不需要产品经理,只需要一个 懂产品的产品助理设计产品就够了,要是一个公司同时有产品经理和项目经理,这两个人就是笨蛋。
暂时先不去评论这个说法正确与否,要了解产品经理与项目经理的异同,我们还是先来聊聊什么是项目管理。
什么是项目管理
什么是项目管理?工作涉及项目管理,我们的日常生活中同样涉及,比如说你要举办一场世纪婚礼、准备去国外来一次度假旅游、和朋友搞一次周末聚餐,甚至泡妞也是需要一点项目管理知识的。
用比较学术一点的口吻来说,项目管理指的是在有限的资源约束下,运用系统的观点、方法和理论,对项目涉及的全部工作进行有效的管理。也就是说从项目的投资决策开始到项目结束的全过程进行管理,包含项目启动、计划、执行和监控、以及项目收尾,以实现项目目标。
这就要求一个项目的管理者,能够通过周密的计划,去管理好项目中的人、事、物,达成项目目标。
举个栗子:日常生活中,我们都会碰到由于迁新居、工作流动等原因,需要进行一场浩浩荡荡的搬家运动。搬家是一件再平常不过的事情了,但是,如何节省搬家时间?如何搬家最省心?如何节省搬家费用?
我们可以尝试着从项目管理的角度来思考一下。
项目目标
将现住处所有东西搬到新的住处
限制条件
本周三之前必须搬,因为要办手续
必须于18:00-21:00搬,太早,在公司上班,太晚,不太方便
人员分配
我 ,收拾人员,全程参与
司机,搬家公司运输人员,运输阶段参与
风险识别
个人的东西太多太多,没有足够的包(需要多准备一些打包的包裹)。
临时叫车怕叫不到车来运输,而要等较长时间(需要提前与搬家公司进行联系)。
项目任务分解
1 收拾东西
1-1 收拾衣服
1-2 捆扎书本及收拾其他物品
1-3 收拾生活用品
1-4 打包
2 短途运输
2-1 寻找并雇佣运输工具
2-2 记录物品数量
2-3 装运物品
2-4 运输至新住处
3 移至新家
3-1 将东西从车上逐渐搬至新家
3-2 拆包,展铺部分用品
3-3 简单布置
项目关键节点
里程碑1:东西收拾完毕 可交付成果:若干打好包的包裹
里程碑2:运输到新家 可交付成果:无
里程碑3:物品移至新家 可交付成果:全部物品移至新家
成本规划
运输费 50元
你看,这就是一次简单的项目管理过程,但即使是一次简单的搬家活动,也需要经过比较周密的计划安排才能取得比较好的效果。所以,从这个角度来说,产品经理日常涉及的互联网产品的项目管理工作,则比搬家复杂得多,其中涉及的人员、资源、时间及任务的分解、规划的复杂性远超一次简单的搬家活动。
既然我们知道了什么是项目管理,就再来看看产品经理和项目经理都有哪些差异吧。
产品经理和项目经理的差异
首先,产品经理和项目经理的职责定义不太一样。
产品经理是 Product Manager ,主要是负责市场调研、用户研究并根据用户的需求,定义和设计产品,然后考虑产品的商业模式、运营推广方式等。接下来去推动相应产品的相关团队成员,根据产品的生命周期,协调研发、测试、市场、运营等,确定和组织实施相应的产品策略,以及其他一系列相关的产品管理活动。从产品的研发、运营、成熟、衰退,一个生命周期的整体把控。
项目经理则是 Project Manager ,负责跟进一个项目,项目管理的职责是实现项目的范围、进度、成本、质量等目标,还要监督控制、协调管理整个项目过程,满足项目干系人的需求和期望。
简单总结起来,产品经理是做正确的事,最重要的是了解和发现用户需求,并提供相应的产品去满足用户的需求,用好的用户体验去更好地满足用户需求;而项目经理则是把事情做正确,需要把项目做的完美,在时间、成本、资源约束的情况下完成项目目标。
其次,从行政权力来分析,他们也不太一样。
在产品管理中,产品经理是领头人,是协调员,是鼓动者,但他并不是老板。作为产品经理,虽然针对产品开发本身有很大的权力,可以对产品生命周期中的各阶段工作进行干预,但从行政上讲,并不像一般的经理那样有自己的下属,但他又要调动很多资源来做事,因此如何做好这个角色是需要相当技巧的。
而项目经理是有自己的下属的,他有一个属于自己做项目的团队,但项目经理往往需要在一个临时的、虚拟的团队架构中,发挥自己的影响力,并达成项目的目标。从理论上来说,项目经理是比产品经理更有管理能力和权力的那个人。
最后,产品经理和项目经理的工作其实又结合的比较紧密。
产品经理与项目经理的分工和协作,真正要严格的区分开来是比较难的,在工作过程当中都是结合的比较紧密的。比如说,产品经理也需要时不时地跟项目经理了解下项目的相关进度,很多产品经理存在这样一个认识误区:需求文档确定了,进入项目阶段之后就不管了。不及时跟进开发的进度,也不去测试服务器测试代码质量,最糟糕的结果就是,产品快要上线的时候,产品经理才发现开发质量和原先的产品需求定义相差太大。
一个项目在立项之前,是没有项目经理的,这个过程全部都由产品经理负责,主要是要完成市场调研及需求确认的过程,待到项目立项之后,一般项目经理都是开发负责人或测试负责人,这个时候问题就来了,大一点的项目都会再指定一个项目经理来协助产品经理,以确保项目能最终按时保质保量上线。可是,在实践过程中产品经理和项目经理这种配合模式比较难达到非常和谐的地步。
不和谐的地方,主要体现在以下几个方面
1.对工作量的评估
产品经理一般对某个项目的上线运营是要背KPI指标的,所以对项目的上线时间一般会以比较理想的状态去进行评估,另一方面是产品经理如果自身在前期的市场调研及用户需求确认环节耗费了大量时间,则给到开发、设计的时间就少了很多。往往比较容易出现的一种情况是,产品经理评估的30个工作日就可以搞定的项目,在项目经理的看来需要变成45个工作日,而且人家项目经理还说了,这只是保守估计。
出现这种对工作量评估差异的情况,主要原因还是产品经理和项目经理之间认识和情绪上的偏差,一个是主人翁的精神,一个是执行者的角色,这样就会出现是为了做任务而做任务的情况,并没有任何的主人翁意识和紧迫感。个人建议产品经理在进行需求讲解的时候,不要一味的只讲功能点和实现逻辑,一定要说实现的产品价值,提供团队成员主人翁意识,这样在协调工作量问题的时候会好很多,而且后续的过程当中也会顺畅很多。
2.对需求的理解角度
产品经理天生就需要对需求非常敏感,在产品迭代的过程中,衡量一个需求要不要做,什么时候做,做到什么程度,往往是从市场和用户那里出发的。而项目经理则不一样,项目经理看需求,往往是从技术实现的角度出发,项目经理看了之后觉得实现的代码量巨大,就想对这个功能点进行拦腰斩,只做其中一部分,甚至建议不做,或者说会影响性能却又给不出更好的方案时提议能否暂时不做这个功能。
这个时候,产品经理和项目经理对需求的实现就出现了分析和冲突,一方面产品经理当然不愿意牺牲用户体验和需求,去做技术上的妥协;另一方面又不得不考虑项目经理的相关推论,还要结合项目的进度和时间计划、节点等,去考虑究竟该如何实现需求。个人建议是产品经理和项目经理两个人,最好是要有一个人能够拍板,如果实在不行,则叫一个领导或者老板来拍板。
理论上来说没有任何功能是技术无法实现的,所以我还是比较偏向于由产品经理来评估决定到底要不要做这个需求。
3.对需求变更的容忍度
需求变更对产品经理来说,倒像是一种家常便饭,试想哪个互联网产品在开发的过程中,不是经常变更需求的。当然,如果一个产品经理在项目开发的过程中,变更需求的频率过高,或者有些需求变更是颠覆了原有的产品架构、技术架构的,那么这样的产品经理则不是那么靠谱了。
靠谱的产品经理则对需求有着更为有力的把控,变更需求的频次较低,且不会出现大的、颠覆性的改动。但即便如此,也依然逃脱不了需求变更的魔咒,谁让市场环境本就是瞬息万变的呢。可是开发人员不是这么认为的,当一个功能辛辛苦苦开发出来,马上接到通知说这个功能不要了,要换成另外一种,这种情况发生的次数多了,换成任何一个人都会觉得是被耍了,毕竟都是自己的成果,说不要就不要了,说改就得改了,而且变更的次数多了也会影响项目进度。
出现需求变更的情况,具体可以采用如下措施:
一是要让项目经理理解需求变更的目的及其价值所在,做好沟通工作;产品经理积极地去与团队成员评估需求变更,是变更还是不变更,如果变更,要评估一下影响范围有多大,是当前迭代变更还是下一个版本去迭代。
二是要严格控制版本,减少变更的次数和降低变更的频率,做好迭代周期的规划。