在产品工作中，经常需要与业务部门打交道。但有时候会因为对业务不熟悉，从而被业务人员欺瞒，这种时候，如何防止被业务人员欺骗，给自己挖坑呢？

面对业务时，你是否也经历过以下令人崩溃的事情？

1. 需求要的急，做出来又说不需要了
2. 业务的需求总是变了又变
3. 投入资源推动上线的新功能，才用了两周，又改回线下作业

以上种种，可能不是因为你的方案设计出现问题，而是没有学会如何与业务打交道。那么应该如何避免陷入众多的业务需求泥潭中呢？接下来我们从以下几个方面去聊聊。

一、像管理供应商一样管理业务部门

作为it部门，我们通常会接受来自公司的多个业务部门的需求，这种一对多的业务模式，如果缺乏管理，势必会导致需求的收集和管理混乱。而同样是一对多的业务，供应商管理已经发展为非常成熟的一套管理方案，我们可以通过借鉴供应商管理相关的思路来管理我们的业务需求部门。

1. 建立需求的反馈机制

由于需要对接的业务部门和业务人员太多，试想一下，如果每个业务人员，都将需求点对点的反馈至数字化部门，那么势必会导致it部门需要投入大量的精力去处理这些杂乱的需求，而这其中很多都是业务部门内部可以合并或者直接解决的需求。如果我们制定了更高粒度的统一需求反馈机制，就有以下几个优点：

1. 业务需求统一提报，方便需求的对接
2. 业务需求经过汇总后，可以将重复或者可以直接解决的需求过滤掉，大大减少了无效需求
3. 业务部门内部可以将需求进行重要性评估，it部门可以以此进行优先级评判

通过改变与需求部门的合作方式，我们可以对各部门的需求，进行过滤和初步处理，从而减少无效的工作投入。

2. 建立一定的考核/评定方式

供应商有交期、质检的等考核指标，对于需求部门同样需要制定一定的考核评定机制，便于我们能够更好的平衡各部门之间的需求和资源投入。

以需求的上线成功率这一指标为例，A部门和B部门都提了10个需求，但是A部门的需求最终决定要做且成功上线的数量分别为7和6，那么其最终的需求达成率大概为85%，而B部门的需求最终决定要做和成功上线的数量分别为5和2，那么其最终的需求达成率为40%。鉴于此，it部门的开发资源，就可以适当的向A部门倾斜。

除了上线率这一类标准的指标，我们也可以参照各自公司的实际情况，制定一些个性化的指标，例如：是否上层领导重点关注的需求、是否是核心业务部门等等，用以协助我们对业务部门的需求进行更好的管理。

二、做好业务预期管理

业务对系统总是抱有一些不切实际的期待，他们幻想着上了系统可以提高他们的效率，减少工作量，如果我们无法对业务预期进行有效的管理，那么系统未达到业务的预期效果时，将会使得项目面临很大的上线阻力。

1. 识别业务预期

如何识别业务预期？在业务调研阶段，业务总是会表达自己希望把系统或者功能做成什么样，这就是业务最真实的业务预期。但是由于业务仅聚焦在自己工作的职责范围，导致其缺少对整体业务以及技术的认知，因此其业务预期存在很大的局限性。

这就需要产品人员在调研阶段，需要准确识别到业务预期是怎样的，从而能够引导业务又正确的预期。

2. 引导业务预期

由于业务产品人员设计的方案，是对业务流程、技术等方面平衡后的产物，在这种情况下，设计方案必定会与聚焦于某一块业务的业务预期有差异。我们可以通过业务方案评审、业务答疑等环节，引导业务，让其对需求有正确的业务预期，降低需求上线的阻力。

很多老鸟产品经理喜欢将调研和重点放在挖掘业务的真实诉求上，却忽略了对业务预期的管理，因此在推动上线的过程中，业务认为系统不好用，从而导致系统上线阻力很大。

三、学会借势

数字化部门，由于是成本部门，所以在绝大部分公司中，都处于弱势地位，如果想要在各部门的协作中处于主导地位，一定要学会借势。

1. 借助相关负责人的势

推动需求上线时，我们面临的很大一方阻力，就是一线操作员工，而他们给出的理由往往也很实在，影响了操作效率。

从线下转到线上，本身就是提高管理规范性的一种方式，这是领导层的管理诉求，而这种诉求，往往会打破原来的工作方式，本来通过微信可以进行便捷沟通的，现在只能将对应的信息录入到系统，增加了一部分工作量，由此也导致了效率降低。

针对这种情况，如果我们只是和操作员讨论如何提升操作便捷性和如何提高操作效率，一般是很难达成共识的，因为无论如何优化效率，仍然很难达到线下的操作效率。此时我们需要识别关键人，通过与管理层直接对话，将矛盾转移到业务部门内部上下级，这就是借助关键人的势来推动业务。

2. 借助业务部门的势

而在涉及到跨部门的需求时，由于各部门之间的相互协作，也会出现A部门优化了业务流程后，与其有工作交集的B部门的业务人员效率降低，此时B部门的业务人员会成为增加项目的上线阻力。

在这种情况下，我们同样可以通过识别项目的关键受益部门，借助关键部门的势，来平衡非关键部门的阻力，从而达成共识，推动项目上线。

3. 为自己存势

在实际工作中，情况往往要复杂很多，当碰到争议性比较大的功能需求双方又很难达成一致时，为了避免双方矛盾升级，我们可以适当的让步，但是需要与业务方明确表达自己对这个功能的看法，在上线后，对此功能进行跟踪，如果最终功能上线没有达到实际效果，就可以以此作为下一次争议性问题的案例。

以上是个人在需求从收集、调研/设计、推动上线这三个阶段的一些与业务打交道的方法和思路。对于企业内部的产品经理，与业务打交道甚至比方案设计能力更重要，为了避免出现被“业务坑”的情况，我们应该将更多的时间和精力放在方案实施的前期工作上，这样我们才能更好的推动项目上线。