В декабре релиз стоит не как разработка. Он стоит как остановка продаж
Перед пиком продаж задача ИТ - не тащить в прод изменения, которые могут задеть точку возникновения денег.
Звучит как ограничение. На самом деле - это способ защитить выручку в период, когда цена ошибки максимальна.
Сколько стоит час простоя в декабре
В ритейле декабрь - это 20-25% годовой выручки. Концентрация максимальная.
Для компании с оборотом 1 млрд рублей в год:
- декабрь - около 200-250 млн рублей
- в день - 6-8 млн рублей
- в час пикового трафика - от 500 тысяч рублей и выше
Теперь вопрос: сколько стоит релиз, который кладет кассы на 2 часа в 20-х числах декабря?
Арифметика простая. Но я видел компании, которые до нее не доходили - потому что решение о релизе принималось не через P&L, а через "ну должны успеть до праздников".
Две реальные задачи ИТ перед пиком
Большинство ИТ-команд перед сезоном думают о фичах. Зрелые - о двух других вещах.
Первое - подготовить инфраструктуру к нагрузке.
Не в теории, а физически: кассы, весы, принтеры, рабочие места, каналы связи, мониторинг, дежурства, резервы критичного оборудования.
Все это должно быть проверено, задублировано и готово к замене в течение часа.
Второе - ввести мораторий на изменения в core revenue контуре.
Не "запрет ради запрета". Это governance изменений в денежном контуре.
Без финансового обоснования, без rollback-плана, без владельца риска - изменение не идет. Точка.
Известная ошибка дешевле неизвестной
Есть формулировка, которую я использую уже несколько лет:
В высокий сезон известная ошибка почти всегда дешевле неизвестной.
Если в системе есть баг, который вы знаете - известны симптомы, обходной путь, время реакции. Люди обучены. Скрипт готов. Потери прогнозируемые.
Если выпустили новый релиз и получили новый баг - вы ничего не знаете. Диагностика займет время. Откат - риск. А часы идут.
Именно поэтому мораторий - не техническое правило.
Это финансовое решение.
Как это работает на практике
В одном розничном контуре мы зафиксировали freeze-дату и сделали ее не ИТ-правилом, а управленческим правилом сезона.
После этой даты любые изменения в кассовом, товарном, ценовом и заказном контуре проходили только через короткий risk-review: что меняем, зачем именно сейчас, что ломается при ошибке, кто принимает риск, как откатываемся.
Большинство "маленьких доработок" после такого разбора само уходило в февраль.
Не потому что ИТ сопротивлялось.
Потому что у изменений впервые появлялась цена.
Что должно быть в freeze-правиле
Я обычно фиксирую пять вещей.
Дата заморозки.Четкая, не обсуждаемая. В одном контуре это было 26 октября. Чаще - середина ноября.
Список контуров, которые нельзя трогать.Кассы, цены, заказы, остатки, оплата, доставка, интеграции с маркетплейсами, лояльность.
Список исключений.ИБ-инцидент, законодательное изменение, критический дефект. Только это - и с двойным тестированием.
Владелец решения.Не "бизнес попросил", а конкретный руководитель, который принимает риск своей подписью.
Rollback-план и дежурный контур.На первые часы после любого изменения.
Это не бюрократия.
Это минимальная управляемость в максимально дорогой период.
Три группы изменений - и как меняется разговор
Главное - freeze должен быть оформлен не как просьба ИТ "давайте ничего не трогать", а как управленческое правило сезона.
Я разделяю изменения на три группы.
Запрещены до окончания пика:кассы, цены, оплаты, заказы, остатки, интеграции с маркетплейсами, доставка, лояльность.
Возможны только через отдельное решение:изменения с прямым влиянием на выручку, маржу, клиентский путь или учет.
Можно делать без захода в прод и core revenue контур:внутренние отчеты, подготовку будущих релизов, разработку и тестирование в непроизводственной среде.
После этого спор становится другим.
Не "ИТ опять тормозит".
А "кто готов принять риск остановки продаж ради этой доработки именно сейчас".
Скрытые издержки "одного маленького релиза"
TCO "маленького релиза" в пик часто начинается не в разработке.
Он начинается в дежурствах, откатах, ручных сверках, потерянных заказах, перегруженной поддержке и объяснениях перед бизнесом.
Ни один из этих пунктов не попадает в ROI-расчет фичи.
Все они попадают в OPEX следующего квартала или в потери декабря.
Кто принимает это решение
Если ИТ-директор умеет остановить изменения сам - он делает это превентивно, с аргументами, через P&L и сценарный анализ.
Бизнес слышит его, потому что язык общий.
Если не умеет или боится - давление "от бизнеса" продавит релиз.
И если что-то пойдет не так, вопрос "кто разрешил?" окажется без ответа.
Это не вопрос смелости.
Это вопрос позиции: умеет ли ИТ объяснять стоимость риска на языке денег - или только на языке технических ограничений.
Собственнику здесь достаточно задать один вопрос:
есть ли в компании четкая дата, после которой core revenue контур не трогают - и кто несет за это ответственность?
Если такой даты нет - компания не управляет риском декабря. Она каждый раз заново договаривается с удачей.