🔒Открыть пост
и посмотреть медиа
и посмотреть медиа
SLA поддержки vs фичи: как не убивать разработку «срочняками»
Клиент: «Нужно быстро поправить».
Менеджер в разработку: «Там срочно».
Разработчик снялся с фичи.
Фича сдвинулась.
Потом ещё одна «маленькая правка».
Потом ещё.
Через месяц все удивляются: почему развитие стоит на месте?
Обычно дело не в том, что команда плохо работает. И даже не в том, что «нет правил».
Дело в том, что две разные вещи свалили в одну кучу: что это за задача и насколько она срочная.
Это две независимые оси, а не одна лесенка.
Ось 1. Что это за задача
— Инцидент — что-то сломалось и бьёт по бизнесу: сайт не открывается, не проходит оплата, не оформляется заказ.
— Запрос на поддержку — рабочая правка: поправить блок, текст, картинку, мелкую ошибку с обходным путём.
— Плановая поддержка — мелочёвка, обновления, контент. Копится в пакет и выходит планово. — Развитие — новые фичи, интеграции, личные кабинеты, автоматизация.
Ось 2. Насколько это срочно
Приоритет — это не отдельный «тип задачи», а результат: влияние на бизнес × срочность.
Это базовая логика ITSM (IT Service Management — управление IT-сервисами): сначала оцениваем влияние и срочность, и только потом назначаем приоритет, окна реакции и порядок эскалации.
И вот тут ломается привычная интуиция:
— фича может быть срочной, например релиз к выставке;
— баг может быть некритичным, например косметика на старой странице;
— «срочная поддержка» — это не отдельный вид работы, а высокий приоритет у конкретного запроса.
Поэтому удобнее держать в голове не список «1, 2, 3, 4», а раскладку «тип × приоритет»: по строкам — что за задача, по колонкам — приоритет (а сам приоритет считаем по влиянию и срочности).
Тогда видно: критичный инцидент летит вперёд всего, а «срочную» хотелку можно спокойно поставить в очередь.
SLA — это про две цифры, а не про одну
Частая путаница: SLA считают только «временем, когда отреагируют».
На деле обязательств минимум два:
— время реакции — за сколько задачу взяли в работу;
— время решения / восстановления — за сколько починили.
И SLA закрывает эксплуатацию — инциденты и запросы на поддержку, у них просто разные окна.
А развитие живёт не под SLA, а под сроками роадмапа и спринтов — это другой тип обязательств.
Например, условно:
инцидент — быстрая реакция и восстановление в рамках согласованного окна поддержки;
запрос — реакция в течение рабочего дня;
плановая правка — в ближайший релиз или пакет задач; фича — по срокам роадмапа и спринта.
Это не отраслевой стандарт, а пример логики. Конкретные цифры всегда зависят от проекта, тарифа, дежурства и критичности системы.
Срочность должна определяться не эмоцией в чате, а заранее согласованными правилами:
— насколько задача влияет на бизнес;
— сколько пользователей затронуто;
— есть ли обходной путь;
— есть ли риск потерь;
— нужно ли подключать дежурного;
— можно ли поставить задачу в план.
«Срочно» от клиента — это важный сигнал.
Но это не должно автоматически ломать весь план.
В JDPlex мы как раз стараемся строить поддержку не в режиме «кто громче написал, тот и прав», а через понятные правила.
Перед стартом поддержки важно договориться:
— что считается инцидентом;
— какие задачи идут в плановую поддержку;
— кто принимает решение по приоритету;
— какие есть окна реакции;
— когда нужна эскалация;
— какой объём времени резервируется под поддержку;
— кто дежурит, если проекту нужна повышенная доступность.
Потому что правил самих по себе мало.
Разработку защищает выделенная ёмкость: дежурный по поддержке, отдельный слот времени под мелкие задачи или заранее зарезервированный процент команды.
Тогда поддержка физически не должна каждый раз снимать человека с фичи.
Зачем это всё
SLA — не бюрократия.
Он защищает обе стороны.
Клиент понимает, когда получит реакцию. Команда понимает, что бросать сейчас, а что нет. Фичи не умирают под потоком мелких правок. А проект продолжает развиваться.
Потому что нормальная поддержка должна не убивать разработку, а создавать для неё стабильную основу.