物流企业到底需要什么样的“产品经理”?你用对了么?

 行业动态     |    2018-08-13 21:38

当前物流行业巨头的竞争异常激烈,技术研发能力直接影响了企业的成本控制及流程系统覆盖率。设置好研发部门,定位好产品经理,对物流企业十分重要。

全文共计 3558 字

阅读时长约 9 字

来源 | 云链咨询(ID:saaschain)

作者 | 大贞

编辑 | 小L

近期,某公司产品经理一个需求引发的打斗视频在网络疯传。市面上产品经理群体规模日渐庞大。哪里有研发,哪里就有产品经理。当前大型物流企业,无不自行组建研发部门,随之而来产品经理需求也极其旺盛。

物流企业,以及以物流为辅助产业的电商企业,如何配置产品经理、研发与业务部门的关系,直接影响了物流业务推进效率。

由于软件发展浸入物流行业历程仍然很短暂,所以在物流领域,上述第一类信息化服务基本占了90%以上,第二类服务在业务型物流企业少之又少,除非企业目标是以技术改变物流行业。

然而,尤其是有技术背景或电商背景发展起来的物流企业,更多的是按上述第二类方式配置研发和产品经理,即独立且平行于业务部门,造成研发部门配置超前化。

研发部门超前化造成的结果是:

1)业务信息化进程缓慢;

2)物流企业完全以互联网企业产品经理待遇标准,招聘软件时代的项目产品经理。

产品经理被配置到研发部门,这种尴尬的配置,造成物流企业为研发配置的高薪「产品经理」连软件时代的项目产品经理都不如,那他是什么?

痛苦的「产品经理」

产品经理更多指的是一个群体,而非一个职级。由于互联网时代对用户体验的高追求,造成产品经理地位日渐提高,随之工资待遇提高,应聘人员对这个岗位的期许也有所提高。

我们来看看产品经理的定义:

产品经理是企业中专门负责产品管理的职位,负责市场调查并根据用户的需求,确定开发何种产品,选择何种技术、商业模式等。并推动相应产品的开发组织,他还要根据产品的生命周期,协调研发、营销、运营等,确定和组织实施相应的产品策略,以及其他一系列相关的产品管理活动。——百度百科

产品经理就是以解决问题为核心,整合和管理各种人力、物力等资源,高效的将解决方案变成实际产品输出的领导者。 ——王淮,《打造 Facebook》作者

从上我们可以看出,产品经理的适配条件:

1)有较高的领导权力,从而有协调资源能力;

2)有发现需求、发起项目的能力,充分了解市场与客户痛点;

3)对产品投放成败负责

如果产品经理以上三个条件缺失一个,都称不上是真正的产品经理:第一条不具备,产品经理会成为受气的夹心饼干,研发的出气筒,业务的抱怨对象;第二条不具备,产品经理会成为业务的传话筒,交互设计者和流于形式的文档撰写者;第三条不具备:产品经理会成为混日子的老油条。

在此场景下,产品经理觉得很无力。一方面工资待遇及企业背景尚可,另一方面无法实现他对工作本质的期待,无力推动又压力重重。最后有理想的产品经理选择离职物流企业,寻找能够适合他期许的下一份工作。对物流企业而言,这无疑是一大损失。

研发部门与业务部门的矛盾

由于研发部门被寄予「用科技改变物流」的厚望,且服务多个业务部门,组织设置平行于业务部门,无汇报关系。超前设置造成技术部门希望掌握主动权,不断希望用新技术去主动改变物流场景,这时实际业务经营团队与研发的超前理念发生了强烈的碰撞。

下面用多个场景进行举例。

1)研发部门主动发起了一个自认为很不错的项目,联系业务部门负责人发起这个项目,主动去做了一个车辆管控APP,业务部门没有理由拒绝研发部门的好意,至少你们很积极地在为业务做事。

做好之后,来到业务部门这里开始实施,但是业务部门说我们现在人员紧缺,最重要的是要解决人员招聘及车辆采购工作,没有相应组织推动这个非紧急工作。产品经理和研发忙活了几个月,最后APP根本没用起来,研发很气愤,说为什么业务部门这么不尊重他们的劳动成果。

