Три с половиной года я строил поддержку в банке, который вырос с нуля до 3,5 миллионов клиентов. Главный вопрос всё это время был не «как сделать процесс стабильным», а «как сделать так, чтобы он пережил постоянные изменения». Это разные задачи, и их часто путают.

Стабильность через жёсткость не работает в гиперросте. Регламент, написанный под один продукт и одну страну, ломается на втором продукте и второй стране. Каждый запуск превращается в переписывание инструкций, а команда — в героев, которые держат процесс руками. Что сработало вместо этого.

Процесс строится вокруг сущностей, а не вокруг шагов. Обращение, инцидент, проблема — три объекта с понятными правилами перехода. Продукты и страны меняются, объекты — нет. Флоу инцидентов и проблем, спроектированный в первый год, прошёл через десятки запусков и путь от первых клиентов до миллионов. В него с самого начала было заложено, что он будет меняться: каждый сбой менял правила внутри конструкции, но ни разу — саму конструкцию.

Роль отделяется от человека раньше, чем появляется человек. Два с половиной года роль incident manager'а держали дежурные поверх основной работы — сначала двое, потом четверо, и я среди них. Но процесс с первого дня был описан так, будто его ведёт выделенная смена. Когда объём это оправдал, команда 24/7 вошла в готовую роль, а не в чью-то голову.

Адаптивность покупается автоматизацией рутины, а не гибкостью людей. Когда заметная часть эскалаций второй линии закрывается без участия человека, у команды появляется запас, чтобы переварить следующий запуск. Объём вырос в девять раз, команда — вдвое; это не про то, что люди стали работать втрое больше.

Итог, к которому пришёл: стабильность — свойство конструкции, а не дисциплины. Если процесс держится на том, что все «знают, как надо», он не стабильный, а хрупкий. Он выглядит спокойным ровно до следующего изменения.

А у вас как: что в поддержке или операциях сознательно зафиксировано намертво, а что оставлено подвижным — и по какому принципу проводите границу?