为什么很难让员工更新问题跟踪器？

在公司和工作中，我一直都在努力让人们更新他们的问题。我曾有几次案例，人们实际上是出于内心的善意而这样做的，但是大约70％的时间我必须追赶人们。

作为通常执行某种或其他形式的管理（我首先是一名开发人员）的人，我尝试给出的主要原因是我不想追赶人们并打扰询问进度，但是我不愿意最终人们不会认为有很多问题要问。在某些罕见和极端的情况下，我最终会更新票证（当我需要创建报告时）。

那么，您是否遇到过这个问题？您如何鼓励开发人员经常更新问题跟踪器？您取得了多少成功？

原因是他们不理解为什么应该更新问题跟踪程序，除了您这样说。

这是为什么？我的猜测是更新跟踪器不会以任何有意义的方式影响他们的工作，因此解决方案可能是实施一个跟踪系统，该系统实际上可以帮助他们更好地完成工作。

很难，因为员工清楚地感觉到更新问题跟踪器并不重要。您必须更改它，但是有一个陷阱。沟通很难。有效的沟通确实非常困难-比您想象的要困难得多。如此努力，以至于交流通常会失败，除非是偶然的。

显示，不要告诉。例如。不知道是您（或老板）需要的数据的报告。显示从员工的角度来看跟上时代的问题跟踪如何影响和帮助他们。

以身作则。

我是一名开发人员，努力使用我们工作中的问题跟踪器。这很不幸，因为我全都是为了他们使事情井井有条。目前，我的解决方案是使用个人跟踪工具，并参考它来讨论我们日常工作中的进展。

这就是让我一直使用跟踪器的原因：

• 与IDE和源代码控件的无缝集成。我们使用了一些笨拙的Web应用程序，因为已经为其购买了许可证。创建/更新任务需要花费很多时间，并且具有一些令人困惑的UI功能。不幸的是，使用此功能超出了我们团队的控制范围。

• 简单。我的意思是不要为了添加任务而占用10个手动填充的字段。每小时估算与完成时间，手动输入项目/组件/等。在几个领域，等等，只是增加了时间。

• 只有一个。不确定这是多么普遍，但是项目管理使用一种工具，支持使用另一种工具，而开发则使用第三种工具。如果其中一个没有更新，则三个肯定不会更新，并且它们之间的同步不太可能自动进行。

首先：“人们更新进度”是什么意思？

您是说“开发人员正在更新当前的估算值”，还是“开发人员未解决问题”，或者是“客户/测试人员未解决已解决的问题”，或者全部在一起？

从开发人员的角度来看，这是思维和文化的结合。

• 思维定势：当您解决问题时，意味着您已经做好了，并负责解决问题
• 文化：如果整个公司不太热衷于使用此类工具，而是喜欢其他组织策略

我的经验是：您至少需要文化指向正确的方向。接下来的工作是定义一个DoD（“完成”的定义）-如果开发人员（也为其他角色工作）可以说（他）履行了整个清单，那么它便可以将问题标记为已解决，并且无需继续进行下去回头。

停止询问编码进度（无论如何它通常都是凭空抽出的任意百分比），直到关闭票证为止。如果您衡量的主要问题是已关闭的门票数量，它将改善。

请注意，但是所有指标都可以玩，并且当与补充指标结合使用时，指标往往会更好地工作，例如，您可能还希望查看重新开放的问题，因为这暗示着它们已过早关闭

正如其他答案所指出的那样，此处的正确问题可能是：为什么要使用问题跟踪器。如果您想让问题跟踪系统真正起作用并定期进行更新，则必须（不仅是从管理的角度，而且从开发人员的角度）对这个问题的一个好的答案。

在许多公司中，问题跟踪系统主要用作管理报告工具。使程序员仅更新问题以使管理人员可以运行报告并不能很好地工作。而且，迫使程序员更新问题也不起作用-您可能已经更新了问题，但是您应该质疑数据。

