В одной компании мы увидели серьёзный разрыв: в системе поддержки было 148 инцидентов по одной и той же проблеме, а в бэклоге разработки — всего 3 дефекта.
Разработчики считали, что проблема редкая. Поддержка знала, что она — массовая.
Проблема была не в багаx, а в том, что сигнал из поддержки почти не доходил до разработки.
Привет, меня зовут Артем Герасимов, я владелец продукта SimpleOne SDLC. Сегодня я расскажу вам, как грамотно выстроить процесс развития продукта от инцидента до релиза улучшений.
Где рвется связь между продуктом и поддержкой
В большинстве компаний техническая поддержка и разработка живут в параллельных мирах. Поддержка решает инциденты, разработка выпускает фичи — и между ними почти нет обратной связи. Давайте разберемся, где именно происходит этот разрыв.
Работают в разных системах
Техподдержка обычно сидит в Service Desk системе, разработка — в таск-трекерах вроде Jira.
Когда нужно создать задачу на разработку, это превращается в целое испытание: нужно отправить либо письмо на почту, либо сообщение в личку, либо создать тикет руками, либо вообще — все и сразу. Даже если есть интеграция по API, у команды разработки, скорее всего, нет доступов к Service Desk, а у поддержки — к полноценным задачам в системе разработки.
Из-за этого происходит потеря контекста: инцидент обслуживается в одной системе, но как только нужно передать его разработке — вся история теряется. Приходится либо дублировать описание, либо оставлять ссылки, которые работают не для всех.
Когда я работал в крупной страховой компании, мы много времени уделяли инцидентам. Мы работали в Jira, техподдержка — в своей системе. У нас была выстроена автоматизация через API, но при переносе терялась информация об ответственном человеке из техподдержки, к которому можно прийти с вопросом. И даже если перенести ФИО, контактов нет — они хранятся в другой системе. Из-за этого приходилось идти к руководителю, и он уже перенаправлял. Это была безумная трата времени, которого и так всегда недостаточно.
Техническая интеграция не решает главного — конфликта целей, ответственности и приоритетов.
Важно договориться на организационном уровне:
кто владеет инцидентом до передачи в разработку (обычно техподдержка);
кто отвечает после передачи (разработка берет на себя дефект);
кто отвечает за корневую причину (владелец продукта или техлид команды);
какие SLA действуют на передачу задачи в разработку (например, критичные инциденты — в течение 4 часов);
какой минимум контекста должен быть зафиксирован при передаче (описание, шаги воспроизведения, скриншоты, контакты ответственного из поддержки).
Без этих правил интеграция остается косметической мерой: системы связаны, но люди по-прежнему не понимают, кто за что отвечает.
Разные инструменты и объектные модели
Поддержка оперирует инцидентами, проблемами и запросами на обслуживание. Разработка работает с фичами, дефектами и техническими задачами. Это не просто разные названия — это разные подходы к описанию одной и той же реальности.
Когда команда разработки видит дефекты, она должна еще понять, связаны ли они с инцидентами или команда нашла их внутри. Без прозрачной связи между инцидентом и дефектом становится сложно приоритизировать работу. Классно, когда разработка видит свои дефекты в связке с инцидентами или управляет инцидентами напрямую внутри своего бэклога — тогда появляется понимание масштаба проблемы.
Но связать сущности в системах недостаточно. Нужны критерии перехода между этапами и ответственные роли:
при каких условиях инцидент превращается в дефект (например, если проблема повторяется более трех раз или затрагивает ключевую функциональность);
кто принимает решение о передаче (обычно старший специалист поддержки или руководитель линии);
какой статус присваивается дефекту при создании и когда он переходит в работу;
кто отвечает за валидацию исправления (разработка тестирует код, поддержка проверяет решение проблемы на проде).
Без этих правил связь между сущностями останется декларативной: формально инцидент связан с дефектом, но непонятно, кто и что с этим должен делать.
Организационный разрыв
Команды подчиняются разным руководителям, говорят на разных языках и часто имеют противоречащие друг другу цели. Использование разных систем учета затрудняет коммуникацию и передачу знаний между специалистами.
Проблема усугубляется тем, что KPI команд структурно противоречат друг другу:
поддержка оптимизирует скорость закрытия тикетов — чем быстрее закрыл, тем лучше показатели;
разработка оптимизирует velocity фич — сколько пользовательских историй завершили за спринт;
бизнес оптимизирует сроки релизов перед заказчиком — важно выпустить в срок, что было обещано.
В результате поддержка закрывает инциденты временными решениями, чтобы не портить статистику. Разработка игнорирует дефекты, потому что они не считаются за velocity. Бизнес требует новые фичи, откладывая исправление технического долга. Без выравнивания этих KPI или введения общих метрик качества (например, процент повторяющихся инцидентов, время от обнаружения проблемы до исправления корневой причины) разрыв неизбежен.
Нет процесса передачи и приоритизации
Тикеты закрываются временными решениями, корневые причины не анализируются. Поддержка решает проблему сама, чтобы «не тратить время», «не отвлекать разработчиков».
Продуктовый бэклог формируется в отрыве от данных поддержки — часто выигрывает бизнес, потому что он более настойчивый. Инциденты не решаются, технический долг копится. Без прозрачной приоритизации команда может выпускать много фичей, но основная функциональность будет падать.
Психологический барьер
Разработчики считают поддержку не своей зоной ответственности. И это отчасти справедливо: если весь день разбирать баги, когда успевать делать "настоящий" продукт?
Решение — в выстраивании единых целей для всей компании. Если разработка, поддержка и бизнес знают, куда движется компания, они движутся в одну сторону. А работа с инцидентами становится частью общей цели, а не отвлечением от нее.
Но одних целей недостаточно. Нужны механизмы, которые сделают участие разработки в поддержке предсказуемым и управляемым:
модель on-call дежурств — назначается ответственный разработчик на неделю или спринт, который первым реагирует на критичные инциденты;
ротация участников — дежурство распределяется между членами команды по графику, чтобы нагрузка не падала на одного человека;
лимит времени на инциденты — например, не более 20% времени спринта на работу с продакшн-проблемами, остальное — на запланированные задачи;
эскалация по критичности — мелкие инциденты решает поддержка, средние попадают в бэклог, критичные прерывают текущую работу дежурного.
Без этих правил участие разработки в поддержке будет восприниматься как постоянные прерывания и потеря контроля над планированием, а не как структурированная часть рабочего процесса.
Почему инциденты должны влиять на бэклог
Инциденты показывают, где продукт не оправдывает ожиданий пользователей. Если постоянно падает ключевая функциональность продукта — это не просто технический сбой — это сигнал о том, что с продуктом что-то происходит, и если не решить корневую проблему — клиенты могут уйти к конкурентам. Поэтому важно сортировать бэклог относительно инцидентов, потому что они подсвечивают критические проблемы.
Кроме инцидентов, ценную информацию дают запросы на улучшения. Когда пользователи массово пишут, что функциональность неудобна, это повод пересмотреть приоритеты. Даже если инцидента как такового нет, неудобство может привести к оттоку пользователей.
Повторяющиеся инциденты формируют технический долг
Когда одна и та же проблема возникает регулярно, но каждый раз решается временным патчем, копится технический долг. Поддержка правит данные, запускает скрипты восстановления, а корневая причина остается нетронутой.
Это приводит к тому, что при массовом подключении новых пользователей или включении функциональности все начинает падать. Систему не обкатали, сформировали технический долг — и получили ночное дежурство с аварийными исправлениями.
Запросы пользователей дополняют продуктовую гипотезу
Запросы на обслуживание и улучшения показывают реальные потребности, которые команда могла не учесть при планировании. Пользователи подсказывают, что им действительно нужно, а не что, по мнению продакта, должно быть нужно.
Важно не воспринимать каждый запрос буквально, но анализировать тренды. Резкий рост обращений определенного типа — сигнал к действию.
Метрики качества становятся прозрачными
Связка инцидентов и дефектов позволяет отслеживать такие метрики, как:
Defect escape rate (доля пропущен��ых дефектов) — сколько дефектов утекло на прод;
MTTR (Mean Time To Repair) дефектов — среднее время исправления;
Плотность дефектов — сколько дефектов найдено на этапе тестирования и после релиза.
Когда система позволяет видеть внутри релиза связь между дефектами и инцидентами, можно намного качественнее анализировать проблемы. Это помогает понять, где в процессе разработки возникают слабые места.
Рекомендации
Теперь перейдем к практике. Важно понимать, что это не разовое внедрение, а трансформационный процесс, который потребует времени, ресурсов и готовности к изменениям.
Шаг 1. Понять, как работает сейчас
Прежде чем что-то менять, нужно разобраться, как устроен текущий процесс. Где возникают узкие места? Сколько времени проходит от регистрации инцидента до его попадания в бэклог разработки? Теряется ли информация при передаче между команды?
Проведите аудит: проследите путь нескольких типичных инцидентов от момента обращения пользователя до закрытия. Зафиксируйте, где происходят задержки, где информация дублируется или теряется, где требуется ручная работа.
Соберите базовые метрики, которые станут точкой отсчета:
среднее время от инцидента до создания дефекта;
процент инцидентов, которые вообще попадают в разработку;
количество повторяющихся инцидентов по одной причине;
процент дефектов, обнаруженных на проде (defect escape rate);
среднее время исправления критичных проблем.
Эти данные покажут масштаб проблемы и помогут оценить эффект от изменений через несколько месяцев.
Шаг 2. Выбрать пилотную команду
Не пытайтесь внедрить новый процесс сразу во всей компании — это путь к саботажу и хаосу. Начните с одной команды, которая:
работает над продуктом с активной пользовательской базой;
получает достаточно инцидентов для тестирования процесса;
открыта к экспериментам и готова давать обратную связь.
Пилот позволит отработать процесс, выявить проблемы и скорректировать подход до масштабирования на друге команды.
Шаг 3. Синхронизировать команды и данные
На основе выявленных проблем нужно понять, как синхронизировать работу отделов. Есть несколько вариантов:
Идеальный вариант — когда поддержка и разработка работают в одной системе. SimpleOne SDLC и SimpleOne ITSM на единой платформе позволяют создавать дефекты прямо из инцидентов с сохранением всего контекста.
Синхронизация по API. Если единая система невозможна, настройте автоматическую передачу данных между Service Desk и таск-трекером. Важно, чтобы при создании дефекта из инцидента сохранялись описание, шаги воспроизведения, вложения, контакты ответственного и связь между сущностями.
В крайнем случае — мессенджер и почта. Но это худший вариант, потому что теряется контекст, нет истории изменений, сложно отследить статус.
Шаг 4. Запустить triage и обучить поддержку
Triage — это встреча, на которой представители поддержки и разработки разбирают новые инциденты и решают:
какие закрыть временным решением;
какие превратить в дефекты;
какие дефекты критичны и требуют немедленной реакции.
Техническая поддержка должна уметь не просто отправлять дефекты в разработку, но и делать это правильно:
объединять несколько похожих инцидентов в один дефект, чтобы не создавать дубли;
формулировать описание так, чтобы разработчик мог воспроизвести проблему;
определять приоритет на основе влияния на бизнес и количества затронутых пользователей.
Проведите тренинги для поддержки: как работать с системой разработки, как описывать баги, как определять критичность.
Шаг 5. Внедрить SLA и правила передачи
Без четких правил процесс развалится. Договоритесь о SLA на разных этапах:
критичные инциденты передаются в разработку в течение 4 часов;
высокоприоритетные — в течение рабочего дня;
средние и низкие — на ближайшем triage.
Шаг 6. Приоритизировать на основе данных
Когда дефекты попадают в единый продуктовый бэклог, их нужно правильно приоритизировать. Дефект, связанный с десятками инцидентов, скорее всего важнее, чем тот, на который пожаловался один пользователь.
Внедрите систему приоритизации, учитывающую:
количество связанных инцидентов;
критичность для бизнеса;
количество затронутых пользователей;
наличие временного решения и его стоимость (сколько времени тратит поддержка на обходной путь).
Прозрачная связь инцидентов и дефектов позволяет владельцу продукта видеть масштаб проблемы и принимать обоснованные решения о приоритетах. Это избавляет от ситуации, когда команда разработки внезапно получает срочную задачу «проверить инцидент» в середине спринта.
Шаг 7. Выстроить работу с KEDB
База данных известных ошибок (Known Error Database) — ключевой инструмент управления техническим долгом. Здесь хранится информация о проблемах, для которых найдены временные решения, но корневая причина еще не устранена.
Важно различать два типа проблем:
Проблемы с данными
Если у пользователей не сохраняется почта или фамилия, это критично, но не обязательно бросать все и исправлять корневую причину прямо сейчас. Можно написать скрипт восстановления данных, который будет работать автоматически, а исправление корневой причины запланировать в бэклоге.
Корневые причины функциональных проблем
Их не всегда нужно исправлять немедленно, если есть временное решение. Но важно зафиксировать в KEDB и не забыть включить в планирование.
Такой подход позволяет разгрузить бэклог: вместо реактивных инцидентов, которые надо править прямо сейчас, появляются более пассивные задачи, которые можно брать постепенно.
Шаг 8. Обеспечить обратную связь после релиза
Цикл не заканчивается на релизе. После того как дефект исправлен, нужно:
уведомить техподдержку об исправлении;
обновить информацию в KEDB;
информировать пользователей, которые столкнулись с проблемой.
Если есть интеграция между системами, это происходит автоматически. Пользователь видит на портале самообслуживания, что его проблема взята в работу, исправлена и выпущена в релизе. Техподдержка получает уведомление и может отменить временные скрипты или временные решения.
Замкнутый цикл обратной связи показывает пользователям, что их обращения не уходят в пустоту, а действительно влияют на развитие продукта.
Шаг 9. Пересмотреть метрики через 3–6 месяцев
После запуска пилота дайте процессу время устояться. Через 3–6 месяцев вернитесь к baseline-метрикам и сравните результаты:
сократилось ли среднее время от инцидента до создания дефекта;
увеличился ли процент инцидентов, попадающих в разработку;
снизилось ли количество повторяющихся инцидентов;
улучшился ли defect escape rate;
сократилось ли среднее время исправления критичных проблем.
На основе этих данных скорректируйте процесс и масштабируйте на другие команды.
Резюме
Разрыв между поддержкой и разработкой — это не технический, а организационный вопрос. Большинство компаний думают, что проблема в интеграции систем.
На практике проблема почти всегда в другом: инциденты просто не имеют владельца в разработке.
Когда поддержка и разработка работают как единая команда, продукт начинает развиваться не только за счет продуктовых гипотез, но и на основе реального опыта пользователей — а это и есть настоящее непрерывное совершенствование.
Отдельная благодарность Яне Панфиловой за помощь в написании и оформлении статьи
