第1622期

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

全文共计 3558字

阅读时长约 9字

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

作者 | 大贞

编辑 | 小L

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

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

1

研发部门配置误区

云链咨询将物流企业信息化服务分为两类：

1）以实现物流运营在线化为目的的信息化开发服务，这类服务更接近软件时代的项目系统推进，其目标是推进物流业务效率提高，研发部门应当隶属业务部门；

2）依托于物流行业单独作为一个信息化产品进行独立销售的软件服务，这类服务更接近当前互联网时代的产品，其目的是销售软件产品，与业务部门没有直接关系，理应独立平行于业务部门。

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

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

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

1）业务信息化进程缓慢；

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

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

2

痛苦的「产品经理」

产品经理的发展史分三步走：1）以宝洁为代表的消费品时代：营销产品经理；2）软件时代：项目产品经理；3）互联网时代：需求产品经理。

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

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

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

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

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

1）有较高的领导权力，从而有协调资源能力；

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

3）对产品投放成败负责

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

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

3

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

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

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

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

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

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

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

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

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

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

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

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

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

4

谁适合做物流企业的「产品经理」？

笔者在多篇文章中强调，物流是传统行业，信息化技术无非是改善效能、提高客户体验的工具。懂业务也就意味着，这个产品经理必须长期浸淫在实际业务本身，并且对物流业务指标有改善的原动力。因此，物流企业各个部门负责人或者是总经理才真正符合产品经理的定位。当然，他们只负责对产品战略层的定位。

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

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

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

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

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

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

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

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

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

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

1）研发部门独立平行于业务部门，无相互制约关系，无内部结算关系；

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

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

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

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

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