实战经验｜如何处理后台产品的业务需求

关注

来源：大金子 2609 2017-07-26

最近在设计ERP系统，对内部使用的产品需求深有感悟，B端产品相较于C端来说，需求更为清晰，但是不谨慎处理，仍然会有诸多问题。下面我对自己踩过的坑做个小结。

不可凭自己臆想出来的需求做产品

像ERP系统这种纯B端的产品，最怕的就是产品经理臆想出来的需求。

很多时候领导的一句优化系统，我们以为这就是需求了，其实并没有搞清楚：

本质的需求是什么？
为什么要优化？
哪里需要优化？

想起以前实习时运营的ERP系统，系统做好了，但是业务人员并不使用，细究原因“我们已经有很多系统了啊，怎么又来一系统？” 这时候软磨硬泡让人家使用？当然不是。

B端的产品是帮助业务员更有效的运作业务流程，而不是凭自己的想象创造一个产品硬套到业务上，绝不可本末倒置。一定要根据业务场景细化你的需求，因此前期的需求调研非常重要。

需求调研的方法：

一定要与业务人员沟通。 通过沟通，梳理清楚业务实际的工作流，将工作流拆分为清晰的环节，这时也就大致形成了系统的结构。接着还需整理出业务流程中涉及到的所有角色以及他们的职责，这部分要尽量细化，因为这些是填充结构的主要内容。
如果是做系统优化，就需要自己上手操作原系统。先了解原系统的结构、模块划分以及业务逻辑。如果原系统有清晰的需求文档最好，然而很多时候并没有这样的条件，那样你就需要自己走一遍整个操作流程。
参考市面上成熟的产品。类似ERP、CRM这些系统，市面上已经有很多成熟的产品可以借鉴，学习他们对细节的处理，产品的结构、流程可以自己把控。

业务需求该如何理解？

业务人员表达出来的需求有时会很宽泛，比如 “这个系统挺烂的”，我们就必须细究“烂”在哪里？是流程太繁琐？功能缺失？等等，这个时候最好让业务人员进行演示，才好帮助我们定位问题。业务人员只是操作系统的表现层，所以提出的需求较为表面，这就需要我们追究出最本质的需求是什么，将客户需求翻译为“产品语言”。

业务需求：网站太丑了

“网站太丑”翻译为产品语言：

整体页面VI不统一
页面排版不整齐
网站结构不清晰

面对业务铺天盖地的需求，我们该如何处理？

当我们了解了需求后，会发现林林总总的业务需求实在无从下手，面对这种情况，产品经理需要有合理的把控。我把业务需求基本上分为流程优化、功能修改、交互体验、页面太乱、系统bug太多这几种：

1、流程优化忌讳拍脑门

如果是流程太繁琐，那么就要弄清楚哪部分流程不符合当前的业务场景，是不是真的能够优化。

我之所以要强调是不是真的能优化，是因为很多工作流都不是一时拍脑门想出来的，而是经过长时间的沉淀积累，缩减任何一个环节，砍掉任何一个环节的关联。系统的逻辑看似是没有漏洞，但是却并不符合业务场景，不能满足业务需求。一个严谨的产品并不代表就是个成功的产品。

所以，要优化流程切记自己不可拍脑门，需要与业务人员确认，尤其这个工作流涉及到很多业务员的KPI时，你更需要与业务人员的领导确认。系统的功能结构、运转流程是最先需要考虑的部分，而且要慎重考虑，因为一旦这些已经敲定，后续再改动就真的是牵一发而动全身了。

2、功能的修改要有自己的判断

怎么判断是不是功能缺失呢？那就要看业务人员的需求了。其实很多时候，当你把业务人员的需求翻译成产品需求时，你就会发现，他们口中的“不合理”很大程度上和缺少功能有关。这涉及到很多细节上的问题。比如，这部分数据没办法导出成EXCEL格式，这部分流程能不能放到线上操作？等等。这时候产品经理也需要进行判断，哪些功能真的是普遍需求，哪些并不合理。

3、交互体验问题常常是隐性的

其实，B端产品也涉及到很多交互体验上的问题。这就是做B端产品简单又不简单的地方。C端用户很多，他们的需求无法统一，甚至很多时候是相悖的，他们很挑剔，一点的体验不爽他们就会对产品失望，这时候你多看看用户的评价，多看看数据分析，你是可以发现的。但是B端用户的需求经常是隐性的，他们经常说“能用就行”，他们会这么说是因为他们只要使用系统能够正常的完成手头的工作，可没有那个闲心去挑剔你的产品细节。

最常见的场景是：费了半个小时写完的表单，点击“提交”，提示“数据格式错误”，然后系统自动把刚才填好的内容全部清空了，这时业务人员的反应是皱一下眉，心里骂一句，然后乖乖的换个格式重新填写。（别问我为什么知道这些，因为我曾经就是那个“业务员”。）其实加一步实时校验就能完全搞定的呀。这种隐性的需求业务人员不会告诉你，需要你自己去上手操作才能发现。当然前提你真的是个精益求精的产品，还有一个前提是，刚好也有一个精益求精的研发。