您是否喜欢在执行当前任务时解决工作聊天中的紧急问题而分心？ 我们认为不是！
想象一下一种情况：您正在开始一项任务，但是您却被聊天中的通知分散了注意力，在该通知中，您被迫要求您提供用户问题的帮助。 现在，您已经在进行积极的讨论，并且了解这是错误还是功能。
现在想象一下，除了您之外，这个聊天室还拥有整个开发部门，由80多人组成，每个参与者都参与了这些讨论。
有了我们在SuperJob的支持，任何无法理解的情况下的技术支持都会立即在Slack上闲聊，从而分散了所有参与者的当前活动。 因此，我们的测试部门试图改变使用用户bug的过程。
以前，处理用户错误的过程如下：
- 从用户那里收到的反馈，并已发送给技术支持专家；
- 一位技术支持专家发现了细节，但没有重现问题，而是立即在吉拉启动了一项技术支持项目任务；
- 任务被扔到了Slack的一个单独的聊天室中（顺便说一下，有6个这样的聊天室：关于申请人，雇主的问题以及针对应用程序中每个平台的问题）；
- 在聊天中，测试人员开始了这项任务，并开始理解，定位问题并弄清楚它应该如何工作。
- 除测试人员外，开发人员还参加了聊天并积极参与了讨论。
- 经过所有澄清后，测试人员将任务转移到所需的开发项目，更改名称并更正描述。
最后，事实证明，很多专家花了很多时间来一次讨论和仔细检查一个问题。 另外，任务说明并不总是让您快速了解问题的实质，因此您必须与用户打开技术支持对应关系，然后花更多时间编辑此任务。
许多问题不是bug，通常不应该提供给开发人员。 但是同时，开发人员已经参与了讨论过程，从而分散了他们的任务。
我们决定需要更改此过程，并使技术支持更加独立。
我们要更改
的第一件事是
摆脱测试人员对错误的双重检查。解决方案是这样的：我们描述了测试人员要进行的工作流程，对其进行了稍微的改动，然后将其交给了技术支持专家。 现在，当用户遇到问题时，他们必须进行检查。
简要描述此工作流程，现在技术支持专家会在启动错误之前独立检查需求，必须重现错误并将任务放入开发项目中。
如果情况没有重现，则该任务将在技术支持项目中启动，并“暂停”直到下一次用户联系。 如果有来自用户的新请求，则技术中心需要再次尝试重现问题，如果重现了问题，则将任务转移到开发项目中。
如果重复的投诉也没有被复制，那么该任务仍将被转移到开发项目中，并带有必须复制该问题的强制性评论。 也许在这种情况下，对于开发人员而言，他们将能够找出并解决问题。
因此，我们不会在单个调用上花费很多时间，只有在重复调用的情况下，我们才可以连接开发人员。
优点：我们节省了测试专家的时间，通常还节省了在聊天中看到问题并与澄清相关的开发人员的时间。
我们的第二个问题是
错误本身的
设计，名字不详，混乱，有时只是一个神秘的描述。
例如：
解决方案：通过示例，我们告诉并展示了如何使用“什么？ 在哪 什么时候？
例如，任务名称“来自“您网站上的作业”的问题”在处理后变得更加透明：“当您进入广播部分时，不会显示“您网站上的作业”块中的作业”。 发生了什么“麻烦”，只有名字才对每个人都清楚。
我们同意使用模板进行描述。 我们将它们添加到了Jira。 创建错误时，您需要根据平台选择所需的模板并将其填写。
所有信息都记录在Confluence的说明中，可以随时访问。
优点：在Jira中搜索错误变得更加容易，并且通过名称，您可以立即确定本质，而无需执行任务。 该描述已变得结构化，对开发人员更易理解。
第三个令人分心的事情是
有几个聊天室并提供技术支持。
解决方案：“更多聊天室！”我们决定只进行一次#support聊天，然后关闭其余的。 现在，所有内部员工都摆脱了发现的问题，只有技术支持人员在那里回答。 他们进行重新检查并开始任务。
优点：现在有一个入口点，您可以报告发现的问题。
以前，开发人员可能会看到某种错误，但根本不知道在哪里报告。 首先，您必须弄清楚哪个聊天要取消。 很难...因此，有些人根本不理会任何事情，而是将所有内容保持原样（好吧，或者特别是有意识的人被扔给了测试人员）。
但是，当然，实施此方法存在一些困难。 例如，技术支持专家无法始终正确地定位问题，无法确定问题是后端还是前端。 因此，存在在错误的项目或错误的团队中发现错误的风险，然后又失去了将任务从一个部分转移到另一个部分的时间。
错误的描述和名称中仍然存在错误。 因此，虽然有必要仔细研究任务以消除这些缺点，但是它们的数量并不是那么关键。
经过所有创新之后，我们的工作流程如下所示：
- 技术支持专家变得更加独立，他们无需等待测试人员仔细检查错误；
- 用户的错误在Jira中的启动速度更快，可以更早地进行开发；
- 测试人员和开发人员不会分散他们的工作；
- 开发人员现在可以
安排holivar在聊天室中就更有趣的主题进行聊天。
以及如何处理公司中用户的错误？ 分享您的示例：）