В небольших по размеру организациях как правило не больше одной установки Jira, Servicedesk и Confluence, которыми пользуются все, начиная от охранника и заканчивая QA. Как сделать так, чтобы и волки сыты, и овцы целы. В смысле чтобы непривилигерованные пользователи имели быстрый доступ прямо из заявок в wiki и при этом не лазали куда не следует, а администраторы не отвлекались от работы чтобы в сотый раз ответить на один и тот же вопрос.
Итак, у нас есть Jira Service Desk и Confluence. Есть портал для персонала, который позволяет делать заявки по самым различным поводам. Есть администраторы, которые заявки выполняют. И есть желание задокументировать все типы заявок по типу «а как это» «а что писать тут».
Почему ServiceDesk а не Jira Software? Потому что для создания заявок в ServiceDesk не нужна лицензия — достаточно добавить клиентов в нужные подразделения (организации). Лицензия нужна только для тех, кто заявки будет обрабатывать. Одно это позволяет безболезненно и без особых затрат «оцифровать» работу IT-департамента. А если подписаться на cloud-версию, вообще красота.
Почему Confluence? Да по тем же причинам, вы получаете продукт, который работает «из коробки» и интегрирован в Jira. Серверная версия устанавливается за полчаса, облачная — за пару минут. Готовые шаблоны, система прав доступа, да и программисты её любят.
Дальше предполагается что у вас естьполуготовый проект в ServiceDesk с несколькими типами заявок. И нужно обеспечить бухгалтера Машу онлайн-документацией по заполнению формы.
Это необязательно, но так легче сгруппировать все статьи, имеющие отношение к ServiceDesk, в одном месте. Я бы ещё порекомендовал отдельный корень для всех статей помощи, но это как вам будет удобно.
Я использую общий шаблон How-To article. Там всё структурировано за нас, нужно только описать назначение формы в начале и поля формы в виде списка.
Важно каждой статье дать уникальную метку, относящуюся только к этому типу заявки. Я использую шаблон projectname-tickettype, так не запутаешься.
Важно чтобы статьи были без Restrictions.
Линкуем к Confluence Space созданном на шаге 1. В поле Доступ (Access) выбираем всех, кто имеет доступ к Service Desk. Для каждого типа тикета указываес нужную метку (все метки должны быть разными, иначе клиенты увидят слишком много статей).
В текущей версии ServiceDesk не совсем очевидная возможность использовать в подписи (Description) типа заявки точно такую же разметку, как и в Description тикета. Поэтому для каждого типа заявки делаем примерно такой Description:
В итоге получаем в подписи заявки маленькую ссылку вроде книжных, кликая на которую пользователь тут же получит описание заявки и как ему заполнять поля в отдельном окне браузера. Профит.
Что же взять в качестве url?
Здесь есть небольшая хитрость. Чтобы в Confluence попал непривилигированный пользователь, ему нужен своеобразный токен от Jira, который сообщает Confluence что информацию показать можно. Чтобы его сгенерировать, нужно создать заявку нужного типа с парой слов из статьи. Jira автоматически добавит на страничку тикета Ссылку на статью Confluence. Когда вы наведёте на неё мышку, справа появится кнопка Поделиться (Share). Кликайте на неё и в комментарии увидите нужный url, который останется только скопипастить в подпись заявки.
Непривилегированные пользователи без каких-либо ежемесячных затрат на человека имеют доступ к современной системе управления заявками. Администраторы пользуются любимой Jira и генерят статьи помощи в привычной Confluence. Пользователей обучать не надо, просто показать один раз. Все довольны.
П.С. кроме ссылки в подписи к заявке можно нагенерить кучу статей, относящихся к каждому типу заявки, после прочтения которых теребить администраторов будут ещё меньше. Достаточно использовать ту самую метку, что вы сгенерили на шаге 2. Тогда при заполнении поля Summary и переходе на другой элемент html ServiceDesk поищет текст Summary среди статей с этой меткой и покажет результаты.
Итак, у нас есть Jira Service Desk и Confluence. Есть портал для персонала, который позволяет делать заявки по самым различным поводам. Есть администраторы, которые заявки выполняют. И есть желание задокументировать все типы заявок по типу «а как это» «а что писать тут».
Почему ServiceDesk а не Jira Software? Потому что для создания заявок в ServiceDesk не нужна лицензия — достаточно добавить клиентов в нужные подразделения (организации). Лицензия нужна только для тех, кто заявки будет обрабатывать. Одно это позволяет безболезненно и без особых затрат «оцифровать» работу IT-департамента. А если подписаться на cloud-версию, вообще красота.
Почему Confluence? Да по тем же причинам, вы получаете продукт, который работает «из коробки» и интегрирован в Jira. Серверная версия устанавливается за полчаса, облачная — за пару минут. Готовые шаблоны, система прав доступа, да и программисты её любят.
Дальше предполагается что у вас есть
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 среди статей с этой меткой и покажет результаты.
