Как стать автором
Обновить

Комментарии 19

Вы, конечно, молодцы. Но на практике у систем ServiceDeck и баг-трекеров разное назначение. ServiceDeck грубо говоря инструмент для поддержки качества предоставляемого сервиса, как раз такие системы следуют идеологиям ITSM. Баг трекеры же созданы для управления процессами разработки ПО.Они, по идее, пересекаются только в очень не многих местах.
Конечно, можно из молотка сделать топор — но это будет плохой топор.
Да, топор действительно получился не без проблем(я их перечислил в статье). Но различные джировские плюшки в нашем случае перевешивали его недостатки. Например банальная кнопка «Создать баг на разработку» в сочетании со стандартным шаблоном бага(что делали, что хотели, что получили) сильно сократило время на прием и обработку ошибок от пользователей.
Jira уже давно не просто баг-трекер, а скорее настраиваемая система управления проектами.

Для организации поддержки есть прекрасный плагин JIRA Service Desk. С… порталом пользователей и настраиваемым SLA.
См. официальный сайт.
Это было когда-то давно так… наверное

ServiceDesk, если прямо переводить — служба поддержки.
Кого и как вы ей поддерживаете — ваше личное дело, никакие итили и т.д. тут никому не могут ничего указывать
Что есть служба поддержки?
Это заявка пользователя и работы по ней., т.е. простейший баг-трекер. А если обработка не в стиле «принял — обработал — закрыл», то это уже совсем не простейший баг-трекер, а нормальный процесс

Касаемо Жиры
У нас на ней сделан и SD, и процесс разработки, и процессы между отделами компании, и т.д.

А JIRA Service Desk вообще очень сильно продвинул Жиру в смысле приема заявок от пользователей
То, о чем Вы говорите это управление инцидентами. Но ITSM это не только инциденты, есть еще управление конфигурациями и много разных плюшек. В чем плюс OTRS — они следуют ITSM, да — небольшим компаниям это не удобно, но крупные предприятия не могут без данных практик жить.
Но это шире, чем просто Service Desk
Или вообще — это не Service Desk :)
Ну в понимании этого термина, как Служба Поддержки пользователей, реагирующая на их запросы
Скажите, существует ли в рассматриваемом модуле разделение запросов пользователей по услугам (продуктам)? Какие есть возможности по контролю исполнения SLA и построению оперативной отчетности?
Помнится, у JIRA недавно появился модуль ServiceDesk, рассматривали ли вы его и почему решили делать все на стандартных инструментариях?
промазал с ответом, он чуть ниже.
Я потихоньку пишу краткую статью про JIRA Service Desk (JSD), там информация будет о нем, возможно вам поможет.
Надеюсь за недельку закончить

По поводу применимости

Проблема JSD в том, что пользователь должен залогиниться в систему, чтобы написать через JSD заявку
Если у вас все пользователи видят Жиру и нет проблем с количеством лицензий — то смело можно использовать. Если один из этих пунктов в пролете — то остается только по письмам создавать задания от единого универсального пользователя
Если честно, то я не понимаю, зачем мне нужно покупать лицензии на пользователей, которые просто регистрируют заявки. На мой взгляд, для таких пользователей в любой HD/SD системе должен существовать нелицензируемый тип учетки.
Ну этого все клиенты Атлассиана не понимают и требуют изменения лицензионной политики, но пока не удалось достичь результата :)
В таком подходе меня напрягает количество действий. Насколько просто там разобраться типовому пользователю развлекательного портала, например? Есть ли там поддержка по почте?
Так по почте и т.д. — это все сама Жира
А Service Desk — это удобная настраиваемая морда для подачи заявок и удобная их обработка: SLA + очереди + отчеты

Настроить можно без проблем, если что-то уже приходилось настраивать в Жире

Есть уже плагин, добавляющий некоторые плюшки к JSD, которых там нет и руки до них у Атлассиана вряд ли быстро дойдут
А чем хуже сборщик запросов + реализация всего остального стандартной Жирой? И он не требует регистрации.
Для создания запросов через email ничем :)

Но через email нельзя заполнить никакие поля, кроме описания и темы
А если брать явное создание запросов пользователем, то в Жире можно указать все, что надо (выпадающие списки, даты и т.п.)
JSD дает более удобную работу с этим всем — человек вообще может даже и не знать, как на самом деле выглядит заявка в Жире, подавая заявки через JSD
Если у вас один тип запросов и всегда один набор полей, то да, сойдет, как альтернатива создания запроса напрямую через Жиру
Ну да, он умеет создавать от указанного пользователя, это хорошо.
Правда я не смог заставить его работать нормально — статистику использования он не показывал

Но если у вас много типов запросов, много категорий, от которых зависит набор полей, если нужны расширенные комментарии к полям и вообще другие названия для них в зависимости от типа и категории — тут только JSD

Он вовремя подоспел — мы перевели всю техподдержку у себя на Жиру
Разработка до этого перешла, через Жиру

Вообще в Жире очень низкий порог вхождения нового пользователя, который ни разу ее не видел и вообще ни с чем таким не работал
Он практически нулевой
Понял, спасибо за развернутый ответ.
1) Если у вас разные ящики для разных проектов, то почему бы и нет. А если один, то как именно вы хотите определять к какому проекту принадлежит письмо?
Если вас интересует разбиение руками поддержки, то в JIRA у задач есть поле «Компоненты» в котором можно указать проект.

2) Контроль SLA можно реализовать за счет того же самого сервиса писем, например следя за событиями с помощью фильтров аналитики

3) Аналитику можно выстраивать практически по любым мыслями критериям: скорость реакции, прохождение задач определённых статусов, можно ее разбить по отдельным специалистам, построить диаграммы Ганта и т. д.

4) ServiceDesk мы смотрели и он ориентирован скорее на внутреннюю поддержку. Нас же интересовала поддержка внешних пользователей.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории