Как передать информационную систему, разработанную командой продукта на поддержку и дать тимлиду и разработчикам спокойно спать по ночам
Проблемы
1. Команды создают информационные системы без продуманной поддержки.
2. Вопросы повторяются: регистрация, зависания, ошибки.
3. Разработчики отвлекаются от основной работы, участвуя во встречах с бизнесом.
Решение
1. Создать процесс приёмки ИС (информационных систем) на поддержку.
2. Организовать поддержку заранее и системно, с документами и ролями.
Ключевые роли
1. Архитектор процесса (АПП) — проектирует структуру и шаги процесса.
2. Владелец процесса — отвечает за результат, контролирует выполнение и улучшения.
3. Менеджер процесса (РМ) — управляет операциями, коммуникацией и сроками.
Как строили процесс
1. Заполняли паспорт процесса: требования, ограничения.
2. Создавали BPMN-схемы и пошаговый план, включая:
- Назначение инженера поддержки.
- Подготовка документации и инструкций.
- Настройка мониторинга и алертов.
- Проведение демо и запуск SLA.
- Принятие ИС на поддержку с чеклистом.
Как внедряли
1. Провели пилот на 8 ИС, затем обучение и раскатку на весь холдинг.
2. Запретили выкатывать ИС в прод без передачи на поддержку.
Результаты
1. Ясность на всех этапах: кто за что отвечает и на каком этапе процесс.
2. Продуктовые и поддерживающие команды синхронизированы.
3. Введены KPI по скорости прохождения ИС через процесс.
Точки роста
1. Включение ИС не от продуктов (например, инфраструктурных).
2. Дополнительное обучение инженеров.
3. Более точное измерение времени приёмки.
Главная победа
1. Убрали хаос: теперь поддержка не начинается «вслепую».
2. Процесс стал измеримым и управляемым.
6 лет работаю со сложными кросс-функциональными ИТ- проектами и процессами. Специализируюсь на клиентском направлении, поддержке, внутренних продуктах, инфраструктуре, немного digital.
Люблю сложное делать простым!
ecom.tech, Москва
Руководитель проектов