认识达内从这里开始

产品经理提出业务需求然后交由设计开发人员来实现，然后在对产品进行测试和修改维护再发布上线就是我们常用的产品开发流程了，而今天我们就一起来了解一下，在需求对接上都需要注意哪些问题。

业务对接不比挖掘C端用户的需求容易多少，这个过程中同样会出现各种各样的问题——尤其是当你的业务方不是做互联网的，那么在需求对接的时候确实会有一定阻力。

我在现在这家公司，业务方中就有很多人是从传统行业过来，习惯用excel工作、对系统并没有什么概念的人。

在我和业务方对接需求的过程，出现过以下这些情况：

一，业务方不一定知道后台产品的价值是什么，能给业务本身带来什么提升;他们可能只知道：业务数据和操作要在系统上进行，比手工更方便一些。

二，有些人习惯于在传统行业用excel工作，对系统的理解会停留在记录和查询的作用。他们提的需求，通常会提一个具体的功能，你要是不问就不会说具体的目的。

比如真实目的是要做一项数据统计，但提过来的需求只是某个页面加个导出功能，或者某个列表加个什么字段之类的。

三，业务方通常会站在自己操作的角度提需求，不一定会关注产品宏观层面的价值、业务流程的标准化、管理规范的问题等。

——尤其是直接操作系统的人，他们提的多的就是具体的功能，如何方便他们操作，会出现有一些功能不能按他们说的做，但他们不理解。

四，业务方不一定有迭代思维，以为产品上线和传统企业的交付一样，一次性做完形成终版然后给他们用。

产品从0到1的过程我们会规划MVP，先上线基本功能并持续迭代;但他们看了会说这个怎么没有我要的什么什么功能，一定要等我们把他们要的都做完了再开始使用。

五，有时候一个事情习惯了会不容易改变。

假如我们出于管理上的目的需要迭代一些操作，改变的他们平时线下的操作习惯，他们可能会抗拒;反而说我已经有办法处理这些问题了，不理解我们为什么还要去改这些功能。

当然，这些情况不绝对，只是有可能会遇到其中的一部分问题。

在经历了那么些个业务对接之后，针对业务对接这项需求收集方式，我总结出了几点可以作为参考的办法：

一，找准业务方的人

别小看这点，有体会了就知道找人很重要的。比如一个部门里，下面的人更了解业务，但通常只会站在自己操作的角度考虑问题。

部门管理人员能决定事情，也通常知道系统要做什么，但对业务流程的细节不一定熟，也不一定有时间和你对需求。

再比如：

同一个部门的业务方，有些人对各类互联网产品比较了解，至少会告诉你他之前用过的系统是什么样的;另一些人就会更传统行业一点，也许前一个人半小时就能对清楚的需求，后一个人得和他讲俩小时。

我至今记得：我接触的一个系统从0的起步时候，跟一个业务负责人一个月开4次会，到后对方还在纠结为什么不买个系统;接下来换业务负责人之后，开了两次会后项目直接顺利启动。

二，听他们说，但不要照着做

这一点和我们对待用户需求的态度一样——从他们说的要加XX功能的背后，了解到他们需求的本质;然后想一种更好的方式满足他们的需求，并且可以直接告诉业务方我们方案，以及这样做的好处，相信他们不会拒绝。

三，多参与到实际的业务中去

知道业务方日常的工作，如何开展工作，系统上关注的点，好直接帮助业务方做一天的系统操作，甚至可以参与到他们的业务目标、会议、KPI这些领域中去。

这一点也和我们对待用户需求一样，但比理解用户需求要难的多——因为一般C端的用户需求门槛低，而业务可是实实在在的专业知识，有专业门槛的。

比如说作为供应链系统的产品经理，要深入仓储的业务，就要了解仓管人员管理仓库的核心目标是什么，什么是周转率，库存成本的计算规则，安全库存有什么用、怎么算，需求预测有什么用、怎么算等物流管理领域的专业知识——如果不深入业务，即使去帮业务方操作系统，也只能看到一些交互层面的小问题。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。