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

实战分享，后台产品中的6个特点分析解读 　　最近一直在做后台产品，我觉得相比前端产品来说，后台产品显得没有那么虚，会更加务实一些，对于产品经理业务上以及相关知识上的要求也要比前端产品更加明确。在最近的工作中，我总结了几个后台产品的特点。 　　 　　1. 后台产品需求较为明确，但要求对业务更加熟悉 　　做后台产品，一般来说需求不会像C端那样模糊，往往很多时候是不需要我们去做调研和分析，而是业务直接推进到需求。甚至对于一些为了配合前端所需要做的产品，比如CMS，需求会更加明确，即前端所需要配置的内容直接推到后台做相应内容即可。相对于C端产品面对用户时需要分析用户的行为，画像，心理预期等等，后台产品对于这方面简直少之又少。 　　但是，需求的明确并不代表需求的简单。做后台产品，需要对业务内容十分的了解。因为后台产品的业务逻辑会更加的复杂，同时流程性会更强。大量的字段堆积及繁琐的操作都需要产品经理去思考，将整个流程梳理清楚。在当前操作下哪个字段需要保留或者去除；这条记录的状态会流转到哪里，出现什么样的情况；阈值情况下会产生什么，如果有前端页面，所对应的前端页面是否会受到影响；一个页面的那么多操作会不会有冲突的地方；这些都需要建立在产品经理对业务的足够熟练上。产品经理必须得将整个业务流程了解透彻，才能在出现问题的情况下及时解决，减少错误的发生。 　　2. 后台产品字段需要整理甄别 　　前文也提到了，后台产品的好多页面往往是以列表形式，表格形式出现的，所以这一定会涉及到大量的字段与数据。我们之前做过一个ERP系统，几乎每一个一级二级页面的都是以列表的形式展示的，所以字段大概会有二十多个，并且每一条数据都会涉及到。 　　这个时候，如何有效的甄别字段，让之后的操作人员用起来不会觉得繁琐、东西很多同时又能满足业务需要就比较考验产品经理了。甄别字段，第一步就是从业务方面去推动。在ERP系统里面，统一属性的页面（比如商品页面）索引列表的字段所需要的信息大致是相同的，比如供应商，订单号，商品名称，商品图片等可以辨别商品的信息，然后不同的列表再加上这个列表相关的信息即可。但是商品信息所涉及的字段也特别多，所以产品经理在整理列商品属性的字段时，也要根据当前页面的业务选取适合这个页面的属性。比如在进行库存盘点的时候，我需要了解的字段是商品库存，商品规格，商品图片等，这个时候供应商等字段就不是很必要。而进行商品入库操作的时候，供应商又是必不可少的字段。 　　所以在我们做后台产产品的时候，不要只是将字段粘贴复制到需要的地方就好了，这样虽然不会遗忘出错，但是会使你的系统更加臃肿，难以使用。 　　3. 后台产品需要用共通的东西串接 　　最近在做一个关于合同相关的系统，有之前的一套老系统作为参考。看到了之前的系统特别的繁杂，所有的东西都是在一个层级全部铺开去操作的。合同在不同的流程阶段有不同的状态，可奇葩的是这套系统并没有一个流程的概念，所有需要流程转化的地方都是通过合同号等相关信息去检索，然后与之前的状态并无相关再另外新开一条记录来进行操作的。这无疑加大了操作者的工作量，同时误操作的几率也大大增加，可能会出现一个合同有多个状态的情况，同时当操作者想要检索该合同时，不同的状态下都有记录，还需要他自己去辨别。所以当操作者第一次操作这个系统的时候，一定会很懵逼。 　　但其实这个系统是有可以进行串接的东西的，即合同的状态，那么上述的所有操作流程完全可以基于合同的一个状态流转去进行。这样，所有的操作都会变成有序的，流程清晰且不同的操作路径都是唯一的，一是可以简化操作流程同时也不会出现上述的种种情况。 　　我们在做后台系统的时候，不同的板块往往由于业务原因很多时候都是可以关联的。如果可以关联的操作，我们在没有特殊情况下完全可以让它进行关联。一方面，关联操作可以让操作者的工作量减少，如果有相关的字段可以直接带过来而不需要手动去输，这样也可以减少误操作。另一方面，对于唯一性的操作尤其是状态流转的这种操作直接关联操作可以极大的减少错误频率。 　　4. 后台产品逻辑性会非常强 　　后台产品的逻辑性相对来说逻辑性会更强一些。因为后台会涉及到大量的数据处理，并且不同的数据进行不同的操作会产生不同的结果。各种限制条件等等也是在后台进行设置的，在不同的情景下所要涉及到的业务内容一般也会有不同。比如在用CMS配置前端页面的时候，用户端所看到的可能只是一个限时抢购的页面，但是后台配置的时候，我们在考虑到最基本的时间限制条件之外，还要考虑到这个活动与其他活动发生冲突的时候怎么办，进行限时抢购的商品能不能进行下架处理，开始时无库存了此时要手动配置成什么状态等等许多可能前端用户并没考虑到的情况都需要在后台体现出来。 　　那么，如何有效快速的理清复杂的后台逻辑呢？我认为对于一般有状态流转或比较标准的流程化