编者简介：虽然后台系统非常重要，但由于其低性价比，很少受到足够的重视。本文简要介绍了后台的概念、类别、设计方法要求和注意事项，回答了“我应该成为后台产品经理”的问题，并推荐对后台系统设计感兴趣的朋友阅读。

事实上，作为一个后台系统是非常重要的，它可以更好地提高系统架构的能力。关于如何提高应用程序一端性能的讨论很少，但在后台这样做是不合理的，因为讨论应用程序两端性能的人不多。虽然它可以提供效率并降低成本，但在许多情况下它并不被重视。

最近，我又开始从事数据背景工作。我很纠结。经过思考，我只是分享了一些作为背景工作的简单经验，希望能启发你。

实际上，有两种方式可以在背景中理解：

一种是最常见的解释，这意味着这是面向内部用户的产品或服务，例如打开操作后台所指的后台；

一个是专业角度的背景。例如，后台产品经理指的是后台系统的产品经理。这里的后台系统不仅包括操作界面，还包括信息流和业务流，这些信息流和业务流在很多情况下可能不会反映在界面上。

比如电子商务物流，当你买东西的时候，你知道商家会打包并委托快递公司进行运输和配送。这个业务流程在任何界面中都是不可见的，但我们都知道这个流程是这样的，它也是后台系统的一部分。

我认为里面的后台实际上更倾向于，所以第二种解释是，这是产品经理应该认识到的后台。

当然，如果你和商业人士谈论背景，它指的是界面含义的背景。我们今天讨论的内容也与界面的背景有关。

一般来说，背景分为两类：功能背景和数据背景。

为特定人员操作和使用提供功能背景。它会影响应用程序端显示的内容和服务。数据后台用于查看特定人员的数据。主要是统计和反映企业的经营情况。

事实上，对于一家公司来说，这两种背景是必要的。

事实上，后台的设计也需要遵循产品设计理论，通常根据使用对象和功能类型进行聚合和分类。

我们先来讨论一下背景函数。

职能背景一般按照内部部门的划分列出各部门需要使用的职能。例如，运营部门需要在应用程序内操作各种资源位（横幅和图标）的配置，因此必须有一个单独的运营管理模块。

然后，应用程序上资源位的位置（主页或我的）和资源位的类型（横幅或图标）会有所不同。你是如何设计这种架构的？是否根据应用的位置将其划分为多个辅助页面？还是根据类型分为横幅和图标？还是按照统一的框架进行设计而没有区别？

这是不同的。不同的分类逻辑决定了如何设计架构和接口。一般来说，根据类型区分或不区分分支是合适的。根据职责和重要性，某些职能可能涉及同时使用多个部门。一般来说，这取决于谁更多地使用此功能。

例如，一些公司会将付费送货放在营销部门，将免费送货放在运营部门（通常是其他内部产品送货或服务）公众号但就功能而言，它通常被放在营销部门的模块下，因为事实上，这个功能对营销部门来说更重要，最重要的是营销部门正在使用它。

数据背景比函数背景更容易处理。通常根据各部门的数据需求进行处理。

当然，如果你从产品的角度来规划，你可以先根据每个部门的指标和业务环节来拆分设计。然而，根据我的经验，最好是根据各个部门的需求进行设计，因为每个人对查看报告都有不同的想法，细分程度和特殊要求仍然非常不同。没有必要制定自己的计划，这是不适用的。

数据背景根据集市将表格设计分为各个部门是可以的，但需要对数据的可靠性进行大量验证。

首先，我们需要确保统计口径是正确的。这个词的定义不应有歧义。第二是在每页上添加统计口径的描述。在某些情况下，会出现相同的统计字段，但统计口径不同。这次你看字段名这不管用。如果你不解释，你就无法分辨。使用它的人会觉得有问题。最后，我们需要根据细节检查统计数据是否准确，并检查数据。

这是一项非常细致而繁重的工作，实际上很麻烦。如果公司流程合理，预留了足够的测试时间，数据将在测试环节进行验证。如果测试链接无法验证或没有剩余时间，将直接发布，然后在线更正数据。

事实上，如果是在一家小公司，满足后一种情况的可能性将非常大。商界领袖走上前来询问他们明天是否可以去。没有理性的概念，也没有必要纠结。如果技术可靠，问题就会少一些。如果不是很可靠，就会有很多问题。

