Управление конфигурацией проекта или Configuration Management

Сразу оговорюсь – речь не про управление конфигурацией программного обеспечения или ИТ-инфраструктуры (об этом есть куча статей на том же хабре) и не про управление конфигурациями 1С, а про управление конфигурацией в проектах в целом (в любых, не только связанных с ПО). Если у вас хоть раз происходила ситуация типа «блин, сделали работу по старой версии ТЗ» или «ой, как же вышло, что использовали не тот материал», то эта статья для вас. Если нет и в принципе у вас работа организована так, что сделать это невозможно – дальше не читайте.

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

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

В любом проекте под понятием «конфигурация» могут скрываться разные вещи, например:

1. Для программного обеспечения – набор требований, код, скрипты автоматического тестирования, документация на ПО, требования к инфраструктуре и среде для его установки, готовая сборка и проч.
2. Для производства – набор чертежей, описание этапов производства и настройки оборудования для производства, документация на продукт, процесс контроля качества.
3. И т.д.

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

Соответственно, управление конфигурацией проекта или Configuration Management – это идентификация, создание, поддержание и контроль конфигурации в ходе проекта.

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

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

Иногда разделяют конфигурацию продукта и конфигурацию проекта, делать это или нет – зависит от конкретного проекта.

Итак, из чего же состоит управление конфигурацией проекта?

Шаг 1. Идентификация конфигурации проекта и создание первоначальной (базовой) конфигурации проекта

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

На нашем традиционном примере с ремонтом:

• Первоначальная конфигурация продукта или будущей отремонтированной квартиры (то самое «взаимное расположение») у нас определена в дизайн-проекте. В ходе ремонта явно не будут меняться визуализации, которые нарисовал дизайнер, и которые больше нужны для подготовки грамотных чертежей и составления ведомости на материалы, поэтому визуализации в конфигурацию можно не включать. А вот чертежи разводки электрики, список материалов для чистовой отделки и проект кухни – вещи, которые точно (ну или скорее всего) будут меняться, и этими изменениями нужно будет управлять. А иначе я очень быстро забуду (или бригада забудет), что «ну вот тут же я просила сделать еще розеточку, которой нет на чертеже!», а потом будет позно.
• Первоначальная конфигурация проекта (а именно ремонта) включает, например, набор требований от управляющей компании о правилах проведения ремонтов (в какое время шуметь, как заказывать пропуск в подземный паркинг на машины доставки, как работает консьерж и будет ли он принимать ваши доставки), текущие требования соседей (не шуметь с 14 до 18, так как у одних маленький ребенок, и не оставлять мешки с цементом в общем коридоре, так как у других астма, и проч.), график ремонта соседа, с которым вы решили объединиться в некоторых аспектах ремонта (например, в заливке механизированной стяжки), график отгулов мужа, которые он сможет посвятить ремонтным работам, и т.д. Все это в ходе ремонта может поменяться и нанести проекту ущерб, если вовремя эти изменения не отследить.

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

1. Присваиваем всем элементам конфигурации четкие и понятные всем наименования. Если нужно – где-то описываем принцип формирования этих наименований в случае, если количество элементов идет на сотни.
2. Определяем, где и как будем хранить документацию и другие артефакты (например, образцы плитки из магазина) и складываем туда все элементы конфигурации. Опять же, если нужно – где-то описываем принцип размещения («чертежи» складываем только в папку «чертежи» в Google Docs, а плитку на фартук на кухне кладем только на стеллаж, подписанный «образцы для кухни», а не на соседние, где плитка для ванной).
3. Организуем доступ всех заинтересованных лиц к нужным им элементам конфигурации (даем ключ от подвала, где хранится плитка, или делаем доступ Read-Only в Google Docs, например). Про «если нужно», думаю, вы сами догадались.

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

Шаг 2. Разработка плана управления конфигурацией проекта

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

Снова вернемся к ремонту, для него в план управления конфигурацией могут входить следующие вещи:

1. Работа с чертежами типа разводки электрики – где взять актуальные чертежи в каждый момент времени, как организован контроль версий, кто и с какой частотой должен чертежи обновлять, и чье согласование для этого нужно. Например, после выражения моего желания «сделать тут новую розеточку» дизайнер должен согласовать ее с электриком (а то вдруг туда розетку нельзя ставить), внести изменения в чертеж, согласовать его со мной (а то вдруг мы друг друга неверно поняли), выложить в правильную папку в Google Docs (старый чертеж при этом переместить в папку «Неактуальные чертежи», а имя новому чертежу присвоить в формате «Порядковый номер версии_Название чертежа_Дата изменения»), съездить отдать обновленную распечатанную версию прорабу и забрать у него старую (чтобы не перепутали в процессе работы) и ткнуть прораба носом в новую розетку на чертеже (чтобы не пропустил). Для контроля раз в неделю – сверка актуального чертежа с фактом в квартире (делаю я). Выглядит длинно, страшно и вообще избыточно, но это на примере с розеткой, а вот на производстве какого-нибудь сложного агрегата для проекта отсутствие любого из шагов контроля может быть фатальным.
2. Работа с требованиями УК или соседей – где взять актуальную версию в каждый момент времени, раз в месяц (делает муж) – уточняющие звонки в УК или соседям с вопросом о том, есть ли у них какие-то замечания по ходу ремонта и не создаем ли мы неудобств, при необходимости – корректировка правил и уведомление прораба об этом.
3. Работа с образцами плитки для кухни – я притаскиваю с разных магазинов и выставок кусочки и складываю их в коробку «неразобранное» на стеллаже с подписью «образцы для кухни». Каждый раз, когда мы с дизайнером встречаемся на объекте – смотрим, что там накопилось, выбрасываем те, которые не подойдут по дизайну или бюджету, оставшиеся перекладываем в коробку «финальные образцы». Из них-то я потом и буду выбирать итоговую плитку, перед этим для контроля с дизайнером еще раз по всем пробежимся, чтобы убедиться, что в бюджет (который за это время мог поменяться, ну или курс доллара скакнул) мы все еще укладываемся.
4. Работа с самим планом управления конфигурацией – кто и в каких случаях может вносить в него изменения, как добавлять новые конфигурационные элементы в случае их появления и как сделать так, чтобы все заинтересованные лица об этих изменениях были уведомлены.
5. И т.д.

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

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

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

Шаг 3. Контроль конфигурации в ходе проекта

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

До определенного объема проекта все это можно держать в голове, и тогда план управления конфигурацией не нужен, но с какого-то момента количество информации начинает превышать физические возможности РМа, и очень легко что-то упустить. Лично я пишу формальные планы управления проектов и план управления конфигурацией в том числе только для проектов, количество участников в которых превышает 50 человек.

Вы пишете планы управления конфигурацией  в своих проектах? Расскажите в комментариях!