Управление релизами (Release Management) по ITIL

Разработка ИТ-систем, сервисов и приложений не заканчивается после внедрения. Улучшение и наращивание возможностей с учетом потребностей пользователей и roadmap продукта — важная часть жизненного цикла ПО. Запланировать и реализовать изменения помогает автоматизация управления релизами на базе service desk.

Чем полезно управление релизами по ITIL, какие этапы входят в этот процесс, какие плюсы приносит автоматизация — далее в материале. 

Что такое управление релизами

Релизы — это запланированные изменения в программном или аппаратном обеспечении. Они необходимы для устранения ошибок, повышения надежности, расширения функциональных возможностей продуктов. Нередко доработки призваны улучшить UX/UI-дизайн, совместимость продукта с внешним ПО или технические характеристики ПО — например, производительность.

Вне зависимости от целей реализация изменений должна быть упорядочена — добиться этого помогает управление релизами. Методология ITIL определяет его как комплексный процесс, объединяющий планирование, реализацию, тестирование и внедрение изменений в ИТ-продукт, а также контроль их качества при дальнейшем использовании.

В некоторых компаниях управление релизами — это составная часть управления изменениями. Однако эта практика призвана минимизировать инциденты и проблемы в  ИТ-инфраструктуре, в то время как процесс release management направлен на постоянное улучшение ПО.

Выделим основные выгоды, который дает внедрение управления релизами по ITIL:

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

Из каких этапов состоит управление релизами

Релизный цикл ПО в разных компаниях имеет свои особенности, но базовая структура процесса едина для всех и соответствует описанной методологией ITIL очередности.

Этап 1. Планирование. Собираются требования к продукту от клиентов или внутренних заказчиков. Для этого используются разные методы: проводятся опросы или анкетирование, анализируются поступившие в службу поддержки запросы. 

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

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

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

Этап 2. Сборка релиза. Релизная команда осуществляет намеченные изменения. Для удобства объемный по содержанию релиз разбивается на спринты, в ходе которых участники решают одну или ряд связанных задач. В один спринт выделяется переработка меню и вкладок банковского приложения, в другой – доработка системы поиска, в следующий – интеграция с чат-ботом.

Этап 3. Тестирование. Проводится проверка выполненных доработок в собственной ИТ-среде. При необходимости формируются группы пользователей, которым выдается доступ к бета-версии, чтобы выявить критичные баги и первично «обкатать» новые возможности. Производится финальная подготовка релиза, в ходе чего исправляются ошибки. В нашем примере систему поиска банковского приложения дополняют ключевыми словами, а роботизированного помощника дообучают лучше распознавать контекст клиентских комментариев.   

Этап 4. Развертывание. После тестирования выпускают обновления, которые затем передают в эксплуатацию. Произведенные изменения подробно описываются в технической документации. Для пользователей проводят вебинары и другие обучающие мероприятия по новым возможностям ПО.

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

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

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

Зачем автоматизировать процесс управления релизами

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

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

Учитывать все это и осуществлять релиз-менеджмент в ручном режиме крайне затруднительно. Вот почему во многих компаниях подобная работа координируется при помощи ИТ-инструментов, например, service desk. Обозначим основные возможности подобной системы. 

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

Например, для этого применяется диаграмма Ганта. С ее помощью фиксируется очередность и взаимосвязи между разными этапами и задачами, которые можно гибко перепланировать. Также легко отследить, какие задачи конфликтуют между собой по срокам.

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

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

Контроль исполнения планов. В реализации ИТ-проектов вести вручную даже собственные активности бывает непросто. Еще сложнее координировать работу всех участников релиза, что приходится делать менеджеру проекта.

Эффективно вести контроль запланированных работ также можно с помощью service desk системы. В некоторых из них доступна настройка автоматических уведомлений о приближении дедлайнов и контрольных точек, смене статусов работ и других важных событиях. Также менеджер проекта может каждую неделю подробно описывать все выполненные мероприятия в формате Release Notes в комментариях или отчете. 

Оценка загрузки команды. Важно понимать, кто из релизной команды перегружен, а кто справится с дополнительными работами. В этом плане также немало пользы приносят уже упомянутые диаграммы Ганта. На них наглядно демонстрируется, как распределены ресурсы команды. Другой эффективный инструмент мониторинга загрузки — канбан-доски, на которых задачи можно легко перекидывать между исполнителями.

Учет связи релизов с инцидентами. Наряду с плановыми могут выходить экстренные релизы, которые направлены на устранение повторяющихся сбоев и ошибок в работе продукта. Причем управление инцидентами тоже можно реализовать в service desk системе.

Используя единый инструмент, удобно отслеживать историю заявок по возникшим сбоям и соотносить их с выполненными доработками. По итогам проекта проще оценить, исправлены ли эти проблемы. С другой стороны, удается выявить инциденты, которые произошли уже после релиза из-за неудачных изменений. 

Хранение информации по изменениям. По сути, service desk выполняет функцию системы контроля версий, где легко отследить все шаги в ходе подготовки релиза. Можно быстро поднять историю реализации проекта и проверить, какие корректировки вносились в изначальный план по мере его реализации.

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

Сбор обратной связи и аналитика по итогам релиза. В ИТ-системе можно анализировать пришедшие непосредственно после выхода релиза заявки пользователей, которые связаны с добавленными функциями и другими обновлениями. Таким образом удается выявить основные сложности при работе с ПО и продумать шаги по их устранению.

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

Вместо выводов

Release management — это важная составляющая управления продуктом. Налаженная координация выпуска релизов помогает бизнесу повысить лояльность пользователей, так как удается быстрее и эффективнее улучшать его характеристики. Достичь таких целей сложно без автоматизированного инструмента, который позволит держать под контролем ход проекта и работу всех участников.

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

Чтобы протестировать возможности ITSM 365 для управления релизами и другими практиками по ITIL, подайте заявку на бесплатное двухнедельное тестирование. Наши специалисты проконсультируют вас и откроют доступ к демо-стенду.