Павел Солонухо, руководитель кластера проектной разработки в AWG, рассказывает об управлении изменениями на проектах клиентов и способах его организации. Статья будет полезна менеджерам проектов и ИТ-директорам малых и средних ИТ-компаний.
Что такое управление изменениями
Управление изменениями — это система процессов, где каждая стадия направлена на то, чтобы изменения происходили упорядоченно, предсказуемо и, следовательно, контролируемо. Это ключевой элемент в реализации масштабных проектов с участием множества специалистов из разных подразделений.Если процесс управления изменения происходит бесконтрольно, спонтанно или попросту отсутствует, то любое изменение может стать неподъемным грузом для менеджеров проектов и всей ИТ-команды.
Как определить проблемы на проекте
Понять, есть ли проблемы в процессе, довольно легко. При грамотном планировании:✅ Все изменения распределены и классифицированы.
✅ Снижаются конфликты изменений, понятны приоритеты.
✅ Обновления не оказывают существенного влияния на работу системы.
✅ Меньше изменений, которые не принесли результата.
✅ Технический долг не разрастается бесконтрольно.
При ошибках в процессе организации образуются:
❌ Большой объем технического долга. В этой ситуации нельзя быстро внести изменения, много ошибок и отказов, рефакторинг стремится к бесконечности, а работа разработчиков превращается в ад.
У меня есть умозрительная метрика: если количество изменений (инцидентов) превышает 15% от общего объёма работ — планирование становится невозможным. Значит, проект начинает развиваться непредсказуемо.
❌ Отмена проектов. Происходит, когда выясняется, что достичь поставленной цели невозможно или потребуется гораздо больше времени, денег и ресурсов, чем предполагалось вначале.
Ошибки в планировании и нечеткие цели ведут к перерасходу бюджета и ресурсов, несоответствию конечного результата ожиданиям заказчика и пользователя, постоянному переносу сроков.
❌ Чрезмерное количество срочных изменений, что отражается на конечном пользователе и команде.
Клиент замечает сбой, но не может решить свою задачу и не знает, когда ситуация наладится. Сотрудники выполняют большой объем внеплановых работ и теряют свою производительность. Фокус смещается на задачи, которые выполняются в порядке «кто громче требует внимания». Аппарат управления бессмысленно тратит силы из-за ручного управления.
Возникает риск реальных финансовых потерь для бизнеса.
Как управлять процессом изменений: 4 шага
Проект будет идти по плану, если внедрить систему контроля изменений. Ниже — реальный пример, что нужно сделать и как на проектах клиентов мы в AWG управляем изменениями.
1 этап. Классифицируем и приоритизируем изменения
Приоритизация изменений помогает решать поступающие задачи и контролировать внесение изменений в спокойном темпе. Главное — отдавать приоритет тем изменениям, которые оказывают наибольшее влияние на бизнес. Мы в AWG выделяем три основные категории изменений:- Плановые изменения: нововведения, направленные на улучшение бизнес-функции. Пример: внедрение изменений, цель которых увеличить оборот или сократить издержки бизнеса.
- Проблема: это инцидент с более низким приоритетом, который можно запланировать и включить в список задач по работе над продуктом.
- Блокирующий инцидент: проблема, которая требует немедленного внимания и решается в первую очередь, так как оказывает финансовое влияние на бизнес. Например, приложение банка перестало работать и пользователи не могут получить доступ к своим счетам и услугам.
❕ На блокирующие инциденты не должно тратиться более 20% времени команды, особенно в долгосрочной перспективе.
Если вы долго не можете выйти из «крутого пике», и количество блокирующих инцидентов со временем не уменьшается: не стоит дожимать из команды все соки, беспечно вливать в проект ресурсы и бюджет. Скорее всего, пользы от этого не будет.
Лучшее, что вы можете сделать в этом случае — остановиться. Поймите реальные причины, проведите заново планирование с учетом текущей ситуации. Скорее всего, вы имеете дело с одной из ошибок описанных выше.
Если вы долго не можете выйти из «крутого пике», и количество блокирующих инцидентов со временем не уменьшается: не стоит дожимать из команды все соки, беспечно вливать в проект ресурсы и бюджет. Скорее всего, пользы от этого не будет.
Лучшее, что вы можете сделать в этом случае — остановиться. Поймите реальные причины, проведите заново планирование с учетом текущей ситуации. Скорее всего, вы имеете дело с одной из ошибок описанных выше.
2 этап. Описываем процесс управления изменениями
Шаг 1: определяем процесс для систематизации потока изменений.Этот этап включает в себя идентификацию источника изменений, определение ответственных за маршрутизацию, приоритизацию и правила, по которым она осуществляется и прочие аспекты процесса.
❕ Блокирующая проблема для одной бизнес-функции может быть совершенно незначима для другой. Поэтому мы договариваемся о принципах, по которым идет классификация инцидентов.
Шаг 2: определяем «поле боя» (ИТ-ландшафт) и составляем интеграционную архитектуру. В своей практике мы визуализируем это в функционально-системном виде.
Шаг 3: разрабатываем стратегию реализации изменений, которые влияют на несколько продуктов и команд.
Проблема лебедя, рака и щуки. Все команды делают свою часть хорошо, но конечный результат не соответствует ожиданиям.
Я назначаю ответственных за разделение первоначальной идеи и мониторинг её выполнения (сборку). Изменения могут быть направлены в систему, комитет, отвечающий за выделение проекта, или следовать автоматическим правилам и другим механизмам.
Всегда определяйте единую точку входа, которая однозначно трактует цель изменений в продукте/проекте. Хорошо, если стейкхолдер (заинтересованная сторона) замкнут на продукте. В таком случае сложнее потерять образ результата и ответственных.
Грубо говоря, если изменение по ценообразованию нужно внести только в 1С, то достаточно разделить задачу на подзадачи, и передать их в бэклог соответствующей команды, которая будет работать над ними, применяя продуктовый подход.
Если изменения надо внести в несколько систем, например, в 1С и в систему лояльности, то становится сложнее. В этом случае уже необходимо синхронизировать команды, создать проектную надстройку, декомпозировать задачи и затем объединить все вместе.
Каждая команда непосредственно отвечает за свой «кусочек». Но для того чтобы все собрать воедино, нужна дополнительная группа людей, которая проконтролирует процесс и сделает так, чтобы изменения вступили в силу.
Этим занимаются руководитель проекта/продкта, core-team проекта (лидеры команд разработки/аналитики/тестирования, архитекторы) и управляющий комитет, куда входят стейкхолдеры, спонсор проекта, команда управления проектом. Если специальной команды под управление изменениями нет, то могут появиться проблемы: несогласованность действий между командами и непонимание отдельных аспектов работы.
Шаг 3. Если поступает изменение, принимаем решение о его внесении осознанно
Наша команда организует единый канал коммуникации для приёма заявок на изменения и инциденты. Создание общего канала коммуникаций делается на любом проекте, если есть высокая технологическая сложность и даже если оборот с проекта небольшой.Это даёт возможность определить:
- виды возникающих инцидентов;
- наличие систематических проблем в них;
- тенденцию к росту или снижению числа инцидентов.
Шаг 4. Контролируем эффективность внесенных изменений
Стоит использовать как минимум две метрики для измерения запросов и их финансовой оценки.Количественная метрика
Если представить, что плановые и внеплановые задачи — это вода, которая течет в бассейн по нескольким трубам и выливается по одной, то задача руководителя проекта — проследить, чтобы бассейн с запросами не переливался. Метрика помогает измерить число плановых и внеплановых запросов на вход и решенных инцидентов на выход.
Метрика, оценивающая изменения с точки зрения влияния
- Если инцидент с высоким приоритетом
- Если проблема носит системный характер
- Если изменение с низким приоритетом
Совершенно точно не все изменения приносят плановые результаты. Это нормально. Главное за этим следить.
Как лучше организовать процесс управления изменениями
Руководитель компании может обратиться к экспертам внутренней команды. Как правило, такая экспертиза есть у ИТ-директоров с хорошим техническим бэкграундом в крупных компаниях.В противном случае хорошим решением будет ИТ-консалтинг. Тут есть несколько вариантов.
1. Аутсорсинг, если нужна сработанная команда с сильной экспертизой. Специалисты выстроят подразделения внутри вашей команды, предложат рекомендации, определят векторы развития.
Мы в AWG решаем задачи клиентов по комбинированному подходу: ищем и определяем реальные причины проблем с управлением, формируем стратегию, занимаемся операционным управлением и реализуем стратегию от и до. Результат: ИТ в вашей компании больше не будет тормозить развитие бизнеса и сможет гибко реагировать на внешние факторы и форс-мажоры.
2. Комбинирование аутсорсинга и аутстаффинга, если нет внутренней комптенции и ресурсов. Специалиста по консалтингу на аутстафе можно подключить под определенные задачи на конкретный срок и подключить аутсорс-команду. В этом случае компания получает сразу все: рекомендации, опыт и внедрение ИТ-решений от специалистов, которые поставят процессы на рельсы.
Для тех, кто испытывает трудности с налаженным процессом, такая комбинация является эффективным решением, позволяющим одновременно улучшить навыки и сформировать компетентную команду, которую собрать как пазл редко у кого получается.
