无论是C端还是B端，产品一般都不是孤立存在，而是整个业务流中的一环，所以也少不了和外部系统对接。那么，如何高效对接外围系统呢？本文作者结合自身经验，总结了一些措施，希望能给你带来帮助。
无论是C端还是B端，某一产品一般都不是孤立存在，而是整个业务流中的一环。如果某产品属于起始产品，产生数据后，也会连接下游产品，承接相应业务数据，完成整个业务流转。比如获客系统沉淀的客户信息、来源渠道等，都会流转到下游交易系统，即客户购买商品产生交易单，交易系统的交易信息也会流转到更下游的财务系统，负责单据的核算做账等业务。
当然，理论上也没有严格意义的起始产品，上述案例的获客系统，其上游也会又获客前的广告系统、推广运营活动系统，但某个公司的业务聚焦点是获客后的交易，所以会以此公司主营业务范围作为信息产品的边界。
另外，每个产品的上游和下游系统也不仅仅只有一个，主要是因为业务不是单线流程，而是网状结构，不同业务流交叉形成复杂的业务生态。例如上述案例中的获客系统，除了下游会有交易系统以外，可能还会有专门的会员系统、积分系统等作为下游系统，主要是因为为满足用户需求，背后会有一系列产品为其服务。
既然大多数产品是业务流程中的某一环，那就少不了和外部系统对接，这里包括外部公司系统，如外部银行、微信、支付宝支付渠道接口等，也包括内部公司其他系统。合作项目是否能成功上线、成功推广，除了自己产品开发好，外围系统是否能对接好也是非常重要。那么如何高效对接外围系统呢？笔者通过实践总结以下事半功倍的措施，希望有帮助。
合作类项目跨部门协调沟通，需要有明确的目标、各自负责的范围、互通数据的流程。但很多时候，以上流程是不清晰的，会导致项目进度受阻，或是项目上线后出现问题互相扯皮的情况，所以在项目开始前明确出来就非常重要。
整体流程包括：明确产品目标、梳理业务流程图、明确各自产品负责的范围及产品方案、督促双方开发按进度完成上线、共同建立清晰的运维机制。根据实际工作经验，以下分为两类合作项目介绍，以及容易踩坑点。
如果是产品经理自己负责的产品需要其他部门配合，则更像大产品经理，除了负责自己产品以外，更多的是站在整体角度，明确项目目标，带着各方系统一起做。对个人的压力会大一些，因为要对内对外协调很多资源，涉及具体要做什么事儿、需要谁来配合、如果对方不配合怎么办、配合后双方系统的产品范围有重复交叉或是三不管地带怎么办、上线后用户投诉互相甩锅怎么办等等问题。
笔者负责的项目中就有以上类似问题，经过反思后，发现有些经验总结后，大脑就会对下次项目启动风险预判提醒。
1）产品上线前
重点给外围系统对接人阐述项目背景、明确项目目标，督促对方出具产品方案和上线时间。当然，对方是否配合取决于钱和开发资源排期，钱上面就是对方报价是否合理，内部好解决些报工时打卡即可（项目制管理的公司，会将每个开发人员打卡项目来衡量资源配比是否合理），外部则需找采购进行评估。
如果对方报价太高，则积极找相关利益方进行协调，比如换供应商、采购进行沟通调价等。如果对方报价合理，则进入方案确认，开发排期环节。此处需重点注意，尽量细化方案细节，比如正向流程、逆向流程，大概率场景、小概率场景，包括上线后容错机制如何设定，产品设计、开发设计尽量面向未来等，这样多考虑的目的就是避免上线后发现需要重新大改的风险。
2）产品上线后
建立双方运维机制，上线不代表着结束，外围系统人员必须配合一起试点推广、全面推广、日常运维等事宜。比如上线时需要准备什么配置项，遇到问题外围系统人员需找产品、开发还是运维来解决？尤其是异常场景，比如外围系统停机发版时，如何保证双方系统数据准确等事宜。
比如，业务系统某付款单，需推送资金系统进行付款，但因资金系统停机，业务系统并未提前准备，则导致付款单推送失败，用户未在规定时间进行付款，造成客户投诉。此类问题，有几种解决方案，根据大家实际情况可自行选择或延伸思考。
第一种需开发，如果单据量较大，并且系统自动识别报错原因，衡量开发投入产出比较高，则可开发报错提醒功能，如遇到付款单推送失败报错，则邮件提醒技术或产品人员。技术人员看到提醒邮件，则可手工再重推，也可再开发自动重推功能，针对失败单据，如判断是因为停机推送失败则重推。
第二种人为要求，要求外围系统每次停机前必须通知上下游系统进行准备，获取到停机通知后，再通过邮件或工作群通知用户避免停机期间操作系统数据。
第三种技术手工处理，针对单据量不大且不紧急情况，则技术人员获取停机通知的第二天则手工处理，并且要求外围系统避免业务单据量高峰期进行停机发版。
以上案例中只是抛砖引玉，目的是需要大家有意识的考虑多一些，完整流程跑一遍，无论是大概率的业务场景，还是小概率的停机场景，都保证和外围系统对接完整，提前演练就避免生产环境大批量数据错误。
笔者今年的两个项目就是属于此类，这类项目，其实坑更大。原因是服务的用户不属于自己产品范围，对产品的目标、产品范围边界、产品方案、推广上线等环节，都拿不准，因为服务的用户是财务人员，而我并没有专业的财务知识，则只能依赖财务系统人员。
相信很多业务型产品经理应该理解这种痛，自己产品作为上游业务系统，需要为下游财务做账系统提供业务数据，自己无法针对间接系统的财务用户做调研。如果遇到能力强、好沟通的外围系统对接人还好，自己还能趁此项目多学习多考虑，悲催的就是遇到不好沟通，但是喜欢甩锅的人，这个也在职场上很常见，毕竟每个人都没有帮助别人的义务。
对，我今年的两个项目，其中一个就遇到了类似情况。
外围系统找到我需要我做相应的功能改造，并按照他们要求出方案时，我还是比较懵的。因为我主业是负责好我的业务系统，服务好我的目标业务用户，而非外围的财务用户。所以我就不断问项目目标、项目具体背景、目前现状、需要解决哪些问题、用户需要什么时，这些基础调研的问题，我都没用从外围系统对接人找到答案，即使上线了，也没给我明确的回复。果不其然，上线后遭到财务用户的投诉，究其原因有两方面，一个是业务系统堆积几年的历史数据未处理，另一个是业务系统的细分场景并未被财务提出如何做账，导致方案不完善，数据错乱。
遇到这种问题，根本原因，还是人的原因。如果想不清楚就下手，肯定会有错误风险，开始上线没问题，只是说明业务量不大，后续业务量上来，就会报错。
今年经历了这次事故后，我反思职场中确实会有各种各样的磕磕绊绊，如果只抱怨别人没做好，就停滞不前，确实也对不起自己投入的时间。于是我化被动为主动，想办法绕过外围系统对接人，直接找到外围系统使用的用户、外围系统所在业务的专家、相类似岗位的其他人员、此对接人的领导等等，侧面或正面的反复了解业务背景、明确项目目标，主动和外围系统用户进行沟通确认方案范围、方案细节，涉及历史数据、主流程场景方案、逆向场景或小概率场景方案等，不断迭代优化，而不只是因为自己不熟悉外围系统业务就不再向前。
所以，即使被动配合其他部门的项目，内心也要化被动为主动，积极促进项目进展。
项目好不容易上线了，此时就皆大欢喜，不再盯着了吗？万万不可，殊不知，项目挺过从0到1，却因为1到N 时栽了大跟头。
就像笔者遇到了一个项目，开发上线推广迭代经历了一年，后面需求逐渐变少，开发维护投入逐渐减少，就不太在意此项目。谁知道，日常运维类项目突然出现了大批量数据问题，究其原因，此类合作方项目，因为上游变动，未衡量变动点对下游的影响，就自行变动，导致下游出错。所以无论是合作方项目对接外围系统，还是自有项目，都需以不变的运维机制对应变化的部分。
那么运维机制是什么呢？如何管理运维人员识别风险呢？
首先，需统一一个官方的项目群，尤其是合作方项目，会拉入上下游系统人员、对应业务人员入群，一有问题就拉小群，导致信息分散，运维人员也抱怨问题太多不集中，无法快速处理。还有的用户除了拉群，还有邮件、报障系统等，问题分散多方，无法集中处理和分析。建立一个唯一的官方项目群，就是目的大家信息拉通，不在鸡同鸭讲。
其次，共享文档非常重要，翻群消息大家都比较头疼，尤其是多业务系统人员和不同公司的不同业务人员的大群，大家只关心自己的那一部分，如果看群消息很难找。所以统一官方群里的官方共享文档就非常重要，统一的问题内容、登记时间、方案回复、截图格式等，都让人快速找到问题和解决方案，也有利于后续产品和运维进行问题分析，有助于产品优化。
然后，定期的培训也非常有必要，如有业务系统变更，运维人员需警惕，快速识别对上下游系统的影响，评估是否需要优化各自系统等等，如优化后，要及时培训用户，提升用户使用系统的效率。
以上就是自己产品对接外围系统的经验，供大家参考。
本文由@元方 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。