我们无法告诉您如何修复您的流程，因为这取决于您自己的情况。

也就是说，这听起来不像是一个很难解决的问题。听起来您的 Jira 配置对于您的工作流程来说不够表达。如果是我，我会首先就需要解决哪些工作流程问题达成一致。听起来你好像已经对此有意见了。有些问题可能比其他问题更紧迫，因此对它们进行优先排序会有所帮助。

接下来，您需要决定是否在 Jira 中解决这些问题。我相信您可以在 Jira 中添加字段并自定义工作流程。您可能还认为有些东西不属于 Jira。例如，您可以选择将功能列表保留在 Confluence 中。当然你还没有说是否有人可以定制 Jira。如果没有，您将需要以其他方式解决问题。

第二个和第三个要点可以说根本不是错误。它们是新功能请求。发明一个列表，让任何人——测试人员、程序员、市场营销、主题专家——都可以提出新功能的建议。墙上的便利贴就可以了。该新请求与任何其他请求一样获得优先级。（相比之下，政策可能是必须立即修复回归错误。）

对于第一个要点，Jira 有一个称为“在测试时发现”的关系。这意味着您在系统中存在错误，并且您可以跟踪何时/为什么发现它，但您并不暗示该错误与新功能有关。

这些观点总是有回旋余地，但我会说你认为第一个和第三个问题应该被视为新问题（分别是错误和功能请求）是正确的。在一个 JIRA 问题中包含逻辑上独立的问题只是一个好主意，如果它们被如此紧密地绑定，以至于任何一个都不能在不修复另一个的情况下合理地修复。

至于第二个，就看情况了。如果是用户想出一个好主意的问题，那么最好把它变成一个新功能。另一方面，如果（我经常遇到这种情况）程序员在严重误解规范精神的同时设法完成规范的文字，那么我可以理解人们要求在同一问题的范围内对其进行分类。

然而：我已经看到这种“把它放在同一个问题中”的心态是由于过于严格的发布程序而产生的，这些程序坚持必须提前修复发布中的最终问题列表。如果这是您所处的情况，那么这就是需要首先解决的问题。

在所有情况下，不同群体之间的合作精神和产生良好结果的愿望远比正式程序的精确细节更有价值。

您的流程中的基本缺陷是您的流程在开发人员和测试人员之间建立了对抗关系：

它确实给开发人员带来了不好的感觉，他们可以理解地认为他们的修复并没有“失败”，甚至最终可能会因为项目的开发时间比最初估计的要长，或者他们的项目被退回的次数而受到公司的纪律处分从 QA 失败。

这是恕我直言的致命缺陷。惩罚开发人员因为他们无法控制的事情（例如需求更改）将使最优秀的开发人员离开。也许您的管理层认为您的开发人员没有足够的能力在不受惩罚的情况下尽力而为——也许他们是对的，由于这种待遇，有能力的开发人员应该离开。

公司应该聘请有能力的开发人员，并假设任何潜入生产的错误都是错误的，而不是恶意的。对将来如何避免此类错误进行事后分析，而不是责怪谁以及如何惩罚他或她。

是的，新功能和改进的理解是新的请求，而不是失败的错误（特别是如果开发人员会因“失败”而受到惩罚）。

开发人员、QA 测试人员和管理层的目标应该是在可用的时间和预算内部署最佳产品以满足最重要的用户需求。