Лекция 2. Лекция Формирование команды
 Скачать 24.68 Kb.
|
|
Лекция 2. Формирование команды Участники проекта Проекты выполняются людьми и для людей. Это взаимодействие порождает множество управленческих задач, необходимость выстроить процессы совместной работы между участниками проекта. Прежде всего определим, кого будем понимать под участниками проекта. Участники проекта – это физические и/или юридические лица, которые непосредственно вовлечены в реализацию проекта. И Исполнитель, и Заказчик обязательно являются участниками проекта. А вот сотрудник, который просто интересуется, как идет проект, уже не входит в группу участников проекта. Такие сотрудники относятся к категории "заинтересованных сторон проекта" (или на английский манер, "стейкхолдеров"). О работе с заинтересованными сторонами более подробно будет рассказано в следующих лекциях. Сейчас же скажем кратко, что под заинтересованной стороной будем понимать персону, группу, организацию, систему, которые могут повлиять на проект или чьи интересы затронет выполнение проекта. В данном разделе сейчас сконцентрируемся на изучении участников проекта, на тех, кто непосредственно выполняет проект. Критически важным для управления проектом является с самого начала понимать персональную мотивацию, заинтересовнаность и ответственность участников проекта в выполнении проекта и получения требуемых результатов. Во-первых, ожидания от проекта и требования формируются непосредственно во взаимодействии участников проекта. Во-вторых, выполнение проекта осуществляется командой участников, от профессионализма и взаимодействия которых напрямую зависит результат. Поэтому важной частью методов управления проектной деятельностью является формирование ролевой модели участников проекта. Это позволяет идентифицировать, кто какие функции в проекте выполняет, и помогает строить управление и взаимодействие с использованием отработанных типовых подходов и методов. Роли в проекте Роль в проекте – определенный набор функций и полномочий в проекте, созданный с целью распределения обязанностей между участниками проекта. Проектную роль можно рассматривать как временную должность в организации. Выделение ролей позволяет определить набор функций, которые должны выполняться в проекте безотносительно к конкретным персонам участников. В соответствии с ролями можно подбирать людей в команду или распределять ответственность и полномочия между участниками уже сформированного коллектива. По функциям в проекте можно выделить группы ролей участников, осуществляющие: Управление проектом. Выполнение работ проекта. Поддержания существования команды проекта. (1) Группа «Управление проектами». Основные функции участников, относящихся к данной группе: инициация проекта, выделение необходимых ресурсов, формирование требований, управление реализацией и осуществление сдачи/приемки. Здесь выделяются следующие роли: Инициатор, Куратор (Спонсор), Заказчик, Руководитель проекта. (2) Группа «Выполнение работ проекта». Для этой группы ключевую роль играет понятие «команда проектa». Команда проекта – это временная рабочая группа, выполняющая работы по проекту и ответственная перед Руководителем проекта за их выполнение. Команда проектa состоит из участников, каждый из которых выполняет в команде одну или несколько ролей. Выделение ролей по формальным компетенциям определяется в целом предметной областью и более детально – конкретными задачами, которые должны быть решены в проекте. В таблице приведены примеры ролей (по профессиональным компетенциям) в различных областях. Таблица 1 — Примеры ролей
(3) Группа «Поддержания существования команды проекта». Основная задача участников этой группы – обеспечение существования и работоспособности команды, где условия для взаимодействия имеют ключевое значение. Здесь важно учесть психологические особенности каждого из участников. К этой группе относят те роли, которые помогают создать дружественную и конструктивную атмосферу, обеспечивают мотивацию команды проекта. В целом, поддержание работы команды – прямая ответственность руководителя проекта. На помощь здесь приходят методы из сферы психологии, касающиеся вопросов группового взаимодействия. Обычно роли распределяются одновременно по двум категориям: формально – по профессиональным компетенциям; неформально – по личностным и поведенческим свойствам участников. Примеры формального распределения ролей среди участников были приведены выше, а теперь посмотрим какие бывают неформальные роли. Одним из популярных и авторитетных исследований в данном направлении являются работы профессора Мередита Белбина, автора теории групповых ролей. Именно он предложил модели ролевого взаимодействия в коллективах. Согласно предложениям Белбина в каждой проектной команде независимо от ее численного состава должны выполняться следующие роли (неформальное выделение ролей, по поведенческим характеристикам): Председатель (coordinator) – выбирает путь, по которому команда движется вперед к общим целям, обеспечивая наилучшее использование ее ресурсов; умеет обнаружить сильные и слабые стороны команды и обеспечить наибольшее применение потенциала каждого участника команды. Мотиватор (shaper) – обеспечивает необходимый драйв, чтобы команда продолжала двигаться и не теряла фокус. Придает законченную форму действиям команды, направляет внимание и пытается придать определенные рамки групповым обсуждениям и результатам совместной деятельности. Генератор идей (plant) – выдвигает новые идеи и стратегии, уделяя особое внимание главным проблемам, с которыми сталкивается группа. Критик (monitor-evaluator) – анализирует проблемы с прагматической точки зрения, оценивает идеи и предложения таким образом, чтобы команда могла принять сбалансированные решения. Работник (implementer) – превращает планы и концепции в практические решения. Очевидно, любой безнадежный проект нуждается, по крайней мере, в паре таких пчелок, но сами по себе они не способны принести успех проекту, поскольку не обладают необходимой широтой кругозора. Вдохновитель (team worker) – поддерживает силу духа в участниках проекта, оказывает им помощь в трудных ситуациях, пытается улучшить взаимоотношения между ними и в целом способствует поднятию командного настроя. Добытчик (resource investigator) – обнаруживает и сообщает о новых идеях, разработках и ресурсах, имеющихся за пределами проектной группы, налаживает внешние контакты, которые могут быть полезными для команды, и проводит все последующие переговоры. Контролер (completer) – поддерживает в команде настойчивость в достижении цели, активно стремится отыскать работу, которая требует повышенного внимания, и старается, насколько возможно, избавить команду от ошибок, связанных как с деятельностью, так и с бездеятельностью. Специалист (specialist) – обеспечивает глубокое знание ключевой области для команды. Изначально Белбин выделял восемь ролей, однако впоследствии добавилась еще девятая роль. Основные рекомендации. Желательно, чтобы все эти роли присутствовали в команде. В среднем у каждого человека есть предрасположенность к 1–3 ролям из перечисленной классификации. У некоторых людей не наблюдается выраженных предпочтений к определенным ролям, они могут выполнять те роли, которые им поручат. Есть люди, которым некомфортно работать в команде в принципе, что также стоит учитывать при формировании команды. На основании работ Белбина разработаны тесты на определение предпочтительных ролей, доступны для желающих проверить себя и свою команду в интернете (например, здесь). Ответственность участников команды Помимо ролевого распределения в команде зачастую необходимо определить персональную ответственность и степень участия в выполнении отдельных этапов и задач проекта. При составлении матрицы ответственности проекта используют, например, методику RACI. Методика RACI является удобным и наглядным средством планирования ответственности членов проектной команды при выполнении задач на каждом из этапов проекта. Термин RACI является аббревиатурой наименований степеней ответственности, как показано в таблице 2. Таблица 2 — Степени ответственности
Матрица состоит из списка фаз и работ проекта по вертикали и перечня ролей участников (иногда персон) по горизонтали. На пересечении указывается степень ответственности роли (конкретного участника) за данный этап или работу. Пример шаблона матрицы приведен в таблице 3. Таблица 3 — Матрица ответственности
Таблица 4 – Пример матрицы ответственности
Основные правила разработки матрицы ответственности: Каждая задача должна иметь Ответственного и одного или нескольких Исполнителей. Консультант и Наблюдатель не обязательны для каждой задачи. Ответственный за задачу – только один. В случае, когда назначается больше ответственных, то четко разграничивают зоны ответственности каждого из назначенных. Одна роль может брать на себя разные степени ответственности. Чаще всего встречается комбинация: «Исполнитель» + «Ответственный». Составлять матрицу ответственности предпочтительнее в команде. Важно, чтобы каждый участник осознал свою роль и задачи, которые ему предстоит выполнить. После составления матрицы ответственности проведите ее анализ: Проведите анализ по каждой роли – по «вертикали». Такой анализ позволяет увидеть обязанности и наделенные полномочия каждого из участников проекта, объективно оценить уровень нагрузки. Много «Исп.». Успеет ли одна роль выполнить столько задач, хватит ли навыков для выполнения? В таком случае возможно, что участник будет разрываться между задачами, что наверняка негативно скажется на всем проекте. Много «Отв.». Правильно ли распределена ответственность за задачи? Рекомендуется более равномерно распределить ответственность. Нет «Исп.» и «Отв.». Проверьте, нужна ли такая роль в проекте? Нет пустых ячеек. Действительно ли эта роль должна быть вовлечена в такое количество задач? Не перегружен ли участник? 2. Проведите анализ по каждой задачи (по каждому этапу) – по горизонтали. Благодаря такому анализу возможно оценить организацию работы на каждом этапе. Более одного «Отв.». Может произойти размытие ответственности, рекомендуется выбрать одного ответственного. Нет «Отв.». Необходимо назначить ответственного. Более одного «Исп.». Проанализируйте, смогут ли несколько участников вместе выполнять одну задачу. Как наладить взаимодействие. Нет «Исп.». Кто-то должен непосредственно выполнять задачу, необходимо назначить такого участника. Много «Конс.». Будет ли эффективно такое количество консультаций? Ведь обсуждения часто тормозят работу: нужно находить компромиссы между пожеланиями и замечаниями, ожидать, пока все ознакомятся с задачей и внесут свои правки. Нет «Конс.» и «Набл.». Правильно ли установлены коммуникации? Грамотно составленная матрица позволяет осознать участникам проекта свою ответственность, а соответственно уменьшить количество конфликтов в команде. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||