我最近的经验是，我开发了2天，并间歇性地修复了3天的错误。感受一下。

1.后台使用方便

因为它是内部使用的背景，事实上，许多小公司并不太注意背景的可用性。界面丑陋，使用困难，模块划分不明确。如果遇到这种情况，可以让技术选择一个好的框架，并在开发时注意干净的页面和清晰的布局。

我遇到了这种情况。整个背景界面扭曲难看。

2.尽可能少的后台

我的公司有六个后端功能。要更新应用程序版本，您需要同时登录三个后端功能来修改数据。这真是太棒了。如果有条件，尝试将它们组合成1-2个背景，或者在设计时不需要将它们分开。

但这并不是将它们结合在一起的最佳方式。例如，如果涉及电话营销系统，系统本身非常复杂，只有电话营销部门才能使用它。在这种情况下，它可以单独用作背景。

从实际情况来看，由于成本高、周期长、风险高、绩效改善难以估量，在公司层面很难通过，因此合并背景是不现实的。我做了一个背景合并。我开发了3个月，间歇性地修复了2个月的错误。太可怕了。

因此，如果领导没有提到这一点，尽量不要采取主动，因为很难在绩效方面给你额外的分数，甚至降低分数。

3.权限设计应合理

设计权限有两种方法：

一个是基于职位设计。不同职位的权限不同，同一职位的权限相同。这种方法的优点是，在设置一次后，新员工只需挂断部门的电话，就可以获得权限。更适合大型企业，功能清晰，变化少；

一种是根据用户选择。每次来时，都需要配置权限。其优点是非常灵活，适合初创企业。一切都在变化，人也不多，所以需要这种方法。

可能需要注意的是，权限可能会在页面中细分。例如，页面上有一个导出按钮。一些公司有详细的要求，他们还将对此导出功能拥有单独的权限。

一些公司将制造和销售钉子系统的组织结构也可以相互关联。扫描登录后，安全性也很好，产品经理不需要设计权限系统。

4.分类应合理

这相对容易理解。它通常基于部门和职能的组合。

但是，必须注意的是，最好不要在一个背景中混合使用数据和函数。并不是说在实施中存在问题，而是会导致分散在不同的地方，使用不方便的问题。而且许多公司都有独立的Bi系统，这将导致双方都有数据，但双方不一定都是对的问题，这更难处理。

然后我们必须注意对原有功能的适应。

在很多情况下，不是添加新功能，而是优化和添加原始功能，这涉及对原始功能的调整。如果未提及该产品，该技术可能不会进行额外处理。建议在提出需求时提及适应问题。

我最近的经验是，我在原来的功能上添加了一个新的功能点，但在技术发布后，没有给出任何解释。直到业务部门观察到数据，我才知道。我需要更新并保存新函数才能生效。我真的接受了。我没处理好。我连描述都没有。

5.最好有一本后台功能手册

因为总是有新人来，一些功能可能会被更新。如果没有记录，他们每次都会询问产品经理。最好写一份说明文件，让所有部门检查并使用。

当然，我也知道有些同事喜欢在不看文件的情况下问你，这也很烦人。你可以根据情况处理。如果关系还可以，你可以说出来。一般来说，你可以告诉他文件中有，你可以自己查阅。

最后，我们来谈谈这个问题。也许有些朋友有点困惑。

在这个问题上，每个人都有不同的看法，但我们认为判断的标准是可移植性是否良好，即您的经验是否可以被其他公司使用。如果不行，那就行不通了。如果是这样的话，它就会起作用。这实际上与产品经理的类型无关，主要考虑到经验和技能的可移植性。

例如，在电子商务中执行仓储合同的产品经理属于后台产品类别。目前，这样的产品经理仍然很受欢迎，经验和技能的流动性也很好。这种产品经理需要考虑系统如何与现场人员互动，实际上测试经验和洞察力。核心是优化流程，提高效率。没有足够的经验是不可能做好的。

在大多数情况下，在后台工作是一件重要的事情，但这对表演来说并不划算，所以在大多数情况下，我们无法将大部分精力投入其中。在设计时，尽量设计更好的架构，然后在框架中进行设计。如果不需要改变，它将涉及历史功能的调整。事实上，这很麻烦。

这就是我今天想说的。我希望它能激励你。

本文最初由@productpersonXuanqing发表。每个人都是产品经理。未经允许不得转载

图片来自unsplash，基于cc0协议