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