编辑导语：产品经理经常会经历一些跨部门协同的项目，在这个过程中，如何协调好双方或者多方的工作，准确理解对方需求，合理的拆分任务并且进行分工，妥善的解决项目推进过程中存在的问题是很重要的一件事，它关系着项目是否能够顺利的推进。本篇文章中，作者总结了高阶产品经理应该如何做好跨部门协同项目。

最近有其它部门的小兄弟拉我做一个的项目，要把公司所有的产品整合到一个会员体系下，进行打包售卖。

笔者对他进行了一些支持，给了相应的产品方案，后续工作由他自己去弄了。

结果等他拉齐各部门的进行需求评审的时候，才发现几乎只跟笔者一个部门沟通过，其它的部门当场表示一脸蒙B，项目中无法确认的过多，导致评审失败，具体的细节又得重新聊过。

想了想这种跨部门的项目推动其实跟一个团队做闭环的项目，从流程上来说虽然大体一样，但落到细节，还是有很多门道。而且这种跨部门协作的经验也正是一些产品经理高级岗位的必备技能。

相信大家在招聘网站上，经常能看到资深一些的产品经理岗位会有以下类似的要求；

这一点笔者回顾过去几年的工作经历里做过几个跨部门的项目，有经验，也有教训，还没有好好总结过，搜索了一下网上确实也很罕有这类的文章，所以笔者在此略献薄技。

一、预备动作1：确定需求

现在的2C产品很少有被做出来后，由产品经理自己负责去做推广。毕竟你有渠道嘛？有推广资金嘛？你能服务用户嘛？你能自己举办活动嘛？

小的项目自己团队闭环，在给定的用户范围内试试水，大的项目一般需要面对更多的用户，以及更大的影响面，就需要由外部力量一起来推动。你的想法最好有实际应用的业务方来支持。

2B业务的产品经理自主性会更强一些，可能会发起比如平台升级，架构优化的项目。

但依旧牵一发而动全身，这种项目的难点就在于如何说服高层，为什么要在这个时间点做这样一件事情，如果高层认可，下面支持，需求自然就确认了。

在有明确的业务方后，一定要深刻的理解业务方的需求，主要从以下几个方面入手：

1. 需求来源的依据是什么，是否已经有历史数据、测试案例；
2. 确认需求是短期（临时）的还是长期的，紧急的还是可规划的，这将直接影响大家做出来的方案是临时的还是持久的；
3. 如果有多个业务方，可以要求业务方按部门需求进行合并，比如市场、运营、客服等部门同时希望在双十一有一个联合售卖项目，如果能够有时间逐个沟通最好，但之后是需要选择出一个业务代表，减小沟通量；
4. 其次需要对其中的重复需求进行整合，进行抓大放小，排好优先级，小需求根据实际情况进行降级处理；如果业务方不同意，则需要给出相应的理由；
5. 最后一定要让业务方给出预期收益，同时也要配合业务方保证收益的合理性。

作为产品经理的专业性需要体现在尽最大程度的满足业务方的需求，同时又花相对较小的代价，以及能够兼顾未来的拓展和可复用性，最后是预估的收益是可计算可预期的，而不是拍脑袋。

否则在之后的环节，将极易受到挑战，举俩个例子：

1. 你这个需求有没有先验证过？能不能做个简单的页面看看有没有用户点击？如果没有，请先做个MVP，否则后续的环节就无法推进展开；
2. 这个项目的收益是否够大，足以说服其它的团队一起参与。或者有高层领导的明示，有很多项目是高层领导出于实验性质的，希望能完成一个从0到1的流程，那么收益就不可能太高，甚至本身是公司的未知领域，收益都无从估计，这种情况是一定要狐假虎威的来拿到高层授权的。

之前说的那个小兄弟，既没有验证会员在当前公司用户的意向，自然也无法给出一个令人满意的项目收益，即使高层觉得项目有价值，但还是无法评审，导致项目延期。所以这个环节请大家先跟业务方一起，细致讨论。

如果以上动作都做完了，就可以进入到下一个环节，组建核心团队。

二、预备动作2：成立核心团队

漫威电影中的超级英雄即使拥有有宛如神明的力量，在面对更强大的敌人时也会组成《复仇者联盟》，组成一个团队，做各自擅长的事情。

同样的，产品经理在面对这种跨端项目时也需要一个核心团队来支持自己，一般会有以下几个主要角色：

其中主产品经理是整个项目能够顺利完成的关键。在跟各产研团队沟通需求的时候，能够代替业务表达需求的必要性；跟业务沟通产品方案的时候，能够代表各部门的产品研发提出可行性。

否则每次开会都得叫上十几个人，低效的开会，频繁的讨论将是项目推进的巨大阻力（当然这不代表不能拉这么多人一起开会，防杠所以请读者自行领悟），这就要求主产品经理对整个项目有深刻的理解和把控能力。

