Я предпринимаю в IT

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