Close

Ready for ITSM at high velocity?

Управление изменениями: роли и обязанности в команде

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

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

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

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

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

Наиболее распространенные роли управления изменениями

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

Менеджер/координатор изменений

Менеджеры изменений, также иногда называемые координаторами, как правило, отвечают за управление всеми аспектами внедрения ИТ-изменений. Они назначают приоритет запросов на изменения, оценивают их влияние, после чего принимают или отклоняют изменения. Кроме того, они документируют процессы управления изменениями и планы изменений. Что важно, такие сотрудники осуществляют подготовку, организацию собраний CAB и сами их проводят. Успех менеджера изменений, как правило, оценивается исходя из достижения целей по срокам и бюджету.

Контролер изменений

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

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

Заинтересованные лица со стороны предприятия

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

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

Инженеры/разработчики

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

Агенты службы поддержки

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

Менеджеры по эксплуатации

Сотрудники на этой должности отвечают за ежедневное поддержание систем в рабочем состоянии, поэтому они делятся своими комментариями по поводу рисков и зависимостей.

Менеджеры по работе с клиентами

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

Специалисты по информационной безопасности и сетевые инженеры

Эксперты по сетевой безопасности и облачной инфраструктуре говорят о важных аспектах, связанных с угрозами и уязвимостями.

Роль CAB (консультативных советов по изменениям) в трансформации

Что такое CAB?

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

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

Задача, стоящая перед CAB

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

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

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

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

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

CAB как консультационный орган по стратегическим вопросам

Чтобы изменить роль CAB, нужно, прежде всего, отказаться от идеи, что всесторонняя власть CAB в вопросах применения изменений приводит к положительным результатам. По данным отчета State of DevOps Report 2019, процессы, требовавшие подтверждения со стороны CAB, негативно отразились на скорости предоставления программного обеспечения, а среди респондентов, следовавших таким процедурам, оказалось в среднем в 2,6 раза больше тех, чья эффективность была низкой. Кроме того, выяснилось, что наличие формальной процедуры подтверждения изменений никоим образом не снижает количество неудачных изменений!

Поэтому сегодня в командах принимаются следующие меры по оптимизации CAB.

Отказ от унифицированного отношения к запросам на изменения.

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

Совместное управление изменениями и релизами

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

Применение прогрессивных релизов для тестирования и итерации

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

Использование автоматизации и инструментов для упрощения управления изменениями

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

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

Управление изменениями должно быть более открытым по отношению к тем, для кого они предназначены

Одна из самых популярных стратегий, используемых вместо CAB (полностью или частично), заключается в привлечении экспертов-рецензентов. При этом задача выявления проблем в коде возлагается на тех, кто лучше всего в нем разбирается. Согласно ITIL 4, «в динамичных организациях, как правило, подтверждение изменений происходит децентрализованно, поэтому эффективность организации в большей степени зависит от решений привлекаемых экспертов-рецензентов». Аналогичным образом, в отчете 2019 State of DevOps report организациям рекомендуется «сместить фокус на подтверждение изменений с привлечением экспертов-рецензентов».

Чтобы обеспечить соответствие нормативным требованиям при использовании такого подхода, необходимо тщательно документировать все данные, и в этом поможет, например, система Bitbucket, автоматически отслеживающая данные авторов и экспертные рецензии и предотвращающая внедрение изменений без выполнения необходимой процедуры.
В Atlassian экспертное рецензирование является ключевым этапом процесса подтверждения. Как сказал один из наших экспертов по ИТ-рискам и соответствию требованиям, «весь код Atlassian хранится в Bitbucket. Если разработчику нужно внести изменение, он извлекает код из Bitbucket и работает с ним на своем ноутбуке. При возврате кода в репозиторий Bitbucket, вместо того чтобы сразу обновить код, система запрашивает экспертную рецензию. Только после такой проверки подтвержденный код возвращается в репозиторий. Что если код не был подтвержден? В этом случае он отправляется первоначальному разработчику с замечаниями от эксперта-рецензента. Разработчик исправляет недочеты и отправляет код на повторную проверку».

Привлекайте экспертов, чтобы соответствовать передовым стандартам

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

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

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

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

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

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

  • Как в нашей команде относятся к различным средам? DevOps, CI/CD, ITIL, и т. д.
  • Полноценно ли мы поддерживаем такие среды? Ограничено ли наше мышление тактическими моментами, такими как автоматизация?
  • Как эти среды, в частности, DevOps и ITIL, влияют на наши подходы к внедрению изменений и выпуску релизов, и насколько они совместимы?
  • В чем заключается наш текущий процесс внедрения изменений?
    • Кто в нем участвует?
    • Что мы можем улучшить?
    • Что мы можем сделать, чтобы превратить больше нормальных изменений в стандартные или предварительно одобренные?
      • Какие изменения вносятся чаще всего?
      • Какие изменения считаются «стандартными»?
      • На какие услуги они влияют?
      • Какие изменения оказались успешными?

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