Планирование коммуникаций и управления конфигурацией в проекте

План коммуникаций проекта

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

А потом сетуют на то, что коммуникации хаотичны, отнимают много времени и сил, не приносят ожидаемой эффективности.

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

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

Почему план коммуникаций проекта улучшает взаимодействие?

• Определенность сроков. Если членам команды непонятно, когда и по каким вопросам они собираются общаться, предоставлять и получать информацию, возникает неопределенность. А как известно, любая неопределенность снижает эффективность деятельности. Информация в проекте появляется в результате каких-то действий. То есть для того, чтобы получить или предоставить информацию, нужно что-то сделать. В таком случае когда членам команды известны сроки предоставления и получения информации, они планируют свои действия по ее получению и подготовке. А это напрямую влияет на другие задачи проекта.
• информации. Если известны не только сроки, но и предмет коммуникаций, члены команды имеют возможность подготовиться. А подготовка позволяет сократить время, которое вся команда тратит, например, на совещании. А еще члены команды снижают неопределенность своей работы, т.к. могут планировать получение конкретной информации от своих коллег.
• Принятие решений. Членам команды постоянно приходится принимать множество решений. Многие из них затрагивают не только их участки работы, но имеют влияние на работу коллег и проекта в целом. В таком случае необходимо понимать, когда будут принимать ключевые для проекта решения. Время принятия решения можно запланировать даже не имея всех необходимых данных в наличии. А значит, на эти решения можно рассчитывать при планировании работы.
• Экономия времени. Это скорее следствие вышеуказанных принципов. Время экономится за счет снижения неопределенности и перевода коммуникаций в исключительно конструктивное русло. В проекте любая экономия времени приводит к увеличению эффективности проекта в целом.
• Дисциплина. Когда нам известно время и предмет коммуникаций, это дисциплинирует, потому что накладывает определенные обязательства на всю команду проекта.

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

План коммуникаций проекта – содержание

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

Разделы документа

• Введение. План коммуникаций проекта является рабочим документом. А значит, в нем должны быть указаны его цели, задачи и содержание – для удобства работы. Естественно, что в плане должно быть указано, кто несет ответственность за поддержание плана в актуальном состоянии.
• Методы коммуникации. Опишите все методы коммуникаций, которые  будут использованы в проекте. Методы: совещание, отчет, конференц-звонок, летучка, электронная почта и т.д. Если у вас уже существуют корпоративные стандарты управления коммуникациями, используйте их.
• Инструменты. В этом разделе опишите инструменты, которые будут использоваться в проекте. Я очень люблю визуальные формы коммуникаций, например, MindManager. Кто-то любит Kanban-доски, а кто-то – табличную форму представления информации. Нужно найти наиболее эффективные инструменты, которые будут удовлетворять всех участников проекта.
• Записи. В этом разделе нужно определить, какие записи, имеющие отношение к коммуникациям, будут необходимы и где они будут храниться (например, регистрация внешней корреспонденции)
• Отчетность. Опишите все существующие и используемые отчеты, включая их цель, сроки и получателей. Обязательно должен быть описан их формат и представление.
• Сроки. В этом разделе  нужно указать, когда должны выполняться формальные коммуникации (например, в конце стадии или этапа проекта).
• Роли и ответственности. В этом разделе вы расписываете – кто будет отвечать и за какие аспекты коммуникаций, включая любые роли в вашей организации.
• Список заинтересованных сторон.
• Информация, необходимая для каждой заинтересованной стороны.

Анализ заинтересованных сторон

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

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

Анализ информации для заинтересованных сторон

• Информация, которую вы можете передать из проекта для каждой из сторон
• Информация, которая вам необходима для проекта от каждого из заинтересованных лиц
• Кто конкретно является поставщиком/получателем информации
• Периодичность коммуникаций
• Средства коммуникаций
• Формат коммуникаций

Источники информации для составления плана коммуникаций

