Как следует интегрировать отслеживание ошибок и справочные тикеты?

У меня небольшой опыт работы с системами отслеживания ошибок, такими как FogBugz, где запросы помощи - это проблемы (или могут быть) ошибками, и у меня есть некоторый опыт использования внутренней системы отслеживания ошибок, полностью отдельной от системы справочного центра. .

У меня вопрос: в компании с существующей (собственной) системой справочного центра, где ее замена невозможна, как следует интегрировать систему отслеживания ошибок (возможно, Mantis) в процесс?

Прямо сейчас заявки на помощь вводятся для проблем, вопросов и т. Д., И они назначаются соответствующему человеку (специалистам ПК, сотрудникам службы поддержки или, если это проблема приложения, которую они не могут решить в службе поддержки, она передается разработчику. ). Пользователь может поместить запрос на небольшие изменения или исправления в приложение в справке, и разработчик, которому он назначен, внесет изменение в какой-то момент, применит свое время к этому заявлению, а затем закроет заявку, когда она перейдет в производство. .

В настоящее время у нас нет системы отслеживания ошибок, поэтому я ищу лучший способ ее интегрировать. Должны ли мы просто взять билеты помощи и поместить их в систему отслеживания ошибок, если это ошибка (или проблема или запрос функции), а затем закрыть заявку, если это не экстренное исправление? Мы, вероятно, не хотим показывать систему отслеживания ошибок кому-либо еще, поскольку они не будут знать, что добавить в систему справочного центра, а что добавить в систему отслеживания ошибок ... верно?

Есть предположения? Предложения? Советы? Совет? Задачи? Не дела? и т.д...


issue-tracking bug-tracking process
person Max Schmeling    schedule 27.02.2009    source источник

Ответы (4)


arrow_upward
2
arrow_downward

Это для производственной системы, в которой конечные пользователи сообщают об ошибках, или для решения проблем во время контроля качества?

Если это первое, то какой-нибудь живой человек должен отсортировать заявки службы поддержки и регистрировать как ошибку только то, что на самом деле является одним из них.

Если последнее, вам вообще не следует интегрироваться.

person cdonner    schedule 27.02.2009
comment
Он должен быть для отслеживания ошибок ... как тех, которые мы находим внутри, так и тех, которые находят конечные пользователи ... как до, так и после запуска приложений. - person Max Schmeling; 27.02.2009
comment
Хорошо, я думаю, что мой ответ все еще актуален. - person cdonner; 27.02.2009
comment
Так что, по сути, не интегрируйте их, просто попросите кого-нибудь преобразовать билеты помощи в задачи, когда это необходимо? Очевидно, можно интегрировать, чтобы человек мог сделать это автоматически, щелкнув кнопку ... - person Max Schmeling; 27.02.2009
comment
Да, мы тоже так делаем. Одним из преимуществ веб-систем в этом случае является то, что даже без явной поддержки интеграции вы можете просто поместить ссылки на другую систему в текстовые поля :-). - person sleske; 26.04.2010

arrow_upward
3
arrow_downward

Сделайте кнопку повышения до ошибки в системе службы поддержки, которая публикует заявку в системе отслеживания ошибок с соответствующей справочной информацией.

person eglasius    schedule 27.02.2009

arrow_upward
0
arrow_downward

Что ж, это компромисс.

Мы используем отдельные системы для обращений в службу поддержки и для устранения ошибок.

Плюсы:

  • Рабочие процессы и требования, вероятно, будут разными для разработчиков и службы поддержки, вы можете выбрать систему для каждой, которая соответствует требованиям (например, поля, которые актуальны только для разработчиков или службы поддержки, различные виды интеграции электронной почты).
  • Четкие обязанности: служба поддержки обрабатывает заявки, разработчики обрабатывают ошибки.

Минусы:

  • Интеграция будет не совсем гладкой (вам нужна либо автоматическая интеграция, которая не всегда существует, либо обратные ссылки вручную, о которых люди могут забыть).

Пока что нас вполне устраивают два продукта. Иногда надоедает вставлять ссылки или закрывать заявку и ошибку, но обычно заявки и ошибки обрабатываются разными людьми, так что это не имеет большого значения.

Один продукт также может работать хорошо, если вы найдете тот, который подходит для каждого рабочего процесса.

person sleske    schedule 26.04.2010

arrow_upward
0
arrow_downward

В системе поддержки поднять билеты мы создаем отдельный рабочий процесс для Prod, Dev и Bugs. Билет отнесен к соответствующей группе в зависимости от характера проблемы. Эти билеты не выставляются ни одной другой группе. Итак, мы можем найти обходной путь в нашей системе портала службы поддержки для отслеживания ошибок.

person Ams    schedule 08.01.2020