我们正在就如何管理IT部门的错误/问题进行一些非常有趣的辩论。我真的很想听听别人怎么说他们如何管理应用程序/提要等产生的错误。
我们正在努力将所有内容放入BPEL（业务流程执行语言）中，以便非开发人员可以看到正在发生的事情，而不必在出现问题时查看代码。问题是......（正如大多数人，我肯定知道）代码只是公平的一部分。您还必须熟悉流程/流程才能真正对错误做些什么。在没有完全理解的情况下进行“修复”会产生很大的影响。
无论如何都希望听到别人如何处理这些类型的问题......（提供对代码/应用程序生成错误的适当可见性）。
谢谢！
取值
答案 0 :(得分：2)
在这里要非常小心，工作中可能有未说明的议程。
面对使我们的错误处理过程更加开放的问题，我们在公共内部网服务器上实现了Bugzilla，但是仔细限制谁可以发布以及谁可以更改bug状态等。这非常有效：面对必须提供repro案件和证据表明，之前一直滔滔不绝的人突然出现了沉默寡言。因此，我们的错误报告质量有所提高。更好的报告==更多修复。每个人都赢了。
我离BPEL这样的地方一英里远。尤其是因为如果您的非开发人员无法读取代码，我不会看到像Nassi-Shneiderman图这样的东西会如何帮助他们。形式主义意味着严谨，非开发人员通常不是很擅长整个事情。
如果目的是宣传您的系统的工作方式，而不是失败的方式，并且您需要制作非开发者可以理解的内容，那么良好的教育解决方案是一个公开的内部网维基。只需要事先了解让人们痴迷并撰写内容有多难。可悲的是，我们很快停了下来。
最后但同样重要的是，请务必确保管理层中的某个人不会尝试使用此流程通过后门强制执行指标/ KPI。这些指标无意义可以在极短的时间内摧毁一个正常运作的部门。
答案 1 :(得分：1)
忠诚的事情是尝试FogBugz，不是吗？
答案 2 :(得分：1)
我建议远离任何复杂的事情（比如BPEL），只需购买可以调整的第三方软件包，如果需要的话。所以，是的，FogBugz就是一个可行的例子。还有其他：AxoSoft OnTime，Rally的RallyDev等......
特别是因为你是一家小商店，我会避免瘟疫在你提到的问题上花费时间，而是专注于你的核心业务。
就管理的各种日志等的可见性而言...创建一个包含这些链接的网页。完成。不要在这样的事情上浪费太多时间。
答案 3 :(得分：0)
有一些公司实施“社交”想法，非常像堆栈溢出在这里实施团队＆amp; |错误和错误修复的个人评分系统，但必须质疑是否会引入所述错误仅用于修复错误。