15. Управление учасниками ІТ-проекта на стадии проектирования

Привет, сегодня поговорим про управление учасниками іт-проекта на стадии проектирования, обещаю рассказать все что знаю. Для того чтобы лучше понимать что такое управление учасниками іт-проекта на стадии проектирования , настоятельно рекомендую прочитать все из категории Управление разработкой программных IT проектов.

15.1.         Осуществление интегрированного управления изменениями

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

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

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

Основным инструментом, позволяющим перевести разговоры об интегрированном управлении изменениями, на уровень конкретных действий, процедур и ответственных ролей является матрица координации изменений (CCM - Change CoordinationMatrix) и сопутствующие ей запрос на внесение изменений (Project Change Request - PCR) и журнал изменений проекта (ProjectChange Log - PCL). Комплексное использование этих инструментов привносит порядок и процесс внесения изменений в проект: стандартизованная последовательность действий, задач и формализованные роли значительно снижают такие проблемы, как расползание содержания проекта (scope creep), перерасход бюджета и смещение даты завершения проекта.

Матрица координации изменений [18]

В соответствии с рекомендациями матрица координации изменений состоит из следующих элементов (см. рис. 15.1).

Рис. 15.1. Пример матрицы координации изменений (ССМ)

1.     Формирование запроса на внесение изменения

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

2.     Регистрация запроса на внесение изменений в журнале изменений проекта

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

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

4.     Принятие решения по запросу на внесение изменения в проект Часто, чтобы не допустить реализации избыточных изменений от инициатора изменения, требуется обозначить тип предлагаемого им изменения в терминах: "необходимое" или "желаемое" ("must have" и "nice to have" ). "Необходимое" изменение - то, без которого проект может стать провальным, следовательно, такое изменение требует надлежащего внимания и утверждения. С другой стороны, "желаемое" изменение обычно придает продукту дополнительную функциональность, но не меняет его суть. При этом желаемое изменение может легко привести к дополнительным усилиям по перепланированию, что становится основным доводом в пользу отклонения такого изменения. Подход необходимого/желаемого изменения может стать хорошим способом избежать рисков существенного расползания содержания.

Итак, принятое решение по запросу фиксируется в PCL. Когда запрос на изменение отклоняется, копия помещается в главный файл, а оригинал возвращается автору с объяснением решения и оснований для него. Если же PCR утверждается, координатор придает ему официальный статус и отправляет его тем, кто будет затронут изменением, для реализации. Координатор также информирует автора.

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

5.     Мониторинг реализации изменений

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

6.     Обновление информации о сроках, стоимости, качестве и т.п. проекта

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

Запрос на внесение изменений

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

Таблица 15.1. Шаблон запроса на внесение изменений (PCR)

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

По возможности рекомендуется реализовать изменения на ранних стадиях проекта, в то время, когда стоимость их реализации традиционно гораздо ниже. Со временем продвижения вперед по расписанию проекта стоимость внесения изменений возрастает [11]. Вообще говоря, на стадии планирования обычно не имеет смысла использовать PCR: при наличии лишь грубо очерченного содержания нет никакой практической надобности пытаться контролировать изменения при помощи формализованной процедуры. Однако на более поздней стадии проектирования PCR приобретает практический смысл и его применение становится финансово оправданным. Например, на проекте разработки нового продукта имеет смысл использовать PCR для изменений, которые составляют отход от согласованных технических спецификаций и влияют на спецификации, выпущенные инженерным отделом для планирования закупок или производства. Тем не менее, в какой-то момент времени внесение изменений в проект может замедлить ход продвижения проекта, потенциально ведя к дорогостоящим переделкам. В подобной ситуации эффективным шагом является замораживание проекта по предметной части, после которого ни одно изменение не будет рассматриваться, если только не находятся критические причины в пользу такого рассмотрения. В качестве примера можно привести финансируемое заказчиком требование добавить в продукт новый показатель безопасности.

Рекомендации к заполнению содержательных разделов PCR (см. табл. 15.1)

1.                     Описание предлагаемых к внесению изменений и их воздействий на содержание / качество

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

2.                     Объяснение причин изменения

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

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

том, что такое рассмотрение чрезмерно медлительно. Об этом говорит сайт https://intellect.icu . Для преодоления этой проблемы вводится графа "экстренные меры", задача такого PCR - проинформировать орган по изменениям о том, что запрашиваемое изменение нуждается в срочном рассмотрении и утверждении. Это может означать, что органу по изменениям придется действовать быстро. Исключительно важно, чтобы чрезвычайные изменения не являлись оправданием дезинформирующих оценок в части качества, исполнения, надежности, безопасности или любых других аспектов.

