热辣点击
赞助展示
最新图片

产品经理or项目经理关于职责和工作的思考

[点击图片进下一张 ] 跳转到

  任何一个问题地提出都有其背后的原因,而PM需要透过现象去寻找本质,这其实也是一个从需求采集、分析到产品设计的过程。

  互联网公司中,产品经理兼任项目经理职责的情况已经很普遍,PM经常会承担起日常产品项目的推进和执行。每个公司要求PM负责项目管理的具体工作各有不同,只有进行合理的定位和职责分配,才能发挥PM应有的价值,提升团队的效率和质量。

  公司年会,酒过三巡之后,同事们开始和我推心置腹说平常工作上的感悟。酒后吐真言,同事也开始毫无顾忌的说出对我的评价,虽然被别人批评总是难以接受,但从批评中总能得到对自己有价值的信息。而其中最重要的一个评价便是:

  在项目项目开发中,因为对技术没有深入的理解,所以造成对产品需求开发时间认知的偏差,从而给开发同事定的开发排期造成其较大的压力。

  这个评价主要集中在项目管理方式上,目前在行业里关于项目管理的模式主要有三种:

  在成熟型的企业中,一般都会有项目经理职位,负责整个产品项目的执行和落地,主要包括项目成本的核算、协调资源开发、项目推进及管理。

  在项目开发过程中,PM参与的环节主要有:完成产品需求的技术评审、交付完整的PRD、产品开发中就需求与研发沟通、开发完成后的产品验收。

  有些企业,产品项目会由技术leader负责开发与推进,PM的职责工作与第一种模式基本一致。

  还有一些企业,PM负责产品的开发和推进,因此PM除了以上和产品需求相关的职责之外,还兼具的职责有:协同各部门安排产品项目成员、协助技术leader确定各个环节的产品开发排期、定期的进度跟踪、项目变更时的优先级和排期调整、项目交付与上线。

  那么我们公司目前的项目管理模式属于哪种呢?其实准确的说哪种都不属于,只是倾向于第三种,而其和第三种的不同之处在于,PM还承担了另外两个重要的职能:

  1、在组织讨论产品技术方案的过程中,前后端开发人员的职能相互割裂 ,无法给出针对产品系统性的技术架构。而且开发人员之间缺乏主动沟通桥梁,需要PM去协调串通。那么PM需要深度参与产品技术从架构到细节的方案中。

  举个例子,我们曾经的一个功能在开发过程中,发现已有的技术方案完全不适用。然后所有开发人员在一起面面相觑,找不出解决办法。最后由我技术功底较强的产品同事给出了解决方案。包括在哪个环节出接口、客户端传什么参数、需要在哪个数据库中建几张表、哪些字段是已有而哪些字段需要新增等。

  2、PM参考开发人员给出开发工作量之后,确定最终的开发排期。因此这个排期就会面临双方的博弈,开发人员为了避免可能带来较大工作量的风险以及对不可预知的需求留出缓冲时间,会将给出较为充裕的排期。而PM为了满足产品的迭代节奏和高层的预期,会压缩开发的排期。因此最终双方会权衡一个排期的中间点。

  而问题的关键点就在于,这个权衡排期的中间点是否合理。其合理性满足两个条件:

  因为产品开发最终的排期是由PM决定,那么其合理性的核心就在于:PM能否准确预估到一个产品从界面、逻辑到联调的开发需要多大工作量。

  就如同我们去买东西时的讨价还价一样,确定购买的唯一准则便是对商品的内在价值心理有数,不论卖家如何吹嘘都不改变看法。而要做到心中有数就是能真正了解和认识我们要买的商品。

  同样地,PM能否准确预估产品的开发量,就在于是否理解到产品涉及到技术和开发流程。如果没有深度开发产品的经验,我相信这个能力是不存在的。

  从上面的分析可以看出,为何开发同事会指出这样的缺点,本质原因就是在公司做产品需要两个条件:

  因为自己没有开发和写代码经验,对技术认知并不深入,因此造成如今存在的困局。

  从上面三种行业项目管理模式可以看出,其核心在于对产品项目的开发排期,是由项目的对应技术leader来进行评估后给出。

  而我们公司的技术leader呢?答案是leader并不参与整个产品项目的开发和执行环节,因此不会参与到给技术方案和开发排期中,原因需要从公司的组织架构和管理说起,目前公司的组织架构有两个维度:

  而目前公司的管理风格是:重业务线,轻职能部门。人员安排和资源协调基本是PM直接越过部门leader,向相关业务线开发人员直接分配工作。而部门leader的职责基本仅限于人员招聘,以及各业务线人员冲突时的协调,其他时间便是做产品需求。

  因此leader并不会参与产品开发技术方案和排期工作上,那为何会如此呢?

  在公司,产品经理的直接汇报对象是老板,老板要求产品需求和项目管理的各个环节由PM负责,当然如果产品开发未达预期首先也是向PM问责。

  那么问题的矛盾之处就在于,如果技术leader并未被分配承担应有的职责,那么leader也就没有理由和动力参与到产品开发和排期的工作中。

  我的看法是:这和创始人对于管理的认知密不可分,公司从创立的那天起就确立了老板需要一手掌控全局和细节的管理风格。当公司越来越壮大,员工越来越多(现在有200人左右),创始人如果还需要事无巨细掌控公司的一切就会越来越困难。

  如何在公司壮大的过程中创始人还能绝对地掌控公司,老板给出了一个于他而言不那么复杂的方式:老板驱动产品经理,产品经理驱动其他团队。PM需要深入到公司业务的各个环节,而老板只需紧盯PM,让PM去解决所有问题。

  任何一个问题地提出都有其背后的原因,而PM需要透过现象去寻找本质,这其实也是一个从需求采集、分析到产品设计的过程。

  如果要适应公司的风格,我需要做的其实是在短时间内就能具备深入了解技术的能力,最好能亲自写代码和实现产品。而PM的能力模型中,对技术的深入理解甚至有开发产品经验真的是其核心要素吗?我心中已有答案。

  作者:Fintechina,互联网证券公司产品经理,专注于国外证券投资市场产品服务,热衷智能投顾和海外资产配置业务方向的探索。

  本文由 @Fintechina 原创发布于人人都是产品经理。未经许可,禁止转载。

  1.说个题外话,刚好自己最近在对比国内国外的PM和项目经理的产品思想,发现国内和中国台湾那边当个合格的PM都至少10年工作经验,国内很多公司却是应届生刚出校门的就当PM,想想还是蛮可笑的。国内PM的圈子真的乱,真的以为人人都是产品经理,见到过很多PM所做的功能没有任何依据,几乎都是抄袭 + 拍脑袋YY + 公司老板需求,这也是为什么会大量使用JSPATCH + RN +WEEX 这些类似热更新的东西,可以线上动态替换,利弊冷暖自知,可以绕过审核的机制,但是国外根本就不使用这个东西,需求一直没有确定,技术一直抱怨,三天一小改,五天一大改,搞得整个团队都在内耗;

  2.我自己的理解,合格的PM = 半个CEO + 战略分析 + 数据分析 + 资源协调 + 产品策划 + 运营策划 + 技术能力 + PUSH能力,合格的项目经理 = 技术架构分析 + 资源协调 + 时间排期 + PUSH能力;

  3.自己是做技术转向为产品,之前做技术的时候, 师傅都是告诉我,代码首先是给人看的,再让机器去运行,所以一直都是用产品的思维去写代码,保证程序组件化和模块化的延展性和拓展性,偏理性,目前做产品偏感性。最后,理解 + 感性,痛病快乐着。(逃

  我觉得这个观点是认同,这才是突出一个PM的真正本质与责任,而不是单纯套模板,虽然老板拍板和需求更改等问题存在,可是起码起到了对PM自己本身来说负责的作用,对得起真正意义上PM职业,也是PM本质里的一份尊重!

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、招聘、社群为一体,全方位服务产品人和运营人,成立8年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上海广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里分享知识、招聘人才,与你一起成长。


点击排行