AWG

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

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

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

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

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

Как определить проблемы на проекте

Понять, есть ли проблемы в процессе, довольно легко. При грамотном планировании: 

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

При ошибках в процессе организации образуются:

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

У меня есть умозрительная метрика: если количество изменений (инцидентов) превышает 15% от общего объёма работ — планирование становится невозможным. Значит, проект начинает развиваться непредсказуемо. 

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

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

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

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

Возникает риск реальных финансовых потерь для бизнеса.

Как управлять процессом изменений: 4 шага

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

1 этап. Классифицируем и приоритизируем изменения

Приоритизация изменений помогает решать поступающие задачи и контролировать внесение изменений в спокойном темпе. Главное — отдавать приоритет тем изменениям, которые оказывают наибольшее влияние на бизнес. Мы в AWG выделяем три основные категории изменений:

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

2 этап. Описываем процесс управления изменениями

Шаг 1: определяем процесс для систематизации потока изменений. 

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


Шаг 2: определяем «поле боя» (ИТ-ландшафт) и составляем интеграционную архитектуру. В своей практике мы визуализируем это в функционально-системном виде.

Шаг 3: разрабатываем стратегию реализации изменений, которые влияют на несколько продуктов и команд.


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

Я назначаю ответственных за разделение первоначальной идеи и мониторинг её выполнения (сборку). Изменения могут быть направлены в систему, комитет, отвечающий за выделение проекта, или следовать автоматическим правилам и другим механизмам.


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

Если изменения надо внести в несколько систем, например, в 1С и в систему лояльности, то становится сложнее. В этом случае уже необходимо синхронизировать команды, создать проектную надстройку, декомпозировать задачи и затем объединить все вместе. 


Этим занимаются руководитель проекта/продкта, core-team проекта (лидеры команд разработки/аналитики/тестирования, архитекторы) и управляющий комитет, куда входят стейкхолдеры, спонсор проекта, команда управления проектом. Если специальной команды под управление изменениями нет, то могут появиться проблемы: несогласованность действий между командами и непонимание отдельных аспектов работы.

Шаг 3. Если поступает изменение, принимаем решение о его внесении осознанно

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

Это даёт возможность определить:

• виды возникающих инцидентов;
• наличие систематических проблем в них;
• тенденцию к росту или снижению числа инцидентов.

Шаг 4. Контролируем эффективность внесенных изменений

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

Количественная метрика 

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

Метрика, оценивающая изменения с точки зрения влияния

• Если инцидент с высоким приоритетом

Сделать постмортем и выявить финансовое влияние на проект. После принять решение о том, нужны ли меры для недопущения этого инцидента.

• Если проблема носит системный характер

С такой проблемой целесообразно поработать. Грубо говоря, если есть, например, ошибка списания бонусов, а попытки определить причину ни к чему не привели, то дешевле и эффективнее будет создание инструкции для сотрудников колл-центра, которые при случае будут выдавать клиентам извинительные бонусы. В такой ситуации компания меньше потеряет, чем при попытке “лечить” исходные проблемы.

• Если изменение с низким приоритетом

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

Совершенно точно не все изменения приносят плановые результаты. Это нормально. Главное за этим следить.

Как лучше организовать процесс управления изменениями

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

В противном случае хорошим решением будет ИТ-консалтинг. Тут есть несколько вариантов.

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

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


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

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