Process 缺陷跟踪和帮助票证集成应该如何进行？

我对诸如FogBugz之类的bug跟踪系统有一点经验，在FogBugz中，帮助通知单的问题是（或可能是）bug，我对在内部使用完全独立于帮助中心系统的bug跟踪系统有一些经验

我的问题是，在一家拥有现有（自主开发的）帮助中心系统的公司中，如果无法替换它，那么如何将错误跟踪系统（可能是螳螂）集成到流程中

现在，问题、问题等的帮助通知单会被提交给相应的人员（PC技术人员、帮助台工作人员，或者如果是他们无法在帮助台解决的应用程序问题，则会被分配给开发人员）。用户可以在帮助通知单中请求对应用程序进行小的修改或修复，分配给它的开发人员将在某个时间点进行更改，将他们的时间应用于该通知单，然后在该通知单投入生产时关闭该通知单

我们目前还没有bug跟踪系统，所以我正在研究集成bug跟踪系统的最佳方法。如果是一个bug（或问题或功能请求），我们是否应该将帮助通知单放入bug跟踪系统，如果不是紧急修复，则关闭通知单？我们可能不想向任何其他人公开bug跟踪系统，因为他们不知道在帮助中心系统中放置什么以及在bug跟踪器中放置什么。。。对吧?

---

有什么想法吗？建议？提示？建议？待办事项？不做？等等。

在帮助台系统上有一个“升级到bug”按钮，该按钮在bug跟踪器上发布问题单，并提供适当的参考信息。

这是针对最终用户报告bug的生产系统，还是针对QA期间的问题解决

如果是前者，一些现场人员应该对帮助台记录进行分类，并只作为一个bug记录真正的bug

如果是后者，则根本不应集成。

好吧，这是一种折衷

我们使用不同的系统来处理服务台通知单和bug

优点：

• 开发人员和服务台之间的工作流程和需求可能会有所不同，您可以为每种系统选择符合需求的系统（例如，仅与开发人员或服务台相关的字段、不同类型的电子邮件集成）
• 明确职责：帮助台处理问题，开发人员处理bug

缺点：

• 集成不会是完全无缝的（您需要自动集成，这并不总是存在的，或者手动前后链接，人们可能会忘记）

到目前为止，我们对两种产品很满意。有时需要粘贴链接或关闭一个ticket和一个bug是很烦人的，但通常ticket和bug都是由不同的人处理的，所以这没什么大不了的

---

如果你能找到一款适合每个人工作流程的产品，那么一款产品可能也能很好地工作。

在raiseaticket帮助台系统中，我们为产品、开发和bug创建了一个单独的工作流程。根据问题的性质将票据分配给相关组。这些票不向任何其他团体公开。因此，我们可以在我们的帮助台门户系统中为bug跟踪做一个变通

它需要用于跟踪bug。。。无论是我们内部发现的还是最终用户发现的。。。在应用程序投入生产之前和之后。好吧，我认为我的答案仍然适用。所以基本上不集成它们，只是让某人在适当的时候“转换”帮助票证以解决问题？很明显，我们可以集成，这样人们可以通过点击按钮自动完成……是的，我们也是这样做的。在这种情况下，基于web的系统的一个优点是，即使没有对集成的明确支持，也可以将指向其他系统的链接放入文本字段：-）。