202 4
2 – 18+ лет в ИТ – 8+ лет в управлении ИТ – путь от QA до Delivery Lead в продуктовых компаниях – Delivery Lead ИТ-компании Qvant – опыт в роли IT Platform Owner крупной финтех B2B платформы Павел Турченко
3 Обеспечиваем цифровое развитие крупнейших поставщиков инженерного оборудования и комплексных технологических решений, таких как Sever Minerals, Техногрупп, Roitech и другие. систем сервисов команд сотрудников 11 1 3 9 97 Автоматизируем бизнес-процессы: – клиентского сервиса – управления продажами – учета и планирования – документооборота – логистики и поставок оборудования – финансов
4 Технологические метрики Инцидент и проблем менеджмент Качество процессов разработки Поддержка Техдолг – SLA по решению инцидентов и статистика их соблюдения – Количество инцидентов критичного уровня за определенный период и их динамика – Defect leakage критичных ошибок в продакшен – Время жизни дефектов до их закрытия в сравнении с SLA – Проактивное управление инцидентами и их критичностью – Управление обращениями по критичному и некритичному функционалу, SLA решения запросов – Объем приоритетного/критичного технического долга с акцентом на стабилизацию систем – План по устранению техдолга и сроки его выполнения
5 Примеры обратной связи – Проблемы сообщаются, но их решение откладывается – Растет количество повторяющихся обращений по тем же проблемам – ИТ не осознает, как сильно эти сбои влияют на бизнес – Критичные проблемы решаются только после эскалации От ключевых стейкхолдеров и бизнес-юнитов: От службы поддержки: – Приоритизируем быстрые исправления вместо устранения корневых причин От команды разработки: – Если важная для нас проблема находится на стороне другой команды, то бывает сложно добиться решения
6 Какие проблемы решали? Скорость решения инцидентов не соответствовала SLA; многие инциденты решались оперативно только после эскалации Отсутствие доверия к ИТ: анализ причин инцидентов проводился не всегда или поверхностно, а достигнутые договоренности могли не соблюдаться Повторяющиеся проблемы: аналогичные инциденты возникали снова и снова Количество проблем с критичным для бизнеса функционалом не уменьшалось со временем
7 Процессы, влияющие на стабильность систем и сервисов Инцидент и проблем-менеджмент Обеспечение непрерывной работы систем даже в случае серьезных отказов. Как решаем критичные проблемы, анализируем и устраняем причины их возникновения Управление качеством разработки Управление техдолгом и технологической целостностью Управление кросс-системным техническим бэклогом в единых приоритетах критичного функционала Уменьшение общего и критичного defect leakage и ускорение исправления дефектов Проактивный мониторинг Управление обратной связью и эскалациями Катастрофоустойчивость и отказоустойчивость Мониторинг инфраструктуры, качества данных, бизнес-сервисов Всесторонний анализ возникающих проблем и доведение их решения до результата
8 Как решали?
9 Как решали? Установили единую классификацию критичности систем 1. Определили приоритеты
10 2. Согласовали, какой функционал (кросс-системно) для бизнеса наиболее важен
11 3. Переопределили, что такое критичные инциденты, перепроверили SLA highest - если полностью упала система PRIO 0 - PRIO 2, либо недоступен бизнес-процесс с SLA = 24/7 high - если полностью упала система PRIO 3 - PRIO 5, либо недоступен бизнес-процесс с SLA = в рабочие часы
12 4. Проревьючили и согласовали уровни критичности дефектов и багов
13 5. Создали прозрачный инцидент и проблем-менеджмент процессы Создали прозрачный инцидент-менеджмент процесс и договорились, как обеспечивать SLA Инцидент-менеджмент - фокус и акцент внимания на решении конкретной проблемы здесь и сейчас (критичные и срочные инциденты) Т.е. если не можем оперативно (в ожидаемые сроки) пофиксить причину возникновения функционально, то ищем наиболее применимый обходной путь
14 6. Ввели обязательный процесс problem management Проблем-менеджмент – фокус на анализ и поиск причин, из-за которых произошла проблема и наиболее эффективных и технологичных способов их устранения.
15 Внедрение data-driven управления SLA по high / highest инцидентам за 2024 Оцифровали количество эскалаций со стороны бизнеса по стабильности работы функционала и контролируем качество их обработки Разделили обращения в поддержку по критичному и некритичному функционалу и отслеживаем динамику обращений по критичному функционалу Интегрировали эскалации в problem management процесс, создав единый бэклог необходимых технологических и процессных изменений Начали следить за количеством критичных инцидентов и выполнением SLA до закрытия 7 8 9 10
16 Еженедельная динамика обращений в поддержку критичному функционалу *Зеленым выделено, где поддержка решила запрос в рамках SLA, а красным - где выбились по времени
17 Управление фокусом Внедрили приоритизацию автоматизации тестирования в зависимости от критичности функционала Систематизировали и внедрили проактивный мониторинг качества ключевых данных Сформулировали критически важные метрики и внедрили в сквозные цели для руководителей и команд Установили единые кросс-командные приоритеты для техдолгового бэклога с фокусом на стабильность систем и сервисов 11 12 13 14
18 13. Сквозные цели для руководителей и команд
19 14. Единые приоритеты техдолгового бэклога Управление конфликтом приоритетов между бизнесом и ИТ : – прозрачные приоритеты – управление через квоты – защита задач и бюджета
20 15. Внедрили процесс планирования и реализации техдолгового бэклога *по аналогии с бизнес- бэклогом с привлечением стейкхолдеров Ввели 2 регулярные встречи: – Межкомандное демо + планирование на следующий PI (1,5 месячный интервал равный трем 2-х недельным спринтам) – Промежуточный синк по прогрессу реализации в середине интервала PI 2. Внедрили инструменты трекинга: – Канбан-доску для задач техдолга, в которой содержатся такие основные артефакты как ценность, cost, задействованные системы и приоритет по аналогии с ведением бизнес- бэклога PI в модели SAFe Прозрачность Коммит Единое инфополе
21 Дашборд скоупа работ в разрезе команд на PI Позволяет определять общий объем работ команды по техдолгу и соответствие выделенной квоте
22 Повысили уровень доверия Итоги: Ускорили процесс решения проблем Сформировали проактивный подход Формируем культуру принятия ответственности За качество разработки функционала отвечает вся команда, а не только QA Начали мониторить возникающие проблемы и их решать до обращения пользователей Мы стали решать проблемы значительно быстрее и даже в рамках SLA Сократилось количество эскалаций На определенном уровне зрелости поддержание стабильности ключевых бизнес-процессов может стать приоритетнее поставки новой ценности
23 Оценить доклад
