在现代企业中，跨部门协作是项目成功的关键因素之一。产品经理在这一过程中扮演着至关重要的角色，需要具备出色的项目管理能力，以确保项目顺利推进并达成预期目标。
产品经理在项目管理中扮演着至关重要的角色，尤其是在跨部门协作中。
如何更顺畅地开展项目工作？确保项目顺利地推进，拿到预期结果。
或许你正面临着相同的问题，一起前往寻找答案吧～
案例中有三个关键角色，他们分别来自不同的部门，各自负责不同业务板块的产品负责人，但需要紧密合作来确保整个订单模块流程的顺畅。
在这个案例中，我们将探讨他们如何在跨部门项目中协作，以及在协作过程中遇到的问题和挑战，以及如何通过改善策略来提高工作效率和项目成功率。
1）客户视角：客户自己公司的财务对成本管控严格，公司的付款账单都需要管理层审批通过，才能付款。但实际上，在业务运作中，系统层面没有做到严格的管控，导致部分运单在未审批同意的情况，订单已扣款。引起客户的不满。
2）产品经理视角：小张在未经小蓝同意的情况下扣款。
产品解决方案：小张付款需小蓝审批同意。
1）小张需调用小蓝的接口查询订单审批状态。
2）小蓝不仅需开发新接口；
另外，因订单数据量大，小张在首次查询结果是未审批同意的订单，如后续审批同意，小张需要同步处理扣款。
因此，小蓝还需开发新的消息，在订单审批同意后推送消息给小张监听。
1、第一次会议：需求内容及排期对齐，小蓝开始研发。
第一次会议参会人：小张、小蓝。
小张在接收到需求后，识别到的相关方是小蓝。
小张给小蓝提需求：需要小蓝提供一个查询订单审批状态的接口。
会议已对齐整体上线排期时间，小蓝按既定排期完成需求评审并投入研发中。
2、第二次会议：小张提出技术方案变更，影响上线排期。
第二次会议参会人：小蓝+开发，小张+开发。
小蓝已进入开发阶段，将开发好的接口提供给小张后，小张在2天后提出技术方案变更，需要小蓝提供一个消息给他监听后续订单的审批状态。
因技术方案变更，增加了小蓝的开发工作量，小蓝担心整体上线时间受到影响，询问小张原定的整体上线排期时间是否需变更。
小张在会议现场询问架构师，架构师答复：“按这个排期时间怎么行？还排不上。要在原定的排期上线时间往后延2周才可以。”
3、第三次会议：识别到新的相关方，技术方案探讨。
第三次会议参会人：小蓝+开发，小张，小明。
小蓝识别出涉及2部分数据的处理，有2个解决方案，其中1个方案涉及新增相关方，需要和小张、新的相关方小明一起沟通对齐技术方案。
a.客户手动审批：审批结果以小蓝的为准。
b.系统自动审批：审批结果以小明的为准，即小明需要返回审批结果给小蓝。
技术方案1：小张直接查询小明的系统同意审批结果，以及小蓝的手动审批的结果；（小张不同意，相比查询2个不同协作方的接口，查询1个协作方的接口，当然更省事啦）
技术方案2：由小蓝将客户手动审批和系统自动审批的结果，整合为同一个接口，返回最终的审批状态给小张；那么，这里就可能需要小明新开发接口；（达成一致这么处理更合理，因为小蓝负责审批，最终的结果是以小蓝的为准）
第三次会议，新增相关方小明，小明的排期暂时排不上，需要主导方小蓝会后协调整体上线排期时间，如按原计划需上升到领导层协调跨部门排期。
4、第四次会议：最终确定技术方案，无需小明改动。
第四次会议参会人：小张+上级，小明+上级，小蓝+开发+技术经理。
小明在会上指出“小蓝需要的数据，都有提供给到”，并表示不需要再开发新接口。
小蓝意识到和开发同学反馈的信息有出入，现场电话联系技术经理，技术经理和开发同学一起来到会议现场沟通技术方案。
最终结论：
首先，关于“系统自动同意的审批结果的处理，是以小明的为准”，这段代码有问题，正确的应该是以小蓝的为准，小蓝无需再次请求小明的审批结果。需修复错误代码。
其次，在修复好的代码上开发新的接口和消息，就可以满足小张的诉求了。
注：不涉及小明的改动，最终的上线排期也不需要再次延期了。
皆大欢喜，很愉快地结束了第四次会议。
在项目管理中，沟通是确保项目顺利进行的关键因素。然而，当一个项目需要多次沟通时，这并不一定意味着是坏事。
频繁的进度对齐有助于及时发现问题并进行调整，这对于项目的健康发展至关重要。但是，如果沟通变得过于频繁而效率低下，这通常是跨部门协作中存在的问题所致。
这些问题可能包括沟通不畅、信息不对称、职责不清晰、目标不一致以及文化差异等。这些因素共同作用，导致需要多次沟通来解决理解和协调上的问题。这就需要特别重视，做好风险管控。
进一步分析，我们可以从各个角色进行问题定位。
1）内部排期不明确，缺乏项目管理意识。
在第二次会议，技术方案变更时，小张才和架构师确认整体上线时间。此时协作方小蓝已经进入开发阶段。
2）需求识别缺漏，技术方案设计不完整。
在小蓝提供接口的后2天，小张才反馈接口不完全满足需求场景，需要变更技术方案。
3）项目里程碑节点不明确，导致协作不顺畅。
因未提前对齐多方协作的项目里程碑节点（开发联调时间、集成测试时间，等关键节点），导致小蓝提供接口给小张后，迟迟没有进行开发联调，信息不对称。
1）内部技术方案把控不到位，缺乏灵活变通。
在第四次会议，最终对齐不需要小明改动，其实只需要修复历史代码逻辑问题，在修复好的代码基础上再开发接口及消息即可。
ps：小蓝和开发同学意识到历史代码逻辑有问题，但没意识到可以修改历史逻辑后再开发的解决方案。而仅仅局限于在历史逻辑基础上怎么新增开发逻辑，属于技术方案设计问题。（算是在填坑了）
这些问题的根源在于跨部门协作中缺乏有效的沟通和协调机制。每个角色都应该对自己的工作负责，同时也需要对整个项目的进展有所了解和掌控。
1、 明确内部排期
1）提升项目管理意识，确保项目按预期上线。
2）学习PMP等项目管理知识，并应用到实际工作中。
3）从过往项目中总结经验，向优秀同事学习。
2、完善需求识别
1）与协作方对齐需求，确保各方改动点明确。
2）技术方案需覆盖需求全流程场景，必要时请技术专家评估。
3、 明确里程碑节点
1）确定并沟通关键节点（如接口定义、开发联调、测试时间等）。
2）协作方应提前规划，主动提供里程碑节点给主导方，确保信息透明。
1、加强技术方案把控
1）开发同学需灵活应对问题，必要时找技术专家评估。
2）产品同学需有刨根问底的精神，了解技术内容，避免盲目信任技术方案。
3）遇到疑问时，多问几个为什么，确保技术方案合理。
通过这些改善策略，可以为小张和小蓝提供更好的工作环境和支持，帮助他们更有效地完成项目任务，同时也提升整个组织的协作效率和项目成功率。
1、项目管理重要性：产品经理需具备项目管理能力，确保项目按预期推进。
2、跨部门协作：明确角色责任，保持沟通透明，及时更新项目进展。
3、技术方案全面性：技术方案需覆盖所有业务场景，避免后期变更。
4、项目管理意识：主导方需有强烈的项目管理意识，协调各方进度。
5、主动性：协作方也应有主导意识，主动推进项目进展。
6、持续学习与复盘：通过学习和复盘，提升个人能力，享受工作带来的成就感。
在每次的工作实践经历中复盘，发现自己的不足，学习他人长处，让自己的短处可以不那么短，甚至可以变成自己的长处。
当长处足够长的时候，去主动帮助他人，通过言传身教，能帮到他人得到成长，这也是一种成就感。
人生是一场体验，工作也是一种体验，在体验中发现乐趣。生活中，感受生活的美好。工作中，不断提升自己的能力。不断探索新的自己，对不同阶段的自己有不同的理解。
本文由人人都是产品经理作者【Nana】，微信公众号：【娜是产品经理】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。