Главная страница
Навигация по странице:

  • Область Название роли

  • 2.3 Ответственность участников команды

  • Название степени ответственности Обозначение в матрице Описание

  • Фазы / Работы Роли участников

  • Персона Андрей Федор

  • ЛЕКЦИЯ 3 - КОММУНИКАЦИИ В ПРОЕКТЕ 3.1 Введение

  • 3.2 Основные определения и понятия Процессы взаимодействия между участниками проекта принято называть коммуникациями

  • Все лекции. Лекция 1 общее представление о проектной деятельности 1 Проектная деятельность общее представление. Понятие проекта


    Скачать 0.68 Mb.
    НазваниеЛекция 1 общее представление о проектной деятельности 1 Проектная деятельность общее представление. Понятие проекта
    Дата26.05.2020
    Размер0.68 Mb.
    Формат файлаdocx
    Имя файлаВсе лекции.docx
    ТипЛекция
    #125455
    страница2 из 11
    1   2   3   4   5   6   7   8   9   10   11

    Команда проекта – это временная рабочая группа, выполняющая работы по проекту и ответственная перед Руководителем проекта за их выполнение.

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

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

    Таблица 1 — Примеры ролей

    Область

    Название роли

    Информационные технологии

    • аналитик,

    • системный архитектор,

    • программист,

    • технический писатель.

    Строительство

    • главный инженер проекта,

    • проектировщик,

    • прораб,

    • инженер технического надзора.

    Реклама

    • маркетолог,

    • копирайтер,

    • дизайнер.

    (3) Группа «Поддержания существования команды проекта». Основная задача участников этой группы – обеспечение существования и работоспособности команды, где условия для взаимодействия имеют ключевое значение. Здесь важно учесть психологические особенности каждого из участников. К этой группе относят те роли, которые помогают создать дружественную и конструктивную атмосферу, обеспечивают мотивацию команды проекта. 

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

      • формально – по профессиональным компетенциям;

      • неформально – по личностным и поведенческим свойствам участников.

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

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

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

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

    3. Генератор идей (plant) – выдвигает новые идеи и стратегии, уделяя особое внимание главным проблемам, с которыми сталкивается группа.

    4. Критик (monitor-evaluator) – анализирует проблемы с прагматической точки зрения, оценивает идеи и предложения таким образом, чтобы команда могла принять сбалансированные решения.

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

    6. Вдохновитель (team worker) – поддерживает силу духа в участниках проекта, оказывает им помощь в трудных ситуациях, пытается улучшить взаимоотношения между ними и в целом способствует поднятию командного настроя.

    7. Добытчик (resource investigator) – обнаруживает и сообщает о новых идеях, разработках и ресурсах, имеющихся за пределами проектной группы, налаживает внешние контакты, которые могут быть полезными для команды, и проводит все последующие переговоры.

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

    9. Специалист (specialist) – обеспечивает глубокое знание ключевой области для команды.

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

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

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

    2.3 Ответственность участников команды

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

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

    Термин RACI является аббревиатурой наименований степеней ответственности, как показано в таблице 2.

    Таблица 2 — Степени ответственности

    Название степени ответственности

    Обозначение в матрице

    Описание

    Исполнитель (Responsible)

    Исп. (R)

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

    Ответственный (Accountable)

    Отв. (A)

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

    Консультант (Consulted)

    Конс. (C)

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

    Наблюдатель (Informed)

    Набл. (I)

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

    Матрица состоит из списка фаз и работ проекта по вертикали и перечня ролей участников (иногда персон) по горизонтали. На пересечении указывается степень ответственности роли (конкретного участника) за данный этап или работу. Пример шаблона матрицы приведен в таблице 3.

    Таблица 3 — Матрица ответственности

    Фазы / Работы

    Роли участников

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    Таблица 4 – Пример матрицы ответственности 

    Работа

    Персона

    Андрей

    Федор

    Мария

    Анна

    Составление меню

    R/A

    I

    C

    C

    Закупка продуктов

    I

    I

    R

    A

    Приготовление

    C

    I

    I

    R/A

    Сервировка стола

    I

    R/A

    I

    I

    Основные правила разработки матрицы ответственности:

    1. Каждая задача должна иметь Ответственного и одного или нескольких Исполнителей. Консультант и Наблюдатель не обязательны для каждой задачи.

    2. Ответственный за задачу – только один. В случае, когда назначается больше ответственных, то четко разграничивают зоны ответственности каждого из назначенных.

    3. Одна роль может брать на себя разные степени ответственности. Чаще всего встречается комбинация: «Исполнитель» + «Ответственный».

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

    После составления матрицы ответственности проведите ее анализ:

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

          • Много «Исп.». Успеет ли одна роль выполнить столько задач, хватит ли навыков для выполнения? В таком случае возможно, что участник будет разрываться между задачами, что наверняка негативно скажется на всем проекте.

          • Много «Отв.». Правильно ли распределена ответственность за задачи? Рекомендуется более равномерно распределить ответственность.

          • Нет «Исп.» и «Отв.». Проверьте, нужна ли такая роль в проекте?

          • Нет пустых ячеек. Действительно ли эта роль должна быть вовлечена в такое количество задач? Не перегружен ли участник?

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

          • Более одного «Отв.». Может произойти размытие ответственности, рекомендуется выбрать одного ответственного.

          • Нет «Отв.». Необходимо назначить ответственного.

          • Более одного «Исп.». Проанализируйте, смогут ли несколько участников вместе выполнять одну задачу. Как наладить взаимодействие.

          • Нет «Исп.». Кто-то должен непосредственно выполнять задачу, необходимо назначить такого участника.

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

          • Нет «Конс.» и «Набл.». Правильно ли установлены коммуникации?

     Грамотно составленная матрица позволяет осознать участникам проекта свою ответственность, а соответственно уменьшить количество конфликтов в команде.

    ЛЕКЦИЯ 3 - КОММУНИКАЦИИ В ПРОЕКТЕ

    3.1 Введение

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

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

    Следовательно, общение (или более строго "Коммуникации") должно происходить по определенным правилам. Даже отсутствие правил может являться одним из правил в команде.

    3.2 Основные определения и понятия

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

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

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

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

    Отсутствие правил коммуникации в проекте способно принести существенный ущерб проекту сразу во всех трёх измерениях: временном, материальном и содержательном. Отсутствие определенных правил может привести либо к тому, что на коммуникации тратится слишком много времени, либо, наоборот, коммуникациями пренебрегают – дальше каждый действует в меру своего собственного понимания задач. Это приводит к рискам дополнительных работ и/или дополнительных затрат времени и ресурсов. Подход к организации коммуникаций под названием «как-нибудь разберемся по ходу» не может быть рекомендован к использованию в проектах на постоянной основе.

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

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

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

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

      • обеспечение вовлеченности участников в совместную работу;

      • координация при выполнении работ;

      • поддержка информированности участников о состоянии проекта;

      • обеспечение подконтрольности деятельности для руководителя проекта и для заинтересованных лиц;

      • хранение рабочей информации.

    Все-таки хочется поменьше говорить и побольше делать!

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

      • иметь определенный режим встреч (совещаний) с командой и с участниками;

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

      • обеспечивать доведение принятых решений и рабочей информации до всех заинтересованных;

      • представлять цели коммуникации, какой вопрос необходимо решить или какое действие инициировать;

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

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

    Для выработки правил, дающих четкие ответы на обозначенные вопросы, а также для обеспечения продуктивной совместной деятельности в проекте, создается система управления коммуникациями.
    1   2   3   4   5   6   7   8   9   10   11


    написать администратору сайта