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