一、认知后台商品

后台商品，单纯而言是后台控制系统商品，主要是用作支撑力小流程、APP等后台商品，且一般来说是面向全国民营企业外部雇员的，如常用的文本实用性后台、课程表后台等。上面主要就透过论说后台商品与B端商品、后台商品与后台商品的差别，来更深入细致的认知后台商品。

（1）功能定位相同：后台商品主要就用作全力支持后台，多为另有；B端商品用作为两个金融行业情景提供更多化解的全销售业务流程计划，多为民用。总之在这类情况下，可能将会把后台“后台化”，升级换代为B端商品，用作贩售。

（2）覆盖范围相同：从商品牵涉到的覆盖范围看，后台商品基本上指的是后台控制系统的有关计划及结构设计；B端商品依照金融行业及顾客市场需求相同，可能将须要提供更多其间台其中的商品服务项目。

（3）使用者不同：后台商品多为另有，使用者多是子公司外部雇员；B端商品依照销售业务情景相同，既可能将是顾客民营企业的外部雇员，也可能将是顾客民营企业的使用者。这也下定决心了二者的。

（1）职责相同：后台商品主要就用作全力支持后台的机能同时实现；后台商品则用作间接服务项目其商品的最终目标使用者。单纯而言，后台是脸面，后台是松井。就跟T台上的备受瞩目有赖于手舞足蹈的辛劳牺牲。后台多样的机能可视化，也有赖于后台控制系统的全力支持。

（2）使用者相同：后台商品的使用者为子公司外部雇员；而后台商品面向全国的则是子公司商品的最终目标受众。

验等要求不高，人员有限的项目组后台商品可以间接不经由结构设计人员的页面加工美化。相比之下，后台商品间接面向全国使用者，除了基本上的销售业务流程和逻辑外，。毕竟使用者用着不爽可能将立马就转向竞品的怀抱了。

二、后台商品的象征意义

通俗来讲，后台商品页面上的数据、文本大多数情况下都取自后台。淘宝上看到的形形色色的商品，包含着商品的名称、价格、介绍图等，这些都不是凭空而来，而是运营利用后台系统进行文本实用性的结果。所以，牵涉到后台控制系统时，往往有赖于数据的“增、删、改、查”。

后台商品作为后台商品的支撑力，须要比后台多想“一步”，从而为全力支持未来后台销售业务的变化提供更多更大的可能将性和灵活性。

互联网机会转瞬即逝，后台只有具备足够的灵活性和可拓展性，才能避免后台销售业务机能迅速更新迭代时，不受“僵硬”后台的牵制而错失机会，影响销售业务发展。

可见，只有熟知销售业务，并对未来销售业务发展有一定的预判，在后台结构设计中预留适宜的“口子”，才能避免后台销售业务发展受后台牵制，为未来发展赋能。

三、六大结构设计准则

由于工作须要，为全力支持后台商品机能，笔者页接触并参与结构设计了各种各样的后台商品，包括课程表控制系统、商品控制系统、活码及各类文本实用性控制系统等。在做了这么多后台商品后，笔者抽象出了以下后台商品的六大结构设计准则。

独立的才是灵活的，才是可扩展的。这里可以借用开发人员常用的两个概念——模块化，来认知独立性的象征意义。

单纯而言，模块化是指在化解两个复杂问题时，自顶向下逐层把控制系统划分成若干更好的可管理模块的过程。模块间独立性强，既可独立运作，又可灵活组合，能够达到1+1＞2的效果。

如何合理模块化，抽象出独立的控制系统模块？

独木难以成林，两个好的商品应当是两个生态控制系统，他们互相连接，迸发出更大的价值。

相互独立的控制系统之间应当透过某一共有对象间接关联或透过映射关系间接关联。

相同控制系统之间的相同组合模式，才能增添真正的灵活性，满足相同销售业务情景的市场需求。他们不能在每一次销售业务情景有变化时，都去对后台大刀阔斧的调整。合理对控制系统进行模块化，并予以关联，能够让他们游刃有余地应对一些情景的变化。

以电商后台为例，商品控制系统、优惠券控制系统、活动控制系统以商品或商品类型等相互关联，运营就可以在相同促销场合下，对相同的商品灵活创建相同的促销活动，提供更多相同的优惠计划。如果只给某几个商品做一次促销活动，或许两个控制系统就可以把文本实用性完成，但若想进一步满足相同促销情景下的相同优惠计划，独立的控制系统相互链接才有更多的灵活性。