• Корпоративные стратегии и политики (например, правила раскрытия информации для публичных компаний)
• Любая доступная информация о проекте (например, структура команды управления проектом, идентифицированные риски, требования к качеству)
• Поговорите с вашими заинтересованными сторонами и поймите, что им нужно
• Еще раз вернитесь к анализу заинтересованных сторон.

Что еще нужно учесть в плане коммуникаций проекта

• Понятны все заинтересованные стороны и их требования к коммуникациям в проекте
• Все заинтересованные стороны согласились с содержанием, периодичностью и методами коммуникаций
• План коммуникаций проекта учитывает время, трудозатраты и ресурсы, необходимые для выполнения коммуникаций
• Понятна степень формализации (бюрократизации, иногда это бывает важно) коммуникаций, а также их периодичность, которая является обоснованной, учитывает важность и сложность  проекта
• Вы используете возможности корпоративных коммуникаций для продвижения вашего проекта (например, корпоративные порталы, службы PR или HR и так далее). Найдите себе союзников в этих службах, поверьте, они очень заинтересованы в успешности вашего проекта и понимают важность коммуникаций.

План коммуникаций проекта – простой шаблон

Тема	Дата и время	Метод	Ответственный	Участники	План обсуждения	Список материалов
Согласование закупки нового оборудования	01.01.17	Очное совещание	Дед Мороз	Снегурочка и олени	1. Нужно ли покупать оборудование2. Достаточно ли у нас средств3. Оценка рисков использования существующего оборудования	1. Бюджет на 2017 год2. Спецификация оборудования3.  ….
…	…	…	…	…	…	…

by Andrew Zaytsev

Источник: https://rzbpm.ru/pm/plan-kommunikacij-proekta.html

Коммуникационное взаимодействие в проекте

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

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

Стадии управления коммуникациями

Система взаимоотношений участников проекта обеспечивает планирование, запуск в действие и регулирование связей между заинтересованными сторонами (ЗС).

Также производится их информирование в контексте целей проекта и с учетом интересов лиц. Большое внимание уделяется контролю и мониторингу коммуникационных процедур.

Система включает в свой состав три основных процесса построения надежного взаимодействия в проектных коммуникациях.

План управления коммуникациями является основным выходом из первого процесса системы. План позволяет найти и формализовать лучшие подходы к началу эффективных и результативных коммуникаций с ЗС.

Сами процедуры качественного обмена информацией между участниками проекта реализуются на основе процесса «Управление коммуникациями».

Процедура «Контроль коммуникаций» отвечает за оценку и коррекцию информирования и взаимодействия на любом этапе процесса выполнения проекта.

Процессы управления коммуникациями проекта и показатели их эффективности

Размещенная выше схема добавляет к традиционной модели несколько значимых акцентов.

1. До начала планирования управления коммуникациями должны быть сформированы организационные предпосылки, которые дают возможность создать план коммуникаций. Данная работа происходит на самых ранних этапах разработки проекта, в момент создания плана управления проектом. План управления коммуникациями учитывает виды и состав информационных потребностей ЗС, внешние информационные запросы, физическую архитектуру позиционирования участников.
2. В стадии управления коммуникациями включается этап создания инфраструктуры, в том числе программно-информационной платформы.
3. Схема включает блок архивирования, без которого невозможно продуктивное развитие активов процессов организации в терминологии PMBOK.
4. Схема дополнена шестью показателями эффективности, которые повышают возможности циклического регулирования управления коммуникациями на основе контроля и мониторинга.

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

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

Модель динамики входов и выходов процессов управления коммуникациями

Конструктивные функции конфликтов в команде

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

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

Конфликт – это всегда соперничество на ценностном уровне или столкновение ресурсных, статусных и властных интересов между членами группы.

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

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

Конструктивные функции важны для проекта и различаются в зависимости от направленности конфликта.

1. Информационная функция, дающая импульс к осознанию ценностей и интересов сторон команды в противоборстве.
2. Конфликт как способ снятия стрессовой напряженности и разрядки обстановки в команде.
3. Функция стабилизации команды как социальной системы и ликвидации источников неудовлетворенности.
4. Конфликт как способ консолидации команды вокруг общей цели и формирования чувства причастности и активизации участников.
5. Функция стимулирования командного творчества, мобилизации энергии для решения задач.
6. Средство формирования новых форм общения внутри команды.
7. Функция конструктивной инициации личностного развития члена команды.

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

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