前面的业务需求聊完了，自然就要开始跟具体的产研团队的小伙伴们干活啦。

三、开始推进项目

1. 拆解需求，沟通需求

除非公司很小，现在的大公司各个部门都有自己专注的领域和负责的业务，甚至比较过分的则是有些基础部门在公司的内部形成了一定的壁垒，他人与之合作时，更像是调取了一个第三方公司的服务。

如果这种服务真的足够完善还是挺方便的，但因为这些部门一般只服务公司内部，其完善性、与项目的匹配度、稳定性都有一定的折扣。所以我们需要将需求进行仔细的拆解，与各部门耐心的沟通，沟通的主要目标：

• 核心团队，熟悉整个业务流程的实现；
• 与实现各业务环节的团队进行沟通，补充和完善业务流程；
• 了解各团队近期的工作重点，确认各端关键负责人；
• 核心团队讨论从各团队收集来的方案，根据实现成本和可持续性等维度，讨论最终的产品方案；
• 确认业务数据在各端是否可以准确拿到。

外加笔者之前的一些讨论技巧：

1. 从业务方的需求出发，和各部门一起绘制业务流程图，画到他们的边界；
2. 根据业务流上的关键节点进行展开到各部门、组织；
3. 在与各部门的沟通中，了解各环节中的上下游，判断这种依赖是否会影响到本项目，如果影响则添加到项目中，不影响，则由各环节各自去闭环；
4. 在与各团队讨论需求时，多讨论几种方便、简单的、复杂的、临时的、长期的、低成本的、高成本的等；
5. 初次与不熟悉的部门讨论需求时，需要与该部门较资深的同学一起讨论，避免因为双方不了解造成的沟通歧义，之后可以选出该部门的关键对接人，来承接己方需求即可（可能是产品经理，也可能直接的研发负责人，根据团队特性来定）减少之后的沟通成本；
6. 以上的讨论至少需要带主研发一起，根据情况带上主测试和PMO，需要他们一起理解整体项目的架构，便于之后评估整个项目的实现成本；
7. 不要跟各团队在此阶段过多的讨论收益，只讨论实现成本和可行性方案，否则最终项目的实现方案难度超过了项目需求，讨论将变得没有意义。

举个例子：

这一块的需求沟通环节是整个项目的重中之重，所以笔者这里需要拿一个简单的案例来说明一下，以上线一门课程进行售卖的需求为例：

1）第一步，根据当前的认知绘制业务流程，依次有：

• 课程配置，做一门新课，需要在平台里配置一些课程信息，以及必要的学习环节等；
• 前端课程展示，用户可以看见，有入口等；
• 商品展示，需要创建SKU，让新用户可以购买。

如下图所示：

但以上这些认知一般是不完整的，即使做过的项目，各部门也可能有迭代更新，所以需要进行下一步。

2）第二步，与已知部门沟通，完善业务实现流程：

• 与课程配置部门进行沟通后，发现还有老师的匹配工作；
• 同样，课程不仅是用户需求可见，还有中台上需要可见，否则工作人员没有办法进行监督；
• 跟电商平台的同学了解后，还需要做法务沟通、商品包装等事宜；
• 最后，电商同学还告诉我们，售后服务需要处理。

如下图所示：

3）第三步，与核心团队确认最终方案

如此第二步的多次够沟通，你将会初步得到项目实现的全部流程，以及有关部门。这时需要跟自己的核心团队一起商量和讨论，是否每个环节都必要，如何在各团队给出的多个方案中进行选择。

下图中，主要是为了保证项目进度，团队舍弃了多端上线和客服需求，由班主任来代替客服的工作等选择。

2. 正式立项，明确分工

之前都是各团队的零散的沟通，是时候把大家拉到一起做一个正式的立项大会了。有些读者可能会问，不会吧，现在才立项嘛？

因为根据之前的拆解需求，和各团队的反复沟通，才能确认各端是否需要参与、以及最终的方案是什么，甚至因为实现成本等问题，最初的需求都会发生一些变化。

否则在不了解各端的情况下，先拉上20个团队一起立项要做A需求，最后聊完发现只需要4个团队的参与做B需求，会极大的降低团队可靠程度。

那么，立项大会需要跟大家聊啥呢？

• 正式的介绍项目背景，项目目标，以及项目的最终收益，如果是多期项目，可以回顾之前的成果，用于保证各团队的投入和参与动力；
• 明确最终的业务方案，这是跟各团队一起妥协出来的最大公约数，确定各业务团队所需要配合实现的需求，以及项目中要使用的方案，划分各端的任务职责；
• 确定沟通机制，确认核心团队的联系人，有研发问题找主RD，有产品问题找主PM，人力排期问题找PMO；
• 重要的里程碑节点，如果项目周期较长，可以分阶段实现，拆分好各阶段需要参与的团队。