后台设计的两个关键文本是字段的创建。在创建字段时，须要全面考虑后台销售业务情景中可能将牵涉到的字段，不可出现缺漏的情况。这些字段是透过总结归纳，提炼出共性，进行合理抽象后的结果。抽象的目的，是为了用最单纯的结构和字段涵盖最大可能将性。

以课程表为例，题目中有“考点”、“难度”、“推荐答题时间”等题目属性，但相同项目的题目所包含的属性相同，如何对各种各样的题目属性进行抽象以满足相同项目的市场需求呢？笔者借鉴统计学中定类、定序、定距、定比的数据类型，将题目属性分为四种类型：分类属性、序列属性、字符属性、数值属性。在创建项目时，可先为项目所对应的课程表创建所需的题目属性，这样相同项目的课程表都可以设置选用相同的属性。

层级？相同数据之间是否关联？如何关联？在结构设计后台控制系统时，须要多与后台开发人员讨论数据结构，理清数据的流转可视化关系。

以教育商品中常用的教材同步习题为例，教材与教材之间是并列关系，教材下包含了章，章下又包含了节，而节下又包含了一定量并列的题目。为了初始化时给使用者的推荐更精准，教材又可能将透过教材年级与使用者的年级有关联。

后台销售业务会随着对使用者洞察的深入细致等不断发生变化，没有两个产品会一成不变。后台作为支撑力后台销售业务的重要支柱，须要全力支持后台销售业务的变化。

但是后台作为架构性的支撑力，其调整变化常常会牵涉到逻辑、数据等的调整。因此，在进行后台结构设计时，一定要长远思考，尤其是牵涉到数据结构、逻辑等部分时，要为销售业务未来的发展留有可拓展的余地。一句话：后台简，后台活。

以笔者所结构设计的课程表为例：由于是从0到1的新销售业务，第一期的刷题小流程只须要满足刷题机能即可，不须要显示类似“难度”、“推荐答题时间”、“考频”题目属性等次要机能，但后台商品未来规划中必然会牵涉到这些文本。因此，哪怕第一期的后台小流程并不会展示以上有关文本，但是在课程表控制系统第一版中就应当加入这些字段。总不能让运营录完题目上线后，再单独录一次题目属性吧？

他们常说“事事有回应，件件有着落”，两个好的后台控制系统也应当如此。使用者在操作完毕后，一定要有所反馈。依照相同的销售业务情景，这里的反馈可能将包括：操作成功提示、操作失败及原因提醒、下一步操作指引等。

此外，后台销售业务销售业务流程复杂，同一事物在相同的环节下，可能将存在相同的状态，这种状态随销售业务流程的变化也须要及时、清晰的予以展示和反馈。

比较常用的例子是商品后台中商品的上下架状态变更。再以课程表控制系统为例，题目创建成功后，须要提交审核，审核状态及审核结果都应当予以反馈。

一旦操作有误，就很有可能将会对后台使用者体验增添很大影响，甚至会影响子公司利益。人非圣贤，很难保证不犯错误。这种情况下就须要从技术上设限，以避免误操作增添的不良后果。

以电商后台为例，商品价格设置错误会间接影响到使用者购买，因此，在价格设置中，类似于“原价应大于现价”、“价格不得为负”这种机能限制是必要的。再以课程表控制系统为例，在录入真题时，题目的题干、选项等不能为空的文本，须要限制使用者必须规范填写后，方能成功提交。

后台是给子公司内部人员使用的，往往牵涉到大量的文本、信息的输入及实用性。因此，一定要充分考虑情景，提高操作效率。对于高重复率的工作一定要尽量让计算机取代人力。

另一方面，后台控制系统充满各种逻辑和销售业务流程，尤其是复杂销售业务，因此如何让后台操作起来更单纯、更好认知也是一门大学问。清晰简洁的文案、必要的注释提醒、合理的销售业务流程划分、编写操作文档和培训等都十分必要。

举个例子，课程表的题目录入情景，一般来说是运营将老师整理好的word文档中的题

本文由@ 卷心菜 原创发布于人人都是商品经理，未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。

该文观点仅代表译者本人，人人都是商品经理平台仅提供更多信息存储空间服务项目。