Аналитики предлагают выделять следующие стадии конфликтов:

• предконфликтная фаза, которая никак не проявляется и остается на уровне внутренних процессов участников события;
• начало конфликта;
• эскалация (нагнетание) конфликта;
• завершение ситуации;
• постконфликтная фаза.

Управление конфликтами между участниками

Владение одной из ролевых классификаций в проектных командах также помогает менеджеру проекта в управлении конфликтами.

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

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

Ролевая расстановка в проекте по Мередиту Белбину

М. Белбин разработал прикладной метод, который помогает организовать совместную работу на основе теории командных ролей.

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

Функции конфликтов, их стадии и командные роли позволяют выстроить эффективное управление конфликтами по следующим направлениям.

1. Системные решения, снижающие вероятность возникновения конфликтов. Среди них – эффективное целеполагание деятельности команды и справедливая система мотивации. Четкая регламентация требований к командной деятельности и установление правил взаимодействия ее членов.
2. Применение методов сглаживания конфликтной ситуации, которые характеризуются пассивной формой реагирования, намерением сохранить взаимодействие и смягчить ситуацию. Методы применимы в ситуации, когда руководитель проекта и одна из сторон конфликта готовы проявить великодушие.
3. Использование компромисса, основанного на принятии противоположной точки зрения, открытого обсуждения позиций сторон и поиска решения, приемлемого для всех. В условиях компромисса велики риски скатиться в конформизм, что иногда неблагоприятно влияет на результаты проекта.
4. Включение открытой конфронтации со стороной конфликта, действующего деструктивно. Проект-менеджер вправе и обязан применить метод в ряде случаев: принципиальности и важности конфликтного вопроса для судьбы проекта; уверенности PM, что его вариант наилучший и укрепит его лидерскую позицию; когда другого способа разрешения конфликта нет, и PM не многое потеряет в случае разрыва отношений.
5. Разрешение конфликта в сотрудничестве конфликтующих сторон. Данный способ допустимо использовать в условиях низкой эмоциональной напряженности и высокой адекватности сторон конфликта.

Управление коммуникациями – хорошо проработанная регламентами процедура. Стадии и процессы этого блока управления детально описаны в PMBOK. Во главу угла поставлены цели проекта, которые опираются на ожидания заинтересованных сторон.

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

Управление конфликтами в составе построения системы коммуникаций – одна из ключевых компетенций менеджера проекта.

Источник: http://projectimo.ru/komanda-i-motivaciya/upravlenie-kommunikaciyami-proekta.html

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

ООО «Заказчик», именуемое в дальнейшем «Заказчик», в лице директора Иванова Ивана Ивановича, действующего на основании Устава, с одной стороны, и ООО «Софтария» в лице директора, Кузьмина Романа Михайловича действующего на основании Устава, именуемое в дальнейшем « Исполнитель», с другой стороны, – в дальнейшем по отдельности или вместе именуемые «Сторона», «Стороны», -согласовали следующий план работы над проектом «Мегапроект».

Данный документ описывает план управления проектом «Мегапроект». Оперативное управление проектом осуществляется менеджерами Исполнителя.

Краткое описание проекта

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

Список артефактов, которые будут получены в процессе работы над проектом

В результате работы над проектом должны быть произведены и переданы Заказчику следующие продукты:

