что такое роль в проекте

Роли в проекте

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

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

Рассмотрим ролевую модель, которая описана в самом популярном в мире (если верить исследованиям PWC) подходе к управлению проектами – PMBOK.

Утверждение требований к продуктам проекта
Приемка продуктов проекта

Утверждение целей проекта, сроков и бюджета
Выделение ресурсов для проекта

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

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

Давайте рассмотрим проект по автоматизации процессов взаимоотношений с клиентами (CRM) в небольшой частной компании. Кто из сотрудников компании, внедряющей у себя CRM, может стать заказчиком такого проекта?

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

Чтобы принять решение о назначении заказчика в проекте CRM, предлагаю последовательно ответить на следующие вопросы:

Если продолжительность проекта составляет примерно полгода, то 48 часов как раз распределятся на 24 недели по 2 часа в неделю. Однако заказчик будет тратить время не только на принятие важных решений. Ему нужно читать и согласовывать документы по требованиям к CRM, участвовать в приемке промежуточных результатов проекта, изучать отчеты руководителя проекта о ходе проекта. На эту работу, с моей точки зрения, уйдет не меньше времени, чем на принятие решений. Отсюда и появляется расчет, что на данный проект заказчику нужно планировать от двух до четырех часов в неделю. Конечно, это очень приблизительный расчет и в каких-то аналогичных проектах у заказчика может уходить намного больше времени на проект.

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

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

Итак, возможны следующие варианты: либо кто-то из этих двух кандидатов сам вызовется стать заказчиком проекта, либо заказчика выберет директор компании, либо старт проекта будет отложен, т.к. пока еще никому результаты проекта не нужны.

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

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

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

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

На самом деле при внедрении CRM руководителем проекта может стать представитель ИТ-компании, которая будет внедрять программный продукт. Но в таком назначении есть смысл, только если ИТ-компания берется сделать проект «под ключ», т.е. готова нести ответственность за достижение всех целей проекта. В случае если ИТ-компания выполняет только часть работ по проекту, придется назначать руководителя проекта из числа сотрудников нашей компании. И если у назначенного на роль руководителя проекта сотрудника нет навыков управления проектом, выполнение проекта в срок и в бюджет с достижением целей – под большим вопросом.

Предположим, что было принято решение отдать ИТ-компании проект CRM «под ключ», и вопрос с назначением руководителя проекта решен – им станет профессиональный руководитель проекта со стороны ИТ-компании, которую еще предстоит выбрать.

В проекте CRM будет 2 команды – со стороны заказчика и со стороны ИТ-компании. Команда со стороны заказчика будет участвовать в задачах по сбору требований и тестированию доработанного функционала CRM, а команда ИТ-компании будет дорабатывать продукт в соответствии с требованиями и готовить его к промышленной эксплуатации.

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

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

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

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

И в завершение – одно наблюдение: чем четче описаны ответственность и полномочия для всех рассмотренных в статье ролей, тем лучше для всех участников проекта. А отсутствие одной из этих ролей приведет к резкому снижению шансов проекта на успех!

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

Успехов вам в определении ролей в проектах!

Источник

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

По результатам множества опросов менеджеров проектов в России и за рубежом, до 80% успеха при реализации проектов обусловлены слаженной работой проектной команды, которая, в свою очередь, обеспечивается верным распределением ролей среди участников. Так какие же роли участников проекта приводят проект к успеху? Многие менеджеры проектов сосредотачиваются на «технических» ролях, таких как проектировщики баз данных, специалисты по сетям, эксперты по пользовательскому интерфейсу и т.д. Все они важны, но нужно подумать и о ролях «психологического» плана, которые могут играть один или более участников команды. В данной статье рассматриваются некоторые наиболее известные подходы в этой области.

На укрупненном уровне роли участников проекта, выполняемые участниками проектной команды, можно подразделить на 3 группы:

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

Роли участников проекта, ориентированные на выполнение задач команды

Роли участников проекта, ориентированные на создание/поддержание работы команды

Индивидуальные роли участников проекта (нефункциональные)

Классический подход к распределению ролей между участниками проектной команды был предложен доктором Реймондом Белбином (Reymond Meredith Belbin). В каждой проектной команде, которая стремится эффективно организовать свою работу, независимо от ее численного состава, должны выполняться следующие 8 ролей.

Председатель (chairman)

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

Оформитель (shaper)

Оформитель (shaper) — придает законченную форму действиям команды, направляет внимание и пытается придать определенные рамки групповым обсуждениям и результатам совместной деятельности. Такой человек может иметь официальную должность «архитектора» или «ведущего проектировщика», но главное то, что эта роль «воображаемая». В безнадежном проекте особенно важно иметь единое и четкое представление о проблеме и ее возможном решении.

Генератор идей (plant)

Генератор идей (plant) — выдвигает новые идеи и стратегии, уделяя особое внимание главным проблемам, с которыми сталкивается группа. Мне кажется, что для такой роли больше подходит название «провокатор» — человек, который пытается внедрять в команде радикальные технологии, искать новые решения технических задач.

Критик (monitor-evaluator)

Критик (monitor-evaluator) — анализирует проблемы с прагматической точки зрения, оценивает идеи и предложения таким образом, чтобы команда могла принять сбалансированные решения. В большинстве случаев такой человек поступает как «скептик», уравновешивая оптимистические предложения оформителя и генератора идей. Критик хорошо знает, что новые технологии отнюдь не всегда работают, обещания поставщиков о возможностях новых средств и языков иногда не сбываются и все может пойти не так, как было задумано.

