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

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

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

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

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

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

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

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

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

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

例如：

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

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

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

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

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

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

参考内容：相关内容。

注意事项：

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

需要说明：

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

出参：我们会提供什么。

需要说明：

我们会提供什么：

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

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

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

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

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

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

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

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

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

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

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

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

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

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