2)业务部门发现了一个流程需要研发配合以提高效率,研发资源充足,愿意投入资源。但是在开发完成后实施过程中,业务部门发现有几点认知盲区没考虑进去,要求研发进行修改,研发部门修改几次之后失去了耐心:为什么在研发最开始之前不把这些场景告诉我们,让我们做那么多无用功?

随后,这个业务部门被列入了黑名单,以后但凡这个部门提的需求,研发部门都暂时先不开发,先派产品经理过来问5个为什么,等你们考虑清楚了再开发。

研发无法站在业务人员的角度思考,岗位代沟造成系统开发容错率低。但跨组织长链条流程必然是在试错中前行,绝对不可能做到一次性成功。

3)研发当前开发资源并不充足,但业务人员站在一线的炮火中,对功能需求很急迫,这时研发的「产品经理」以专家的姿态评估你的需求是否合理,是否值得资源投入。

需求合理性评估变成了一场又一场培训会,「产品经理」一次次的提问并不是心中已有答案,而是业务部门对他们的科普,需求合理性评估完花了一个月时间,研发终于开始排期。

业务部门在等待中磨灭了功能推进的激情,等功能开发出来之后,也许组织结构发生了微妙的调整,原来的需求提出者已经换了个部门,研发的积极性再一次被挫伤,他们的劳动成果再一次被忽视。

可以看到,配置在研发部门的产品经理,在三个场景中都不具有主导地位。

考核指标不一致也是造成研发部门与业务部门产生矛盾的主要原因。研发部门的考核指标是系统开发量及系统实施使用情况(包括研发出高科技颠覆物流行业的一流技术)。业务部门的考核指标是经营目标,比如成本下降,收入提高。

在笔者之前就职的企业,由于研发配置的产品经理不了解实际业务,业务部门本身也会衍生出产品经理岗位,造成与研发部门产品经理工作内容有许多重叠部分,最后研发部门产品经理的日常工作变成了PRD撰写及用户界面交互设计,职位高一点的产品经理变成了需求合理性评审员。这种配置,造成了人力资源的严重浪费。

物流企业如果确实需要招聘类似产品经理职位,可以对产品经理岗位进行进一步细分:

1)岗位名称调整以摆脱市场产品经理预期。比如偏向业务分析为主的调整为需求分析员,归属到各个业务部门,PRD撰写归属需求分析员。

2)业务部门用项目经理的方式组建项目小组,这个项目经理可以理解为产品战术层实施者,直接向部门负责人汇报,部门负责人关注地推结果。

3)研发部门取消产品经理,增加交互设计师,需求沟通一般有需求分析员,交互设计师,研发三者同时进行,中间不进行二次传达。

下图表示物流企业的产品经理在整个产品设计过程中的位置:

研发与业务部门之间的矛盾,在当下的物流企业,有两个途径也许可以解决:

1)如果仍希望保持研发部门独立于其他部门,研发部门与其他业务部门以外包方式进行,业务部门的功能开发需求外包计入成本,对研发部门计入收入,独立核算。如果公司研发资源缺少,并且只是一个开发量短周期波峰,那么允许研发资源外包,引入外部研发以产生鲇鱼效应;

2)研发部门完全服从于业务部门,不做部门平行设置,研发隶属于业务部门,目标同质化:为企业盈利共同努力。允许一定的研发资源损耗,提高研发容错率。

在笔者原从事的物流企业,存在两种研发形态:

1)研发部门独立平行于业务部门,无相互制约关系,无内部结算关系;

2)研发隶属于业务部门,需求分析员角色以所属业务部门员工为主导。

最后证明,在当前阶段,隶属于业务部门,并被业务部门驱动的研发组织设置在系统推进及效率上更具有优势,或许更加适用于物流企业。

研发部门原有为高精尖技术负责的产品经理,理应继续保留在研发部门:

当前物流行业巨头的竞争异常激烈,技术研发能力直接影响了企业的成本控制及流程系统覆盖率。如果因为组织设置原因造成业务推进速度过慢,对企业竞争力存在很大的影响,因此设置好研发部门,定位好产品经理对物流企业十分重要。

*本文经授权转载,如需转载请联系原出处。

推荐阅读