在互联网企业中，常常需要对接各个部门的人，这时候产品很容易犯“我是产品 owner，就什么都要亲力亲为”。本文结合跨部门业务需求的技术方案对接的实际案例，展开分析，一起来看看吧。

互联网企业是为客户提供整体的解决方案，多个部门的产品业务是相互关联影响的，需要大家一起发力，跑通业务全流程，形成闭环。那么，作为产品人，在项目工作开展中，跨小组/部门对接就是家常便饭了。

在跨小组/部门对接时，稍不注意，就容易犯“我是产品 owner，就什么都要亲力亲为”的错。

本文将针对跨部门业务需求的技术方案对接的实际案例，展开讲解。

大家有则改之，无则共勉～（欢迎一起探讨不同的观点）

一、实际案例

需求主导方产品经理带着开发仔，拉通跨部门产品和开发开会，会议议题是对齐需求涉及到双方整体的技术方案。

会议全程是主导方产品经理在讲技术方案要如何做，涉及接口要如何改，ta的开发仔坐在一旁看着手机。四个人的会议，变成三个人的会议。

二、案例中存在的问题

1. 缺少专业技术保障

主导方开发人员没有进入深度思考和探讨的状态，只能凭产品经理一个人有限的判断去传递信息给协作方。

2. 无法确保技术方案已覆盖需求场景

尽管产品经理已经提前和ta的开发仔沟通过技术方案要如何实现，但没有关联方的技术方案整合，需求整体技术方案是有缺漏的，都不算是完整的技术方案，无法保障需求场景已被覆盖。

3. 分工不明确

定义技术方案是开发人员的工作和专业，产品经理无法替代开发人员。

一旦你做好了，以后都是你来做，你就成了保姆式产品人，你的时间精力被分散了，没有更多的时间去思考产品人本身应该做的事情。如果你没做好，可能是你来背这个锅。

所以，你可以有相应的能力，但不应该是你来做！

工作中，我们应该做好分工，各司其职，专人做专事。产品经理每天要和多个工种的不同角色协作沟通，更重要的是做好资源整合，利用好资源帮你做好事情，拿到结果！

三、为什么说产品经理不适合主导技术方案对接？

不专业的人去做专业的事情，很容易出错，从而引发一连串问题。

因为前期技术方案未全面覆盖业务需求场景，无法提前规避问题，可能要在开发过程，或者测试环节才发现问题。为了解决问题，在临近上线时间，主导方临时拉通关联方再次对齐技术方案。

如果临时补救成功，可以拿到结果。但过程中状况百出，协作关联方会因此对与你对接产生不靠谱的印象，产生后怕的心理。（内心OS：每次对接都状况百出，沟通费劲）

如果临时补救不成功，项目将存在风险，可能会延期，影响业务结果交付。一旦出错，业务辐射面广，引发生产问题，影响客户正常使用，将演变成严重问题。如果是涉及到钱相关的业务，很可能造成企业/客户的经济损失。

四、从项目管理角度分析问题

从项目管理角度看，临时补救，需要变更技术方案，其中存在变更成本。发现缺陷的时间越晚，纠正缺陷的成本就越高。

这是因为设计和开发工作通常已经基于缺陷的组件而进行。此外随着软件开发生命周期的进展，活动的调整成本有所增加，因为更多的干系人会受到影响。变更成本曲线可以描述这种现象。

五、产品经理应如何开展跨部门业务需求的技术方案对接？

当你接到涉及跨部门协作的需求，作为主导方，要做技术方案对接时，你一定要相信你的开发仔的专业，相信 ta能胜任这个工作，能把事情做好，放心交给他负责，专业的事情要交给专业的人去做。

具体可以按以下5个步骤开展：

step1：明确需求后，提前和你的开发仔沟通，将需求传达到位，让ta全面了解需求场景。

step2：在需求层，与你的开发仔达成一致后，让开发仔想想在技术层面可以如何实现，明确你方的技术方案。

比如涉及你的产品模块哪些地方的改动，是否涉及到其他关联方（比如：跨小组、跨部门）的改动，需要关联方如何配合处理。

技术方案的评定，交给你的开发仔去找研发小组长或技术架构师评定吧。

step3：明确你方技术方案后，和关联方约定会议时间，参会人员是所有关联方的产品和开发人员。

step4：会议对齐技术方案，由你的开发仔主导讲解，你旁听就好，在与关联方讨论过程中，涉及技术方案未覆盖或不符合业务场景的地方，你可以提出问题或补充说明，帮助完善技术方案，确保技术方案覆盖需求场景。

step5：与跨部门对齐整体技术方案后，这时才算技术方案敲定了。接下来按照项目排期时间正常研发上线。

总结

1）产品经理要专注本职工作，将更多的时间花在梳理用户故事、需求场景、业务流程、产品方案、用户使用数据反馈等重要工作上。

2）秉承专人做专事的原则，明确分工。做正确的事，且正确地做事！

3）如果你的本职工作都没做到位，就去做你不专业领域的事情，往往会让事情往不正确的方向发展。

4）技术方案需在启动开发前评估好。随着软件开发生命周期的进展，发现缺陷的时间越晚，纠正缺陷的成本就越高。

5）做好资源整合，利用好资源帮你做好事情，拿到结果！