理论上，会议上不应该有特别复杂的讨论，只是公布方案，拉齐认知，更不要临时发现缺少某个关键部门的参与，这些都应该是上一环节没有讨论清楚，请反思总结。

当会上大家都默认没有意见后，此时项目就已经成了60%以上。那我们就接着推进吧！

3. 需求评审，研发推进

有立项大会还是否需要进行项目整体的需求评审呢？根据笔者的个人经验是需要的。立项大会后，给各团队一些思考的时间，消化需求，确认风险，人力安排，项目优先级调整等。

一般就安排在立项大会的第二天或者第三天，拉齐之前各部门的对接人进行需求评审。

评审主要是快速把整体产品方案再过一次，作为主产品，要给最终解释；以及各端遇到的新问题，比如测试数据，配置规则等，收集好后，再单独跟各端进行反馈。

项目需求评审后，各端就要正式进入到各自的研发阶段。此阶段如果有PMO参与，则需要由他们来保证项目的推进，如果没有则主产品也可以来做以下事项：

1. 督促各自部门进行需求评审，给出各部门大致的时间安排，研发时间，测试时间，与其它部门的联调时间；
2. 确认各端的人力投入成本，有问题需要立即向上反馈，确认与其它项目的协调；
3. 与主测试准备联合测试方案及测试数据；
4. 积极的与各端进行沟通，周期性的关键负责人站会、电话会议，确认项目进度，及时发现问题，解决问题。

由主研发和主测试同学去确认之后的项目联调方案：

• 要求各端在联调前，保证作为一个独立模块的正常使用；
• 有条件有需要的情况下，进行封闭式联调，以保证项目进度；
• 主产品需要跟进保证整体的产品功能与业务需求的一致性。

最后需要和主研发一起，制定多端上线顺序。这是跨端项目与独立项目最大的不同，独立项目所有上线流程都是部闭环，上线依赖发生在项目内部。跨端项目则需要核心团队根据团队之间的依赖关系，设计好上线顺序。

举个简单的例子：商品的付费购买功能与商品的使用功能，谁先上线？如果付费功能上线的一瞬间，有用户下单，但功能还无法使用就可能造成重大的线上事故。

当这个顺序拓展到十几个部门的上线后，将会产生更多的连锁反应。

4. 上线总结，复盘优化

到此，项目90%的工作基本完成。只是项目上线交付给业务去使用，真正给到更广大的用户使用时，会有更多的问题暴露出来。作为项目的主产品经理，以及最了解项目的人，遇到问题可以最高效的分发到对应团队，避免问题扩大化。

笔者之前遇到过主产品离职的大型项目，一个工单扭转十几个部门不知道谁来承接的情况，错失了解决问题了良机。

其次主产品需要对各团队项目数据的进行验收，这是量化各团队和最终项目收益的主要指标，要保证大家的劳动成果。如果有问题，找到相应的团队及时修正。

及时复盘项目，梳理各部门的职能，并对项目中的方案进行评估，提出改进方案。比如临时方案迭代成持久化的方案，手工方案改自动化方案，写表方案改管理后台方案等。

最终，需要确认收益，和大家共享成果。

5. 常见问题

1）问题一：因为边界的模糊，同样一个功能，A和B都可以做，那么谁来做？

笔者这里给出一个参考答案：

首先，需要跟主研发进行讨论这个项目未来可能的项目架构，即此功能谁最适合长期维护；其次，谁能够不耽误项目进度，在当前的情况下，选择效率更高，成本更低的方案；最后，通过此功能，未来谁的收益更大。如果依旧不服，向上反馈。

2）问题二：很多业务需求未必与需要配合团队的业绩产出所匹配，如何给大家一个信服的收益？

首先确认需求拆分到的团队是否匹配，是否有分配错误的情况，这一点在沟通需求的环节就要消除；其次，拿项目的测试数据说话，拿之前的历史数据说话，保证项目收益，以提高优先级；最后，如果对方还不满意，找到对方的领导进行沟通，将项目上线写入相应同学的业绩考核指标中。

3）问题三：如果项目反复进行，还是否需要如此繁琐的沟通？

同样的项目如果做第二次和第三次时，部分稳定环节可以进行省略，但基本的通知一定要到位，有些部门经常会有各种迭代升级，之前的老方案有变更时，不一定通知到位。甚至可能已经有了更简便的方案，可以加入到项目的考虑中来。

四、总结

跨部门项目的核心点，还是在于分解、合并与沟通，主产品经理的沟通占据项目中50%的工作，剩下的则推进团队以及坚决的执行、推进。项目稳定后，将流程规范化，自动化，程序化，以减少重复的人力投入。

最后，祝大家好运，实践出真知。

作者：核桃壳，微信：walnutshell911

本文由 @ 核桃壳 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议