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

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

不可凭自己臆想出来的需求做产品
像ERP系统这种纯B端的产品 ，最怕的就是产品经理臆想出来的需求。
很多时候领导的一句优化系统，我们以为这就是需求了，其实并没有搞清楚：

本质的需求是什么？

为什么要优化？

哪里需要优化？

想起以前实习时运营的ERP系统，系统做好了，但是业务人员并不使用，细究原因“我们已经有很多系统了啊，怎么又来一系统？” 这时候软磨硬泡让人家使用？当然不是。
B端的产品是帮助业务员更有效的运作业务流程，而不是凭自己的想象创造一个产品硬套到业务上，绝不可本末倒置。一定要根据业务场景细化你的需求，因此前期的需求调研非常重要。
需求调研的方法：
[ol]

一定要与业务人员沟通。 通过沟通，梳理清楚业务实际的工作流，将工作流拆分为清晰的环节，这时也就大致形成了系统的结构。接着还需整理出业务流程中涉及到的所有角色以及他们的职责，这部分要尽量细化，因为这些是填充结构的主要内容。

如果是做系统优化，就需要自己上手操作原系统。先了解原系统的结构、模块划分以及业务逻辑。如果原系统有清晰的需求文档最好，然而很多时候并没有这样的条件，那样你就需要自己走一遍整个操作流程。

参考市面上成熟的产品。类似ERP、CRM这些系统，市面上已经有很多成熟的产品可以借鉴，学习他们对细节的处理，产品的结构、流程可以自己把控。
[/ol]
业务需求该如何理解？
业务人员表达出来的需求有时会很宽泛，比如 “这个系统挺烂的”，我们就必须细究“烂”在哪里？是流程太繁琐？功能缺失？等等，这个时候最好让业务人员进行演示， 才好帮助我们定位问题。业务人员只是操作系统的表现层，所以提出的需求较为表面，这就需要我们追究出最本质的需求是什么，将客户需求翻译为“产品语言”。
业务需求：网站太丑了
“网站太丑”翻译为产品语言：

整体页面VI不统一

页面排版不整齐

网站结构不清晰

面对业务铺天盖地的需求，我们该如何处理？
当我们了解了需求后，会发现林林总总的业务需求实在无从下手，面对这种情况，产品经理需要有合理的把控。我把业务需求基本上分为流程优化、功能修改、交互体验、页面太乱、系统bug太多这几种：
1、流程优化忌讳拍脑门
如果是流程太繁琐，那么就要弄清楚哪部分流程不符合当前的业务场景，是不是真的能够优化。
我之所以要强调是不是真的能优化，是因为很多工作流都不是一时拍脑门想出来的，而是经过长时间的沉淀积累，缩减任何一个环节，砍掉任何一个环节的关联。系统的逻辑看似是没有漏洞，但是却并不符合业务场景，不能满足业务需求。一个严谨的产品并不代表就是个成功的产品。
所以，要优化流程切记自己不可拍脑门，需要与业务人员确认，尤其这个工作流涉及到很多业务员的KPI时，你更需要与业务人员的领导确认。系统的功能结构、运转流程是最先需要考虑的部分，而且要慎重考虑，因为一旦这些已经敲定，后续再改动就真的是牵一发而动全身了。
2、功能的修改要有自己的判断
怎么判断是不是功能缺失呢？那就要看业务人员的需求了。其实很多时候，当你把业务人员的需求翻译成产品需求时，你就会发现，他们口中的“不合理”很大程度上和缺少功能有关。这涉及到很多细节上的问题。比如，这部分数据没办法导出成EXCEL格式，这部分流程能不能放到线上操作？等等。 这时候产品经理也需要进行判断，哪些功能真的是普遍需求，哪些并不合理。
3、交互体验问题常常是隐性的
其实，B端产品也涉及到很多交互体验上的问题。这就是做B端产品简单又不简单的地方。C端用户很多，他们的需求无法统一，甚至很多时候是相悖的，他们很挑剔，一点的体验不爽他们就会对产品失望，这时候你多看看用户的评价，多看看数据分析，你是可以发现的。但是B端用户的需求经常是隐性的， 他们经常说“能用就行”，他们会这么说是因为他们只要使用系统能够正常的完成手头的工作，可没有那个闲心去挑剔你的产品细节。
最常见的场景是：费了半个小时写完的表单，点击“提交”，提示“数据格式错误”，然后系统自动把刚才填好的内容全部清空了，这时业务人员的反应是皱一下眉，心里骂一句，然后乖乖的换个格式重新填写。（别问我为什么知道这些，因为我曾经就是那个“业务员”。）其实加一步实时校验就能完全搞定的呀。这种隐性的需求业务人员不会告诉你，需要你自己去上手操作才能发现。当然前提你真的是个精益求精的产品，还有一个前提是，刚好也有一个精益求精的研发。
4、页面信息的归类很重要
页面排版太乱的问题是最容易发现的。很多系统，看第一眼就觉得“闹心”了，很可能是页面信息都乱堆在一起，那么你需要把页面信息进行归类并且整齐排版。
可以举个例子：
（1）归类前

（2）归类后

5、bug太多不能怨社会
如果是系统bug太多，那么你需要找研发沟通，进行bug修复。千万不可就完全推到研发与测试头上了，其实这还是你的问题，是你项目把关有问题，毕竟你才是业务与技术沟通的对接人。
以上这些是我对业务需求的一些理解。后台产品非常考验一个产品经理的沟通能力以及对需求的把控。我们需要将业务需求翻译成产品语言，并转化成技术人员可以理解的需求，把这过程中产生的偏差要尽量降低到最小。当然，产品经理不能只是个单纯的翻译官，更需要有对需求的把控以及对产品更长远的思考 。