1990 年代的召唤，他们希望恢复错误报告流程

自互联网发明以来，软件开发已经改进了 100 倍，但人们报告错误的方式自 1990 年代以来没有改变。

你有过这样的经历吗？一位工程师拿起一张票，经过一番调查后，他们确定它在他们这边工作正常，并且他们没有足够的信息来重现该错误。他们在工单上添加评论，切换到不同的任务，并等待错误报告者向他们提供更多信息。

这个循环重复几次，每次工单中有新信息时，工程师都必须记住他们在何处停止并尝试继续讨论。像这样的上下文切换对工程师来说是痛苦的，典型的错误报告过程似乎是这种麻烦的典型代表。

虫子的真实生活

想象一下，一位同事在工程 Slack 频道中报告了一个登录问题，而几位工程师则放下一切进行调查。尽管他们尽了最大努力，但他们无法重现该问题。

他们要求提供更多信息，例如浏览器和设备的类型。然后他们指示员工尝试各种故障排除步骤，例如清除缓存和刷新页面。来回的异步聊天通常会消耗一个小时或更长时间。最终，工程团队不得不安排与该员工的调试电话，以尝试找出他们计算机上的问题。

在通话期间，员工共享他们的屏幕，工程师指导他们如何打开开发工具中的控制台和网络选项卡以了解发生了什么。最终，工程师们看到网络选项卡中出现 401 错误，即“密码不正确”。本质上，问题不在于登录被破坏，而是前端未能冒出“密码不正确”错误消息并将其显示给用户。一个简单的前端错误本应花费五分钟时间来识别和解决，却让几个工程师耗费了一个下午的时间。

是时候改变了

今天的错误报告过程仍然陈旧。自 1990 年代以来，世界发明了 Slack 等即时通讯和 Zoom 等视频通话，并在全球范围内采用了远程工作。错误沟通已经数字化。错误跟踪已从书面文件转移到 Jira 票证。然而，错误报告仍然充满了浪费工程时间的烦人的来回。

我们都经历过处理不明确的错误报告而缺乏解决问题的必要背景的挫败感。这就是为什么一年前，我们中的一些人开始设想一种更好的方法。如果我们可以构建一个新工具来使错误报告现代化并解决错误报告不明确的问题，减少来回沟通的需要，并节省工程师的时间和精力呢？

所以，这个想法果酱出生于。旨在使错误报告过程更有成效和效率的工具。我们想创建一个解决方案来帮助工程师解决技术错误，而不是沟通问题。

因此，我们着手构建一个工具，使任何人，无论其技术背景如何，都能捕获有关错误的丰富的上下文技术数据，以便工程师能够快速识别和解决问题。我们想创建一个工具，让工程师的生活更轻松，同时也帮助向他们报告问题的人也更有效。

当我们去年初开发和测试 Jam 时，我们看到了它在加快我们自己团队工作方式方面的潜力。例如 - 以我们自己的代码中的错误 Jam 为例。我们的工程师无需跳上实时调试电话，就可以直接从错误报告本身看出问题所在。

我们开始与其他工程团队分享 Jam，我们对反响感到非常兴奋。 Ramp、T-Mobile 和戴尔是 Jam 的早期采用者，他们提供了宝贵的反馈，帮助我们塑造了产品。根据他们的反馈，我们现在可以自豪地说 Jam 拥有超过 14,000 名用户并且还在增加。

但我们的工作远未完成。我们知道错误报告过程可能是让工程师感到沮丧的一个主要来源，我们致力于改变这一点。如果您厌倦了不清楚的错误报告，我们邀请您试一试 Jam 并告诉我们您的想法。我们的使命是为工程建设更美好的未来，我们需要您的反馈来实现它。您可以通过 [email protected] 私下联系我，加入我们的旅程。