Основные правила Project-менеджера. Менеджер проектов это кто


А что делает Менеджер Проекта? — soloviov

Как-то меня представили одному разработчику со стороны Клиента, сказав, что я в команде - менеджер проекта. Разработчик не удержался и ответил: “А, так вы один из тех, кто с утра говорит нам, что делать, а сам потом весь день балду пинает?”

Это - классика жанра. Именно так менеджеры проекта воспринимаются многими разработчиками. Не всеми, конечно. Искренне верю, что читатели блога понимают, во что обычно превращается проект без менеджера.

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

Люди и Роли

Первое, что требуется четко осознать: PM - это не навык и не должность. PM - это роль в проекте.

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

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

И вот тут начинается самое интересное. Угадайте, кому достаются те роли, для которых в команде не нашлось выделенных людей? Правильно: тому, что отвечает за конечный результат - менеджеру проекта.

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

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

  • Подготовка к проекту (Starting up a Project)
  • Открытие проекта (Initiating a Project)
  • Планирование (Planning)
  • Управление стадиями (Controlling a Stage)
  • Управление доставкой продуктов (Managing Product Delivery)
  • Управление границами стадий (Managing Stage Boundaries)
  • Закрытие проекта (Closing a Project)

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

Что часто ожидают от PM?

Оценка

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

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

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

Принятие решений проектного уровня

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

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

Проектирование

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

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

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

Практическое знание технологий

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

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

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

Контроль качества

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

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

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

Теперь у успешных Заказчиков возник вопрос: Зачем мне обо всем это думать, если мой менеджер гениален, и даже при совмещении ролей проблем нет?Возник? Тогда продолжаем разговор…

Учет ресурсов

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

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

  • Либо выясняется, что новому менеджеру нужно еще 3 человека в помощники
  • Либо оказывается, что прежний менеджер “управлял проектом” 30 часов в неделю, а новый утверждает, что будет тратить на “управление” 15 часов в неделю при схожем размере проекта
  • Либо все это происходит наоборот

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

Категоризация работ внутри проекта веб-разработки может быть, например, такой:

  • Управление проектом
  • Проектирование (включая ТЗ и/или прототип)
  • Разработка дизайна основных шаблонов
  • Графические работы
  • Разработка фронт-офиса (статических шаблонов)
  • Программирование (внедрение функционала и CMS)
  • Тестирование
  • Разработка сопроводительной документации
  • Обучение пользователей
  • Администрирование

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

И в заключение, заранее отвечая на вопрос “Какие роли объединять, а какие - нет?”, скажу: единого рецепта не существует. Старайтесь балансировать таланты Вашего менеджера и его полномочия/ответственность. На баланс влияют:

  • Размер проекта и организации
  • Типизация проектов
  • Мотивация менеджера
  • Наверняка что-нибудь еще :)

Удачи! Следите за эфиром!

www.soloviov.ru

«Аналитик и» Проектный Менеджер

Данная статья продолжает цикл статей «Аналитик и» , и в честь надвигающегося дня проектного менеджера в ней мы затронем некоторые аспекты совместной работы бизнес-аналитика (аналитик, Business Analyst, BA) и менеджера проектов (менеджер, Project Manager, PM). Для этого мы вспомним, кто такой аналитик, а потом определим, кто такой PM и какие у него основные функции и обязанности. Различия, как и сходства, будут на лицо, однако кроме этого мы также расскажем о том, что хотят менеджеры от аналитиков, что менеджеры должны делать по отношению к аналитикам, рассмотрим основные проблемные точки взаимодействия. Также мы затронем такую важную тему, как объединение двух ролей (BA и PM) в одном человеке, какие от этого могут быть плюсы и какие минусы.

Кто такой аналитик и кто такой проектный менеджер.

Для начала определим, кто есть ВА и РМ. Да-да, про это совсем недавно было упомянуто в статье «Курс молодого БА: Кто такой бизнес-аналитик?», но, как говорится, «повторение мать учения». Согласно BABOK ’у бизнес-аналитик – «роль, которую выполняет любой человек, когда пользуется набором техник и методик для помощи заинтересованным лицам в решении бизнес-проблем или достижении поставленных задач». РМВОК определяет менеджера проекта (-ов) как «лицо, ответственное за управление проектом», а следовательно, и за его успешность в целом.

