Рассмотрим ситуацию: существует компания, занимающаяся разработкой программного обеспечения (ПО). Для формализации бизнес-процесса нужно определить:
Для формализации бизнес-процесса с учетом рекомендаций ITSM нужно определить:
Наша компания небольшая, потому создаем в системе одну компанию для себя и несколько компаний для основных клиентов, имеющих возможность взаимодействовать с нами посредством нашей системы. В основном заявки создают Тестировщики, Менеджеры и сами Разработчики. Внешние клиенты также могут создавать заявки на устранение выявленных багов или на доработки функционала системы.
Практика подсказывает, что Администратору нужно дать права перевода из любого статуса в любой, но мы не будем отображать это на визуальной схеме.
Бизнес-процесс для Багтрекера выглядит следующим образом:
Следует отметить, что правила уведомлений могут быть настроены независимо от настроенных переходов статусов.
На практике бизнес-процесс может отличаться от представленного как в простую, так и в более сложную сторону; состав участвующих ролей и статусов может быть отличным.
Сервисы служат для логического объединения заявок в независимые группы. Если у вас несколько проектов по разработке ПО, например, «Разработка игры №1», «Разработка игры №2», то сервисами будут именно эти проекты. На разных сервисах могут быть разные Пользователи, разные бизнес-процессы, разные уведомления, разные сроки работ по заявкам и так далее.
Кроме того, у Сервиса есть понятие, как Этапы. При разработке ПО под этапами понимаются версии ПО. Этапы удобно использовать для того, чтобы определить, какие заявки на доработки или исправление ошибок наиболее критичны и должны быть отработаны в первую очередь. Менее критичные заявки откладываются на более поздние этапы развития ПО. Например, текущая версия ПО – 1.01 и существуют 3 этапа развития: Релиз 1.02, Релиз 1.03 и релиз 1.04.
В этом случае менеджер, отвечающий за разработку проекта, определяет первоочередность тех заявок на ошибки и доработки, которые должны быть отработаны к Релизу 1.02. При создании или редактировании заявки менеджер или исполнитель указывает в качестве этапа номер релиза, чтобы разработчик в дальнейшем мог применить простой фильтр по этапам для того, чтобы узнать, какие именно заявки он должен отработать к Релизу 1.02.
Ниже можно увидеть несколько примеров того, что видят различные пользователи, которые работают в системе в тот или иной момент работы над заявкой.
1
2
3
4
В уведомлении менеджер или разработчик видит, кто и когда создал заявку, какой у нее приоритет, есть ли вложенные файлы и т.д. Он может кликнуть по названию заявки и перейти сразу к карточке заявки в системе.
Формат уведомления настраивается через гибкие шаблоны уведомлений, вы можете сами определить, какие поля включать в email-уведомление.
На списке заявок Исполнитель, Тестировщик или Менеджер, не заходя на карточку заявки, подведя курсор к наименованию заявки, может узнать следующую информацию: Тема заявки, Описание заявки, имя Заявителя, срок выполнения, последний комментарий.
Так видит карточку заявки менеджер или, например, исполнитель. В нашем случае разработчик Петров Андрей взял заявку на себя, назначив себя исполнителем.
Ответственные разработчики могут быть назначены исполнителями на заявку автоматически в зависимости от категории заявки или от статуса заявки. Допустим, для категории «Ошибка» исполнителем по умолчанию может назначаться разработчик Савельев Илья, а для категории «Доработка» - Петров Андрей.
Так видит карточку заявки менеджер или, например, исполнитель. В нашем случае разработчик Петров Андрей взял заявку на себя, назначив себя исполнителем.
Ответственные разработчики могут быть назначены исполнителями на заявку автоматически в зависимости от категории заявки или от статуса заявки. Допустим, для категории «Ошибка» исполнителем по умолчанию может назначаться разработчик Савельев Илья, а для категории «Доработка» - Петров Андрей.
ОФильтры служат для ограничения выборки заявок по определенным критериям.
Тестировщик, заведя несколько заявок, может создать фильтр «Мои в работе», чтобы иметь возможность отобрать только те свои заявки, которые приняты в работу Разработчиками. Настройки фильтра будут следующие:
Результат выполнения фильтра покажет Тестировщику только те созданные им заявки, которые были приняты в работу Разработчиками (статус «В процессе»):
Для Исполнителя можно создать фильтр «Мои проверенные», применение которого выведет Исполнителю список тех его заявок, которые проверены Тестировщиком.
Настройки такого фильтра будут следующие:
Результат выполнения фильтра покажет Исполнителю те отработанные им заявки, которые проверил Тестировщик:
Менеджеру важно иметь представление о количестве заявок, открытых в рамках ближайшего релиза. Например, ближайший готовящийся релиз ПО – Релиз 1.02.
Менеджер создает для себя фильтр «Релиз 1.02 открыто» со следующими параметрами:
Применение фильтра покажет Менеджеру список заявок, открытых на Релиз 1.02:
Как мы видим, в работу над Релизом 1.02 пока еще не взята одна заявка.
В системе предусмотрен функционал, позволяющий прикладывать к Заявке скриншоты сразу из буфера обмена Windows в браузере IE, не прибегая к сторонним графическим редакторам для обрезки и сохранения скриншота. Функционал позволяет обрезать вложенные из буфера обмена скриншоты, выделять на них рамкой места, требующие отдельного внимания Разработчиков и давать скриншотам названия. В совокупности, все это позволяет разработчикам быстрее ориентироваться в предоставленной Заявителем информации.
Кнопка добавления скриншота доступна на карточке заявки в браузере IE:
В системе предусмотрен функционал, позволяющий авторизованному в рабочем домене пользователю авторизовываться в системе при первом обращении к ней через браузер IE, минуя стандартную системную форму ввода логина и пароля.
Иными словами, пользователь «проваливается» в систему сразу после того, как он обратится к ней через адресную строку браузера, закладку в браузере или ярлык.
Данный функционал очень удобен при работе с системой внутри локальной сети, где, как правило, все пользователи работают в домене, а следовательно, имеют доменные учетные записи, что позволяет приступить к работе с системой максимально быстро.