Рабочая пчелка (company worker)

Рабочая пчелка (company worker) — превращает планы и концепции в практические рабочие процедуры, систематически и эффективно выполняет принятые обязательства. Другими словами, в то время как оформитель придает законченную форму крупным технологическим решениям, генератор идей предлагает радикальные новые решения, а критик занимается поиском изъянов и недостатков в этих предложениях, рабочая пчелка — это тот человек, который работает, не привлекая внимания, и выдает на гора тонны кода. Очевидно, любой безнадежный проект нуждается по крайней мере, в паре таких пчелок, но сами по себе они не способны принести успех проекту, поскольку не обладают необходимой широтой кругозора.

Опора команды (team worker)

Опора команды (team worker) — поддерживает силу духа в участниках проекта, оказывает им помощь в трудных ситуациях, пытается улучшить взаимоотношения между ними и в целом способствует поднятию командного настроя. Другими словами, такой человек выполняет в команде роль «дипломата».

Добытчик (resource investigator)

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

Завершающий (completer)

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

Альтернативные подход

Интересный подход был предложен Риком Баррерой (Rick Barrera), членом PMI, специалистом в области управления проектами. Он выделяет 4 основные категории участников, различных по типу поведения:

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

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

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

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

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

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

Источник

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

Разбирая проектные роли, надо четко отделять их от самого человека: сотрудник может выступать сразу в нескольких ипостасях, а также участвовать в одной разработке в роли А, а в другой — в роли Б. Совершая любое действие в работе, надо понимать от чьего имени это происходит.

Список ролей

Менеджер проекта, PM

Создает и поддерживает план проекта, отвечает за его выполнение.

KPI — маржинальность проекта.

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

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

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

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

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

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

KPI — соответствие системы нефункциональным (нагрузочным) требованиям, легкость ее расширения и развития, отсутствие проблем при интеграции.

Ведущий разработчик, Тимлид

На малом проекте (нет выделенного архитектора) ведущий разработчик отвечает за все задачи по разработке.

Собственно разрабатывает код проекта.

KPI — нулевое количество ошибок в коде.

Планирует работы по тестированию.

KPI — нулевое количество репортов об ошибках от клиента.

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

Системный администратор / сотрудник DevOps

Должен быть способен без программистов развернуть систему.

KPI — попадание в план по задачам разворачивания системы.

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

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

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

KPI аккаунта — рост оборота контрактов по его клиенту и общая маржинальность. В силу этого аккаунт может принимать решения о перебалансировке объема работ между несколькими проектами для одного клиента.

Начальник отдела разработки/аналитики

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

Директор, Генеральный директор, Директор группы компаний, Президент и Заместитель Бога на Земле.

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

Типовые совмещения ролей

Источник

Команда Проекта: Состав, Роли и Этапы Развития

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

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

Содержание:

Что такое команда проекта?

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

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

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

Что отличает команду проекта от группы с общими интересами?

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

Группа людей с общими интересами превращается в команду, когда каждый ее участник может выполнить следующие условия:

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

Рассмотрим подробнее тех, кто обычно формирует такие команды.

Роли в проекте

Роли в проектной команде — это основа, с которой нужно начинать формирование любой рабочей группы. Хороший состав работников — это часто 50% успеха всего проекта. Рассмотрим командные роли на примере проекта по разработке ПО.

Менеджер проекта

Менеджер проекта — главное ответственное лицо в проекте. Его главная цель — привести все и всех к успеху, минуя препятствия, риски, и, сопровождая все это восторженными взглядами конкурентов.

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

У менеджера проекта много забот и обязанностей. Вот главные из них:

1. Планирование проекта

От стараний менеджера зависит, будет ли одобрен проект или нет. Чтобы получить «зеленый свет», обязательно нужен хороший план проекта и график того, как все будет происходить. Важно в самом начале определить объем проекта, спланировать роудмэп и наметить результаты.

Без уникальной стратегии здесь также не обойтись. К счастью, любой управленец избавлен от лишней головной боли, поскольку большую часть планирования берут на себя онлайн инструменты. Например, простейшая таблица Excel или удобная диаграмма Ганта решают многие вопросы «по щелчку».

2. Организация задач

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

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

3. Поддержание духа лидерства

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

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

4. Мониторинг

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

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

5. Коммуникация

Постоянное общение в коллективе — это тоже залог его успеха. Это еще одна забота менеджера.

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

Члены команды

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

Их роли и обязанности зависят от разных факторов. Обычно они занимаются следующим:

Спонсор/заказчик проекта

Спонсор или заказчик — это одновременно внутренний защитник проекта и тот, кто больше всех заинтересован в успешном его исходе.

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

Бизнес-аналитик

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

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

Существует также более общая классификация командных ролей:

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

Состав команды проекта

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

Чаще всего бывают следующие составы проектных групп:

Закрепленный состав

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

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

Команды с неполной занятостью

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

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

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

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

Диаграмма Ганта для проектных команд

Управляйте проектами любой сложности с удобным онлaйн-планировщиком.

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

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

Этапы формирования команды

1. Формирование

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

2. «Притирка»

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

3. Нормальное функционирование

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

4. Реорганизация

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

5. Расформирование команды

Команда расформировывается, когда заканчиваются все задачи. Здесь может быть два варианта:

Пример команды проекта

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

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

Заключение

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

Напоследок, запомните 6 коротких правил для успешного руководства эффективной командой:

Создавайте успешную команду и покоряйте новые проекты!

Источник