4.                     Оценка влияния на расписание проекта

Сетевой график, на котором показаны логические зависимости операций, помогает анализировать, каким образом изменения в одном предмете поставки и соответствующих ему операциях повлияют на зависимые операции, расположенные дальше во времени. Часто оценивание влияния на расписание выполняется интуитивно, что в среднем на 40% менее эффективно аналитического подхода (McAfee, 2009), в то время как неформальный, но качественно выполненный анализ сетевого графика пойдет на пользу любому проекту.

5.                     Оценка влияния на стоимость проекта

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

6.                     Идентификация типа изменения

Для избегания риска "расползания" расписания, объема и бюджета проекта необходимо просеивать все предлагаемые изменения путем определения, как они повлияют на содержание и качество проекта. Если изменение оказывает незначительное влияние, то оно может рассматриваться как незначительное корректирующее воздействие, не затрагивающее базовые планы содержания, качества, стоимости и расписания. И наоборот, изменение может быть определено как значительная перемена в содержании работ, финансировании и сроках. Это может служить обоснованием необходимости перепланирования (или переопределения базового плана), включая изменения расписаний, бюджета и распределения ресурсов. Для того чтобы сделать всех вовлеченных в полном объеме осведомленными о таких последствиях, необходимо определиться с тем, является ли данное изменение значительным или незначительным. А это, в свою очередь, становится возможным лишь после оценивания влияния изменения на содержание, качество, стоимость и расписание.

7.                     Принятие решения/ резолюция по PCR

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

Журнал изменений проекта

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

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

Таблица 15.2. Шаблон журнала изменений проекта (PCL)

Матрица координации изменений обеспечивает последовательность шагов, через которые проходит изменение, и таким образом описывает процедуру отражения информации в PCL. Запрос на внесение изменений является предметом администрирования PCL - соответствующая информация из PCR отражается в журнале изменений проекта. Крайне важно отслеживать статус каждого запроса на внесение изменения, для этого в столбце "Завершено" может быть отражена следующая информация: "Еще нет" или "Да".

15.2.         Обеспечение качества проекта на этапе проектирования

Работы по обеспечению качества проекта на фазе проектирования направлены на решение следующих задач.

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

На этапе планирования фазы проектирования ЖЦ ИТ руководитель проекта совместно с менеджером по качеству выполняеткорректировку программы обеспечения качества проекта.

Для этого предварительно менеджером по качеству осуществляются:

• проверка наличия операций по обеспечению качества выполнения следующих процессов:
• настройка рабочей среды;
• настройка конфигурации (для системного тестирования);
• настройка инфраструктуры, тестирование системы;
• выполнение системного и пользовательского теста;
• установка рабочей среды;
• выполнение теста на запуск;
• подготовка и проведение обучения для конечных пользователей;
• корректировка графика выполнения, списка ответственных за обеспечение качества;
• согласование с руководителем проекта откорректированной программы обеспечения качества, в которую также включается описание обеспечение качества выполнения следующих процессов:
• создание спецификаций на проектирование;
• создание технических спецификаций;
• определение методов интеграции и модификаций;
• определение критериев тестирования;
• определение дополнительных требований к обучению;
• настройка конфигурации;
• установка среды разработки;
• установка среды тестирования;
• разработка функциональных характеристик;
• тестирование параметров/функций;
• тестирование процессов;
• общее тестирование;
• создание технической и пользовательской документации;
• проверка наличия необходимых процедур;
• доработка процедур обеспечения и контроля качества на этапе производства (настройки и внедрения).

15.3.         Обеспечение целостности элементов конфигурации

На фазе проектирования действия по управлению конфигурацией проекта используются для обеспечения целостности базовых результатов текущей и предшествующих фаз ЖЦ ИС.

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

Реализуемое на данной стадии сопровождение и контроль документов, как и прежде, предусматривает сохранение и ведение документации по проекту. Цель подпроцесса - гарантировать:

• доступ к документам для ознакомления;
• защиту документов от несанкционированного доступа;
• контроль за ведением документов;
• осведомленность получателя о статусе документа;
• обеспечение процедуры обзора и утверждения документа.

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

