背景

2021 年 8 月，TGO 活动，票选 9 月话题，选择《大量事业部需求与产研团队资源之间的矛盾》，话题提出者：dclar，教练：GM。

话题背景

话题提出者 dclar，XXX 部门负责人。XXXX 的领军企业，是当下环境中产业互联网行业中的一员，作为深耕产业业务模式的企业，都在经历数字化转型的爱与痛。业务不断演进发展的同时，还要对更多的产业试水线上业务与 to B 向 To C 的试转型，给产研团队带来非常大的压力，如何权衡井喷式的业务发展与产研团队团队资源的问题迫在眉睫。

名词

航道

企业 A 内，每一个业务线称为一个事业部，企业 B 内，每一个业务线称为一个航道。以下采用“航道”代表一个业务线的部门

产研团队

泛指所有技术研发与产品团队的总和

BPO

航道的业务产品经理(Product Owner)

TPO

产研团队的产品经理(Product Owner)

抛出问题

无穷尽的需求，做不完的报表

面临的现状是，公司内部，产研团队是单独是一个大的航道，多个业务航道内因自身的业务发展需要对于报表和指标都是井喷式的来袭，虽然采用了一系列的 idea 评审、需求评审来过滤无效与伪需求，并采用一系列的自助化工具进行疏导与抵挡，并增加 HC，收到了一些成果，也看到在向好的方向扭转，但确实问题还是有存在的，对于此类产业互联网企业中需求与研发的 Balance 希望能和业内同行做些沟通和交流。

相同的境遇

与企业 A 类似，企业 B 有着非常类似的场景与问题，也有着自己的解决方法

一些共鸣与启发

常态化需求管控

对于业务方，如果不做需求管控的话，需求就是一个无尽的海洋，不同于互联网公司的资源业务一体化的模式，产业互联网公司都是以航道区分，产研团队本身就是一个独立的航道，接收所有业务航道的业务→数字化的需求，通过技术手段赋能公司。从这个架构体系下看，资源一定会有瓶颈。但识别有效需求要作为一个常态化的 Filter，这样才能做到好钢用到刀刃上

量化目标

所有的需求本身需要可量化，有目标，明确优先级与紧急成都，并且采用立项方式。无论是互联网企业还是实体产业型企业，都存在立项制，不同的是，前者的立项是保证始终与持续迭代，后者的立项多在于产品或研发对企业实质性的贡献，更清晰量化目标保证项目的成功与持续输血

战略的眼光

虽然采用立项制，但一些创新型的项目是否就没有了生存空间了么？

不能一概而论，所有的增长在提高人效与科学性的同时，还需要与时俱进的演进，战略型项目就是在风险与机会中寻找突破的过程，这种项目不仅需要有，需要更科学的管理和更强的资源来协同支持，与普通的量化目标的项目分离管理

拉通认知

业务航道与产研航道有时候最大的分歧在于，双方都不知道对方在做什么，互不理解，相互是甲乙方的关系，甚至于出现合同制等企业间合作的低效态势。

在实践过程当中，减少双方隔阂，拉通双方认知，识别对方痛点，从根本上解决问题是重中之重。

• 各自成立自己的 PO 团队

• 业务航道内成立自己的 BPO 团队，熟练掌握自己的业务知识，并尽可能的理解并了解产研团队内 PO 的工作职责

• 产研团队内成立自己的 PO 团队，这是一直有的组织，称为 TPO，一般是主导产品开发对整个项目产品的周期负责

• TPO 与 BPO 的有效融合

• TPO 是懂得技术的产品经理，BPO 是懂一线航道业务的产品经理，双方的认知拉通是项目本身成功的关键，更多的问题在于双方的沟通、互信与深度合作

• 识别根本目标与价值

• TPO 与 BPO 在互信基础上，最终在目标统一一致的基础上合作，整体对产研团队的输出结果负责

建立公共服务中心

一些技术服务中心要体系化，不能重复造轮子，大的技术栈尽量做到统一有序，为快速迭代保驾护航

角色互换(beta)

这是一个开放性的话题，或者是探讨性的领域。一定程度上可以考虑 TPO 与 BPO 的角色互换，考虑相互到对方的工作状态中去体会，用身体力行来实践，目的是增进理解，增加了解，为拉通认知提供更加有效的沟通基础

后记

感谢 GM 百忙当中抽出宝贵时间与我进行一次长谈，让我体会到产业型企业在数字换转型过程当中都经历着自己的痛，但也都摸索出一套行之有效的解决方案。

无论是何种方案，我们都可以看出一点，即价值决定着方向，科学化管理辅助落地，而最终还需要企业内的战略目标与价值观的不断洗礼，无乱航道如何发展，都是在服务于整个集团的战略，分解战略目标，通过科学的管理与梳理，不断前行。

By dclar 2021 年 9 月 18 日