ITSM для высокоскоростных команд
Управление изменениями: роли и обязанности в команде
Основная цель любой методики управления изменениями — сократить число инцидентов при выпуске обновлений, которые приносят пользу клиентам и выводят компанию на лидирующие позиции. Кроме того, применение методики имеет определенные последствия. Сегодня клиенты предъявляют высокие требования к ИТ-сервисам и ожидают оказания качественных услуг без сбоев. В стремительно развивающейся среде очень важно внимательно управлять услугами и как можно чаще оптимизировать их. Сегодня ИТ-команды используют методы, позволяющие снизить риски и при этом предоставлять клиентам услуги в максимально простой и гибкой форме.
Для достижения этой цели в организациях назначаются определенные должности и распределяется ответственность за управление изменениями. В крупной организации обязанности могут быть распределены между целым рядом должностей и команд.
В небольшой компании один человек может отвечать как за управление изменениями, так и за другие рабочие задачи. Сотрудник, в обязанности которого входит управление изменениями, также может быть разработчиком или руководителем команды. В других случаях процессы, связанные с изменениями, могут постепенно и равномерно распределяться среди существующих команд.
Не существует единственно правильной модели распределения ответственности, связанной с управлением изменениями. Компаниям необходимо разрабатывать среды, максимально подходящие под их требования. С учетом этого всем командам полезно пересмотреть делегирование ответственности за контроль изменений тем сотрудникам, специализация которых мало пересекается непосредственно с контролируемыми проектами.
Используя новые возможности автоматизации и интегрируя имеющиеся методы в существующие рабочие процессы, мы можем привлечь сотрудников, задействованных в управлении изменениями, к решению задач стратегического уровня и тем самым сэкономить ресурсы других команд, чтобы они могли сконцентрироваться на своих прямых задачах.
Наиболее распространенные роли управления изменениями
Роли, предусмотренные в управлении изменениями, зависят от различных факторов, включая размер и тип ИТ-организации. Вот некоторые из наиболее распространенных позиций.
Менеджер/координатор изменений
Менеджеры изменений, также иногда называемые координаторами, как правило, отвечают за управление всеми аспектами внедрения ИТ-изменений. Они назначают приоритет запросов на изменения, оценивают их влияние, после чего принимают или отклоняют изменения. Кроме того, они документируют процессы управления изменениями и планы изменений. Что важно, такие сотрудники осуществляют подготовку, организацию собраний CAB и сами их проводят. Успех менеджера изменений, как правило, оценивается исходя из достижения целей по срокам и бюджету.
Менеджер/координатор изменений
Менеджеры изменений, также иногда называемые координаторами, как правило, отвечают за управление всеми аспектами внедрения ИТ-изменений. Они назначают приоритет запросов на изменения, оценивают их влияние, после чего принимают или отклоняют изменения. Кроме того, они документируют процессы управления изменениями и планы изменений. Что важно, такие сотрудники осуществляют подготовку, организацию собраний CAB и сами их проводят. Успех менеджера изменений, как правило, оценивается исходя из достижения целей по срокам и бюджету.
Менеджер/координатор изменений
Менеджеры изменений, также иногда называемые координаторами, как правило, отвечают за управление всеми аспектами внедрения ИТ-изменений. Они назначают приоритет запросов на изменения, оценивают их влияние, после чего принимают или отклоняют изменения. Кроме того, они документируют процессы управления изменениями и планы изменений. Что важно, такие сотрудники осуществляют подготовку, организацию собраний CAB и сами их проводят. Успех менеджера изменений, как правило, оценивается исходя из достижения целей по срокам и бюджету.
Контролер изменений
Контролер изменений — это сотрудник, принимающий или отклоняющий изменения. Иногда это один человек, например менеджер или директор. Иногда это группа сотрудников, входящая в совет по изменениям. А иногда это коллега, выступающий в роли рецензента. В соответствии с ITIL 4, «в динамичных организациях, как правило, подтверждение изменений происходит децентрализованно, поэтому эффективность организации в большей степени зависит от решений привлекаемых экспертов-рецензентов».
Менеджеры изменений и контролеры изменений, как правило, сообща подтверждают изменения и внедряют их в компании. В некоторых случаях, особенно в небольших компаниях, менеджер изменений является ответственным лицом, принимающим решения, не советуясь с другими людьми и командами.
Заинтересованные лица со стороны предприятия
Часто в процесс управления изменениями вовлекаются представители предприятия, и их мнение может влиять на принятие решений. Это практикуется все чаще, ведь услуги на базе программных продуктов крайне важны для большинства предприятий.
Например, если изменение негативно повлияло на скорость связи между программным обеспечением учета платежей в бухгалтерии и CRM в отделе продаж, может понадобиться, чтобы представители бухгалтерии и отдел продаж участвовали в собраниях CAB и принятии окончательных решений касательно изменения.
Инженеры/разработчики
Команды разработки, как правило, отправляют изменения на подтверждение и документируют их по мере необходимости. В компаниях, где используется подход «сам создал, сам и запускай», после подтверждения изменений такие команды выполняют развертывание изменения, отслеживают его и обрабатывают связанные с ним инциденты или проблемы. Также бывает, что команда управления изменениями, отвечающая за любые инциденты, вызванные изменением, может быть отделена от разработчиков, применяющих изменение.
Агенты службы поддержки
Агенты службы технической поддержки могут формулировать свое видение инцидентов и распространенных проблем с услугами, вызванных изменением.
Менеджеры по эксплуатации
Сотрудники на этой должности отвечают за ежедневное поддержание систем в рабочем состоянии, поэтому они делятся своими комментариями по поводу рисков и зависимостей.
Менеджеры по работе с клиентами
Стремясь к благополучию клиента, менеджеры по работе с клиентами могут предоставить сведения о настроениях клиента, его опасениях и постоянно меняющихся потребностях.
Специалисты по информационной безопасности и сетевые инженеры
Эксперты по сетевой безопасности и облачной инфраструктуре говорят о важных аспектах, связанных с угрозами и уязвимостями.
Роль CAB (консультативных советов по изменениям) в трансформации
Change advisory boards have historically played a crucial role in assessing the risks associated with change requests and approving or rejecting them. Traditional CABs often acted as gatekeepers controlling the release of proposed changes.
However, they have been criticized for poor time management skills, lengthy change request backlogs, and their detachment from the actual work. Fortunately, CABs are evolving to become more strategic advisors, transforming their role in the change management process.
Задача, стоящая перед CAB
Бытует мнение, что собрания CAB — неприятное мероприятие. Мы жестко критикуем их за потерю времени, за недостижение целей, привлечение большого числа случайных людей и за то, что они вообще проводятся, несмотря на возможность переписки по электронной почте. Отчасти это происходит из-за того, что на CAB традиционно возлагается слишком много ответственности.
Проиллюстрируем эту ситуацию, сравнив ее с работой диспетчерской вышки в аэропорту. Представьте себе, что CAB — это контрольная вышка на летном поле. Ее функция — давать пилотам разрешение на посадку. Вряд ли кто-то делегировал бы диспетчерам вышки оценку конструкционной безопасности самолетов или проверку наличия у пилотов летных лицензий, так как соответствие этим требованиям уже подтверждено FAA и другими авиационными ведомствами.
Вместе с тем, в собраниях CAB традиционно участвуют различные заинтересованные лица, которым приходится принимать глобальные решения, связанные с безопасностью всевозможных изменений. И зачастую собрания происходят в конце недели, когда уставшие сотрудники хотят поскорее поехать домой. Проще говоря, собрания CAB заранее обречены на неудачу.
Более того, на собраниях CAB главным образом обсуждается риск возникновения инцидентов при внедрении изменений. Безусловно, это важный аспект, но ведь при этом не менее важно оценивать риски, связанные с задержкой ценных изменений. Слишком медленная динамика развития продукта может нанести вред клиентам или даже разорить компанию, с учетом высочайшей конкуренции на рынке программного обеспечения, предоставляемого в виде услуг.
Можно повысить приоритет роли CAB и сделать ее более узкоспециальной. При наличии нужных методик многие изменения могут быть автоматизированы. Таким образом, CAB может стать важным консультационным этапом внедрения изменений, на котором отслеживаются различные тенденции, и вместе с командами искать пути ускорения изменений, представляющих важность для клиентов.
CAB как консультационный орган по стратегическим вопросам
Чтобы изменить роль CAB, нужно, прежде всего, отказаться от идеи, что всесторонняя власть CAB в вопросах применения изменений приводит к положительным результатам. По данным отчета State of DevOps Report 2019, процессы, требовавшие подтверждения со стороны CAB, негативно отразились на скорости предоставления программного обеспечения, а среди респондентов, следовавших таким процедурам, оказалось в среднем в 2,6 раза больше тех, чья эффективность была низкой. Кроме того, выяснилось, что наличие формальной процедуры подтверждения изменений никоим образом не снижает количество неудачных изменений!
Поэтому сегодня в командах принимаются следующие меры по оптимизации CAB.
Назначение ответственных лиц при управлении изменениями в компании
Когда речь идет о распределении должностных обязанностей в процессе управления изменениями, нужно, прежде всего, понять, что единого решения здесь нет. Все зависит от вашей корпоративной культуры, структуры штата, навыков сотрудников, нормативных требований и т. д.
Чтобы получить четкое представление о том, какие должности должны быть в вашей компании, рекомендуем сыграть в нашу игру: все собираются вместе и обсуждают вклад каждого участника в работу команды и что нужно каждому, чтобы быть успешным.
Чтобы скорректировать набор должностей в контексте управления изменениями, рекомендуем начать с совместного обсуждения приведенных ниже вопросов.
- Как в нашей команде относятся к различным средам? DevOps, CI/CD, ITIL, и т. д.
- Полноценно ли мы поддерживаем такие среды? Ограничено ли наше мышление тактическими моментами, такими как автоматизация?
- Как эти среды, в частности, DevOps и ITIL, влияют на наши подходы к внедрению изменений и выпуску релизов, и насколько они совместимы?
- В чем заключается наш текущий процесс внедрения изменений?
- Кто в нем участвует?
- Что мы можем улучшить?
- Что мы можем сделать, чтобы превратить больше нормальных изменений в стандартные или предварительно одобренные?
- Какие изменения вносятся чаще всего?
- Какие изменения считаются «стандартными»?
- На какие услуги они влияют?
- Какие изменения оказались успешными?
Управление изменениями — важный процесс, и в обозримом будущем без него никак не обойтись. Независимо от того, какие методы управления изменениями вы используете, всегда можно что-то улучшить, например можно начать отслеживать изменения или применять оценку рисков и системы автоматизации. Узнайте, как возможности Jira Service Management по управлению изменениями могут повысить эффективность команд по ИТ-операциям.
Atlassian's guide to agile ways of working with ITIL 4
ITIL 4 is here—and it’s more agile than ever. Learn tips to bring agility and collaboration into ITSM with Atlassian.
Читать технический документKnowledge Management Explained | Atlassian
Knowledge management processes create, curate, share, use, and manage knowledge across an organization and even across industries. Learn more here.
Прочитать статьюНе прерывая развертывание: управление изменениями во времена неопределенности
Некоторые компании возвращаются к громоздким процессам управления изменениями. Здесь говорится о том, как можно избежать добавления методов защиты и даже оптимизировать свои подходы.