后台产品设计的10个步骤.docx

第PAGE\*MERGEFORMAT14页共NUMPAGES\*MERGEFORMAT14页

后台产品设计的10个步骤

我本人在小公司做了一段时间的公司内部支持系统，总结出了一部分关于后台产品的个人经验。本文分为六个部分，按后台产品设计过程的顺序，分别是后台产品有什么用、有哪些后台产品、业务需求怎么对接、产品本身怎么设计、如何上线和如何跟进使用情况。上篇写了些比较虚的产品目标和作用，这篇从具体工作内容出发，写业务需求对接和产品设计这两方面的体验和心得。三、后台产品的需求对接3.1是不是业务方说什么，我们就做什么后台产品服务于业务，在产品需求调研的阶段，后台产品经理要做的事情和做C端产品自然有区别。C端端产品通常是通过各种手段去接触用户、挖掘用户的需求，面向B端客户的产品也差不多，只是调研对象变成了B端用户。而面向企业内部的后端支撑产品，需求调研的主要方式是与所谓的“业务方”进行业务需求的对接——这个业务方，指的就是公司其他部门的人。比如做供应链系统，就要找供应链部门的采购、仓管对接需求；比如做CRM系统，市场部门就是业务方。这一节主要写需求对接方面的问题，具体的需求调研和分析就不拓展了。在我刚做后台产品的时候，我一直有个疑惑：我们的需求方是很确定的那几个人，我们的产品只要面向他们服务，那我们做的岂不就是既定的需求，只要他们说什么，我们做什么就行了？在各种需求对接的时候，业务方通常会直接说你给我一个什么什么功能，我们按他说的做，不就已经满足需求了？后来我逐渐发现：业务方提出来的具体需求，不一定是合理的。尽管我们做的系统是给他们用的，但产品需求的出发点更多是站在公司业务的角度，考虑系统对业务的价值，流程是否合理——这些是需要由我们产品去规划的，而不只是功能用着怎么样。还有，业务方并不一定了解产品能给他们带来什么，他们提出要什么功能，并不一定能解决他们真正的需求目的。这个产品经理自己的能力有关系：在初阶阶段，因为自己能力有限，会停留在接收需求并执行的阶段；但水平提高后，就会知道怎么做更合理，逐渐去规划整个产品。因此，除了一些细节的小功能很简单，直接做就行；一旦涉及到整个业务模块的需求，一定是由产品经理主导——了解到业务本身，然后给业务方标准化的流程，告诉他们怎么用；并不一定要按照他们说的做，不然做出来的很可能不会是可行的方案，业务方也只会认为产品经理只是个做系统的。不过我也看到有些牛人说，面向公司内部的产品经理发展空间有限，毕竟用户太少，既定的需求多；在项目中业务方的重要性更高，确实没法像做C端或者平台的产品经理那样能主宰一个项目。——这种情况或多或少存在，这个问题只能说见仁见智吧。3.2业务对接的常见现象和解决方法业务对接不比挖掘C端用户的需求容易多少，这个过程中同样会出现各种各样的问题——尤其是当你的业务方不是做互联网的，那么在需求对接的时候确实会有一定阻力。我在现在这家公司，业务方中就有很多人是从传统行业过来，习惯用excel工作、对系统并没有什么概念的人。在我和业务方对接需求的过程，出现过以下这些情况：第一，业务方不一定知道后台产品的价值是什么，能给业务本身带来什么提升；他们可能只知道：业务数据和操作要在系统上进行，比手工更方便一些。第二，有些人习惯于在传统行业用excel工作，对系统的理解会停留在记录和查询的作用。他们提的需求，通常会提一个具体的功能，你要是不问就不会说具体的目的。比如真实目的是要做一项数据统计，但提过来的需求只是某个页面加个导出功能，或者某个列表加个什么字段之类的。第三，业务方通常会站在自己操作的角度提需求，不一定会关注产品宏观层面的价值、业务流程的标准化、管理规范的问题等。——尤其是直接操作系统的人，他们提的最多的就是具体的功能，如何方便他们操作，会出现有一些功能不能按他们说的做，但他们不理解。第四，业务方不一定有迭代思维，以为产品上线和传统企业的交付一样，一次性做完形成最终版然后给他们用。产品从0到1的过程我们会规划MVP，先上线基本功能并持续迭代；但他们看了会说这个怎么没有我要的什么什么功能，一定要等我们把他们要的都做完了再开始使用。第五，有时候一个事情习惯了会不容易改变。假如我们出于管理上的目的需要迭代一些操作，改变的他们平时线下的操作习惯，他们可能会抗拒；反而说我已经有办法处理这些问题了，不理解我们为什么还要去改这些功能。当然，这些情况不绝对，只是有可能会遇到其中的一部分问题。在经历了那么些个业务对接之后，针对业务对接这项需求收集方式，我总结出了几点可以作为参考的办法：第一，找准业务方的人别小看这点，有体会了就知道找人很重要的。比如一个部门里，下面的人更了解业务，但通常只会站在自己操作的角度考虑问题。部门管理人员能决定事情，也通常知道系统要做什么，但对业务流程的细节不一定熟，