加载项被禁用了怎么办，软件被禁用了怎么解除

B端产品设计最常围绕增删改查、展示、计算、提交、业务流程展开，而增删改查是原型设计的基础。 “删除”数据的方法包括删除、失效、作废。那么，你用什么样的逻辑来做出选择呢？这篇文章的作者分享了自己的观点，一起来看看吧。

今天的文章不是很长，但却解决了最近反复讨论的一个问题：“删除”数据的方式有删除、禁用、禁用，但我想表达一下我个人的选择背后的逻辑是什么？观点。

01 数据删除逻辑两年前写过一篇文章《增删改查显算传，七字箴言搭建ToB系统底层框架》，到目前为止我就直接引用，方便读者理解。

如果存在新的数据路径，您需要将其删除。一般来说，删除有两种类型：

物理删除：实际删除。数据从数据库层面删除，查询找不到数据，数据无法恢复。一般情况下，不建议对敏感底层数据配置删除功能。此外，设计应避免软删除（意外删除，即仅从页面中删除数据，并且数据库重写数据的状态）。您可以使用产品设计中常用的删除后召回和数据库备份和恢复。前后数据业务关系太强，无法设计删除功能。那么数据应该如何合理处理呢？我个人理解存在删除要求可能包括以下几种情况：

过时的无用信息：可以根据实际业务情况和指定条件，设计数据库定时任务，定期清理垃圾数据。这适用于大量数据输入错误的情况。使用数据逻辑删除和编辑功能。如果需要改变状态或者停止营业：使用字典状态来限制。虽然本文对删除逻辑和范围的理解仍然有效，但缺点是对具体使用场景的描述不够详细。下面介绍一下适用场景以及删除、禁用、禁用的区别。

02 移除、禁用、禁用的适用场景1. 移除的适用场景根据尼尔森的10项可用性设计原则，系统应该提供undo功能并且必须提供undo功能。手动输入每天频繁添加的数据可能会导致错误。从体验角度来说，系统应该允许数据删除。

删除分为立即删除（提交信息后toast中提供撤消和重做选项）和后续删除（列表或详细信息中提供删除功能）。

立即删除通常用于发布轻量级信息，因为内容简单，发布后信息的整体印象仍然存在，并且从技术角度来看与业务的联系较少。回滚数据也很困难，并且不太容易出现错误，例如立即调用刻度列表注释。

这里的撤销是逻辑删除，并不是从数据库层面删除数据，而是将数据从已提交、不可撤消状态更改为可编辑或已提交状态。

1）删除轻量级信息——将立即取消

在后端系统设计中，删除后通常与列表同时发生。

这里有几点可以讨论。为什么删除按钮在列表页而不是详情页？至少一件事是详情页删除不能满足您的批量删除需求。

2）删除电商后台数据列表——

综上所述，删除除了高频次新增场景外，还必须满足一种场景：非核心、低耦合的数据，而不是“作废”或“作废”。

Tips: 如果删除数据是一个有风险的操作，在确认过程中可能会看到二次弹窗确认（提示删除后无法恢复、提示删除后的效果）、高亮文字等，也是有必要的提供警告。

2、失效的应用场景数据不再有用、无法再被其他运营商引用、无法删除怎么办？可以使用“禁用、停用、禁用”功能来控制数据有效性和可见性。

例如，为了保证准时交货，我们公司采用的是销售和采购为主的业务模式（库存是根据客户订单购买，而不是提前采购），下单后自动触发定时器。 我们正在招聘。采购订单的。

然而，当在数据库层面进行删除操作时，难免会出现客户暂时取消或修改订单的情况，从而导致重复购买。

所以我们最终采用了作废的形式，标记为作废的订单对指定人员是可见的，并且可以通过特殊的业务链接进行注销。我对金融体系的参与并不深，所以这应该与账单上的红色标记含义相同。

另一个例子，Oracle 有一个设计，允许您禁用物料分类。这也是由于业务耦合度较高，需要保留信息，但不适合后续其他业务参考生成新信息。数据。

综上所述，如果您的业务耦合度较高，数据变更影响其他业务且必须保留，您可以通过“失效、去激活、失效”的方式删除数据。

3、失效的适用场景与失效类似。区别在于是否有明确的数据失效期限。

例如，员工帐户在权限控制的整个生命周期内进行管理。这是因为员工解约有明确的时间节点，发生在未来，并且在解约发生之前账户必须保持可用。

删除或禁用是不合适的，因为它需要即时操作，并且对时效性要求很高。另一方面，忘记它可能会影响其他相关数据。员工未支付的工资等（删除）。

另一个例子，Oracle确定材料的保质期，以确定它们是否可供其他企业报价。对应的场景是，在B端商业业务中，所有商品或产品的线下价格调整都是有计划的。按时失效物料，方便采购和仓库人员提前规划物料管理。

这同样适用于价目表，以控制其整个有效期内的数据显示。

综上所述，基于失效，如果你的数据有明确的过期日期，你可以通过调整过期日期来提前规划或“删除”它。

03 “停用”组织是否意味着停用个人账户？这个问题的背景是一位学生关于组织结构中“超越”职能的问题。这里的禁用是否意味着禁用组织结构内的员工帐户，使其无法访问系统？

这个问题其实暴露了两个不理解的业务场景和产品设计原理。

读完冯仑的《野蛮生成》（点击看阅读笔记）后，我对建立公司的组织架构有了一些想法。当时，我把这句话写在了读书本上。我当时在想组织架构的变化会给公司带来什么影响，现在我发现我的理解是错误的。组织是为了实现目标，人群行为管理也是为了实现目标。因此，要站在更高的层次思考，有必要研究企业目标变化对企业组织结构和人群行为的影响。

在Oracle（我没有机会了解完整的Oracle产品，它太大了，只是通过我参加的Oracle培训课程），OMS产品组织被称为库存组织，HR组织和业务实体我们。我们将其分为四个主要类别。相当于财务会计的就是收入和成本数据。

在我遇到的B端产品设计中，组织架构的成本和利润组织的划分是严格按照公司的战略目标来规划的，当目标发生变化时，分配也会发生变化。随着组织内部资源的相应调整，组织结构也会发生增减。 （问题中的学生提出的“禁用组织结构”实际上是不正确的。组织结构的变化通常是有计划的，不是突发事件，因此应该禁用组织结构。）是的。）

即使组织发生变化后，组织内部发生的成本和收入仍然会进入会计系统，因此人员也是成本的一部分，数据自然需要保留在系统中。

因此，组织内部的人员会被调到其他部门或者离开组织。因此，组织内的个人账户必须由其所属组织修改。否则，您的帐户将被停用。

回到产品设计本身，我们有一次只做一件事的原则，产品架构的设计要坚持低耦合的原则。

一个组织的失败就是冻结该组织的相关数据。冻结的前提是组织内的有效数据和账户必须迁移到其他组织或同时禁用。这个“先决条件”是禁用组织和禁用个人帐户必须分开进行。

到目前为止我已经写了这篇文章，但可以总结如下。

对于频繁添加的数据或者非核心、耦合性差的数据，可以使用删除功能。如果您的业务耦合度较高（数据变更影响其他业务，必须保留），请使用Invalidate、Deactivate、Revoke。删除数据。基于失效，如果数据有明确的过期日期，可以通过调整过期日期来提前规划或“删除”数据。本文最初发表在@RaRa 的《人人都是产品经理》上。它禁止未经授权的复制。

标题图片来自unsplash，基于CC0协议。

本文观点仅代表作者本人观点。人人产品经理平台仅提供信息存储空间服务。