Управление проектами.РУ

Управление проектами.РУ
Сообщество тех, кто умеет или хочет научиться
хорошо управлять проектами
16 января 2019 Все для начинающего РМа
1 222 0

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

Юлия Бажанова
Редактор проекта, РМР, РМЕ, PRIME

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

Сразу оговорюсь – речь не про управление конфигурацией программного обеспечения или ИТ-инфраструктуры (об этом есть куча статей на том же хабре) и не про управление конфигурациями 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 человек.

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

комментарии

Добавить комментарий

Такой e-mail уже зарегистрирован. Воспользуйтесь формой входа или введите другой.

Вы ввели некорректные логин или пароль

Sorry that something went wrong, repeat again!

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: