Рецепт гладкого релиза: PMy на заметку

Всё ближе момент, когда мы выпустим в свет наше решение, свежее, новенькое и сияющее. Волнительно? Не очень, ведь мы его уже проверили со всех сторон.

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

На основе этого плана мы ставим задачи разработчикам и «аудиторам» — коллегам из других отделов, которые проводят ревью решения (да, это тоже лайфхак). Надеемся, эта шпаргалка пригодится для подготовки к релизу продукта в прод.

Инфраструктура

1. Подготовлены с нашей стороны и приняты заказчиком требования к UAT и Prod инфраструктуре на стороне заказчика. Подготовлена сама инфраструктура на стороне заказчика, предоставлен доступ.
2. (Для корпоративных мобильных приложений) Согласована схема распространения приложения на устройства пользователей (магазин приложений / MDM система / что-то еще). Заказчиком организована закупка устройств.
3. Настроен конвейер CI/CD и/или прописана технология обновления решения.
4. Продумана стратегия резервного копирования и восстановления и подготовлена соответствующая инфраструктура.
5. Продумана и реализована система технического мониторинга решения и диагностики проблем (ELK стек, средства мониторинга k8s и т.д.)

Первоначальное наполнение решения

1. Исторические данные. Решено, из каких источников и на какую глубину нужно мигрировать данные, есть технология/механизм/инструменты миграции.
2. Продумана процедура и подготовлены инструменты (утилиты, скрипты) проверки корректности (полноты, консистентности) мигрированных исторических данных.
3. Наполнены справочники.
4. Перенесены пользователи / оргструктура.

Интеграция

1. Проверена работоспособность интеграционных сервисов в UAT/Prod окружении. Есть версионность сервисов со стороны заказчика и/или с заказчиком согласована процедура подготовки к обновлению версии сервисов на их стороне.
2. Настроена панель мониторинга или инструменты доступности сервиса для «мгновенной» проверки, на чьей стороне проблемы.

Обучение пилотной группы пользователей

1. Подготовлены демо-стенды для демонстрации решения заказчику, организованы доступы, организованы раздачи приложения и тестовые девайсы.
2. Определена группа внедрения со стороны заказчика и привлечена на тестирование при подготовке релиза еще на QA окружении — проведены демонстрации.
3. Проведены итоговые тест-сессии/демо-сессии с пилотной группой пользователей.
4. Подготовлены материалы для пользователей: сценарии демонстрации, короткие “How-to” со скринами/роликами, демонстрирующими бизнес-действие.

Передача решения

1. План передачи исходников, план настройки серверов сборки на стороне заказчика.
2. План передачи исходников и ресурсов UI: макеты, UI kit, инструкция по использованию UI kit.
3. Подготовлены архитектурные документы (топология инфраструктуры, технология деплоя и т.д.) для передачи заказчику на эксплуатацию.
4. Проведен инструктаж и тренировочный деплой с админами заказчика.
5. Проверено, что еще нужно сделать для формальной/юридической передачи в эксплуатацию в соответствии с требованиями договора с заказчиком.
6. Проработана процедура постановки решения на техподдержку на стороне заказчика (первая линия) и на нашей стороне (вторая линия). Настроена система учета обращений.

Пользовательская документация

1. Руководство пользователя / инструкции в согласованном с заказчиком формате (сценарии, ролики и т.п.)

Бизнес-мониторинг

1. Выработано и согласовано с заказчиком понимание того, какие бизнес-показатели решения (KPI) мы будем отслеживать и анализировать.
2. Есть данные и инфраструктура для мониторинга бизнес-показателей: например, аналитический куб со статистикой продаж в системе, Grafana со статистикой активности пользователей.

Выбор момента для релиза

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