История о том, как родился регламент релиза
Факапы в IT — это нормально. Два факапа один за другим — нет!
Когда ваше демо проваливается — это плохо, если это происходит несколько раз подряд, уже можно говорить о системном сбое. И неважно, что служит причиной: клиентам все равно, виноват внешний сервис или вам «чуть-чуть» не хватило времени на тесты — они видят только неработающую систему.
Столкнувшись с такой ситуацией, наша команда была вынуждена остановиться и разобраться в причинах. По результатам ретроспективы, был создан регламент, который избавляет любой проект от 95% рисков, связанных с демо.
Премьера с осечкой: как Airtable развалил демо
На первый взгляд все выглядело идеально: функционал написан и задокументирован, проведено локальное тестирование, все работает как часы — статус задачи: «готово». Осталось показать результат клиенту. Однако между завершением работ с кодом и встречей с заказчиком прошло несколько недель — по меркам IT — целая вечность.
Итак, день X: клиент, инвестор, команда в сборе. Рассаживаемся, включаем экран, запускаем ключевую функцию — и… приложение «лежит». Оказалось, Airtable, который мы использовали для хранения и обработки данных, неожиданно ввел геоблокировку из РФ, и узнаем мы об этом не из сообщений системы, а из логов прямо во время презентации. Результат: демо провалено, клиент недоволен, репутация компании в нокдауне.
Ок, заказчик входит в положение и готов подождать. Мы понимаем ответственность, не спим, стараемся. Наконец приложение готово и в промежуточном окружении выглядит даже идеально. Однако на стенде клиента выясняется: интеграции снова не работают, данные не синхронизируются, часть экранов пустые. Мы снова показываем не функциональную систему, а набор ошибок.
Post mortem без эмоций: анатомия провала
Как люди серьезные, мы не стали устраивать истерик и «разбора полетов на эмоциях». Проблемы в итоге удалось устранить, репутацию спасти, но post mortem был обязателен: извлекать уроки из ошибок — признак профессионалов.
Начали с того, что собрали ключевых участников: разработчиков, тимлидов, продакт-менеджеров и DevOps-инженеров. Разложили события по временной шкале: что менялось за три недели до демо, за неделю, за день и в сам момент презентации.
Причины, если не углубляться в частности, следующие:
- отсутствие четкой точки «готовности к демо» с формальными критериями;
- нет обязательного этапа подготовки релиза с регламентом;
- контроль интеграций и внешних сервисов зависит от «человеческого фактора»;
- ответственность за финальное состояние системы размыта между участниками.
Формально и первый, и второй раз сбой произошел не по нашей вине. Но заказчику все равно, виноват Airtable, интеграция или космические лучи — он работает с нами и результатом этой работы видит сломанную систему. Решение стало естественным итогом анализа: нам нужен единый регламент релиза с чек-листами по этапам, плюс автоматизированные smoke-тесты и мониторинг критических интеграций.
Регламент, который закрывает 95% рисков
Путь от идеи до продакшена мы разделили на пять этапов. Для каждого составили чек-лист: простые проверки там, где нужна человеческая логика, автоматизация — везде, где возможно.
Этап 1. Планирование релиза
У планирования теперь есть конкретные действия и метрики: оценка задач, привязка к версии, реалистичная дата с буфером и контроль внешних факторов вроде API или инфраструктуры. Цель очевидна — учесть риски заранее, чтобы избежать пустых обещаний и обломов.
Чек-лист этапа
- Определяется функционал релиза → задачи добавляются в релиз.
- Каждая задача:
- имеет оценку;имеет исполнителя;привязана к конкретной версии/релизу.
- На основе оценок формируется предварительная дата релиза.
- Для каждого типа продукта заранее определяются особенности поставки и стенды.
Если сделать контроль этих пунктов системой, проекты чудесным образом преображаются: сроки перестают плавать, ожидания становятся прозрачны, а мелкие доработки на финале переходят в разряд погрешности, теплеют отношения с заказчиками, возникает доверие!
Этап 2. Разработка и функциональное тестирование
Теперь формализуем разработку: закрываем фичи, тестируем, делаем ревью. Цель этапа — убедиться, что код не просто написан, а полностью готов к следующему шагу.
Чек-лист этапа
- Основной функционал реализован согласно задачам.
- Проведено функциональное тестирование.
По нашему опыту, этого достаточно, чтобы исключить сюрпризы вроде внезапных прозрений о забытых требованиях заказчика вечером перед релизом.
Этап 3. Демо с клиентом
Следующий список превращает хаос фидбека в структурированный бэклог — ничего не теряется, приоритеты прозрачны и очевидны всем.
Чек-лист этапа
- Проводится встреча-демо.
- Фиксируются замечания, и уточняется доработка.
- При необходимости:
- создаются дополнительные задачи;корректируется дата релиза.
- После внесения правок повторно проводится функциональное тестирование и проводится регрессионное тестирование dev.
На выходе: все стороны в курсе прогресса, вероятность неожиданностей на релизе сведена к минимуму, доверие растет — заказчик видит ваше трепетное отношение к продукту, за который он платит свои деньги.
Этап 4. Подготовка к релизу (ключевой)
На этом шаге закрывается максимум рисков: от миграций и конфигов до мониторинга и финального прогона по ключевым сценариям.
Чек-лист этапа
- Ставится стори на подготовку prod релиза:
- задача на подготовку backend;задача на подготовку frontend;задача на подготовку документации (release notes, список артефактов, инструкция по деплою);задача на подготовку health-check сервисов (доступность API, интеграций, отсутствие критических ошибок).
- По готовности задач собирается релизный билд (backend / frontend / плагин / app).
- Проводится smoke-тест на prod. Цель: убедиться, что билд рабочий и смотрит на prod, все интеграции рабочие.
- Проводится мини-демо на prod. Цель: исключить ситуацию, когда билд выставлен не туда или настроен неверно.
Система на старте — backend настроен, frontend собран, документация заполнена, мониторинг включен, тесты и мини-демо подтверждают корректность. Риски закрыты, команда готова к деплою.
Этап 5. Деплой и передача клиенту
Премьера! После недель подготовки, проверок и перепроверок — момент, когда код уходит в боевое окружение.
Чек-лист этапа
- Задача по подготовке релиза переводится на клиента со всей актуальной информацией и закрепленной документацией.
- По возможности проводится smoke-тест со стороны клиента.
Блестящий релиз — это довольный клиент, а довольный клиент — это новые заказы, много новых заказов!
Пара советов в заключение
Ошибки неизбежны, особенно в сложных системах с множеством интеграций. Гораздо важнее, как команда на них реагирует. Столкновение с реальностью заставило нас признать, что апелляция к фразе «сломалось не по нашей вине» в общении с заказчиком — слабый аргумент для бизнеса. Вместо «раздачи слонов» мы формализовали процесс подготовки релиза и добавили слой автоматических проверок и мониторинга, полностью перестав полагаться на допущения.
Собрав регламент по горячим следам, мы сразу начали применять его к новым проектам и командам, результаты радуют:
- ни одного сорванного демо;
- все презентации проходят спокойно, без «ой, сейчас поправим»;
- период между завершением техработ и релизом сократился до 1–2 дней;
- команда стала меньше паниковать перед важными показами.
Копировать наш опыт 1:1 не обязательно. Вы можете взять наш план и настроить под себя. Например, небольшим командам можно просто сократить чек-листы и сфокусироваться на ключевом: демо, подготовка, дымовые тесты. Продуктовым компаниям с частыми релизами — глубже интегрировать проверки в CI/CD-пайплайн. Интеграционным проектам — усилить именно мониторинг и алерты по внешним сервисам.
Да! Рекомендуем положить регламент в общий доступ (Notion, Confluence, репозиторий), оформить как живой документ и регулярно обновлять после ретроспектив.
Если вам есть что добавить — велком в комменты, а хотите оптимизировать собственные процессы — пишите нам. Мы поможем адаптировать регламент под ваши цели!
.