Что проверить перед запуском продукта: чек-лист из 30 пунктов

Перед запуском не спрашивайте команду, «всё ли готово». Назначьте владельца каждого риска и запросите наблюдаемое доказательство. Пройдите 30 пунктов ниже по шести контрольным воротам. Критический пункт без доказательства означает CONDITIONAL GO с жёстким условием либо NO-GO — даже если дата уже объявлена.

Сначала создайте карточку запуска

Чек-лист работает только вместе с короткой карточкой решения. Укажите версию и аудиторию запуска, владельца решения, дату окна, критические риски, метрики здоровья, пороги остановки, способ отката и канал связи команды. Для каждого пункта ниже сохраните ссылку на доказательство: протокол теста, дашборд, сценарий, инструкцию или утверждённый текст.

Ворота 1. Ценность и границы запуска

Сначала докажите, что команда одинаково понимает, для кого и зачем запускается продукт. Здесь нельзя подменять наблюдение количеством сделанных функций.

• Сформулирован один приоритетный сегмент и конкретная ситуация использования, а не «все, кому может пригодиться».

• Ключевая проблема подтверждена наблюдаемым поведением или уже совершаемой работой пользователя.

• Ценностное предложение называет результат и механизм без превосходных слов и непроверяемых обещаний.

• Для первой версии явно записано, что входит в запуск и что сознательно остаётся за его границами.

• Определён следующий дорогостоящий риск, который должен уменьшить именно этот запуск.

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

Ворота 2. Пользовательский путь

Пройдите путь глазами нового пользователя на том же устройстве и с теми же ограничениями, которые будут у первой аудитории. Отдельно проверьте путь отказа: ошибка не должна превращаться в тупик.

• Новый пользователь может начать и завершить главный сценарий без устных подсказок команды.

• Регистрация, вход, восстановление доступа и выход проверены для применимых ролей.

• Пустые, загрузочные, ошибочные и повторные состояния объясняют следующий безопасный шаг.

• Цена, ограничения, согласия и необратимые действия показаны до подтверждения пользователем.

• Критический сценарий проверен с клавиатуры и на целевом мобильном экране без горизонтального переполнения.

Ворота 3. Качество, безопасность и эксплуатация

Зелёный build — только начало. Команда должна знать, как заметит деградацию, кто получит сигнал и как вернёт рабочую версию. Для безопасности используйте подходящий профиль требований, а не один автоматический скан.

• Релевантные unit, integration, end-to-end проверки и production build завершились успешно на точной версии кандидата.

• Критические требования безопасности проверены по явному профилю, а найденные риски имеют решение и владельца.

• Миграции данных испытаны на копии, для них записаны backup, восстановление и безопасный порядок выполнения.

• Мониторинг охватывает доступность и ключевые части пользовательского сценария, а оповещения доходят ответственному.

• Откат или выключение функции проверены практически и укладываются в допустимое для продукта время восстановления.

Ворота 4. Измерение и обучение

До первого пользователя решите, что будет считаться здоровым запуском. Не меняйте формулу после того, как увидели неудобный результат.

• Для главного результата определены событие, единица измерения, окно и источник данных.

• Для защитных метрик заданы пороги деградации: ошибки, задержка, отказ, жалобы или другая цена риска.

• События аналитики проверены на тестовом сценарии без передачи лишних персональных или секретных данных.

• Существует исходная точка сравнения либо честно зафиксировано, что baseline пока отсутствует.

• Назначены время первого обзора, участники и заранее записанные варианты решения по результатам.

Ворота 5. Коммуникация и поддержка

Запуск не заканчивается нажатием кнопки. Пользователь должен понимать изменение, а команда поддержки — воспроизвести проблему и быстро передать её владельцу.

• Название, описание и обещание продукта согласованы между интерфейсом, письмом, справкой и командой продаж.

• Инструкция объясняет первый полезный результат и известные ограничения без рекламного тумана.

• Поддержка получила сценарии частых вопросов, признаки критической проблемы и маршрут эскалации.

• Для внешней коммуникации указаны владелец, время отправки, аудитория и способ исправить ошибочное сообщение.

• Подготовлен канал сбора обратной связи с согласием на обработку данных там, где оно требуется.

