使用错误跟踪/问题跟踪软件来讨论设计问题，新工具等

是否有人有使用bugzilla / mantis或JIRA之类的bug跟踪/问题跟踪软件的经验，不仅可以解决bug或任务，而且可以发起并维护最终导致决策的讨论？

例如，开发人员认为应废除所有受保护的字段，并使用访问它们的受保护方法更改为私有字段。这不是他的电话，他想讨论。通常，他在下一次开发人员会议上提出要点，然后在会议上做出决定。相反，我的想法是让他提出某种“决定”类型的问题并描述他的意图，就像通常描述一个错误或任务一样。

其他开发人员可以根据自己的意愿发表评论，最后，该问题以“已接受”或“被拒绝”结束。

我从中看到的优势：

• 异步通信：当他们还没有时间监督上述决定的所有后果时，没有人会被迫在会议上发表自己的意见。
• 导致决定的考虑因素的书面记录。如果后来有人再次提出这个问题，可以向他提出。
• 可以建立与其他问题的关系，例如可以将一项任务跟踪到一个决策。
• 与版本控制软件（例如提交）的集成可以追溯到决策。

缺点：

• 金锤味浓：通常使用问题跟踪软件来跟踪可操作的项目
• 组织的开销可能不成比例：与人之间无需进行简短的非正式演讲，就必须以书面形式交流自己的想法

我们的工作方式是，问题跟踪应该跟踪所有问题。在对其进行分析之前，我们不知道哪些问题是可行的。如果跟踪系统中仅包含可解决的问题，则很可能对它们进行过早分类，这意味着所有讨论和决策都将丢失。我们采用了所有事物都应采用的方法（无论如何，在我们的工作流程中），否则问题可能会反复出现而没有可见性。

我们在Jira实现中为“风险”提供了一个类别，因此我们正在使用Jira跟踪不可操作的项目，但是能够以某种方式危害软件。跟踪有关该项目的讨论，一旦风险消失（或减轻），问题就可以解决。您提供的示例可以轻松地进入“风险”类别。

重要的是要讨论和跟踪诸如此类的事情，并记录决策。当开发人员在几个月后再次提出问题时，“要求并回答”的响应就可以证明其合理性。

如果我错了，请纠正我；但是我认为您在说的是-“可以/如何使用错误跟踪/问题跟踪系统来执行“决策跟踪”。是否还是我缺少某些东西？

一开始我会说这确实是个好主意。尽管我们没有按照确切的方式使用它，但出于跟踪目的使用它还是有道理的。在我们的案例中，电子邮件很长-紧随其后的是论坛/邮件列表。

但是，从广义上讲，您的问题是关于如何有效地制定（和管理）决策，以及将工作的涵义与可以带来更好洞察力的决策联系起来。

就像我说的，如果有帮助的话，这是一个好主意。没错。但是，有效地制定/管理决策几乎不需要什么具体的事情。

1. 的确，大多数决策应该基于广泛的包容性努力，以便在做出决策之前适当覆盖和衡量所有重要方面。因此，无论您使用什么工具，都必须启用对所有相关人员的透明信息访问。您说对了，异步传输和收集信息的方式对您有所帮助，因为人们可以在提出建议之前及时投入。如果要求提供预先的答案（通常是在会议中），则与同一个家庭作业足够的人相比，判断可能不那么合理。

2. 但是，这并不一定意味着每个投票都相等的“纯民主”。通常，决策者应该是一个或几个-并且在他们接受所有意见的同时，他们必须对决策负责，而不是所有提供意见的人。

3. 大多数决定必须是可行的。可能很难避免矛盾。但是，决策是不可行的，只能是主观的，这一事实意味着将来有可能（错误）进行解释。

4. 对决策的级别和范围进行分类很重要。最重要的是，我们必须确定是要讨论特定的设计问题还是特定的代码方面，过程的方面，还是这些项目计划和跟踪相关问题？当问题从生产代码中发出时，通常都很适用-所有这些都适用，但是我们必须能够区分所有不同方面，并能够独立地进行管理，以便能够有效地管理这些决策。

5. 有时，决策可能取决于我们是否对个人使用某些系统或角色和职责；将这些决策与特定决策的代码一起放在告示板式论坛上可能很困难。

6. 只是一个额外的轶事；每个团队都必须将代码审查和设计审查本身作为一个过程进行处理-这将详尽地涵盖许多问题，例如您引用的示例。他们必须确定决策跟踪是否涉及其他事物。

良好的决策制定实践涉及很多纪律，涉及如何将信息汇总在一起并确保以正确的精神贯彻执行决策。

工具只能帮助使信息更具有表现力。但这可能对您有帮助。

FogBugz是必经之路。它不是免费的。最新功能使实施敏捷方法更加容易。

一种更简单，自由的方式就是Asana。

无论使用哪种工具，团队沟通对于促进成功的项目都是最重要的。