Производимый на данной фазе контроль конфигурации предназначен для управления элементами конфигурации [22]. В рамках данного процесса должна быть обеспечена возможность модификации элементов конфигурации. Например, новые результаты по проекту, как правило, означают создание нового элемента конфигурации. Данный подпроцесс должен обеспечиватьзамораживание состояния элементов конфигурации, например, при достижении базового набора конфигурации. Менеджер по управлению конфигурацией осуществляет контроль конфигурации, а руководители проекта со стороны заказчика и исполнителя принимают участие в принятии решений по вопросам, возникающим в процессе контроля конфигурации.

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

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

Учет состояния конфигурации производится с целью отслеживания состояния конфигурации и ее элементов. В задачи подпроцесса входит предоставление из репозитория УК следующей актуальной информации о состоянии всех элементов конфигурации:

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

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

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

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

• добавление/удаление элементов конфигурации;
• задание базового набора;
• "замораживание" версий.

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

15.4.         Обновление реестра рисков на фазе проектирования

Для фазы проектирования ЖЦ ИС наиболее типичны следующие источники рисков [17]:

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

Наиболее распространенными действиями, направленными на смягчение вышеперечисленных рисков, являются действия, направленные на то, чтобы:

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

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

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

При выявлении и анализе рисков существенную помощь могут оказать формализованные методы. Например, в стандарте SPICEописаны 35 основных процессов, используемых при разработке ИС, и методы их оценки, а также приводятся пять групп процессов (взаимодействие поставщика и потребителя, проектирование, обеспечение, управление и организационные процессы) и набор соответствующих базовых методов. При сравнении текущих процессов проекта с приведенными референтными моделями можно выявить вероятные риски каждого из процессов [15].

15.5.         Набор команды проекта

Основными задачами управления персоналом на стадии проектирования ЖЦ являются:

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

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

В ходе процесса управления ресурсами на стадии проектирования основное внимание уделяется планированию и распределению персонала с требуемой квалификацией для выполнения запланированных работ этапа. Основные методы решения этой задачи - организационное планирование, оценка навыков, набор персонала, ведение переговоров. В процессе планирования этапа участвуют менеджеры проекта со стороны исполнителя и заказчика, поскольку со стороны заказчика нужно согласовать позиции, которые занимает персонал, и определить его ответственность. Поскольку во время выполнения проекта происходят организационные и временные изменения, подбор, организация и обучение команды становятся одной из самых значительных проблем проекта. Чтобы обеспечить проектные работы человеческими ресурсами в нужное время и с требуемой квалификацией, организуют обучение персонала. Планы обучения составляются таким образом, чтобы обеспечить в полной мере исполнениечленами команды своих ролей. Для крупных проектов обучение необходимо внести в рабочий план, чтобы учесть загруженность персонала и возможности его привлечения к работе над проектом [18]. Обучение могут производить как организация-исполнитель, так и специализированные учебные центры. При разработке плана обучения должна быть разработана процедура контроля качества произведенного обучения, которая включает действия по проверке знаний на предмет их соответствия требованиям к квалификации планируемых работ.

Описание процесса

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

Согласно PMBOK [1,23], набор команды проекта - это процесс привлечения человеческих ресурсов, необходимых для выполнения проекта.

При наборе членов команды проекта необходимо учитывать следующее:

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

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

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

Исходной информацией для определения численности команды проекта являются расписание проекта и организационные диаграммы. Пример шаблона организационной диаграммы приведен на рис. 15.2. Организационная диаграмма проекта - это графическое представление состава команды проекта и отношения подотчетности между ее членами. В зависимости от потребностей проекта она может быть официальной или неофициальной, подробной или обобщенной [18].

Рис. 15.2. Шаблон организационной диаграммы [18]

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

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

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

Рис. 15.3. Шаблон для документирования процесса набора команды

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

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

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

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

Сплочению команды способствует размещение членов команды проекта в одном месте. Стратегия со-расположения предполагает наличие комнаты, оснащенной электронными средствами связи, досками для расписаний и другими приспособлениями, которые способствуют взаимному общению.

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

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

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

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

В общем, мой друг ты одолел чтение этой статьи об управление учасниками іт-проекта на стадии проектирования. Работы впереди у тебя будет много. Смело пиши комментарии, развивайся и счастье окажется в твоих руках. Надеюсь, что теперь ты понял что такое управление учасниками іт-проекта на стадии проектирования и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Управление разработкой программных IT проектов