以我的经验，真正让开发人员（以及测试人员，管理人员等）有效使用问题跟踪系统的唯一方法是将其集成到开发过程中。这意味着该过程的一部分的输出成为该过程的下一部分的输入。

为了授权错误跟踪系统，我建议以下内容：

• 开发人员只能处理问题跟踪器中记录的错误/功能，并且无法在其之外进行任何工作。所有想法，重构项目，新功能，要开发的自定义工具等也都应该记录下来。
• 按优先顺序处理问题。优先级应部分由管理层确定，但开发人员在确定优先级时也应绝对有发言权。当涉及维护和重构问题时，尤其如此。

关于处理，您可以使用类似以下的内容：

• 状态“新”表示开发人员尚未解决问题，并且仍在优先问题中
• 状态“已分配”表示已将其分配给开发人员。这可以由开发人员或其他人（例如团队负责人）完成。我发现分配给每个开发人员一些问题很好，并且通常是“繁重的工作”（例如新功能）和简单的选择（例如简单的错误或一些简单的维护工作）的混合。这使开发人员可以根据自己的心情选择工作。
• 状态“进行中”表示开发人员正在处理问题。每个开发人员在任何时候都只能“处理”一两个问题。
• 解决问题后，开发人员可以将问题的状态更改为“需要测试”，并将所有者更改为测试人员。这是重要的一步，因为这也是测试人员的工作队列。
• 测试人员可以将状态更改为“测试失败”，然后将所有权更改回开发人员，这意味着开发人员可以将其移到开发人员的队列中，也可以将状态更改为“准备部署”。
• 然后，负责发布的人员可以根据发布周期合并和发布状态为“准备部署”的问题。

简而言之：将问题跟踪系统作为开发过程的重要组成部分，您不必担心问题不会被更新。

也许他们认为打开浏览器，登录，查找故障单并填写繁琐的工作。也许您可以尝试用钩子鼓励他们。如今，常见的功能是在git / hg消息中[我假设您使用其中之一]，您可以键入类似FIXED＃123的内容，并且一旦您提交提交，票证就会自动更改。这样，对于开发人员来说几乎是没有用的（如果他在单独的分支中处理每个问题-他已经有票证ID），并且很可能他会在提交消息中添加这两个字符。如果此解决方案还不够，可能意味着票证的范围太大，应该分为许多较小的票证吗？

这听起来更像是公司文化问题。谁提出了使用跟踪器的需要？如果这是一个人或一个团体扔出去的东西，并希望其他所有人都接受并使用，那么祝您好运。除非人们了解它是什么，知道如何使用它，并接受它确实使他们的生活（他们的生活，而不是您的生活）变得更轻松，否则除非得到管理层的强迫，否则他们不会使用它。话虽这么说，如果使用跟踪器是公司的决定，那么应该由管理层来实施它。除非您的角色包括让/让人们使用跟踪器的责任和权力（听起来像否，就像您表示自己是开发人员一样），否则无论您做什么，都不会走得太远（实际上，恕我直言）。

这可能类似于为什么很难让人们定期输入时间。这是一项繁琐的工作...

许多问题跟踪器都与IDE集成在一起。例如，使用TFS工作项跟踪程序，您可以在执行签入时将任务标记为已解决。甚至还有一个选项要求签入与任务关联。将工作项的更新作为签入过程的一部分可以简化操作。另一种方法是在单独的界面中打开问题跟踪器以执行更改。

另一个选择是召开状态会议（或在日常站立期间），其中有人打开跟踪器并在人们提供状态时更新任务。

要考虑的一件事是GUI本身是一个障碍。例如，一些障碍可能包括：

• 点击次数过多
• 未优化或功能不足的Issue Tracker Application Server
• 可用性或可访问性差

公开一个API将允许通过脚本编写与技术工件相同的问题跟踪器（代码覆盖范围，单元测试报告，构建状态等）。

参考文献

• Scrumwise-API

• JIRA Cloud REST API参考

• Alfresco内容服务REST API