曾经配置过帮助台/票务系统的人是否经历过创建“正确”票务类别的相同迭代过程？
修订版本 1：
- 基础设施
- 服务器
- Citrix
- Windows 服务器
- ...
- 桌面
- 视窗
- 苹果
- ...
- 服务器
- 应用
- 应用程序 1
- 问题
- 要求
- 应用程序 2
- ...
- 应用程序 1
- 用户
- 重设密码
- 被锁在外面
- ...
一切似乎都很好，直到你意识到你在每个公司站点都有上述功能，所以你尝试将站点指示器纳入层次结构，一切似乎又都很好。然后你意识到大老板想要知道所有基础设施票据的总数，但由于你有 16 个不同的基础设施桶 - 每个站点一个 - 你无法轻松回答这个问题。等等，等等。
根本问题是我们试图使用静态层次结构来建模本质上是多维的东西。问题不仅仅是对数据进行切片和切块。层次结构越“完整”，帮助台分析师就越难以正确分类每张票（“它是一台服务器，但它在纽约办公室，那么它应该归类在服务器还是纽约？”）关系数据库也存在同样的问题，因此最终创建了多维数据集。它存在于博客文章中，因此最终你可以用多个类别标记一篇文章。标记是答案，但大多数票证跟踪产品不支持这个概念，所以我们又回到了静态层次结构。
鉴于此，我很想知道人们如何设计他们的类别层次结构，使其尽可能广泛，同时保持相关性，同时又不给分析师的生活带来困难。
谢谢
答案1
你说的完全正确，问题在于你试图只使用一个类别字段来编码本质上是多维的东西。你需要为其他维度添加额外的字段。
我们使用 IssueTrak，它具有可用的标准类别层次结构。但它也有一个单独的位置字段，因此您可以按位置、类别或两者进行报告和统计。还有其他字段可以针对您的特定站点打开或关闭。例如，如果您愿意，您可以将位置汇总到区域中，并根据需要将其称为不同于位置和区域的名称。如果您想使用部门，可以打开它们。有组织。有资产项目，因此您可以将票证与 Server01 关联，例如，Server01 可以拥有自己的一组您可以报告的特征。
再次强调，我认为尝试将各种维度编码为层次结构是错误的。在我看来，您需要为您可能想要报告的各种类型的事物设置单独的字段。
答案2
我的无益的回答是尝试坚持标签或严重依赖搜索。
我的经验是，你在层级结构上投入的时间越多，选项集就越长，人们实际上花在选择正确类别上的时间就越少。保留默认设置或选择最模糊的类别比花几秒钟额外选择最具体的类别更容易。
答案3
保持它们非常简单，并确保类别反映您要报告的内容。如果您只想按服务器或工作站报告故障，那么添加大型层次树是没有意义的，因为在每个日志条目上导航会很麻烦。
如果您对报告不太在意，就不要创建预定义类别。几乎可以肯定，您会遇到不符合您模式的内容，并因此不得不进行错误分类。
答案4
我和你一样有类似的困境。目前我们有 3 个业务部门需要使用此跟踪器，我们使用选择矩阵来确定谁应该收到哪个类别的通知，以及谁可以在哪个类别中发帖。
因为我们有员工在各个企业之间流动，所以我们实际上使用第 1 级类别作为企业名称，使用第 2 级类别作为支持领域。例如：
- Α
- 操作系统问题
- 应用 1
- 视听设备
- 太棒了
- 操作系统问题
- 应用 1
- 视听设备
- 查理
- 操作系统问题
- 应用 1
- 视听设备
这个模式还很新，所以我们还没有遇到任何问题（目前）
有两件事让我印象深刻；重新阅读你的问题。
- 这是适合您的追踪器吗？它似乎缺少您想要的功能。也许是时候为这项特定工作寻找其他工具了？
- 对项目进行分类的一般规则是，树状层次越高，项目的范围就越广。方向应该是从最宽的定义到最窄的定义。