本文作者总结了自己在工作中遇到的后端产品的种类，以及这些产品的特点。 享受~
后台产品，顾名思义购物商城网站 一个商品应该具备哪些字段，就是不直接面对用户的产品。 我总结出一个背景产品可以从以下两个方面来衡量：
满足的需求更多是业务需求，而不是个人诉求。 使用产品的目的性极强。 后台产品在使用的时候一般都有很强的用途，或者需要完成业务操作，或者需要完成一定的流程审批。 总之，在使用的时候，他们一般出于个人感情原因不会使用。
根据以上两点，也是点餐。 你去餐厅，服务员拿你手上的手机给你点餐的系统是后台产品，但不是让你自己点外卖或扫码点餐。 我之前做的一个PDA系统，流程和淘宝购物流程很像，但是也是后台产品，因为是辅助业务开发的。 基于这两点，我在自己做过的产品中总结了一些不同的背景产品形态，并进行了归类。
工具
去年我做了我们平台的两个内部应用，一个是平台的质控系统，一个是称重系统。 同时，最近在做ERP项目的时候，也做了PDA这边的部分。 在分类上，我称这些系统为工具系统。 类似的还有我们出去吃饭时店员用的点餐系统，还有我们收快递时快递小哥手里拿着的PDA里的系统。
我总结了工具类产品的几个特点：
1、用户端一般为移动端
由于工具产品的特殊性，所要求的便利性尤为重要，往往需要在不同的场景下使用。 用于工具的后台产品一般都是手机产品。 如PDA、PAD、手机APP等。因此，一般来说购物商城网站 一个商品应该具备哪些字段，在设计时，需要根据不同的业务场景选择合适的操作终端进行设计。
2、可操作性强
与其他后台产品相比，工具类产品的可操作性特别强。 具体来说，工具产品应该是为满足一定的作业程序化、标准化、智能化、集约化而开发的产品。 所以这个时候使用工具后台产品的操作就很重要了，也是它唯一的目的。
在设计工具产品时，需要考虑以下几个方面：
(1)操作步骤、输入按钮等交互需要多加考虑。 由于工具类产品的核心功能是操作，设计者需要思考如何在这种场景下实现操作简单方便的目的。
（2）工具类产品多用于移动端场景，而不是像其他后台产品一样在电脑上运行。 因此，这个时候就需要考虑工具类产品的使用场景。 比如在比较大的市场使用PDA，信号可能不是很好，那么弱网环境应该是什么体验，图片是否加载，操作步骤是否应该简化； 这么吵的地方，提示音的音量是不是应该大点？
3.相对于其他后台产品，权限较低，整体比较简单，功能比较单一
一般我们提到产品中的背景，第一印象可能是复杂繁琐。 但由于工具类产品的经营者一般是实际经营者，其权限普遍较低。 但也因为它可能只是满足某些需求的一组工具。 所以，由于以上原因，工具类产品会比一般的后台产品简单，功能也比较单一。
记录类
记录类产品是指为了以后操作的可追溯性，后期工作的查漏补缺，以及业务人员操作时对当前需要的内容的一些记录而开发的产品。 比如我最近的ERP系统，需要记录货物的到货入库，需要录入新进的货物，这些都是记录产品。 一般来说，唱片产品不是单独存在的，而是作为一个大系统的一小部分。
我总结了唱片产品的几个特点：
1.规划字段时，备案产品应增加标识字段
由于记录产品大量作为以后一些工作的参考记录，数据流动性大，与其他数据整合的可能性大，业务人员查阅修改的机会也大，有时会需要存档. 因此，一般的记录产品都需要增加一个标识字段，通过设置规则的编码方式为其确定唯一的ID。
2. 生成新记录数据时要全盘思考
在设计唱片产品时，每条数据的生成方式都需要慎重考虑。 因为实际上你的整个页面都是每条新记录叠加生成的，所以你必须在源头上进行控制。
一般来说，如果是通过外部业务原因直接推送到系统做记录，可以通过在页面添加新按钮的方式来添加。 这时候应该是弹窗或者是新的页面。 有些字段是填写还是选择等需要思考。 如果是因为一些业务转账而直接在系统内部生成的一条记录，那么从另一个页面带过来哪些字段，去掉哪些字段，需要同时增加哪些信息是比较重要的点。
另外，数据生成后，这个数据是直接叠加在列表的最前面，还是有状态，有位置。 添加数据后是否有审核过程，审核分几个步骤，审核过程中是否展示数据，展示在哪里，可以细化的点很多。
3.过滤和搜索应该精简和准确
对于记录产品，为了更准确地定位所需数据，一般会进行筛选和搜索。 在条件方面，页面中的所有字段都可以作为过滤和搜索条件，但是我们在做的时候，不能只凭个人习惯来决定。 需要和业务人员多沟通，弄清楚他们在操作这些信息的时候最敏感的字段是什么，最好识别的字段是什么，差异最大的字段是什么，然后做删除和搜索条件。 好的筛选搜索是在筛选和搜索上特别精简，但可以达到非常准确的目标。
4.边界条件、输入字段、操作等限制必须到位
由于唱片产品的特殊性，运营商需要输入大量的数据。 这时候，如果操作失误而没有被发现，就可能会出现错误，造成业务延误。 因此，在设计时，我们必须考虑到这些约束条件。 比如字段的边界值是多少，字段中允许输入的合法字符有哪些，总共需要输入多少个字符等。这些限制可以通过正则表达式等技术手段来降低必须到位。 同时，记录在不同条件下的操作也可能不同。 这也是需要考虑的。 这也适用于下面提到的配置产品。
5.其他功能小点如排序、操作交互要综合考虑
记录产品中每条数据的字段类型相同，所以有时会涉及到排序功能。 那么产品经理要考虑数据正常是怎么记录的，是按时间顺序正序还是倒序，哪些字段允许排序，排序方式是什么。 操作的交互需要思考设计。 该操作是可以在列表页操作还是需要点击进入详情页，阅读详情后才能操作。 还有要不要做批量操作之类的小功能点，产品经理也要根据业务综合考虑。
配置类
配置类产品可以说是比较常见的后端产品之一，也是涵盖内容比较广泛的一种。 内容管理配置、活动配置、人员管理配置等统称为配置产品。 关于本系统中不同角色的权限配置，以及其他页面下拉框的选项配置等。因此，作为一个后台系统，配置项应该是必不可少的。
常见的分离配置产品如CMS，这个应该完全属于配置产品。 然后我在平时的工作中也总结了配置产品的几个特点：
1.一般都有配置项，所以不会单独存在
配置产品一般是为了实现系统中的其他功能点，或者配置其他网站等而开发的模块，一般不会单独存在。 所以在做配置产品的时候，不能简单的把目前正在做的事情做完。 一定要看配置产品和它配置的系统所改变的东西的变化。 大局更重要，考虑的事情也更多。
2、思维的广度不能停留在表面
在做配置产品的时候，对应的配置项可能不是特别复杂，但是产品经理在做的时候一定要慎重考虑。 比如在配置CMS配置商城的时候，前端需要操作的页面可能比较简单，用户需要接收的信息也不会特别复杂，但是在配置后台的时候，所有必须考虑信息。 . 即使用户只有1%的机会操作，也必须配置这1%时间的操作结果。 又比如在划分角色的时候，有些角色可能暂时不用，但是为了整个系统以后的迭代，一定要包含进去。
3、处理角色时，一定要整理好资料，流程要顺畅
如果我们在做一个特别复杂的系统，配置项往往决定了你的系统是否好用，因为不同的角色可能看到的操作内容不同。 而这些操作内容对于角色来说会是一个有机的整体，让他们觉得系统不突兀，所有的流程都要顺畅，不会觉得少了点什么，怪怪的。
因此，我们在进行配置设置时，不能简单地增删字段、显示隐藏功能，把系统的易用性放在重要位置。 需要在隐藏字段和操作的同时配置关联内容。 只有这样，不同的角色才能在使用的时候感觉到自己在使用一个完整的系统。
关系类
可以说，关系类产品的分类和定位与上述几种产品不同。 无论是配置类还是记录类，都是按其运行方式来划分的。 关系类按功能划分。 只是因为最近在做关系类产品，所以单独说一下。
目前市场上典型的关系型产品是CRM，很多公司都使用自己的CRM来管理与客户的关系。 我们最近一直在为合作伙伴开发一个管理系统。 涉及的关系主要是商城与商城内门店的关系管理。 设计关系管理产品时，思路是什么？
我觉得既然是关系管理系统，产品经理的第一步就是理清他们的关系，虽然一开始关系可能特别复杂，而且比较难的是有时候不仅仅是两个关系，就会出现三个甚至多个角色的交叉关系。 这个时候前期的工作肯定会很辛苦。
一般在做的时候，第一步就是把角色之间的所有交流都梳理清楚，双方在什么情况下会交流，然后系统会发生什么样的交流。 这一步很重要，也很复杂，需要产品经理非常耐心细心。
其次，梳理完关系之后，我们要梳理一个主线，就是为什么两者可以有关系？ 他们是如何传承的？ 转账过程中会带入哪些信息？ 需要什么样的操作？ 比如一个电商客户管理系统的主线是客户购买商品，那么这是它的主线。 在数据内容上，客户购买产品后，我有客户的购买数据，我可以梳理客户的RFM数据模型，为每个用户建立画像。 在营销方面，我可以根据客户的购买情况和记录进行相应的操作。 可根据客单价复购率对客户进行VIP评级，制定不同的折扣。 通过这条主线分岔，先搭建整个系统的架子。 然后通过这个流程填写不能关联的内容，比如客户信息的录入等等。
然后，根据业务的重要程度调整位置，填写具体内容。
最后把整体流程跑到一边，看看有没有遗忘的流程，再和需求方的业务方对接。
内部申请 外部申请
内部应用和外部应用主要是指我们提供的服务对象。 内部是指公司内部使用，外部可能是作为B端产品给市场或合作伙伴使用。
在我们网站主页上的 CMS 上工作时，第二部分中的广告数量本来是有限的。 后台连上的时候，我负责CMS的运行，说我们不会傻到加100个广告。 我还需要对网站的内容负责。 是的; 在做品管系统的时候，需求很顺利的被满足了，因为其实这些东西他们确实是急需的，然后推到我们这边去实现。
所以在做内部应用的时候，相对来说，压力和挑战会稍微小一些。 一是本身就是同事的需求会尽量满足你，二是公司既然要建这个系统，说明公司确实需要这样的系统。
但是外部系统就不是这样了，因为这个时候我们面对客户的时候，如果遇到一些客户自己的需求不明确，或者市场上有客户跟我们竞争，怎么去赢得客户？这时候得到客户的青睐，得到市场的认可也是极其重要的，和C端产品的研究用户竞争。
以上是我总结的一些不同类型的后端产品及其特点。 划分可能方向不同，有些可能重复，但都是作为一个单一的背景产品，具有鲜明的该类型特征，这也是我在平时工作中总结出来的它们的特征。 一套后台系统往往是复杂庞大的，单独作为一套系统来使用其实不是很常见。 把这些小块按照业务内容整合在一起，也是很考验产品经理能力的地方。
专栏作家
痴迷，微信公众号：痴迷启蒙，人人都是产品经理专栏作家。 电商O2O领域，专注于数字硬件、人工智能、新闻资讯领域。
