复杂产品设计的边界感

践行知行合一 2024-09-03 12:11:09

“我负责哪些产品功能”、“我可以为上下游提供哪些数据服务”、“我需要上下游提供哪些数据服务”、“我应该如何与上下游交互对接”等等产品问题不由自主的会在大脑中出现，都是作为产品经理的我们在日常工作中经常会向自己或相关产品经理问到的问题。

特别是，当我们需要与自己所负责的产品系统/模块存在数据信息交互的上下游系统/模块产品经理argue新的改造产品功能应该如何设计、应该在自己还是对方的系统/模块范围内实现时，对接的双方都会穷尽所有说辞来试图说服对方接受自己所提出的产品功能设计建议。

那么作为产品经理的我们应该如何去应对，如何去协调双方给出最合理的产品设计解决方案？根据过往工作经历，建议按照“以我为主，关注边界”的原则来思考。

在实际业务中正常运转、体现相应产品价值的每个产品系统/模块都有其定位和在支撑业务顺利进行中所应该肩负的应处理的业务阶段范围，供应链产品是由很多不同功能的产品系统/模块组成，并且在物流、信息流、资金流等三方面数据层面提供支撑，作为供应链软件产品的组成部分，每个产品系统/模块所起到的作用各有不同。

例如：采购订单管理模块：定位在响应来自各种不同来源采购订单创建诉求，对生成的采购订单进行状态管理，并将生成的采购订单作为基础凭证被其他上下游系统/模块来调用、流转，以实现业务方商品采购全生命周期管理。

那么按照采购订单管理模块的定位，虽然在创建采购订单时需要用到供应商数据、合同数据、商品主数据、库存数据等数据信息，生成的采购订单在到货后生成的结算单等相关数据，甚至退货、退款过程中数据等的管理都不应在采购订单管理模块的产品功能逻辑范畴，根本原因是这些数据信息的管理与采购订单管理模块的定位不符，采购订单管理模块只定位在采购订单信息流源头数据的生成及管理。

类似地，商品主数据管理模块：定位在商品主数据的创建及管理，商品主数据模块作为一个基础、通用被调用产品模块，被调用后生成采购订单的产品逻辑、资金结算的产品逻辑、退货逆向的产品逻辑等数据信息管理都不应在商品主数据管理模块的产品功能逻辑范畴。

产品定位是核心，也是与上下游系统/模块产品经理argue的依据重心。

从产品专业性来分析，作为存在相互关联的上下游系统/模块产品功能，不同的产品系统/模块分属于由不同的的产品经理、不同的产品团队甚至不同的公司主体分别负责。

我们负责的仅是其中某个环节并由相应产品系统/模块体现。咱们最了解的也只是自己所负责的产品系统/模块情况：例如，咱们所负责产品系统/模块定位、产品功能逻辑、业务和研发资源配置、与上下游哪些系统/模块对接、可以为上下游系统/模块提供的数据清单以及可支持的数据信息交互方式等等。

在实际工作中也不可能允许给予充足的时间和机会去建立对与上下游发生交互的所有系统/模块功能有十分深入的理解。对于上下游产品系统/模块所包含的内在产品功能逻辑及其他相关情况等不很了解，甚至是黑盒状态。（如图1）

图1 系统/模块间相互交互关系

那么，当搭建新的产品功能并需要与上下游系统/模块发生交互对接时，我们应该从对内、对外两方面入手：

对内“以我为主”以自己所负责的产品系统/模块的定位为主，基于“我”去推导出来所需要、所能够提供的数据信息。站在自己所负责产品系统/模块定位角度，确认产品系统/模块内部应新增/改造的产品功能逻辑，非自己范围内需求应坚决拒绝，并据理力争，确保新增/改造的产品功能复合产品系统/模块定位要求。避免所负责产品系统/模块功能范围的无限延展，失去产品核心。避免产品系统/模块功能的耦合性及可扩展性都向坏的方向发展。
对外“关注边界”，对于上下游系统/模块内在的产品功能逻辑，由于没有精力和机会知道全貌，我们不应该猜测对方产品系统/模块的内部情况，而是将关注点聚焦在产品系统/模块对接的工作面，即边界上。上下游系统/模块对咱们而言是完全的黑盒，在与上下游产品系统/模块产品经理交流过程中摆正自己的位置：咱们是需求方，对接方是为咱们提供解决方案的产品设计方，咱们需要做的是明确、无误地提出自己的数据对接需求，明确需要的数据属性、需传递的字段清单、需支持的数据交互方式、需实现的数据交互频次等等层面信息。

至于这些需求如何实现、是否有更好的支持方式，都应交给需对接的产品经理来统筹考虑。（如图2）