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

专为互联网人打造的365天成长计划,500门视频课程随便看,构建你的产品、运营知识体系。查看详情

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

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

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

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

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

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

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

需求调研的方法:

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

业务需求该如何理解?

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

业务需求:网站太丑了

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

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

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

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

1、流程优化忌讳拍脑门

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

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

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

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

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

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

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

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

4、页面信息的归类很重要

页面排版太乱的问题是最容易发现的。很多系统,看第一眼就觉得“闹心”了,很可能是页面信息都乱堆在一起,那么你需要把页面信息进行归类并且整齐排版。

可以举个例子:

(1)归类前

(2)归类后

5、bug太多不能怨社会

如果是系统bug太多,那么你需要找研发沟通,进行bug修复。千万不可就完全推到研发与测试头上了,其实这还是你的问题,是你项目把关有问题,毕竟你才是业务与技术沟通的对接人。

以上这些是我对业务需求的一些理解。后台产品非常考验一个产品经理的沟通能力以及对需求的把控。我们需要将业务需求翻译成产品语言,并转化成技术人员可以理解的需求,把这过程中产生的偏差要尽量降低到最小。当然,产品经理不能只是个单纯的翻译官,更需要有对需求的把控以及对产品更长远的思考 。

 

作者:大金子,1岁产品经理,1年互联网产品设计经验。

本文由 @大金子 原创发布于人人都是产品经理。未经许可,禁止转载。

祝给予赞赏的伙伴,2017年发大财!
4人打赏

评论( 5

写下你的想法
  1. 后台产品很好优化,产品经理和研发各跑全流程20遍就OK了 :cry:

    回复
  2. 总结得很好,很多都是我实际工作中有遇到的情况!

    回复
    1. 回复

      感谢支持,您如果有什么想法也欢迎与我分享哦 :oops:

  3. 总结得不错

    回复
    1. 回复

      感谢支持

推荐阅读