Ниже приведены обязанности обоих специалистов:

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

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

Основные обязанности

Извлечение, анализ, формализация, визуализация и документирование требований.

Внедрение и реализация организационных процедур на проекте

Кларификация неясных требований/внесение предложений по улучшению требований.

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

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

Определение целей, задач проекта и критериев успешности

Разъяснение требований остальным участникам команды разработки.

Определение и документирование факторов, препятствующих успешной реализации проекта

Участие в процессе управления требованиями (обработка запросов на изменение требований, оценка влияния на проект).

Управление ресурсами

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

Организация и проведение встреч («митингов», «брифов» и других собраний, имеющих сходные англоязычные названия)

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

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

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

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

Мотивация команды

Мотивация команды

 

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

 

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

 

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

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

 

Разработка стратегии по управлению рисками на проекте.

 

Управление запросами на изменение: анализ изменения масштаба (вместе с аналитиком), издержек, плана и расписания.

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

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

 

 

Дополнительные обязанности (опционально + зависит от опыта и стажа)

Координация проекта и постановка процессов (фактически выполнение роли менеджера проекта, не считая критических решений и вопросов).

Разработка устава проекта

Участие в «предпродажной» стадии проекта вместе с маркетологами и менеджером проекта

Управление завершением контракта: контроль выполненных обязательств, административная работа по закрытию контракта

Обучение аналитиков-стажеров.

Утверждение методики разработки ПО. Перевод «задокументированных» требований в необходимый формат, который будет соответствовать используемой методике.

Координация команды аналитиков.

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

 

Участие в написании документации для тестировщиков.

 

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

 

Участие в стратегическом планировании деятельности организации

 

Управление базой знаний компании

Управление базой знаний компании

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

