我们有一个标准的问题跟踪系统，可以跟踪最终用户和项目管理方面的缺陷/增强功能。但是，我们还需要跟踪内部团队缺陷，这些缺陷可能包括重构代码的某些部分或更改最终用户没有任何交互的应用程序中的某些内容。
最好是在同一跟踪系统中跟踪这些缺陷和增强功能吗？我对此的保留意见是，查看用户缺陷的项目经理会对这些内部请求感到困惑，这将引起不必要的关注。我们是否会建立另一个缺陷跟踪系统，仅供内部团队使用？
答案 0 :(得分：4)
更少的系统（几乎）总是更好，除非您享受额外的管理工作以消除编码时间。
我喜欢Pivotal Tracker将这些分开的方式，以避免您所谈论的混乱，并明确关注客户。用户缺陷是“错误”，没有明显客户利益的内部项目是“家务”，并且不会出现在许多视图中，因为它们没有提供客户价值（没有用户故事与它）。
所以我认为大多数问题跟踪器都有解决问题类型的方法，我会将“支付技术债务”问题与错误分开。
您可能还想考虑为什么要开始项目经理不了解的任务。您可能只需要更清楚地说明为什么需要完成此任务。因此，不是“重构用户身份验证”，而是“提高用户登录系统的可维护性”，或者任务的基本目标。
显然，每项技术任务都需要提供商业价值，并考虑它的具体内容（除了“我的代码更优雅”）可能是一个很好的练习。