Как связать обращения пользователей внутренних систем с задачами разработчиков?

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

Почему обращения теряются после выпуска продукта

Компании продолжают развивать собственные системы, и в разработке у крупных предприятий заняты десятки и сотни сотрудников. Работа над продуктом при этом не заканчивается на выпуске в промышленную эксплуатацию. Пользователи пишут в службу поддержки, что не работает поле, что-то сломалось или нужна новая функциональность. Если служба поддержки и разработчики работают в разных системах, обращение приходится вручную пересказывать в задачу, а пользователь не знает, когда исправление выйдет в релиз.

Как связать ITSM и разработку

В службе поддержки обращения регистрируют как инциденты, запросы на обслуживание или запросы на изменение. На стороне разработки у тех же обращений появляются свои сущности: инциденты становятся дефектами, а пожелания пользователей — задачами на доработку. Связь между ними должна сохраняться на всем пути: от обращения к дефекту, от дефекта к задаче, от задачи к релизу. Когда релиз выходит, по этой цепочке видно, какие обращения и изменения он закрывает.

Как это устроено в SimpleOne

На платформе SimpleOne служба поддержки работает в SimpleOne ITSM, а разработка — в приложении SimpleOne SDLC для управления жизненным циклом продукта. Оба приложения используют общую базу конфигурационных единиц (CMDB), поэтому инцидент, дефект, задача и релиз связаны с одной и той же системой или услугой. Через ту же CMDB к процессу подключается управление ИТ-активами. Подробнее о связи инцидентов с разработкой рассказали в выступлении на конференции NAG Conf Kazakhstan 2026.

С чего начать

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

Как устроено управление инцидентами — в документации SimpleOne ITSM, какие процессы входят в систему управления разработкой — на странице SimpleOne SDLC.