Мы продолжаем рассказывать про “лучших друзей проектного менеджера” — совет по контролю за изменениями (Change control board — CCB). Это группа людей, связанных с проектом, которая принимает решение о том, принимать ли поступившее изменение в проект.
В предыдущей статье мы рассказывали о том, почему такой совет нужен даже для небольших проектов, какие задачи он выполняет и как и когда он создается. В этой статье мы подробнее расскажем, кто обычно входит в CCB и как он работает.
Кого приглашают в совет по контролю за изменениями
Как работает совет по контролю за изменениями
Как внедряют изменения в реальных проектах
Кого приглашают в совет по контролю за изменениями
Мы уже рассказывали, что формальной структуры совета по контролю за изменениями не существует. Свод знаний проектного менеджера PMBOK дает лишь общие указания, рекомендуя адаптировать работу под конкретные случаи. Обычно в совет входят те, кто хорошо знает, как работает проект: специалисты из разных отделов, сам руководитель проекта, а еще эксперты, заказчики и те, кто поддерживает проект деньгами. В зависимости от того, какой это проект и в какой организации он проходит, в команде могут быть и другие люди.
Профессор компьютерных наук и эксперт в сфере проектного менеджмента Лоран У. Уокер, предлагает, чтобы число участников было нечетным — для исключения равного количества голосов — или чтобы решающим голосом был спонсор (лицо, предоставляющее ресурсы для проекта). Кроме того, в процессе анализа изменений обязательно должен участвовать представитель заказчика, который, вероятно, предложит свои идеи по предотвращению расползания границ проекта.
“Клиенты также могут добавлять информацию или ясность в процесс обнаружения проблем и выработки решений. Как уже упоминалось, четкое изложение того, каков объем проекта и какие функции являются “обязательными”, “хорошо иметь” и “приятно иметь”, может прояснить путь к тому, что именно необходимо сделать для завершения проекта.
Сосредоточение на “обязательных” позволит выполнить работу. Если есть время на “хорошо иметь”, то тем лучше для клиента. “Приятно иметь” можно удалить или рассмотреть для будущих проектов”, — советует он.
Эксперт в сфере проектного менеджмента с 20-летним опытом Элизабет Хэррин считает важным, чтобы в CCB входили кроссфункциональные специалисты — с разной специализацией. Это нужно для предотвращения конфликтующих изменений.
“Например, если моя команда может обновлять список доступных категорий в одной части системы. В это же время другая команда также обновляет эту часть системы, но при этом удаляет САМУ функцию категорий (это немного экстремально, но вы понимаете, что я имею в виду). Эти конфликтующие изменения можно обсудить и проконтролировать соответствующим образом.
Мне как-то рассказали историю об изменении в центре обработки данных. Там инженеры работали над кабелями и полом по обе стороны серверного стека. Без поддержки пола с обеих сторон серверный стек опрокинулся! Вот как важно убедиться, что изменения управляются запланированным и разумным образом”, — делится она.
Как работает совет по контролю за изменениями
Подробно о целях, задачах и составе совета мы рассказывали в предыдущей статье. Теперь давайте рассмотрим, как это работает на практике — на примере проекта приложения бронирования столиков в ресторане.
Как договариваться об изменениях
Допустим, мы разрабатываем приложение для бронирования столиков. В процессе возникла идея внедрить предзаказ блюд, которая может повлиять на сроки, бюджет и бизнес-модель. Чтобы оценить и контролировать такое изменение, работает следующий алгоритм:
- Выявление инициативы
Любой участник проекта (в нашем случае — отдел маркетинга) инициирует изменение, оформляя запрос на изменение (Request for change — RFC). - Формализация RFC
Описываются: суть изменения, инициатор, причина, приоритет, категории изменений и затрагиваемые части проекта. - Анализ влияния
Команда оценивает технические, бизнес- и UX-аспекты. Определяются риски и возможные последствия. - Оценка затрат и ресурсов
Прикидываются дополнительные сроки, необходимое количество людей и бюджет. - Обсуждение в CCB
RFC выносится на обсуждение совета по контролю за изменениями. Участники (PM, разработчики, UX, представители заказчика, спонсор) принимают решение — внедрять изменение или нет. - Фиксация решения
Все решения документируются: что одобрено, с какими условиями, какие шаги предпринимаются далее. - Актуализация планов
При необходимости обновляется дорожная карта, бюджет, команда и бизнес-метрики.
Как внедряют изменения в реальных проектах
Хотя термин Change Control Board (CCB) чаще встречается в учебниках по управлению проектами, на практике многие крупные IT-компании внедряют аналогичные механизмы для управления изменениями — особенно в критически важных и масштабных системах. Ниже — несколько примеров, где и как это реализуется.
Microsoft
В Microsoft, особенно в экосистеме Microsoft 365, процессы change management строго формализованы. Команды по обслуживанию регулярно встречаются для обсуждения предлагаемых изменений, включая обоснование, область действия, влияние на безопасность, приоритет, зависимости, планы развертывания, роли и обязанности. Эта информация документируется в системе отслеживания управления изменениями. Если изменение отклоняется, обоснование явно документируется в тикете для дальнейшего использования.
Amazon Web Services (AWS)
Хотя внутренняя структура CCB в AWS не раскрывается публично, известно, что все изменения проходят через многоступенчатую систему одобрений и автоматизированных проверок. AWS также делится рекомендациями по внедрению change management для клиентов, что указывает на высокую важность этого процесса.
Несмотря на репутацию быстрой и гибкой инженерной культуры, Google применяет строгий контроль для ключевых компонентов — например, поисковых алгоритмов и рекламных систем. Все значимые изменения проходят через ревью, тестирование и внутренние согласования — по сути, это и есть элементы CCB.
Так команды по продуктам Google Cloud используют стандартный подход к разработке программного обеспечения для управления изменениями, который отдает приоритет непрерывной интеграции (CI) и непрерывной доставке (CD). CI включает в себя частое предложение, тестирование и отправку изменений, часто несколько раз в день для любого продукта или услуги. CD — это расширение CI, в котором инженеры непрерывно готовят релиз-кандидаты на основе последнего стабильного снимка кодовой базы.
В модели управления изменениями Google есть четыре основных этапа: проектирование, разработка, квалификация и развертывание. Этот подход отдает приоритет созданию и развертыванию изменений поэтапно для клиентов Google Cloud как можно скорее, но и максимально безопасно. Учитывается безопасность изменений до того, как пишется какой-либо код. Безопасность остается в приоритете и после того, как изменения развернуты в производстве.
