所以，我在一个相当小的 IT 部门工作。我们有大约一半的最终用户使用的故障票务系统。我的一些同事并没有真正鼓励我们的最终用户使用我们现有的系统。最终结果？经常中断，因为最终用户会通过 IM 联系我们或直接来我们的办公室处理琐碎的事情。这显然会使编写代码变得困难。
现在，我想我可以说“嘿，你介意下次填一张故障单吗？”，但那样我就会成为坏人，因为其他人不会这样做。我也不希望最终用户觉得我难以接近。我只是想让他们明白寻求帮助的正确方法。
那么在这种情况下，对我来说最好的做法是什么？
【问题讨论】：
标签： end-user bug-reporting trouble-tickets
让它有吸引力。
向用户提及，整个开发团队都会查看故障单问题，并且发现可以更快地得到解决。假设任何没有票的东西都有可能在洗牌中迷失方向。为他们提供面向外部的链接，以便他们可以查看进度和开发人员/支持 cmets 在他们的工单上。提供电子邮件提醒，让他们感觉自己是流程的一部分，并获得有关问题的即时信息。
让它尽可能顺畅。
使系统的用户输入部分尽可能易于使用和直观。没有人喜欢填票，我当然不会为了这样做而费尽心思。无需登录，无需登录，只需输入我的问题和联系信息即可。
与您的团队交谈。
最终，除非您的团队和您在同一页面上，否则在上述系统上付出的辛勤工作将变得无关紧要。召集团队会议并与他们讨论这个问题。在你的老板在场的情况下，试着用他能理解的方式来表达。提及浪费的宝贵时间、跟踪系统中不存在的客户问题等问题。
【讨论】：
听起来你的经理让你失望了，因为他没有强迫用户在获得帮助之前提交工单。问题从那里开始，并且只会持续到您的同事允许这种行为。我们在工作中使用 redmine 来提供应用程序支持，并且在告诉用户“提交工单，我们会调查它”方面取得了良好进展，但它必须是所有相关人员的一致声音。
【讨论】：
对他们使用一点心理学。对于不发送故障单的人，提醒他们，他们部门 80% 的人使用票务系统。即使是谎言，也会因为跟风效应而鼓励良好的行为。请记住，这个人与人口统计数据越相似，就越有可能影响他们的行为。所以“你的直接同事”会比“整个公司的人”工作得更好。
使用票务系统的人应该得到一颗金星，不，说真的。
2 月份的《哈佛商业评论》中有一篇非常简短的文章，内容是关于利用社会压力影响行为。它讨论了一些新的研究，但文章没有包括参考资料。
【讨论】：
你没有。用户甚至我都讨厌那些东西。相反，您的政策应该是“不要让我思考”。你必须自己收集所有你需要的东西，并以对你的用户不可见的方式自动处理。在他们选择安装后。
【讨论】：
除非您说服您的同事首先使用该系统，否则您可能不会取得太大进展。在大家都同意所需的流程之后，您就可以与您的用户交谈了。如果您团队中的每个人都遵循相同的规则，您可能会强制您的用户使用系统，方法是让未进入系统的问题的周转时间变慢，甚至可能完全忘记它们。
但是，即使您可以说服同事和用户输入票证，您仍可能会发现票证不完整/信息不完整。我们都看过很多票，比如“功能 X 坏了，请修复它”，但没有提供其他信息。根据您每天获得的票数，我可能会硬着头皮走过用户，亲眼看看他们的问题是什么。
【讨论】：
在这种情况下，我们经常代表用户记录票证。
【讨论】：
在我以前的工作场所，有人告诉我，没有故障单就什么都做不了。当我问为什么时，我被告知支持团队的生产力是通过使用故障单来衡量的。这迫使我使用故障单（因为它们是必需的），并给了我这样做的动力（我不想让我的同事看起来很糟糕）。
在我的新工作场所，所有技术支持都外包出去了。我真的必须打电话给技术支持，他们会代表我创建一张票。
【讨论】：
另外 - 停止鼓励这种行为。使用您的 IM 过滤选项仅在线显示给开发团队。不要检查您的电子邮件 - 或设置过滤器将高优先级的内容（您的老板、您的开发团队）过滤到您的收件箱，并将其他所有内容过滤到您每天或每隔一天检查一次的文件夹中。
【讨论】：
Simucal 的建议很好。在某些时候，您 - 将 - 必须告诉他们“提交票证”。如果你事后问他们，他们不会在意，因为他们得到了他们需要的东西。
解决此问题的一个好方法是让专人提供支持。我的团队这样做了，它极大地提高了我们的生产力，并消除了至少 90% 的中断。
除此之外（或替代），您可以每天轮换谁来处理用户请求。这样做的结果是或多或少需要一张故障单。当其他人开始处理请求时，它需要跟踪请求中发生的事情。随着时间的推移，这也为您的流程带来了更多的凝聚力：人们创建小脚本来执行常见任务，完成的工作被转移到修订控制中，等等。
【讨论】：