• Исходные коды программного обеспечения «Мегапроект» (Должны находиться в системе контроля версий SVN, установленной на территории Заказчика
• Дистрибутив программного обеспечения
• Инструкция по сборке дистрибутива из исходных кодов, находящихся в системе контроля версий.
• Инструкция по установке дистрибутива
• Руководство для администратора системы

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

• Техническое задание на разработку системы (SRS)
• Критерии приемки проекта
• Календарный план разработки
• Бюджет проекта
• Документ, описывающий архитектуру проекта (SAD)
• База данных учета изменений (это не документ, а база данных системы ISSUE Tracking JIRA)
• И данный документ — план управления проектом

Организационная структура проекта

Со стороны Заказчика в проекте участвуют исполнители следующих ролей:

• Представитель заказчика — представитель Заказчика, ответственный за формулирование требований, принятие стратегических решений, одобрение или не одобрение изменений а также предоставление информации, необходимой разработчикам проекта. Обычно Представитель Заказчика является представителем группы лиц, осуществляющих стратегическое управление проектом, однако существование и состав этой группы лиц является внутренним делом компании Заказчика. При данном масштабе проекта предполагается один Представитель Заказчика.
• Главный заказчик — лицо, ответственное за разрешение проблем общего характера, в случае разногласий между менеджером проекта и представителем Заказчика.
• Администратор инфраструктуры — ответственен за предоставление доступа к системам, находящимся на стороне Заказчика (SVN, Jira итп) а также за обеспечение их бесперебойной работы.
• Приёмщики — лица, ответственные за проверку выполнения критериев приемки.

Со стороны Исполнителя в проекте участвуют

• Менеджер проекта — выстраивание процессов управления проектом, решение важных вопросов, контроль процесса, внесение корректив.
• Лидер команды — управление оперативной деятельностью проекта согласно заданным процессам.
• Аналитик — уточнение требований к проекту
• Разработчики проекта — разработка архитектуры, написание кода, тестирование результатов друг друга
• Эксперт – аудитор — выполнение независимого аудита кода
• Тестировщики — выполнение независимого тестирования

В данном проекте возможно совмещение некоторых ролей, при этом недопустимо совмещение роли разработчика и тестировщика.

Процесс управления проектом

Согласована с Заказчиком и определена в ТЗ

Выбор персонала

В выполнении данного проекта со стороны Исполнителя планируется участие следующих специалистов.

• Пелевин Дмитрий Олегович — Лидер команды, Старший разработчик
• Рудер Иван Давыдович — Аналитик, Разработчик
• Кузьмин Роман Михайлович — Менеджер проекта
• Чуркин Иван Валерьевич — Эксперт-аудитор

Тестировщики на этой стадии проекта не определены. Будут выбраны в зависимости от наличия свободного времени.

Ресурсы

Рабочие станции разработчиков и ПО, необходимое им для работы предоставляет Исполнитель.

Заказчик предоставляет доступ к системе контроля версий SVN, находящейся на одном из ее серверов и обеспечивает бесперебойную работу этого сервера и его доступ в интернет.

Заказчик предоставляет доступ к системе Issue Tracking-a JIRA.

Заказчик предоставляет доступ к системе класса Team Collabortaion (возможно Confluence, коль скоро используем JIRA).

Исполнитель также предоставляет сервер для сборки версий системы и систему Continuum, в качестве системы непрерывной интеграции(CI)

Обучение персонала

В рамках проекта необходимо выделение бюджета и времени для обучения разработчиков технологии Мегатехнология.

Предварительное расписание

Первый релиз проект должен выйти 20 августа 2010 года

Планируемый бюджет

Бюджет проекта составляет 3 миллиона долларов.

Управление требованиями

Изменение требований инициируется Представителем Заказчика в виде создания нового Issue в JIRA и назначения Аналитика ответственным за него.

Аналитик ответственен за выполнение оценки влияния каждого изменения на проект. Изменение может

• Увеличить бюджет проекта
• Увеличить календарный срок проекта
• Внести в проект новые риски

Источник: http://blog-of-roman.blogspot.com/2008/10/2-2-2-2-3-3-3-3-3-3-4-4-4-4-4-4-4-4-5-5.html

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

Зачем нам нужен план управления конфигурациями? Основные понятия и концепции документа

Александр Новичков
10.04.2007

Всегда не хватает времени, чтобы выполнить работу как надо, но на то, чтобы ее переделать, время находится…

Что такое план УК?

Многие компании при попытке поставить любой процесс (не важно какой, но в данном случае – Управления Конфигурациями) ограничиваются только инсталляцией программных средств с минимальными затратами в дальнейшей работе. Так был загублен не один проект. Во-первых, всегда должна быть планомерная работа.

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

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

План должен быть документально оформлен и выполнен (план может быть частью плана управления конфигурацией системы).

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

Кто пишет план УК?

По большому счету написание плана – коллективная работа. Здесь задействованы все участники проекта, так как на основе их информации и рождается план УК.

Если говорить применительно к терминологии УК, то есть роль, которая отвечает за физическое написание плана – Менеджер УК.

Менеджер Управления Конфигурациями – ключевая роль. Этот человек знает процесс разработки. Понимает цели и задачи УК. Все свои знания он излагает в плане УК. Сам управляет процессом УК.

Очень часто пытаются либо вообще обойтись без такой роли, либо «спихивают» ее на разработчиков. Естественно, это неправильно, так как разработчик не видит всей картины процесса разработки, может не понимать структурных взаимодействий между отделами… и т.д.

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

Такой человек всегда есть в коллективе, как правило, это лидер разработчиков или руководитель отдела разработки.

Техническое применение плана (реализация плана в средствах поддержки УК)

Как мы уже говорили выше – план содержит высокоуровневое описание процесса, но чтобы инструментальные средства поддержки УК начали следовать плану, необходимо выполнить их физическую настройку:

• Установить средства;
• Разработать экранные формы запросов на изменение;
• Установить политику доступа;
• Определить жизненный цикл запросов на изменение;
• Поставить данные под УК в соответствии с планом;
• И т.д.

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

Когда готовят план УК?

План разрабатывается на ранних стадиях общего планирования проекта. План должен быть подготовлен на самых ранних стадиях, еще до того, как разработчики включили компьютеры – момент проработки технического задания уже нужно писать план УК. Это в идеале. На практике, как правило, процесс уже сложился и его требуется сначала описать, а потом, по потребностям модифицировать, улучшить.

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

Иногда применяется практика выделения общих частей плана УК и утверждение их как составная часть стандарта на разработку в компании. После чего каждый проект использует общий план + выпускает к нему набор дополнений для конкретного проекта.

Впрочем набор дополнений не может противоречить основному плану.

Поддержка плана в актуальном состоянии

План рассматривается всеми участниками процесса и рецензируется ими.

План – живой документ. План пишут живые люди, которые могут ошибиться.

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

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

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

Самое любопытное заключено в том, что если специалисты на ранних этапах внедрения отслеживали актуальность плана, то со временем план УК (а вместе с ним и большинство документов по другим процессам) постепенно «задвигается» и работа по нему прекращается.

И получается очень занятная ситуация: с одной стороны, если идти по формальным признакам, в организации есть процесс и есть НМО, описывающее его. С другой стороны, по факту, НМО описывает нечто, чего уже нет в организации. В итоге можно считать, что в организации нет плана УК, так как он не отражает реалии.

С подобным ходом вещей необходимо нещадно бороться. Мы все прекрасно понимаем, что нормальное состояние человека и организации это совершенствование (совершение процесса, самосовершенствование… и т.д.) имеющегося.

Просто насущно необходимо совершенствовать документацию по процессу вместе с самим процессом. Их эволюционирование должно осуществляться параллельно. Только тогда можно будет говорить о зрелости процессов в организации.

План УК в стандартах

План УК является важнейшим документом процесса. По большому счету он является единственным документом процесса УК.

Состав и содержимое плана УК определяется в некоторых стандартах, но в большинстве случаев существенно дорабатывается под нужды конкретной организации или проекта при внедрении процессов ЖЦ ПС.

Все рассмотренные в данные книге стандарты определяют процесс, роли, но не все определяют и классифицируют планы УК. Рассмотрим подробнее требования стандартов на содержимое планов УК:

Таблица 1 – Определение структуры плана УК в стандартах

Источник: https://www.ibm.com/developerworks/ru/library/plan-uk/

Управление конфигурацией проекта или 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 человек.

Источник: https://upravlenie-proektami.ru/upravlenie-konfiguraciey-proekta-ili-configuration-management