编辑导语：产品经理在日常工作中会接到来自多方的诉求，产品经理需要对这些需求进行判断以及对接，对接需求也需要多方面的配合；本文作者分享了关于产品经理进阶，到底该怎么对接需求的方法和思考，我们一起来看一下。

作为一名支撑企业内部信息化的产品经理，除了来自一线人员的的业务诉求，在面向客户的产品的发展过程中，有时也会向我们提出一些需要配合的诉求。

面对这类需要配合其他产品提供相关功能以支撑业务的诉求，便会有对接需求产生。

一、什么是对接需求？

不管是ToB的产品还是ToC的产品，随着业务体量的发展到一定的程度，为了提高产品交付的效率和质量，产品会被划分成越来越细的业务模块。

按业务模块划分后，交由不同的人员去负责，专注于对应的业务模块进行产品能力的建设和优化。

专业度的提升，能够提高单位时间的产出效率，降低单位时间的产出成本，减少资源浪费。

当我们需要基于用户诉求，提供包含多业务模块的产品能力时，各业务模块就进行对接配合，组合提供出能够支撑用户完成业务诉求的产品和服务。

举个例子：

企业A为客户提供某项SaaS服务，为了提高营收，提高用户的付费转化率，运营同学找到前台产品经理提出了增加销售触点的需求；希望在客户使用产品服务的过程中，也新增下单入口，引导用户购买。

前台产品经理了解了业务背景和业务诉求后，想到企业内交易相关的诉求是有专门的产品经理在负责的，加下单入口这个事儿还得找交易产品经理去沟通下，需要他们提供交易相关的能力。

于是前台产品经理和运营同学一块儿去找了交易产品经理，沟通这个需求，看这个事儿需要双方之间如何进行对接和配合。

对接需求：是当某个业务域从自己的业务场景出发去做一些产品优化时，其中某些环节涉及到其他业务域，需要与其进行配合，通过上下游的任务交接，整合提供各业务模块能力的配合需求。

当产品业务域划分，各团队分别针对各自的业务域进行产品能力的建设和优化时，若要提供包含多个业务模块能力的产品支持用户能够完成业务流程、达成业务目的，就会出现对接需求。

对接需求，可以按照对接内容、对接方式、对接业务方类型分别去进行分类。

1. 按照对接的内容来分，可以分为对接业务和对接数据

下述内容，均是以我们作为「被对接方」的视角进行阐述的。

对接业务：指的是我们作为下游业务，需要基于上游业务的场景，产生的业务数据，作为媒介进入我们的业务环节时，需要提供相关的业务能力，从而支持用户完成业务操作，达到业务目的。

例如：

上述案例中，当前台产品与交易业务进行对接配合时，当用户在使用产品时，通过某个入口去下单，就需要前台产品给交易产品提供用户信息以及下单入口信息。

进而，在进入下单流程后，可以结合用户信息等，给用户推荐合适的购买内容，并且完成下单操作。

对接数据：指的是我们作为上游业务，需要基于下游业务的诉求，为其提供相关的业务数据，作为下游业务环节中，用户开展业务的数据依据和参考。

例如：

上述案例中，在前台产品中拓展了下单入口后，为了便于用户了解订单情况，后续还会提供查看订单的能力；而订单的业务数据也是由交易产品统一沉淀和管理的，因此需要交易产品提供相关的订单数据。

2. 按照对接的方式来分，可以分为仅对接接口和对接业务功能流程

对接业务按照具体的对接方式，又可以分为两种：

1. 仅调用下游业务接口，前端操作页面由上游业务自行建设；
2. 上游业务提供业务入口，提供下游业务所需的业务数据，然后就进入下游业务提供的功能流程中，完成业务目的。

业务对接方式的选择，需要看具体的情况来分析。

例如，与公司外部的产品进行业务能力对接时，一般都是只提供接口服务，具体页面需要自行承建。

因为不同的对接方的业务不尽相同，基于各自的业务场景以及不同的设计风格，提供操作页面难以做到统一，由对接方自行承建会更合适。

3. 按照对接的业务方类型来分，可以分为对内对接需求和对外对接需求

• 对内对接需求，是指公司内部的产品与产品之间协作，进行业务能力、业务数据间的对接、组合，以支撑业务；
• 对外对接需求，是指与第三方公司合作，和公司外部的产品进行能力对接，以支撑业务。

本文仅针对对内对接需求进行展开说明。

二、对接需求容易带来什么问题？

1. 同样的内容需要重复介绍沟通的低效

面对业务方，当不同的业务方有各自的诉求来咨询时（例如对接的方式、对接的排期、对接的注意事项）。

