Как подружить Jira ServiceDesk с общим Confluence и помочь пользователям

В небольших по размеру организациях как правило не больше одной установки Jira, Servicedesk и Confluence, которыми пользуются все, начиная от охранника и заканчивая QA. Как сделать так, чтобы и волки сыты, и овцы целы. В смысле чтобы непривилигерованные пользователи имели быстрый доступ прямо из заявок в wiki и при этом не лазали куда не следует, а администраторы не отвлекались от работы чтобы в сотый раз ответить на один и тот же вопрос.

Итак, у нас есть Jira Service Desk и Confluence. Есть портал для персонала, который позволяет делать заявки по самым различным поводам. Есть администраторы, которые заявки выполняют. И есть желание задокументировать все типы заявок по типу «а как это» «а что писать тут».

Почему ServiceDesk а не Jira Software? Потому что для создания заявок в ServiceDesk не нужна лицензия — достаточно добавить клиентов в нужные подразделения (организации). Лицензия нужна только для тех, кто заявки будет обрабатывать. Одно это позволяет безболезненно и без особых затрат «оцифровать» работу IT-департамента. А если подписаться на cloud-версию, вообще красота.

Почему Confluence? Да по тем же причинам, вы получаете продукт, который работает «из коробки» и интегрирован в Jira. Серверная версия устанавливается за полчаса, облачная — за пару минут. Готовые шаблоны, система прав доступа, да и программисты её любят.

Дальше предполагается что у вас есть полуготовый проект в ServiceDesk с несколькими типами заявок. И нужно обеспечить бухгалтера Машу онлайн-документацией по заполнению формы.

1. Создаём отдельный Namespace в Confluence


Это необязательно, но так легче сгруппировать все статьи, имеющие отношение к ServiceDesk, в одном месте. Я бы ещё порекомендовал отдельный корень для всех статей помощи, но это как вам будет удобно.

2. Создаём статьи помощи при заполнении форм


Я использую общий шаблон How-To article. Там всё структурировано за нас, нужно только описать назначение формы в начале и поля формы в виде списка.

Важно каждой статье дать уникальную метку, относящуюся только к этому типу заявки. Я использую шаблон projectname-tickettype, так не запутаешься.

Важно чтобы статьи были без Restrictions.

3. Заходим в свойства проекта (Project Settings) в ServiceDesk и кликаем Knowledge Base


Линкуем к Confluence Space созданном на шаге 1. В поле Доступ (Access) выбираем всех, кто имеет доступ к Service Desk. Для каждого типа тикета указываес нужную метку (все метки должны быть разными, иначе клиенты увидят слишком много статей).

4. Кликаем на Типы заявок (Request Types)


В текущей версии ServiceDesk не совсем очевидная возможность использовать в подписи (Description) типа заявки точно такую же разметку, как и в Description тикета. Поэтому для каждого типа заявки делаем примерно такой Description:

Заявка на установку нового оборудования ^_[помощь|url]_^

В итоге получаем в подписи заявки маленькую ссылку вроде книжных, кликая на которую пользователь тут же получит описание заявки и как ему заполнять поля в отдельном окне браузера. Профит.

Что же взять в качестве url?

Здесь есть небольшая хитрость. Чтобы в Confluence попал непривилигированный пользователь, ему нужен своеобразный токен от Jira, который сообщает Confluence что информацию показать можно. Чтобы его сгенерировать, нужно создать заявку нужного типа с парой слов из статьи. Jira автоматически добавит на страничку тикета Ссылку на статью Confluence. Когда вы наведёте на неё мышку, справа появится кнопка Поделиться (Share). Кликайте на неё и в комментарии увидите нужный url, который останется только скопипастить в подпись заявки.

Результат


Непривилегированные пользователи без каких-либо ежемесячных затрат на человека имеют доступ к современной системе управления заявками. Администраторы пользуются любимой Jira и генерят статьи помощи в привычной Confluence. Пользователей обучать не надо, просто показать один раз. Все довольны.

П.С. кроме ссылки в подписи к заявке можно нагенерить кучу статей, относящихся к каждому типу заявки, после прочтения которых теребить администраторов будут ещё меньше. Достаточно использовать ту самую метку, что вы сгенерили на шаге 2. Тогда при заполнении поля Summary и переходе на другой элемент html ServiceDesk поищет текст Summary среди статей с этой меткой и покажет результаты.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

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

    0

    Здравствуйте! Подскажите, какое участие Вы принимали в настройке системы (JSD, Confluence)? Являетесь ли Вы администратором какой-либо из систем?
    Или же это отзыв пользователя(клиента) Service Desk? Или администратора проекта JSD?

      0
      Я по совместительству администратор Jira Software, ServiceDesk и Confluence. Сейчас в облаке, раньше в серверной версии. Писал плагины, автоматизировал систему управления программистами :)
      0
      Спасибо!
      Подскажите, как администратор поработавший с Jira как на сервере, так и в облаке, проявляется ли какая-либо ограниченность в функционале плагинов в облаке?
      Особенно интересует реальный опыт сравнения JMWE, Scriptrunner.
      Какие плагины Вы бы ещё порекомендовали из своей практики?
        0
        1. Большинство серверных плагинов в облаке не работают.
        2. Те, что работают, функционируют «под присмотром» Atlassian и если операция занимает слишком долгое время — Jira её останавливает. Например, один и тот же скрипт для JMWE может прекрасно работать для 10 тикетов, но отваливаться для 11ти (имеется в виду отфильтровать тикеты по JQL и применить к ним операцию).
          0
          очень интересный факт. спасибо Вам за информацию!

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое