Назад |
Перейти на главную страницу
Требования к системе отслеживания проблем
Я не делал этого довольно давно, но на самом деле собираюсь пройти процесс оценки различных средств отслеживания проблем.
Начиная с этих требований:
- должен быть настраиваемым (настраиваемые поля, настраиваемые рабочие процессы)
- электронная почта и веб-шлюзы
- манипулирование метаданными по электронной почте (например, закрытие по электронной почте и т. д.)
- уведомления по электронной почте (по запросу)
- возможность назначать "наблюдателей" по умолчанию для новых проблем
- поддержка классификации задач (категории, проекты, ..)
- взаимосвязи проблем (второстепенные проблемы, связанные проблемы, повторяющиеся проблемы, проблемы слияния)
- Интеграция с AD
- Безопасность (например, разрешить пользователям видеть только свои проблемы)
- API
- Интерфейс CLI (мне все равно, но другие предложат это)
Какие требования мне здесь не хватает?
Могу добавить:
- Платформа (ОС и язык программирования) в зависимости от того, что вам удобно поддерживать, или кто-то будет владеть этим, когда он будет дома.
- Интеграция IDE если вы собираетесь использовать его для рабочих процессов, связанных с проблемами приложения (т.е. имеет ли он полезный интерфейс с Eclipse или Visual Studio).
- Интеграция SCM, опять же, если вы собираетесь отслеживать проблемы с приложением. Приятно связать ошибки или функции с проверками в репозитории исходного кода. Не так полезно для работы с тикетами службы поддержки.
Кроме того, если он будет выполнять роль службы поддержки, возможно, отслеживание запасов или отслеживание лицензий.
ОБНОВЛЕНИЯ
- Возможность назначать ресурсы по умолчанию (например, техников / программистов) при появлении новых проблем (автоматическая сортировка уровня 1) в зависимости от типа проблемы или приложения, для которого поступает заявка
Возможность прикрепить файл.
Возможность использовать шаблон: например, создать новый вид дела с заранее определенным списком вложений.
Возможность вести журнал рабочего времени по делу.
Что касается безопасности, шифрование между конечными точками важно, но не всегда предлагается.
В функция виртуального пользователя в FogBugz довольно приятно. Мне это нравится больше, чем стандартные группы. Я бы счел это обязательным, если бы использовал его уже несколько лет.
Когда бы вы ни смотрели на программную платформу / пакет, также стоит обратить внимание на поддержку самого продукта. Как быстро можно исправить ошибки? Это открытый исходный код, чтобы вы могли решать проблемы самостоятельно, или вы будете полагаться на другую компанию?
Мелочь - настройка темы / шаблона / логотипа. Некоторые компании предпочли бы решение, которое они могли бы настроить в соответствии со своим корпоративным имиджем.
- Белые бумаги или раздел решений позволяя персоналу службы поддержки искать известную проблему или КАК.
- Создание заявки на действие мониторинга
- Прикрепление файлов / журналов
- Подходит для смартфона интерфейс для внешнего доступа
- Автоматическая эскалация нерешенных проблем
Поток системы управления процессами на основе статуса заявки (как это делает Jira)