Ворота 6. Решение и первые 72 часа

Финальная встреча нужна не для отчёта о проделанной работе, а для решения по остаточному риску. Не считайте CONDITIONAL GO удобным способом проигнорировать красный пункт: условие должно иметь владельца, срок и ограничение аудитории.

• По каждому незакрытому пункту записаны риск, временная мера, владелец и крайний срок.

• Размер первой аудитории и темп расширения соразмерны наблюдаемости и возможному ущербу.

• Один человек имеет полномочие остановить запуск при достижении заранее согласованного порога.

• На первые 72 часа назначены дежурства, окна проверки метрик и единый журнал решений.

• Запланирован разбор с фактами: что ожидали, что произошло, чему научились и какое изменение следует дальше.

Как вынести решение

Удобное правило: если команда не может показать доказательство за несколько минут, пункт не закрыт. Ссылка на документ полезнее устного «это у нас есть», но и документ не считается доказательством, если он относится к другой версии продукта.

Пример: запуск нового тарифа

Команда сервиса хочет открыть новый тариф десяти процентам клиентов. Факт: главный путь оплаты прошёл end-to-end, события активации и отказа видны на дашборде, поддержка знает ограничения. Допущение: объём обращений останется близким к текущему. Порог остановки команда фиксирует до запуска на основе своей обычной нагрузки. Решение — CONDITIONAL GO только если включение можно остановить, а дежурный видит обращения и ошибки в согласованные окна.

Через 72 часа команда сравнивает наблюдаемые события с исходной точкой и отдельно читает причины отказов. Она не объявляет успех по одному росту оплат, если одновременно ухудшился возврат средств или пользователи не понимают условия. Следующий шаг выбирается из фактов: расширить аудиторию, исправить узкий этап, продолжить наблюдение или откатить версию.

Практический следующий шаг

Скопируйте поля карточки запуска в рабочий документ, назначьте владельцев шести ворот и проведите 45-минутную встречу только по красным и неподтверждённым пунктам. Не обсуждайте дизайн заново, если он уже проверен: запросите доказательство, зафиксируйте риск и вынесите одно из трёх решений.

Проведите учение до открытия доступа

За день до окна запуска разыграйте один реалистичный сбой на точной версии кандидата. Например, новый пользователь не завершает оплату, событие аналитики перестаёт поступать или поддержка получает сообщение без достаточного контекста. Участники не должны заранее знать подробный сценарий. Наблюдайте, кто замечает сигнал, где ищет данные, кому передаёт решение и сколько ручных согласований требуется. Цель учения — проверить рабочий маршрут, а не оценить людей.

После учения отделите дефект продукта от дефекта готовности. Первый требует исправления или ограничения запуска. Второй может означать неясную ответственность, недоступный дашборд, устаревшую инструкцию или отсутствие права выполнить откат. Для каждого разрыва назначьте владельца, доказательство закрытия и срок до финального решения. Не заменяйте повторную проверку обещанием «разберёмся по ходу»: под нагрузкой неопределённость становится дороже и затрагивает уже реальных пользователей.

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

Завершите запуск отдельным разбором, даже если инцидентов не было. Сопоставьте фактическую аудиторию, пользовательские действия, защитные метрики и нагрузку на поддержку с карточкой запуска. Запишите, какие предположения подтвердились, какие проверки оказались бесполезными и что нужно изменить в следующем чек-листе. Не объявляйте продукт полностью безопасным по результатам короткого окна: решение относится только к проверенной версии, масштабу и условиям. Следующее расширение требует нового, пусть и сокращённого, прохода по рискам.

Проверьте откат как пользовательский сценарий, а не только как техническую команду. После возврата версии вход, основной путь и сохранённые данные должны оставаться в ожидаемом состоянии, а поддержка — знать, что сообщить затронутым людям. Если изменение данных необратимо, обычный rollback может быть ложным обещанием; тогда нужен отдельный план совместимости и восстановления. Зафиксируйте эту границу в решении до запуска, чтобы команда не обнаружила её во время инцидента.

Что читать дальше

• 12 тестов спроса для бизнес-идеи

• Матрица выбора между самозанятостью, ИП и ООО

• Шаблон понятного ценностного предложения