Как связать инциденты поддержки с дефектами разработки?

Инцидент и дефект нужно связать ссылкой в обе стороны. Поддержка создаёт дефект прямо из инцидента, к одному дефекту привязывает все инциденты с той же ошибкой, а заявитель узнаёт, когда исправление вышло в релизе. Тогда ошибка остаётся в системе со всей историей, и разработка видит, сколько обращений за ней стоит.

Что ломается, когда связи нет

• Теряется контекст. Разработчик получает «у клиента не работает отчёт» без скриншота, шагов и версии и тратит время на уточнения.
• Не видно масштаба. Десять клиентов пожаловались на одну ошибку, а разработка видит одно сообщение в чате и ставит его в конец очереди.
• Клиент не знает об исправлении. Ошибку исправили, но инцидент висит открытым, или его закрыли без ответа. Клиент пишет снова.
• Дубли. Одну ошибку заводят три раза разные инженеры поддержки.

Как выстроить передачу

1. Дефект создаётся из инцидента, а не пишется заново. Название, описание и вложения переходят в дефект, ссылка на инцидент сохраняется.
2. Один дефект — много инцидентов. Перед созданием дефекта инженер ищет уже заведённый и привязывает инцидент к нему. Число привязанных инцидентов — довод для приоритета.
3. Разработчик видит исходные инциденты и может задать вопрос в рабочих заметках, не уходя в чат.
4. Релиз закрывает круг. Когда исправление выпущено, это видно в инциденте, и поддержка сообщает заявителю.
5. Правила приоритета записаны. Какой приоритет инцидента даёт какой приоритет дефекта — договорённость поддержки и разработки, а не решение дежурного.

Так устроена передача после внедрения SimpleOne ITSM в ВЭББАНКИР: «Задачи, связанные с инцидентом, автоматически передаются в разработку и остаются видимыми для обеих команд в их собственных интерфейсах».

С чего начать

Договоритесь о минимальном описании дефекта из поддержки: шаги, версия, скриншот, сколько клиентов затронуто. Затем уберите передачу ошибок через чат: дефект только из инцидента. Проще всего это сделать, когда поддержка и разработка работают на одной платформе.

Договорённости с разработкой стоит закрепить соглашением. При внедрении SimpleOne ITSM в Positive Technologies среди задач была «автоматизация взаимодействия с командами разработки (R&D)», а в результате появилось «эффективное взаимодействие с командами разработки (R&D) благодаря настроенным OLA» — операционным соглашениям между подразделениями. Система обеспечивает «связность с системами разработки (R&D) для обработки обращений о дефектах и отслеживания статусов исправлений».

Как это сделано в SimpleOne ITSM и SDLC

В SimpleOne ITSM — системе управления ИТ-услугами российского вендора SimpleOne — из формы инцидента создают дефект в SimpleOne SDLC — приложении для разработки программных продуктов на основе гибких методологий. При этом:

• название берётся из темы инцидента, вложения и скриншот копируются;
• заявитель видит в инциденте уведомления о связанном дефекте;
• разработчики видят связанные инциденты;
• когда релиз с исправлением выпущен, в обсуждении инцидента появляется сообщение.

Как это настроить, описано в документации SimpleOne SDLC. Как перейти на такую связку, если поддержка и разработка сейчас работают в зарубежной системе, — в ответе о замене системы в своём контуре.