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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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