在互联网企业中，常常需要对接各个部门的人，这时候产品很容易犯“我是产品 owner，就什么都要亲力亲为”。本文结合跨部门业务需求的技术方案对接的实际案例，展开分析，一起来看看吧。
互联网企业是为客户提供整体的解决方案，多个部门的产品业务是相互关联影响的，需要大家一起发力，跑通业务全流程，形成闭环。那么，作为产品人，在项目工作开展中，跨小组/部门对接就是家常便饭了。
在跨小组/部门对接时，稍不注意，就容易犯“我是产品 owner，就什么都要亲力亲为”的错。
本文将针对跨部门业务需求的技术方案对接的实际案例，展开讲解。
大家有则改之，无则共勉～（欢迎一起探讨不同的观点）
需求主导方产品经理带着开发仔，拉通跨部门产品和开发开会，会议议题是对齐需求涉及到双方整体的技术方案。
会议全程是主导方产品经理在讲技术方案要如何做，涉及接口要如何改，ta的开发仔坐在一旁看着手机。四个人的会议，变成三个人的会议。
主导方开发人员没有进入深度思考和探讨的状态，只能凭产品经理一个人有限的判断去传递信息给协作方。
尽管产品经理已经提前和ta的开发仔沟通过技术方案要如何实现，但没有关联方的技术方案整合，需求整体技术方案是有缺漏的，都不算是完整的技术方案，无法保障需求场景已被覆盖。
定义技术方案是开发人员的工作和专业，产品经理无法替代开发人员。
一旦你做好了，以后都是你来做，你就成了保姆式产品人，你的时间精力被分散了，没有更多的时间去思考产品人本身应该做的事情。如果你没做好，可能是你来背这个锅。
所以，你可以有相应的能力，但不应该是你来做！
工作中，我们应该做好分工，各司其职，专人做专事。产品经理每天要和多个工种的不同角色协作沟通，更重要的是做好资源整合，利用好资源帮你做好事情，拿到结果！
不专业的人去做专业的事情，很容易出错，从而引发一连串问题。
因为前期技术方案未全面覆盖业务需求场景，无法提前规避问题，可能要在开发过程，或者测试环节才发现问题。为了解决问题，在临近上线时间，主导方临时拉通关联方再次对齐技术方案。
如果临时补救成功，可以拿到结果。但过程中状况百出，协作关联方会因此对与你对接产生不靠谱的印象，产生后怕的心理。（内心OS：每次对接都状况百出，沟通费劲）
如果临时补救不成功，项目将存在风险，可能会延期，影响业务结果交付。一旦出错，业务辐射面广，引发生产问题，影响客户正常使用，将演变成严重问题。如果是涉及到钱相关的业务，很可能造成企业/客户的经济损失。
从项目管理角度看，临时补救，需要变更技术方案，其中存在变更成本。发现缺陷的时间越晚，纠正缺陷的成本就越高。
这是因为设计和开发工作通常已经基于缺陷的组件而进行。此外随着软件开发生命周期的进展，活动的调整成本有所增加，因为更多的干系人会受到影响。变更成本曲线可以描述这种现象。
当你接到涉及跨部门协作的需求，作为主导方，要做技术方案对接时，你一定要相信你的开发仔的专业，相信 ta能胜任这个工作，能把事情做好，放心交给他负责，专业的事情要交给专业的人去做。
具体可以按以下5个步骤开展：
step1：明确需求后，提前和你的开发仔沟通，将需求传达到位，让ta全面了解需求场景。
step2：在需求层，与你的开发仔达成一致后，让开发仔想想在技术层面可以如何实现，明确你方的技术方案。
比如涉及你的产品模块哪些地方的改动，是否涉及到其他关联方（比如：跨小组、跨部门）的改动，需要关联方如何配合处理。
技术方案的评定，交给你的开发仔去找研发小组长或技术架构师评定吧。
step3：明确你方技术方案后，和关联方约定会议时间，参会人员是所有关联方的产品和开发人员。
step4：会议对齐技术方案，由你的开发仔主导讲解，你旁听就好，在与关联方讨论过程中，涉及技术方案未覆盖或不符合业务场景的地方，你可以提出问题或补充说明，帮助完善技术方案，确保技术方案覆盖需求场景。
step5：与跨部门对齐整体技术方案后，这时才算技术方案敲定了。接下来按照项目排期时间正常研发上线。
1）产品经理要专注本职工作，将更多的时间花在梳理用户故事、需求场景、业务流程、产品方案、用户使用数据反馈等重要工作上。
2）秉承专人做专事的原则，明确分工。做正确的事，且正确地做事！
3）如果你的本职工作都没做到位，就去做你不专业领域的事情，往往会让事情往不正确的方向发展。
4）技术方案需在启动开发前评估好。随着软件开发生命周期的进展，发现缺陷的时间越晚，纠正缺陷的成本就越高。
5）做好资源整合，利用好资源帮你做好事情，拿到结果！
本文由 @Lena 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。