跨部门协作，怎么做才能不心累？
极客时间编辑部
讲述：丁婵大小：7.28M时长：05:18
你好，欢迎收听极客视点。
跨部门推动项目，最常听到的抱怨就是“别人不配合，我也没办法啊”。
的确，跨部门协作是一个让很多职场人头痛的问题。而如果我们能够在项目开始之前，问自己一句话：别人凭什么要配合我？可能我们的心态、手段、结果都会不一样。
一、心态
如果一个项目涉及多部门协作，说明这不是一件简单的工作。当事人要做好相当的心理准备。跨部门推动项目，不但考验你的影响力，还考验你的耐心。
二、该不该我负责
跨部门推动工作遇到阻力，可能的原因之一是：你不是负责这件事的最佳方。
UC 关于跨团队、跨部门合作，有一项基本原则：谁是最大受益者，谁推动。
简单说就是，这件事情做成了，最大的受益者是谁？最大的受益者应作为主导方来推动项目，并承担相应的主要考核指标。
三、利益相关方有哪些
做过 To B 或政府项目的人，应该都遇到过：本来评审会上说得好好的，真正在项目执行过程中，冷不丁就跳出来这个部门、那个负责人，说“你的工作不符合要求”，或者说“这个需求还需要经过我们领导的审批才行”。
跨部门项目也是如此。比如涉及到钱的项目，财务 / 风控合规部门就经常是被忽略的一方，到头来不符合规范的地方都要打回，也需要接受其相应领导的审批。
所以，利益相关方没有分析到位，执行的时候一定会受到阻力。
四、背景 / 收益 / 目标
一个真实的案例是，在项目中，完成业务迁移项目需要产品、运营、销售、实施、测试、技术等多个团队配合。而迁移的商家数是衡量技术团队的重要指标，所以技术团队拼命推动这件事，但这并不是其他团队的核心业务指标，所以整个迁移过程比较费劲。
从这个案例中可以了解到，其业务系统应该是属于电商类的。那么商家数据就是核心数据之一。
针对这个案例，可以有两种做法，第一种做法是在开始这个迁移之前，和各方讲清楚：
为什么要做这个迁移：是业务发展的需要，还是当初技术架构设计不合理，无法支撑接下来的业务产品扩展？
迁移完成之后收益是什么：是商家数更多了，还是商家在平台上面卖货的体验更好了？
如何评价这次迁移的价值：迁移只是一个动作，迁移完成只是一个结果，迁移完成之后的收益，要有一个客观的衡量标准。
另一种做法是：要求别的部门配合自己，来完成自己的业务指标。
两种做法，哪种效果更好呢？显然是第一种。
五、方案和风险评估
迁移类的项目，确实有许多“坑”。简单来说，就是你把一堆“东西”从一个仓库搬到另外一个仓库。
看起来没有什么技术含量啊，但请试想一下：
如何确保两个仓库的物品编号是一致的？
新仓库的物品摆放是否方便随时存取？
搬运东西的过程中，有遗失损毁怎么办？
搬运东西的过程中，有人要存取怎么办？
新仓库的大门钥匙是否要集体重新更换？
你看，问题并不是“搬运”这么简单，还涉及到保全、效率和业务运作的问题。
同样的道理，大家并不是对迁移有抗拒，而是对迁移的成本和迁移的风险有顾虑，加上对迁移的收益不明确，所以遭到其他部门的冷落和阻力也就不足为奇了。
作为跨部门项目的主导方，你是否有一个清晰的可执行方案，同时考虑到各方的关切和顾虑，并且在方案中有对应的应急措施，是打消各方顾虑阻力的重要因素。
除了上述 5 个角度外，跨部门合作的项目，在启动会、里程碑总结会议上，各部门能够拍板的人一定要在场，确保会议的产出是有效的，也避免后续发生变故，白费功夫。
最后，在跨部门协作中，建议：
找出谁是项目最终的受益方，由最大的受益方配合推动。如果是研发部门，那么你的上级就是这个事情的最大受益方。
找出正向及负面利益相关者，倾听他的诉求。
评估自己的方案能否 cover 来自各方的顾虑。一旦出现风险，你要怎么应对，主要风险都要在方案中体现出来。
能否分阶段执行，有没有明确的截止时间可供各兄弟部门评估投入。
是否找对了兄弟部门正确的接口人。
以上就是今天的内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(2)
- 最新
- 精选
啊忠想把事情推动下去，三板斧缺一不可。
鲍勃不错不错，尤其是第一条谁受益谁推动
收起评论