人员配置的错误会造成人力资源的严重浪费，同时对于产品经理来说，会限制其工作成长空间。

汽车后市场的发展现状之前文章已经讲过，这里不再赘述，可以参考上一篇《汽车后市场模式解析之（一）：SaaS产品》。

随着该行业互联网化的深入，产品研发部门（有的称“IT部门”）的投入日渐增长，在整个企业成本所占的比重越来越大，因此，配置好产品研发部门资源分布，最大化资源利用率，提高单位产值，对于企业成本控制有着重大意义。本篇着重从产品部门的人员配置讲起，技术开发的部分请关注后续篇幅。

汽后常见的产品研发归属划分及问题

1. 目前市场常见的分为两类

1. 把汽后的传统业务搬到线上，这类型更接近软件时代的项目系统推进，其目标是利用软件的自身优势推进汽后业务效率提高，产品研发部门应当隶属业务部门；
2. 依托于汽后行业单独作为一个信息化产品进行独立销售的软件服务（SaaS），这类服务更接近当前互联网时代的产品，其目的是销售软件产品，与业务部门没有直接关系，理应独立平行于业务部门。

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

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

超前化造成的结果是：

1）业务信息化进程缓慢，研发周期和时间成本被拖长；

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

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

2. 产品经理的痛苦

产品经理的发展史分三步走：

1）以宝洁为代表的消费品时代：营销产品经理；

2）软件时代：项目产品经理；

3）互联网时代：需求产品经理。

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

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

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

——百度百科

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

——王淮，《打造 Facebook》作者

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

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

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

3）对产品投放成败负责。

上述三点缺一不可，否则就不能称之为真正的产品经理，最多算是专员或助理。

第一条不具备，产品经理会成为受气的夹心饼干，研发的出气筒，业务的抱怨对象；

第二条不具备，产品经理会成为业务的传话筒，交互设计者和流于形式的文档撰写者；

第三条不具备：产品经理会成为混日子的老油条/甩锅侠。

在此种配置下，产品经理会倍感很无力。

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

产品研发部门与业务需求部门的矛盾

之前文章也多次提到过产品研发与业务部门的矛盾，由于这方面的问题过于尖锐和普遍，我们不妨换一个切入点再讲一下。

由于产品研发部门被寄予「用科技改变汽后」的厚望，且服务多个业务/需求部门，组织架构设置平级于业务部门，无汇报和向上负责关系。超前设置造成技术部门希望掌握主动权，不断希望用擅长的互联网思维和新技术去主动改变汽后场景，而实际业务运营团队往往更注重跟自己利益密切相关的KPI，因此与产品研发的超前理念发生了强烈的碰撞。

鉴于此，以下场景会频繁在汽后公司上演：

1）产品部门通过分析收集来的用户反馈或者数据，主动发起了一个自认为很不错的项目，联系业务部门负责人发起这个项目，主动去做了一个门店接车APP/Feature，经过几番评审与沟通（注意：此时的业务部门可能并没有真正理解产品的idea，毕竟传统思维和互联网思维之间有时候会存在巨大Gap），业务部门没有理由拒绝产品部门的好意，至少看起来产品很积极地在为业务做事。

产品上线后，来到业务部门这里开始实施，但是业务部门说我们现在人员紧缺，最重要的是要解决拉新客源和库存管理工作，没有相应组织推动这个非紧急工作。产品经理和研发忙活了几个月，最后APP根本没用起来，产品很气愤，埋怨业务部门不尊重他们的劳动成果。

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

随后，这个业务部门被列入了黑名单，以后但凡这个部门提的需求，研发部门都暂时先不开发，先派产品经理过来问10万个为什么，甚至逼着业务部门签字画押才来开发。

产品研发无法站在业务人员的角度思考，岗位代沟造成跨部门沟通效率极低，成本极高。然而跨组织长链条工作流程又必然需在试错中前行，绝对不可能做到一次性成功。

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

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

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

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

考核指标不一致也是造成产品研发部门与业务部门产生矛盾的主要原因。产品研发部门的考核指标是系统完成量，以及研发周期的把控。业务部门的考核指标是经营目标，比如成本下降，收入提高。

谁适合做汽后企业的「产品经理」？

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

在笔者之前就职的企业，由于研发配置的产品经理不了解实际业务，业务部门本身也会衍生出产品经理岗位（其实本应该叫：需求收集/分析员，这里可能是胡乱取名字造成的误解，产品经理的头衔真的很酷吗？），造成与研发部门产品经理工作内容有许多重叠部分，最后研发部门产品经理的日常工作变成了PRD撰写及用户界面交互设计，职位高一点的产品经理变成了需求合理性评审员。这种配置，造成了人力资源的严重浪费，以及产品经理自身成长的乏力。

汽后企业如果确实需要招聘类似产品经理职位，可以对产品经理岗位进一步细分。先从岗位名称入手，解除人们普遍对产品经理职责的锚定效应，例如：

1）偏向业务分析为主的更名为「需求分析员」，归属到各个业务部门，负责理解、梳理业务需求及PRD撰写。

2）业务部门用运营项目经理（注意区别于研发项目经理，如果有的话）的方式组建项目小组，这个项目经理可以理解为产品战术层实施者，直接向部门负责人汇报，部门负责人关注推进结果。

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

下图表示汽后企业的产品经理在整个产品流程中的位置：

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

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

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

在笔者目前所在的汽后企业，存在两种研发形态：

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

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

最后证明，在当前阶段，隶属于业务部门，并被业务部门驱动的研发组织设置在系统推进及效率上更具优势，或许更加适用于汽后企业。研发部门原有为高精尖技术负责的产品经理，理应继续保留在研发部门，例如数据型产品，算法型产品等。

下面是基于汽后企业的两种产品经理配置方式：

当前汽后行业的竞争愈演愈烈，产品研发能力直接影响了企业的成本控制及运作流程。如果因为组织设置原因，特别是关键的产品研发架构设置，造成业务推进速度过慢，对企业竞争力存在很大的影响，因此设置好产品研发部门，定位好产品经理对汽后企业十分重要。

同样的，与汽车后市场类似的广大传统行业在互联网化的进程中很可能也存在类似的问题，限于笔者个人经历原因，不能做过多列举，欢迎有想法的各行业精英朋友在评论区留言，谈谈对你行业的看法。

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

题图来自Unsplash，基于CC0协议。