实战分享，后台产品中的6个特点分析解读

最近一直在做后台产品，我觉得相比前端产品来说，后台产品显得没有那么虚，会更加务实一些，对于产品经理业务上以及相关知识上的要求也要比前端产品更加明确。在最近的工作中，我总结了几个后台产品的特点。

1. 后台产品需求较为明确，但要求对业务更加熟悉

做后台产品，一般来说需求不会像C端那样模糊，往往很多时候是不需要我们去做调研和分析，而是业务直接推进到需求。甚至对于一些为了配合前端所需要做的产品，比如CMS，需求会更加明确，即前端所需要配置的内容直接推到后台做相应内容即可。相对于C端产品面对用户时需要分析用户的行为，画像，心理预期等等，后台产品对于这方面简直少之又少。

但是，需求的明确并不代表需求的简单。做后台产品，需要对业务内容十分的了解。因为后台产品的业务逻辑会更加的复杂，同时流程性会更强。大量的字段堆积及繁琐的操作都需要产品经理去思考，将整个流程梳理清楚。在当前操作下哪个字段需要保留或者去除；这条记录的状态会流转到哪里，出现什么样的情况；阈值情况下会产生什么，如果有前端页面，所对应的前端页面是否会受到影响；一个页面的那么多操作会不会有冲突的地方；这些都需要建立在产品经理对业务的足够熟练上。产品经理必须得将整个业务流程了解透彻，才能在出现问题的情况下及时解决，减少错误的发生。

2. 后台产品字段需要整理甄别

前文也提到了，后台产品的好多页面往往是以列表形式，表格形式出现的，所以这一定会涉及到大量的字段与数据。我们之前做过一个ERP系统，几乎每一个一级二级页面的都是以列表的形式展示的，所以字段大概会有二十多个，并且每一条数据都会涉及到。

这个时候，如何有效的甄别字段，让之后的操作人员用起来不会觉得繁琐、东西很多同时又能满足业务需要就比较考验产品经理了。甄别字段，第一步就是从业务方面去推动。在ERP系统里面，统一属性的页面（比如商品页面）索引列表的字段所需要的信息大致是相同的，比如供应商，订单号，商品名称，商品图片等可以辨别商品的信息，然后不同的列表再加上这个列表相关的信息即可。但是商品信息所涉及的字段也特别多，所以产品经理在整理列商品属性的字段时，也要根据当前页面的业务选取适合这个页面的属性。比如在进行库存盘点的时候，我需要了解的字段是商品库存，商品规格，商品图片等，这个时候供应商等字段就不是很必要。而进行商品入库操作的时候，供应商又是必不可少的字段。

所以在我们做后台产产品的时候，不要只是将字段粘贴复制到需要的地方就好了，这样虽然不会遗忘出错，但是会使你的系统更加臃肿，难以使用。

3. 后台产品需要用共通的东西串接

最近在做一个关于合同相关的系统，有之前的一套老系统作为参考。看到了之前的系统特别的繁杂，所有的东西都是在一个层级全部铺开去操作的。合同在不同的流程阶段有不同的状态，可奇葩的是这套系统并没有一个流程的概念，所有需要流程转化的地方都是通过合同号等相关信息去检索，然后与之前的状态并无相关再另外新开一条记录来进行操作的。这无疑加大了操作者的工作量，同时误操作的几率也大大增加，可能会出现一个合同有多个状态的情况，同时当操作者想要检索该合同时，不同的状态下都有记录，还需要他自己去辨别。所以当操作者第一次操作这个系统的时候，一定会很懵逼。

但其实这个系统是有可以进行串接的东西的，即合同的状态，那么上述的所有操作流程完全可以基于合同的一个状态流转去进行。这样，所有的操作都会变成有序的，流程清晰且不同的操作路径都是唯一的，一是可以简化操作流程同时也不会出现上述的种种情况。

我们在做后台系统的时候，不同的板块往往由于业务原因很多时候都是可以关联的。如果可以关联的操作，我们在没有特殊情况下完全可以让它进行关联。一方面，关联操作可以让操作者的工作量减少，如果有相关的字段可以直接带过来而不需要手动去输，这样也可以减少误操作。另一方面，对于唯一性的操作尤其是状态流转的这种操作直接关联操作可以极大的减少错误频率。

4. 后台产品逻辑性会非常强

后台产品的逻辑性相对来说逻辑性会更强一些。因为后台会涉及到大量的数据处理，并且不同的数据进行不同的操作会产生不同的结果。各种限制条件等等也是在后台进行设置的，在不同的情景下所要涉及到的业务内容一般也会有不同。比如在用CMS配置前端页面的时候，用户端所看到的可能只是一个限时抢购的页面，但是后台配置的时候，我们在考虑到最基本的时间限制条件之外，还要考虑到这个活动与其他活动发生冲突的时候怎么办，进行限时抢购的商品能不能进行下架处理，开始时无库存了此时要手动配置成什么状态等等许多可能前端用户并没考虑到的情况都需要在后台体现出来。

那么，如何有效快速的理清复杂的后台逻辑呢？我认为对于一般有状态流转或比较标准的流程化后台可以从以下几个步骤去着手考虑：

1. 首先将所有流程先跑通一遍，不要去管其他发生的情况以及其他与主流程无关的跳转。

2. 在将这个流程整理出来之后，根据业务将其划分为几个模块，每一个模块作为一个单独的流程进行内容的填充。

3. 最后将一些在不同模块之间有跳转链接关系的副流程链接在一起。

经过以上这几个步骤，一个简单流程的逻辑大致就可以理清楚了，然后不同业务组合到一起整体的逻辑框架就可以搭建出来了。

5. 交互细节要求不会很高

我们在做C端产品的时候，对用户的感受特别看重，因为一些小小细节往往决定着你是否能在竞品中胜出。但是后台产品的用户对于这些细节并没有特别在意。因为他们的最终夙愿并不是希望这款产品用的有多么爽，而是希望这款产品可以减少自己多少的劳动力，缩短了多少的工时，提高了多少的产出。所以在这个时候，产品的业务性就要比交互细节性更强。

当然，这并不是说后台产品的交互不重要，只是说对于细节方面不回要求很高，但是整体交互还是需要去认真思考的。比如这个按钮应当放在什么位置才能简化操作，哪些地方需要着重处理给操作者以警示，这个操作是以弹窗的形式还是新页面的形式去进行等等都是需要思考的交互方式。

所以一般在设计后台产品的时候，我们对于一些大的可以影响或者警示操作者的交互要比一些从心理方面出发的交互细节要更加注重。

6. 后台产品相对成型，市面上的产品参考意义很大

其实对于后台产品来说，市面上好多成熟的系统都已经做的比较好了，并且大多数可以叫的上名字的系统（CRM、CMS、ERP等等）都长得大同小异。所以一个产品经理要了解你做的东西都是比较方便且目的性都会比其他产品强太多的。比如要在做一套ERP系统的时候，就可以去了解一下SAP公司的相关系统，这种前人经过无数次试验的打磨出的优秀系统参考意义极佳。

以上这些是我在工作中一些小的总结。做好一个后台产品对于一个产品经理的考验程度要大于C端产品，加强自己在后台产品方面的知识和业务补充对于今后的职业生涯来说会有一定的竞争。然而，一套好的后台产品复杂程度与优秀程度肯定远远不止这些，要成为一个好的后台产品经理，依然任重而道远。