在当今世界，需要能够最有效地满足各方利益的应用程序。 通常，这是使用各种限制来实现的。 例如，它们不允许用户执行对自己或系统所有者不利的动作。 在这种情况下，有必要使这种限制引起的不适最小化。
例如，系统所有者需要反馈表中+7（）--格式的电话号码，以便进一步自动化使用。 为了方便用户，最好在提交表单时不仅使用提示或验证，还应使用输入掩码，以免以错误的格式输入数据。 事实证明，狼满了，绵羊完好无损。
在某些情况下，系统会限制用户以防止潜在损失。 因此，例如，就像开车前系好安全带一样，在在线支付服务中，您不仅需要输入卡中的数据，而且还需要通过SMS消息中的代码来确认付款，这大大降低了偷钱的可能性。 应当指出的是，这种对用户安全的关注对于服务所有者来说是有益的，因为它降低了声誉风险，否则可能会像在Alexei Apukhtin的工作中那样出现：“ ...他是偷了还是被偷了...主要是他参与其中。讨厌的东西...”。
因此，在开发应用程序时，有必要考虑一下功能，以取悦直接客户和普通用户。 考虑到这一点，可以区分五个级别的系统限制：
- 没有办法限制用户 ，也就是依靠用户不要犯错误并且不会损害自己或系统所有者。
- 部分限制 -用户可能会犯错，但可能性较小（或不太严重）。
- 引入必要的限制 ，但不要过多-用户受到限制，以至于他不会犯错，但是限制不会在使用系统时造成问题。 这是一个理想的选择。
- 没有必要限制 -用户受到限制，以防止用户使用系统。
- 完全限制用户 ，即阻止该功能。
对于第一层和第五层，一个熟悉的例子是一个熟悉的情况，当收银员在商店里大喊“加利，取消！”，而全能的加利来进行救援。 在这种情况下，收银员已完全阻止了从支票中取出打孔商品的功能，而Gali对此操作没有任何限制。 也就是说，这些限制程度通常可以用作角色模型实现的一部分。
在我们不讨论极限的情况下，系统会创建一个中间选项。 然后，任何项目的重要任务是引入所有必要的限制，但不要过多（第三级）。 因此，例如，不是在填写申请的每个阶段填写验证码（第四级），而是在发送完整表格之前。 或者，以便电话输入字段不仅包含输入掩码（第二级），还包含用户已输入11位数字的检查。
我们举一个例子。 我们有一个项目来开发一个与收集过程一起使用的应用程序（以下称为收集器软件）。 作为该项目启动的一部分，我们起草并就职权范围达成了一致，然后完成了分析师的大部分工作。 值得注意的是，客户是一家刚刚开始追收债务的公司，也就是说，后来证明，该过程仍处于调试阶段。
就在那时，当该项目的开发工作已经进行了大约六个月时，就收到了有关该系统潜在用户的工作功能以及计划中的改进的新信息。 应该立即注意到，那时我们执行了以下功能任务，包括：
- 分配任务打电话给债务人；
- 分配任务的执行；
- 确定交互的结果（由用户手动）；
- 确保遵守俄罗斯联邦关于与债务人互动的频率的法规的要求1 。
让我们澄清一下，列出的最后一个功能如下：收集器软件限制了分配可能违反法律要求的任务的可能性。 在这种情况下，如果无法接通（用户设置相应的呼叫结果），则任务被推迟，操作员可以稍后返回。 也就是说，失败的拨号尝试不能被认为是一种交互，您可以尝试再次完成任务。
有关用户体验功能的知识是什么？ 事实证明，如果尝试无法成功到达债务人的移动电话，则操作员不仅会推迟任务，而且如果将其他任何号码分配给债务人，也会立即尝试到达他们。
鉴于时间紧迫，将分析师重新投入到项目中是不切实际的，因此我们的质量保证专家承担了考虑现有实施与计划如何在客户端使用该应用程序一致的任务。 在分析过程中，我们构建了以下逻辑链：
- 债务人可能有多个号码（移动电话，家中电话，公司电话），但是您可以将呼叫安排为仅一个号码。
- 如果操作员无法联系到客户，则该任务将被推迟，但仍然无法拨打另一个号码，因为 待处理的任务也将阻止呼叫其他号码。
- 因此，为了尝试达到另一个号码，用户需要手动取消挂起的任务并分配一个新任务。
- 但是同时其他号码可能无法接通。 事实证明，由于缺少拨号而推迟了任务，但是却被取消了。 您需要再次任命他们，以便稍后再次致电。
应该注意的是，根据来自客户的信息，实践中不成功的拨号尝试经常发生。
此外，计划开发一种功能，用于将Collector软件与用于事件自动指定的分析系统（以下称为ASANM）集成在一起，该系统是在客户端创建的。 其实质如下：
- 每天（每天一次），ASANM会根据合同形成必须执行的任务列表，并将请求发送到收集器软件；
- 软件从接收到的列表中收集器分配那些不超过交互限制的任务。
根据质量检查专家的结论，在现有实施中，运营商和ASANM都无法安排呼叫所有债务人号码的电话。
通常，人们了解到已实施了第四级限制（不必要的限制）：要拨打其他号码，您需要手动取消挂起的任务。 实际上，事实证明，法律并没有限制与债务人联系的尝试次数，而是限制了成功的互动尝试次数。 这意味着应该根据任务的结果来计算交互限制。
在这方面，我们启动了实施格式的更改，并选择了一种更为便捷的方式来满足要求：
- 根据活动结果计算互动次数；
- 如果未达到限制，则允许用户/ ASANM安排事件不受限制；
- 如果达到限制，则取消不必要的事件并禁止其任命。
进行更改花费了整个时间，但是我们可以肯定地说，这次并没有白费，现在由于普通用户在应用程序中工作时不会遇到任何麻烦，因此系统所有者将能够计划使用ASANM的操作员的工作。
结论
建议所有在实施限制时关心用户和客户的人都遵守两个简单的规则：
- “有了足够的保姆，孩子就不会失去视力”-也就是说，您需要充分保护用户，避免犯可能损害他或系统所有者的错误。
- “怕狼，但要去森林”-必须避免不必要的限制，因为否则会失去开发产品对用户的价值。
1要求由《联邦法律》（2016年3月7日）N230-“关于在进行归还逾期债务的活动时保护个人的权利和合法权益以及对联邦法律进行修订”“关于小额信贷活动和小额信贷组织”的规定。