我们需要重复去做沟通和介绍（明确业务诉求、业务流程、向业务方介绍我们的产品目前提供的能力，如果对接之后，基于不同的业务场景可以怎么使用），在相同的事情上花费时间。

2. 无法及时响应业务的低效

常见的情况，例如在与业务方沟通时，没有澄清清楚对方需要的是什么能力，我们能提供什么，提供后可以怎么结合诉求和场景去使用起来，导致提供的能力无法较好地满足业务诉求，后续返工，无法按时交付。

或是与业务方澄清时，发现对方提的诉求按照我们现有的能力是无法支撑的，需要先优化，再对接，响应周期比较长。

三、如何高效应对“对接需求”

1. 当对接需求来了—给出对接指南，以高效应对

1）对接指南是什么？

对接指南：是当有业务方对我们提出对接需求，需要我们提供相关产品能力时，能够指导对接工作开展的说明文档。

对接指南主要分为两部分：

第一部分，从业务角度出发，告诉业务方：我们希望对方给到我们的信息有什么，可以在指南中列出一些问题，引导业务方考虑和回答。

通过我们在对接指南中罗列出的让业务方回答的问题，去引导业务方更加全面和深入地思考相关的业务问题，以及涉及的业务场景和业务逻辑。

能够更加精准地定位业务问题和对接需求中双方需要做的事情，以及减少不必要的沟通时间，提高协作效率。

第二部分，从对接角度出发，告知业务方：后续双方需要如何配合，需要业务方提供什么数据，我们会提供什么数据或能力，提供后能够如何使用。

在对接指南中提前提出后续在对接配合时，双方分别需要提供什么数据或能力，如果存在目前不支持的功能点，能够提前识别出来，进行优化并对接。

减少由于提供的功能不适用于业务诉求而返工、浪费资源的可能性。

2）对接指南如何梳理？

梳理第一部分：对接前，业务方需要考虑和回答的问题。

核心思路：需要引导业务方进行思考，完善业务逻辑，避免低效沟通。

参考内容：相关内容。

注意事项：

业务背景：需要是完整的业务背景，即现在是基于一个什么样的业务情况下，遇到了什么问题或者想要达成什么业务目标，促使业务方需要去做某件事；

在这当中，有哪一部分，是涉及到我们的业务的。

业务诉求：基于上述的业务背景，再进一步说明，对我们提出的业务诉求具体是什么。

可以从以下三个方面，去考虑我们要罗列的问题：

• 用户从哪来：会在什么情况下使用？
• 用户要干吗：来了之后，需要做什么？
• 用户到哪去：使用后，接下来要去做什么？

业务优先级及期望时间：

示例：业务诉求中可以罗列出来让业务方回答的问题，引导对方进行相对完善的考虑。

为什么需要说明完整的业务背景和诉求（业务场景和业务流程）？

作为对接需求的一方，我们是多个业务环节中的一环。

为了确保我们的优化能够在业务场景中支撑到用户，而不仅仅是提供了某个功能点。

否则，即使我们提供了相应的能力，但是在完整的业务流程里却走不通，业务价值将会大打折扣。

因此，为了保证业务价值能够更好地实现，用户体验更加顺畅，我们需要去了解完整的业务背景，以及从实际的业务场景出发，关注业务完整的上下游。

从场景、从用户的角度出发去考虑整体的需求和流程，而不是仅仅关注到我们提供的能力。

为什么需要说明业务优先级及期望时间？

基于上述对业务诉求的了解，我们可以大致知道目前的产品能力能否满足业务诉求。

再结合期望时间，有一个大致的预期感知和判断，可以提前思考相关的对接策略，提高后续的沟通效率。

例如：

当前产品能力是已经能够满足业务诉求的，那么基本上预期时间如何，都没太大关系，排期完成对接即可。

以及，如果说我们的现有产品能力是不满足业务诉求的，但是在预期时间内，有足够的研发资源能够去做优化然后对接的，也是排期完成优化及对接即可。

但如果在预期时间内，是没有足够的研发资源去做优化然后对接的，那么需要去沟通对应的对接策略：

• 首先，能否接受我们基于目前已有的产品能力，所满足的业务诉求的程度—如果能够接受，可以考虑先完成对接，使用起来，后续再排期优化；
• 其次，能否接受我们优化至能够满足业务诉求的排期时间，再对接使用—如果能够接受，可以考虑先不对接，等优化完后，再排期对接；
• 最后，该对接需求的业务优先级是否真的重要紧急到必须在预期时间内做到满足业务诉求—如果是的话，需要考虑申请研发资源，排期完成优化及对接。

2）梳理第二部分：对接时，双方需要提供什么？

