Стратегии эффективного управления релизами согласно ITIL. Разбираем ключевые подходы и лучшие практики для управления релизами в IT-проектах.

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

Например, банковская сфера вкладывает достаточно средств для того, чтобы уровень удовлетворенности клиентов при использовании их онлайн–продуктов был достаточно высоким. От этого зависит слишком многое: останутся ли текущие клиенты в банке, придут ли новые и т.д.

Релизы имеют разные цели и классификации. Перечислим некоторые из них ниже.

1. Масштабность.

Крупный релиз.

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

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

Малый релиз.

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

Например, увеличение размера кнопки корзины в интернет–магазине на первый взгляд может показаться незначительным. Но на самом деле это улучшает пользовательский опыт и повышает вероятность совершения покупки.

Чрезвычайный релиз.

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

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

1. Метод реализации

Полный релиз.

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

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

Дельта–релиз.

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

Например, внедрение нового раздела на сайте, которого раньше не было.

Пакетный релиз.

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

Полезность внедрения будет зависеть от поставленной цели. Чем крупнее релиз, тем больше изменений он в себе несет.

Методология ITIL позволяет эффективно управлять релизами. Она делает этот процесс более структурированным, последовательным и логичным, то есть дает возможность планировать. Данный фреймворк сокращает количество инцидентов и проблем в ИТ–продукте.

ITIL делает это за счет того, что работа над релизом является комплексной. Она включает в себя:

• планирование релиза;

• реализацию;

• тестирование;

• внедрение изменений в ПО или приложение;

• контроль качества и сопровождение.

Управление релизами подразумевает целый комплекс действий, который выполняется последовательно. Таким образом удается организовать качественный процесс в соответствии с требованиями ITIL.

1 этап: Планирование.

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

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

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

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

2 этап: Разработка и сборка релиза.

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

3 этап: Тестирование.

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

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

4 этап: Развертывание.

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

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

5 этап: Контроль качества.

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

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

Автоматизация процесса управления релизами предоставляет несколько возможностей. Среди них такие, как:

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

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

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

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

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

• Диаграмма Ганта дает возможность увидеть, как распределены силы команды. Это позволит понять, кто из сотрудников может взять на себя дополнительные задачи, а кто уже достаточно загружен. Такая информация особенно пригодится в том случае, если предстоит большой фронт работ, либо ведется работа над чрезвычайным релизом.

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

• Единая система автоматизации также может содержать метрики, которые необходимы для измерения эффективности команды и самого процесса управления. Программа сама автоматически рассчитает все формулы и визуализирует их результаты в виде графиков и диаграмм. Те, в свою очередь, используются для анализа и отчетности.

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

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

Ниже рассмотрим ключевые роли, которые принимают участие в процессе управления релизами.

Проектный менеджер и менеджер продукта.

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

Команда разработчиков.

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

Тестировщики.

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

Служба поддержки.

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

Маркетологи.

На них стоит в основном три задачи.

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

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

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

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

Какие могут последствия, если отказаться от управления релизами?

Снижается качество программного продукта.

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

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

Увеличивается число инцидентов.

Чем их больше, тем более вероятно, что в дальнейшем это станет серьезной проблемой с последствиями. На ее устранение потребуется больше времени, трудозатрат и средств. Это может сказаться на производительности программного продукта и ухудшить работу пользователей.

Контроль критических релизов.

Не всегда релизы могут быть запланированы, иногда их приходится экстренно разработать и внедрить из–за обнаружения критических ошибок и багов. Они значительно влиять на эффективность и производительность программного продукта, поэтому требуют немедленного решения. Но команда уже может вести работу над запланированным релизом. Тогда эффективное управление позволит грамотно распределить нагрузку и избежать дублирования задач.