您如何以对程序员和非技术人员友好的方式处理错误跟踪？[关闭]

实际上，我们在项目中使用的是螳螂。还是我应该说“我们尝试使用”。我所知道的所有错误跟踪器的问题在于它们是由程序员为程序员制作的。因此，该设计不存在或完全荒谬。

当然，作为一名程序员，我可以毫无问题地使用螳螂，但是当项目中所有参与 ** 的人发现它们的设计如此糟糕且难以使用以至于他们更喜欢使用带有项目符号列表的Google文档时，bug跟踪器会很有用他们发现或建议的错误。

我将要安装一个论坛，在我看来，这就像是在错误跟踪器和简单项目列表之间的“中间”解决方案。至少一个论坛允许监视和集中有关建议的讨论。

如果我的担忧不清楚，我的问题可以总结为：

您如何处理针对非技术用户的错误和建议报告？

**通过参与，我并不意味着实际的客户或最终用户。我在考虑我们的集成商，项目经理以及参与质量检查的人员。

我们在今年早些时候从Mantis切换到FogBugz（和Kiln），但是我们没有改变的一件事是我们完全不让“用户”访问Bug跟踪器。其他部门的负责人具有只读权限，但老实说，他们是经理，他们通常会在几周内忘记这一点。我们软件的所有用户都与一个故障排除人员打交道，他们可以确定是配置问题，用户错误还是软件错误。然后，此人充当将实际问题输入FogBugz的看门人。这可以防止我们的系统陷入与实际无关的问题。

因此，要回答您的真实问题...。对于我们而言，错误跟踪软件不是“由程序员”，“对于程序员”的问题，因为只有“程序员”会使用它。其他所有人都直接与人打交道。

（请注意，我们的产品不是收缩软件，我们的所有用户都是直接雇员，或者与服务部门的雇员一起工作。）

我们将redmine用于此类事情。关键技巧是大多数用户从未看到 Redmine，他们只是发送电子邮件至support@example.com。使用一些更高级的技巧-主要是密排我们的redmine帐户，并包括问题＃-我们可以使更新保持在redmine中。对于更高级的人，我们只允许他们直接使用redmine，因为它比MANTIS更加现代和用户友好。

目前，我们正在使用MKS。对于非程序员，我已经设置了一些报告以及带有他们感兴趣的摘要的仪表板。这意味着我必须进行初始设置，但是他们能够监视缺陷的进度和总体摘要我向他们展示了如何访问报告和仪表板后，它们本身就可以访问数据。他们还需要一些培训来修改票证，但总会有一些培训开销。幸运的是，它与所涉及的功能成比例。

我第二次使用Redmine，然后亲自使用The Bug Genie（是的，俗气的名字，但设计精良；如果您在PHP环境中和/或由于某种原因不能运行Ruby）进行对非技术用户。

除此之外，关键之一是最终用户在默认情况下所看到的问题绝不需要多于他们所提出的问题（可选地，您可以具有搜索功能以避免重复的票证，但这取决于您的需求和设置）。看到所有问题只会使界面混乱并使最终用户感到困惑。通常，用户应该只看到他们需要看到的内容，因此，例如，项目经理只会看到他们控制的项目的问题。正如其他人提到的那样，对于最终用户而言，提交票证越简单越好。如果您可以提交甚至不需要跟踪程序UI的票证（通过电子邮件或仅包含提交票证所需字段的简单表单），即可获得加分。

我们使用“ Visual Studio的应用程序生命周期管理功能”，以前称为团队系统。我们的一大优势是，您可以将查询结果（例如“所有要求”或“所有pri 2或更低版本的错误，将不在下一版本中发布”）导出到电子表格或Project文档中。项目经理，最终用户代表，利益相关者等可以编辑这些文件-更改优先级，更新描述，分配给其他人，无论如何-然后，当文件将其返回到连接到TFS的计算机上时，您可以点击发布和所做的更改将返回到存储库中。程序员可以直接从Visual Studio处理工作项，但非程序员绝对不能接近VS。此外，每个TFS项目都有一个共享站点，因此您不必

如果您不是VS商店，可能不是一个选择，但值得考虑。

如果您正在与QA / PM人员交谈，则需要评估各种开放源代码和封闭源代码跟踪工具。有能力设置内部版本等功能的人员很好，这样，QA / PM人员可以针对特定的内部版本插入票证，并且在解决问题时，他们可以知道要测试哪个内部版本。

实际上，我使用的大多数礼节工具都比非程序员更适合非程序员。StarTeam对我来说效果很好，但我不知道它是否还在。您可以自定义字段，如果需要的话。只要确保他们不会太过分。

如果您在谈论最终用户，那么您需要查看帮助台软件，然后根据需要让您的帮助台人员升级到错误工具。