核心思路：提前识别对接配合中需要注意的事项和问题，尽可能避免后续提供了不适用的功能，导致返工及延期。

参考内容：相关内容。

注意事项：

入参：业务方需要提供什么。

需要说明：

• 其中哪些业务数据是必须提供的，哪些是可以看情况选择性提供的；
• 针对需要提供的参数进行进一步说明，即这些业务数据是什么含义，为什么需要提供，提供后有什么用途。

出参：我们会提供什么。

需要说明：

我们会提供什么：

• 对接业务时，告诉业务方，我们会返回什么业务结果。例如业务方对接下单能力时，需要告知其下单结果。
• 对接数据时，告诉业务方，我们会返回哪些业务数据。例如业务方对接获取订单数据时，需要告知对应的业务数据，例如用户信息、购买商品、购买金额、下单时间等。

在实际业务中可以怎么使用：

示例1：入参，业务方需要提供什么

示例2：出参，我们会提供什么

通过上述内容，提前和对方在业务层面沟通好过程中双方涉及的和所需要的业务数据，理解用途。

如果存在目前还不支持的情况，需要分析并优化以支撑业务。

尽可能减少双方研发在进行开发对接时才发现按照当前的接口情况，并不能满足业务诉求，进而需要重新进行需求分析、接口设计、研发估时这些返工的情况，导致需求研发过程中的风险产生。

业务方看完对接指南后，我们还需要做什么？

业务方根据上述对接指南中的内容，已经大致梳理好了业务背景、业务诉求，了解了双方在后续的交互过程中，需要提供的数据和我们会返回的数据、提供的能力，以及如何去使用这些数据和能力。

接下来，我们需要与业务方再进行沟通：确认需求场景，了解对方目前的诉求和能力，以及明确我们接下来具体的对接方式。

结合对方的诉求和能力沟通确认对接方式，是仅提供接口服务即可，还是需要我们提供功能流程。这里需要具体情况具体分析。

• 例如对外面向客户的产品，对整体UI风格统一性要求较高，要求内部支撑产品团队提供统一的客户订单管理功能时，建议自行建设前端功能页面；
• 例如面向内部员工的CRM产品，要求交易产品提供统一的客户订单管理功能时，建议直接对接功能流程。因为对于订单管理来说，不同的渠道都是需要统一考虑的，如果自行建设，我们改了功能，对方也得跟着改，不如直接对接。

2. 在对接需求之外—主动去思考和规划产品能力的搭建节奏

1）为什么我们要主动思考和规划？

主动思考和规划：即不需要业务方提出说，现在需要我们提供什么能力，我们才去建设。

而是能够自驱自发地去思考，接下来业务上，可能需要我们提供什么样的产品能力，我们要在什么时候能够提供什么样的产品能力。

如果缺乏主动思考和规划，当业务提出需求，而目前没有现成的产品能力能够支撑业务诉求时，可能遇到的问题如下：

若该业务需求重要紧急到，必须在预期时间内做到满足预想的业务诉求：

• 情况1：为达成上线目标，需要额外去申请和协调研发资源；
• 情况2：在产品方案到开发实现的过程中，进行一些妥协（例如：相同的产品能力基于不同的业务诉求进行重复建设），但后续还需要进行调整，浪费研发资源；

若该业务需求，没有必须要在预期时间内满足预想的业务诉求：

• 情况3：预期时间内，提供的解决方案能够支撑业务流程走通，但是用户体验相对来说不够顺畅，或者某些优先级较低的功能点暂不支持，需要做一些舍弃；
• 情况4：预期时间外，优化完成后再与业务方对接上线，产品能力支撑业务诉求相对滞后，响应业务不够及时；

2）如何去思考和规划？

可以从以下几个问题去切入思考：

• 长远来看，我们的产品定位和目标是什么？要能够解决什么问题？满足什么诉求？
• 现状来看，我们的产品能力是什么样的？已经能够提供哪些能力，去支撑业务诉求？
• 结合后续业务可能的发展方向，思考我们需要再搭建哪些的产品能力，当业务有需要时，快速响应和支撑。

具体涉及产品规划的做法，本文不展开阐述。

四、小结

随着业务的发展、业务域的细分，对接需求顺应而生。

为了提高对接需求的效率与质量，我们可以提前梳理对接指南，以减少不必要的沟通时间和更加精准地定位问题和我们要做的事情。

另外，在进行需求对接之余，我们还需要主动去做好思考和规划，以提高业务响应速度和降低由于某些为及时响应业务而提出的临时方案带来的开发成本。

作者：产品BBQ；公众号：产品BBQ

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

题图来自Unsplash，基于CC0协议