Чего же хочет менеджер от аналитика?

  • Выполнения «аналитических» активностей на проекте (менеджер может не знать всех потенциально возможных вариантов активностей, но будет хотеть, чтобы аналитик мог их выполнять и выполнял в конечном итоге, если это уместно)
  • Советов и рекомендаций по работе с требованиями и по другим аспектам аналитических активностей
  • Оценок трудоёмкости или длительности выполнения работы
  • Отчетности, причем как промежуточной, так и финальной
  • Уведомлений, если что-то идёт не так (например, не получается достигнуть целей по срокам или качеству)
  • Запросов, если чего-то не хватает для выполнения задач
  • Вопросов и уточнений, если что-то непонятно
  • Выполнения поставленных задач в установленный срок и с нужным качеством
  • Чего хочет аналитик от менеджера?

  • Анализа и разъяснений результатов (обратная связь)
  • Помощи, если что-то идёт не так или если не хватает полномочий
  • Предоставления всего необходимого (условия, информация, ресурсы, люди, процессы, инструменты и т.д.) для выполнения задач в срок и с нужным качеством
  • Уведомлений об изменений условий проекта / работы (например, сроков или объема задач)
  • Контроля за выполнением задач
  • Назначения сроков выполнения задач
  • Распределения и разъяснение задач
  • Ввода в курс дела (организационные и административные аспекты, инфраструктура проекта)
  • Когда один человек пытается носить сразу две шляпы (объединение функций аналитика и менеджера в одном человеке).

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

    Рассмотрим несколько вариантов.

    1. Роль менеджера проектов выполняет бизнес-аналитик. Даже если мы не будем учитывать тот факт, что аналитику придется, помимо извлечения, анализа, документирования требований и управления ими, тратить время на административные задачи, такой вариант во многих случаях не является оптимальным. ВА по своей природе склонен детализировать любые неясности, стараться как можно более подробно описывать требования и донести до разработчиков. Это, в свою очередь, может негативно сказаться на временных рамках проекта. Конечно, опытный ВА знает, когда нужно остановиться, но опыт к нам приходит не сразу, а заказчик ожидает результаты уже сейчас.

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

    Но все ли так гладко на проекте, когда данные роли разделены? Конечно, сложности будут всегда. (… хотя нет: нет проекта – нет сложностей.) Опять же, выделим несколько вариантов. И снова все сводится к опыту:

    Опытный менеджер

    Неопытный менеджер

    Опытный аналитик

    Несмотря на казалось бы выигрышный вариант, и здесь есть определенные риски. Порой начинается «раздел территории». Поскольку и РМ, и ВА взаимодействуют с одними заинтересованными лицами, часто работают с одними и теми же документами, могут возникнуть трения, особенно когда РМ не считает нужным делиться всей информацией по проекту, или аналитик, руководствуясь теми же мотивами, скрывает какие-либо артефакты (документы и пр.). Важным является также и тот факт, что РМ, как уже говорилось выше, имеет больше полномочий и конечное решение принимает именно он. Однако это вовсе не означает, что схема «Руководитель – Подчиненный» эффективна в отношениях РМ’a и BA’я. Гораздо более продуктивная их командная работа, что, впрочем, часто применимо ко всей команде.

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

    Неопытнй аналитик

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

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

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

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

  • «Слишком эффективная» коммуникация с заинтересованными лицами (ВА и РМ, часто являясь экстравертами с ярко выраженными коммуникационными способностями, могут сами того не желая мешать друг другу при одновременном общении с участниками проекта)
  • Разное понимание рисков проекта (для аналитика это в первую очередь неточныенеполные требования, для менеджера проекта – сроки, ресурсы, административные аспекты)
  • Несинхронизированные ожидания (например, менеджер хочет, чтобы аналитик управлял командой, или аналитик хочет, чтобы менеджер рассказывал, как написать ТЗ)
  • Нереалистичные ожидания (сделать за день то, что надо делать 2 месяца)
  • Некачественное или неполное выполнение ожиданий
  • Невыполнение ожиданий (не в срок, не то вообще или вообще ничего)
  • Непонимание (отсутствие обратной связи, нежелание или невозможность уточнить детали)
  • Как наладить, улучшить или построить отношения с менеджером?

    Итак, советы аналитику по тому, как наладить, улучшить или построить отношения с менеджером (можно пользоваться и в обратную сторону):

  • Составьте список взаимных ожиданий и синхронизируйте его с менеджером. Не беда, если некоторые вещи, которые будет хотеть от вас менеджер, вы пока не будете иметь возможность предоставить. По крайней мере, вы будете их знать. Кстати, вполне вероятно, что менеджер тоже сходу не сможет соответствовать всем вашим ожиданиям.
  • Придерживайтесь полученной договоренности и периодически делайте повторную синхронизацию. В рамках своего профессионального роста вы будете осваивать всё новые знания и навыки, которые помогут вам больше соответствовать ожиданиям вашего менеджера. Да и у менеджера могут появиться новые ожидания.
  • Берите на себя новые обязательства, выходите за рамки ожиданий (в хорошем смысле). Именно это и есть ваш профессиональный рост. Хороший менеджер (если это будет позволять проект и компания), обязательно отметит ваши стремления и заслуги.
  • Постарайтесь поставить себя на место менеджера, представить, какие сложности могут волновать его больше всего. Это даст вам понимание того, как эффективно организовать свою работу, чтобы при этом еще и помочь РМ’у. Не все проблемы могут быть озвучены открыто, что совершенно естественно, ведь у нас всех есть недостатки (от которых мы стараемся избавиться, ведь правда?). Иногда некоторые сложности и вовсе не связаны с личностными характеристиками: если РМ завален организационной работой и не имеет возможности часто общаться с разработчиками, в то время как ВА большую часть своего времени проводит именно с командой, то для ВА имеет смысл (не в ущерб своей работе) помочь менеджеру, выполняя некоторые его обязанности. В итоге выиграют все. Главное – чтобы такая ситуация не приняла статус нормальной, и менеджер не «делегировал» все свои обязанности аналитику, вовсе отстранившись от работы.
  • Несмотря на продолжающиеся споры о целесообразности разделения ролей бизнес-аналитика и менеджера проектов, эффективная коммуникация между ними не менее важна. ВА, находясь на стыке различных коммуникационных групп, как никто другой должен быть гибким. Гибким в отношениях с заинтересованными лицами, гибким в выборе методик работы с требованиями. Можно и растяжкой заняться для полного набора, ибо в здоровом теле здоровый ВА (:

    Свои комментарии о статье вы можете оставить на форуме.

     

     

    analyst.by

    Основные правила Project-менеджера / Хабр

    Хочу поделиться своим опытом и наблюдениями, которые следует взять на вооружение и не отступать им каждому самураю project-менеджеру. Ведь известно, что project-менеджер это ключевая фигура в любом проекте. Он должен взаимодействовать как с Заказчиком так и с командой разработчиков.Совершенствуйте свои знания Невозможно знать абсолютно все! Встречаются проекты, для выполнения которых, просто необходимо почерпнуть знания из различных источников. Провести не один день за литературой и просмотреть не один час интерактивов, что бы понимать в итоге, что от вас хочет Заказчик и как эти требования донести на понятном языке до разработчиков. Помните! Если вы будете иметь только общее представление о работе своих подчиненных, то они в итоге получат либо (в лучшем случае) «надзирателя», который будет всегда полагаться только на их честность, либо (в худшем случае) «нахлебника», которому будут «вешать лапшу на уши» вся команда и проект будет, мягко говоря, отставать от графика.Ваша команда Найдите сильные стороны вашей команды, дайте им ту работу, которая больше всего им подходит. Мотивируйте при этом свою команду. Помогайте им работать сплоченно. Если верстальщик не знает технологию AJAX, не загружайте его этой работой. Если дизайнер не умеет делать ролики во flash, не ставьте перед ним такой задачи. Умейте планировать Только спланировав проект, вы не выбьетесь из графика, не перегрузите работой свою команду и сдадите проект в срок.Узнавайте подробности всех требований Заказчика Без подробностей по техническому заданию ваш проект может выбиться из графика. Если Заказчик в техническом задании указывает, что ему нужен flash-плеер, то узнайте все детали: какой именно, сколько потоков, что он должен проигрывать и так далее.Учитесь на прошлых ошибках «Не ошибается только тот, кто ничего не делает». Все мы люди и все мы ошибаемся. Запоминайте свои ошибки, анализируйте их, и старайтесь не повторять.Излучайте уверенность Верьте в то, что вы способны на большее. Будьте уверены в том, что вы сейчас делаете и что собираетесь делать. Уверенный project-менеджер тот, который уверен, что за оставшиеся 2 дня до дедлайна успеет сделать и сдать проект.Умейте сказать «нет» Надо уметь сказать «нет» заказчику, если он требует невозможное, не по профилю вашей команды или выбивающееся из графика и сметы работ.Не беритесь за проекты, если вы не уверены, что вы их доведете до конца Вникайте в то, что хочет от вас и вашей команды Заказчик. Если вы не уверены, что уложитесь в сроки при требованиях Заказчика, не беритесь за проект.Не делайте заведомо никому не нужных проектов. Любой продукт (сайт, мобильное приложение, интерактив) будет использоваться конечной аудиторией. Вы делаете все проекты для нее, а не для Заказчика. Если Заказчик требует сделать мобильное приложение перегруженное функционалом, с отсутствующим юзабилити, адовыми страшными иконками, которые рисовал его 8-летний сын, объясните ему, что это приложение не будет использоваться никем. Таким образом, вы убережете себя и свою команду от лишней, невостребованной долгосрочной работы и сохраните Заказчику его бюджет.

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

    habr.com

    Менеджер проекта — кто он — Work.ua

    Профессия «менеджер проекта» появилась в середине XX столетия в военных ведомствах США, где были созданы первые инструменты управления проектами. На рубеже веков она получила всеобщее признание и была названа самой востребованной профессией десятилетия.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Особенности управления проектом

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

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

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

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

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

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

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

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

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

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

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

    Источник: hr-portal.ru

    Чтобы оставить комментарий, нужно войти.

    www.work.ua


    Цельнозерновые злаковые
    Жиры
    Овощи
    Фрукты
    Напитки
    Физическая активность