почему менеджер проекта ─ это не менеджер продукта — статьи на Skillbox
Есть заблуждение, что менеджер продукта и менеджер проекта ― это один и тот же человек, только называется по-разному. На самом деле нет. У менеджера продукта и менеджера проекта — разные зоны ответственности.
Продукт ― то, что создает компания. Это, например, может быть мобильное приложение. Менеджер отвечает за весь жизненный цикл продукта. То есть за приложение от начала и до конца: за создание и последующее развитие. Создание любого продукта состоит из проектов.
Проект ― это этап создания или развития продукта, он всегда ограничен сроками и бюджетом. Например, есть мобильное приложение, которое работает только онлайн, но компания хочет сделать так, чтобы его можно было использовать без доступа к интернету. Запуск новой большой функции приложения ― отдельный проект, за который отвечает project-менеджер. Он должен собрать команду разработчиков и распределить ресурсы, чтобы уложиться в сроки и бюджет.
Многие думают, что менеджер проекта есть только там, где нужно управлять работой удаленной команды. Это не так.
Менеджер проекта нужен везде, где есть краткосрочный проект с ограниченным бюджетом. Например, на заводе: чтобы открыть новое производство, нужно найти и обустроить помещение, закупить оборудование для работы и обучить сотрудников его использовать. Или, например, чтобы построить дом, нужно найти место, закупить стройматериалы, распределить ресурсы и постоянно контролировать процесс. Вдруг цемента не хватило или кто-то из строителей получил травму, а проект нельзя останавливать ― сроки горят. Но пришел менеджер проекта и решил все проблемы: цемент закупили, замену строителю нашли, процесс продолжается.
Задача менеджера проекта ― все рассчитать и распределить ресурсы так, чтобы минимизировать риски, уложиться в сроки и бюджет, не забыть про качество. Не важно, какой продукт производит компания и где находятся сотрудники. Команда может работать в одном помещении или удаленно из разных стран — все равно нужен менеджер, который правильно организует работу и будет нести ответственность за проект целиком.
Профессия менеджера проектов сложилась в сфере IT, поэтому многие связывают ее только с digital. Но на самом деле project-менеджер может работать в любой сфере: отвечать за процесс создания сайта в веб-студии, за проект по продвижению книги в издательстве, за процесс производства любого товара, за программу лояльности в банке. В общем, сфера не важна. Есть сроки, бюджет и команда, которую надо привести к результату, ― есть менеджер проекта.
С менеджером продукта все наоборот. Принято считать, что такой менеджер связан с производством, например, смартфонов и компьютеров или других «физических» товаров. На самом деле продукт может быть любым: смартфон или мобильное приложение для заказа такси, строительная компания или банк ― везде, где нужна стратегия, нужен и менеджер продукта.
Если менеджер продукта и менеджер проекта ― это две разные профессии, то получается, что ими не может заниматься один человек? Теоретически, может. Но это индивидуально. У менеджера продукта много задач, если он будет брать в работу еще и проекты, то времени может не хватать.
Обычно product-менеджер работает с пользователями, чтобы понять, какие у них потребности. Он продумывает стратегию создания и развития продукта, убеждает команду, что эта стратегия ― то, что надо. Если он возьмется вести проект, то его список задач увеличится вдвое.
Прежде чем предложить что-либо для разработки, менеджер продукта анализирует ситуацию на рынке, отслеживает конкурентов и запросы пользователей. Но это не значит, что менеджер проекта не пользуется аналитикой. Оба анализируют рынок, но у них разные цели.
Цель менеджера продукта ― решить проблемы пользователя и принести прибыль бизнесу. Ему важно сделать так, чтобы продукт получился классным и полезным, и его захотели купить.
Цель менеджера проекта ― решить проблемы заказчика: учесть сроки, бюджет и убедить заказчика, что получится то, что надо.
Из-за того, что менеджер продукта плотно работает с командой, многие думают, будто у него руководящая должность. Это не так. Обычно менеджер продукта не управляет командой, но отвечает за выбор направления движения. Его задача ― придумать, как сделать круто, и убедить команду, что его стратегия будет работать. Команда должна ему поверить и захотеть за ним идти. Для этого product-менеджеру нужны лидерские качества. А вот когда в рамках стратегии появляется проект, — нужно запустить приложение или обновление, то тут задачи команде ставит project-менеджер.
Менеджер проекта отвечает за распределение ресурсов, поэтому можно подумать, что менеджер продукта вообще никак не связан с бюджетом. Но это не так. Менеджер продукта отвечает за весь жизненный цикл продукта. То есть он должен понимать не только, какой продукт понравится пользователям, но и сколько это будет стоить компании. Поэтому для менеджера по продукту важно уметь хорошо считать. Он планирует весь бюджет, а менеджер проекта только получает ограниченную сумму и должен правильно ее распределить.
Итак, подведем итоги. Менеджер продукта создает и развивает продукт или сервис, который понравится пользователям и который купят. А менеджер проекта появляется, когда есть проект с ограниченными сроками и бюджетом и нужно правильно выстроить процесс работы, чтобы добиться результата.
Теперь вы знаете, чем занимается менеджер проекта и как не путать его с менеджером продукта. Тренд последних лет ― отсутствие границ. В том числе и между разными ролями в команде. Менеджер продукта, как и менеджер проекта, должен обладать компетенциями не только в своих сферах, но и во всех смежных областях. Иначе управлять командой и создавать хороший продукт не получится.
Если хотите заниматься IT-продуктом, то вам понадобятся хотя бы базовые знания в UX-дизайне, программировании, управлении проектами. Нужно понимать, как работают методологии управления и как общаться с командой разработчиков на их языке.
Курс «Управление Digital-проектами»
Курс поможет вам оценить себя как менеджера: разобраться и понять, почему у вас что-то не получается. Определить, какие навыки и знания нужно подтянуть. И сделать это, выполняя практические задания.
- Живая обратная связь с преподавателями
- Неограниченный доступ к материалам курса
- Стажировка в компаниях-партнёрах
- Дипломный проект от реального заказчика
- Гарантия трудоустройства в компании-партнёры для выпускников, защитивших дипломные работы
skillbox.ru
Рассуждения о смысле работы менеджера проектов и о том, как сформулировать требования к этой вакансии
Поиск сотрудников – дело нелегкое, особенно таких, которые взаимодействуют с клиентом от лица компании. Речь о менеджерах проектов. Это громадная ответственность как перед командой, так и перед клиентом. Еще более громадная ответственность на руководителе, который такого менеджера на работу приглашает.В поисках такого сотрудника я пошел стандартным путем: для начала, решил описать портрет идеального менеджера, как рекомендуют все книжки и специалисты. Вспомнилось несколько типов менеджеров, с которыми приходилось взаимодействовать. Параллельно возникла куча вопросов к коллегам, и этими вопросами я поспешил поделиться – и при возможности, обсудить.
Менеджеры проектов — кто они?
В первом моем представлении, менеджер проекта — это представитель заказчика на стороне исполнителей. В конце концов, негоже творческому люду отвлекаться на организационные вопросы, бухгалтерию и особенно на ценообразование. Всё это — задачи менеджера проектов.
1) Администраторы
Готовят документы и собирают подписи руководителей, раздают задачи курьерам и чем-то похожи скорее на офис-менеджеров, чем на менеджеров проектов. Следят за бухгалтерией и своевременным документооборотом. Что-то в этом духе. Кстати, как бы это ни отдавало бюрократией, но всё это – очень важная часть обслуживания клиентов компании. Бывает очень грустно, когда, например, сайт сделан, и все вроде как довольны, но: нет вовремя предоставленных клиенту актов, счетов, закрывашек, и к компании-подрядчику относятся не как к хорошему производителю сайтов, а как к раздолбаям, которые мешают подготовке финансовой отчетности.
2) Почтальоны
В таких почтальонов обычно переключаются даже самые компетентные менеджеры проектов, особенно когда они находятся в «запарке». К сожалению, они не всегда отдают себе отчет в том, запарка генерирует еще большую запарку.
Суть работы почтальонов сводится к тому, чтобы не читая и не разбираясь, просто переслать письмо клиента одному из исполнителей. Исполнителю нужно самому:
- понять суть запроса
- проверить, действительно ли всё так плохо, как пишет клиент
- попробовать всё воспроизвести
- затем, на выбор, ответить менеджеру либо «не нашел ошибки», либо «исправил», либо «у меня всё работает» (причем не важно, что именно работает).
Если менеджер не проверит еще и работу исполнителя, и просто форварднет реакцию исполнителя клиенту (вариант «исправил»), то это вообще катастрофа: клиент явно расстроится от того, что его не поняли, поняли не правильно, или сделали то, что не надо было, а то и вовсе ничего не сделали.
3) Продюсеры
Придумывают для клиентов всякие штуки и контролируют их реализацию на всех этапах работы. Всё формулирование задач и их приоритетность координирует именно продюсер. На мой взгляд, продюсер – это консультант, вышедший из «производства»: он знает технологии, их применение, все этапы разработки – причем, до нюансов, и в состоянии подобрать исполнителей на проект (или наделен полномочиями выбирать подходящих людей для решения задач клиента).
Такие менеджеры чаще добиваются блестящих с точки зрения функциональности, красоты и работоспособности результатов, но у них есть один мощный недостаток: они редко отслеживают фактические расходы (то есть в них административно-бюрократический навык обычно хуже всего развит). То есть эти люди ориентированы на результат фактический, а не финансовый. В идеальном случае они могут придумать всё так, чтобы уложиться в половину сметы или вовремя остановиться (ведь нет пределов совершенству, на которое они ориентированы) – тогда это самый бесценный менеджер как для компании, так и для клиента. В таких ребят чаще всего перерастают специалисты, создавшие собственный бизнес, и лично (кровно) зависимые от своих клиентов, за счет которых они живут.
Кстати, продюсером может стать любой специалист компании — и диайнер, и технолог, и программист.
4) Менеджеры клиентов
Еще же есть менеджеры клиентов — ведь большинство из наших компаний не ограничивается созданием сайтов (еще есть фирменные стили, приложения для мобильных устройств, полиграфия, реклама всякая, и так далее). Чаще всего бывает так, что:
А) требуется оказание комплекса услуг прямо сейчас и
Б) много разных услуг могут быть оказаны не сразу, а на протяжении, скажем, двух лет.
Первый вариант часто очень привлекательный, но фактически мало когда востребованный. Второй встречается чаще, но если менеджер не дышит с клиентом в унисон, и не знает – чем тот живет, то часто весь объем работ упускается, и дальше еще двух-трех услуг дело не заходит. Чтобы клиентов не терять, логично предлагать им востребованные услуги с упреждением, ведь часто это весьма прогнозируемые события. При этом часто так случается, что на стороне клиента иногда даже не догадываются о том, что услуга для них востребована (то, что у вас написано на сайте, не всегда очевидно заказчикам, а если делать персональные предложения, то становится даже иногда очевидным – правда, задним числом; менеджеру клиента подготовить хорошее персональное предложение проще – бывает достаточно встретиться или даже просто позвонить).
5) Фрилансерам тоже приходится выступать собственными менеджерами
Фрилансеры-специалисты тоже выступают в роли менеджеров проектов на своих локальных задачах (локальные задачи для них являются проектами сами по себе). Казалось бы, это – очень классно: быть самому себе менеджером. Но многие фрилансеры тоже предпочитают общаться с заказчиками через менеджеров – потому что они фильтруют задачи и могут помочь отличить ненужную прихоть от реального бага или заблаговременно растолковать клиенту, что это такая полезная фича.
Сначала я фрилансеров рассматривал просто для статистики, а затем в голову пришла мысль о том, что лучшие фрилансеры по сути своей являются еще и менеджерами клиентов (см. п. 4).
Идеальный менеджер в моем понимании
Лично я считаю, что идеальный менеджер – это сплав продюсера и менеджера клиентов. Новых клиентов найти сложно и работе предшествует большая подготовка, притирка. А со старыми работать в этом смысле проще и надежнее, особенно когда можешь вместе с клиентами придумывать новые штуки и всячески развивать и поддерживать их проекты. Деньги поступают гарантированно (или с известными и предсказуемыми задержками), меньше притирок и придирок, глубже погружение в проекты.
Но все люди – люди, и время от времени кочуют из одного типа менеджера в другого, в зависимости от специфики работы организации, клиентов и личных навыков (которые они могут развивать). Обычно мы исходим из того, что умеет человек и что у него лучше всего получается, и то отдаем ему в работу то, с чем он лучше всего справится и что принесет большую пользу компании. Это хорошо работает в небольших или очень крупных компаниях, где либо никакой унификации действий не требуется по причине малочисленности коллектива, либо всё уже отработано и зафиксировано в виде стандартов и бизнес-процессов, к которым сотрудник привыкает с первых дней работы (а то еще и на этапе собеседования на себе всё это чувствует).
В средних компаниях, человек по 70-100, личностный фактор еще очень силен и заметен, но уже очень сильно требуются какие-то стандарты разработки и взаимодействия между отделами. В случае с рекламным агентством, в котором отдельно — коммерческий отдел, медиа-отдел, веб-студия, SEO и поддержка, эти взаимоотношения еще важнее: во-первых, желательно избегать дублирования менеджеров (например, есть менеджеры веб-студии и коммерческие менеджеры могут отчасти дублировать друг друга, потому что общаются с клиентами), во-вторых, грань между менеджером проекта (веб-сайта, например) и менеджером клиента постепенно стирается (и туда же присовокупляется «администратор» и «коммерческий менеджер»). И как раз в средних компаниях вопрос определения базовых задач менеджеров стоит очень остро.
Вопрос об идеальном менеджере для меня возник не случайно: нашей компании как раз нужен такой сотрудник. Чтобы составить текст вакансии, мне пришлось перебрать в голове кучу ситуаций и знакомых, коллег и клиентов, чтобы понять, что же требуется от человека. Так получилась условная классификация, которую я предложил в начале поста. Но я уверен в том, что ситуаций и людей гораздо больше, и наверняка у сообщества есть интересные примеры и практики – поэтому посчитал не лишним поделиться мыслями.
(Если кому интересно, как я сформулировал вакансию, до обсуждения на «Хабре», можете посмотреть её описание на сайте студии.)
Ну и самим менеджерам проектов это дело наверняка пригодится — чтобы определиться с развитием своей карьеры.
Вопросы, которые хотелось бы обсудить с коллегами
Чем менеджеры проектов, по сути своей, отличаются от коммерческих менеджеров – только тем, что не ищут новых клиентов компании? Специализацией? Но ведь для успешности продажи нужно как минимум хорошо владеть предметом, иначе есть риск того, что клиент окажется более осведомленным в работе, так что разница в специализации – в идеальном случае – становится весьма эфемерной. Поделитесь своими практиками, уверен, многим будет интересно.
Сколько каких проектов может вести менеджер одновременно? А если это менеджер клиентов – то сколько клиентов может параллельно вести один менеджер?
Что делать в случае с технической поддержкой более сложной, чем публикация данных (каталогов, картинок и т.д.), когда требуется доработка функционала? Плодить еще одного менеджера в отделе технической поддержки, или возвращать из поддержки задачу разработчикам? Ответ кажется очевидным, но поддержка должна работать всегда, а менеджеры могут оказаться загруженными другими проектами, и клиент сойдет с ума от ожидания реакции или от того, что ему придется работать с другим менеджером. Так что Капитан Очевидность как бы отдыхает.
habr.com
Основные правила Project-менеджера / Habr
Хочу поделиться своим опытом и наблюдениями, которые следует взять на вооружение и не отступать им каждомуСовершенствуйте свои знания
Невозможно знать абсолютно все! Встречаются проекты, для выполнения которых, просто необходимо почерпнуть знания из различных источников. Провести не один день за литературой и просмотреть не один час интерактивов, что бы понимать в итоге, что от вас хочет Заказчик и как эти требования донести на понятном языке до разработчиков.
Помните! Если вы будете иметь только общее представление о работе своих подчиненных, то они в итоге получат либо (в лучшем случае) «надзирателя», который будет всегда полагаться только на их честность, либо (в худшем случае) «нахлебника», которому будут «вешать лапшу на уши» вся команда и проект будет, мягко говоря, отставать от графика.
Ваша команда
Найдите сильные стороны вашей команды, дайте им ту работу, которая больше всего им подходит. Мотивируйте при этом свою команду. Помогайте им работать сплоченно. Если верстальщик не знает технологию AJAX, не загружайте его этой работой. Если дизайнер не умеет делать ролики во flash, не ставьте перед ним такой задачи.
Умейте планировать
Только спланировав проект, вы не выбьетесь из графика, не перегрузите работой свою команду и сдадите проект в срок.
Узнавайте подробности всех требований Заказчика
Без подробностей по техническому заданию ваш проект может выбиться из графика. Если Заказчик в техническом задании указывает, что ему нужен flash-плеер, то узнайте все детали: какой именно, сколько потоков, что он должен проигрывать и так далее.
Учитесь на прошлых ошибках
«Не ошибается только тот, кто ничего не делает». Все мы люди и все мы ошибаемся. Запоминайте свои ошибки, анализируйте их, и старайтесь не повторять.
Излучайте уверенность
Верьте в то, что вы способны на большее. Будьте уверены в том, что вы сейчас делаете и что собираетесь делать. Уверенный project-менеджер тот, который уверен, что за оставшиеся 2 дня до дедлайна успеет сделать и сдать проект.
Умейте сказать «нет»
Надо уметь сказать «нет» заказчику, если он требует невозможное, не по профилю вашей команды или выбивающееся из графика и сметы работ.
Не беритесь за проекты, если вы не уверены, что вы их доведете до конца
Вникайте в то, что хочет от вас и вашей команды Заказчик. Если вы не уверены, что уложитесь в сроки при требованиях Заказчика, не беритесь за проект.
Не делайте заведомо никому не нужных проектов.
Любой продукт (сайт, мобильное приложение, интерактив) будет использоваться конечной аудиторией. Вы делаете все проекты для нее, а не для Заказчика. Если Заказчик требует сделать мобильное приложение перегруженное функционалом, с отсутствующим юзабилити,
В заключении хочу сказать, что project-менеджер является ключевой фигурой в большинстве проектов. Изъятие его из проекта или замена будет иметь катастрофические последствия и может поставить крест на многих проектах. Во время реализации проекта его менеджер должен постоянно заниматься уточнением графика работы, контролем выполнения заданий и служить дополнительным «справочным пособием» к спецификации системы, которую реализуют члены его команды.
habr.com
Как стать руководителем проектов в IT / Habr
Привет, друзья!Так получается, что со мной периодически связываются мои знакомые и знакомые моих знакомых, которым меня порекомендовали, с примерно одним и тем же вопросом: «Как мне стать project manager’ом в IT, если до этого я работал(-а) на похожей позиции, но не в IT?».
Так как подобных запросов накопилось несколько штук за довольно короткое время, я решил написать об этом отдельную статью. Ну вы понимаете — я же ленивый, и теперь смогу сразу давать ссылку на этот текст, вместо очередного повторения уже несколько раз сформулированных ответов. Статья не претендует на универсальность — это только мой взгляд на ситуацию. В то же время скажу, что когда проводишь собеседования, нанимаешь и обучаешь project manager’ов — накапливается довольно много общих критериев, отвечающих на вопрос «А что же на самом деле должен знать и уметь IT project manager?», чтобы успешно работать в IT.
Кстати, знание английского языка в статье даже не обсуждается. Оно просто обязательно.
Поехали?
Как обычно выглядит запрос:
Алексей, добрый день! Меня зовут <…>. Мне посоветовал к Вам обратиться <…>. Нужен Ваш экспертный совет. Буду благодарна Вам за подсказку. Нашла тренинг для проектных менеджеров, который Вы читаете. Хотела бы спросить стоит ли проходить мне его. Кратко о моей ситуации: <…> хотела бы себя попробовать дальше развивать в проектном направлении, но уже в IT-сфере. Уже проходила несколько собеседований, но пока безуспешных (работодатели часто ссылаются на то, что нет опыта в IT). В связи с этим у меня возникла мысль о том, как заставить все-таки поезд тронуться. Буду очень благодарна за совет по поводу курсов. Возможно есть смысл посмотреть что-то смежное к менеджеру проекта, если нет шансов, чтобы взяли в IT-сферу на такую позицию? Буду благодарна за любую обратную связь.
Варианты обращений отличаются только предыдущим опытом работы в неких не-IT областях.
Что я могу посоветовать?
Сначала напугаю и сгущу тучи.
1. Действительно, почти всегда отказывают ровно потому, что для project manager’a в IT крайне важно разбираться не только в project management’e как таковом, но еще и в IT. Это требуется ровно для двух вещей: а) для нахождения общего языка с подчиненными (тестировщики, аналитики и разработчики, которые все айтишники) и соответственно понимания сути диалогов, спецификаций, проблем и прочего, и б) для нахождения общего языка с представителями заказчика, которые зачастую точно также имеют в основном айтишный background. Конечно, есть некоторые небольшие шансы убедить будущего работодателя, что понимания специфики IT-области не критично для данной позиции. Важно помнить, что эти шансы очень и очень небольшие. Все-таки наниматель лучше знает, что ему надо, и убедить его в другом — довольно сложно. Особенно работодателей в IT — они уж точно знают, какой именно сотрудник им нужен. В то же время, никто не запрещает пробовать убеждать. Вдруг получится?
2. В IT очень важным является понимание этапов разработки продуктов (SDLC — Software Development Life Cycle). Работая в НЕ-айтишных организациях это понимание полностью получить, увы, невозможно. Есть моменты специфичные для IT-отрасли. А раз project manager в IT отвечает за разработку продукта/кода/функционала к заданному сроку, с заданным качеством и в заданных рамках по качеству/функционалу, то ему обязательно понимать, как же достичь всего этого теми средствами, которыми он обычно располагает в IT-сфере. В других отраслях могут быть свои нюансы, отличающиеся от IT в ту или иную сторону.
3. Любые тренинги по управлению проектами «вообще», скорее всего не сильно помогут. Нужны тренинги по управлению проектами в IT. Поясню почему я так считаю: тренинги «вообще» не дадут понимания двух важных вещей: «айтишного технического языка» и «понимание этапов разработки именно в IT».
4. В любой IT компании, уже есть свои сотрудники, желающие стать руководителями. И эти сотрудники (разработчики, тестировщики, аналитики) — уже разбираются в IT (владеют тем же техническим языком, что и окружающие), а также знают SDLC. Более того, они знают заказчика, знают специфику компании и ее внутреннюю кухню (это не критичные пункты, но сравнивая с нулевыми знаниями внешнего кандидата — даже эти пункты могут перевесить). Таким образом получается, что внешний кандидат НЕ из IT-отрасли вынужден конкурировать как с внутренними кандидатами изнутри самой компании, так и с другими внешними кандидатами, тоже из IT-отрасли.
Итак, какие же параметры получились?
1. Владение техническим IT-шным языком. Понимание, к примеру, что вообще такое FTP, Signoff, Sprint, ASAP, Regression, XML, Database request, Deadline, FYI, Client-Server Architecture, Redline, Smoke Test, FTE, Release… Список можно продолжать бесконечно. Быть супер специалистом в некоторых упомянутых вещах — совсем не требуется. Требуется понимание сути, что это такое вообще, что за термины, что они обозначают, что за ними стоит, иначе бы будете как слепой в мире зрячих.
2. Знание SDLC (Software Development Life Cycle) — этапов разработки программных продуктов. И не просто знание, а понимание, почему именно такие этапы, почему именно в таком порядке, где и почему можно перескакивать с одного этапа на другой и можно ли двигаться по этим этапам в обратную сторону, и если да, то когда и при каких условиях.
3. Методологические навыки управления проектами и людьми (PM Hard Skills). Сюда входят знания методологий, принципов управления и процессов по областям. Таких как Agile, Scrum, Kanban, Waterfall, Communication management, Specification & Requirements management, Change management, Risk management, Reporting и т.п. Хорошая новость — всему этому так или иначе можно научиться на соответствующих тренингах, вебинарах и множестве доступных онлайн материалов.
4. Личностные навыки управления проектами и людьми (PM Soft Skills). Сюда входят Team & Client management skills, Ability to solve complex tasks, Presentation skills, Conflict management skills, Communication skills, Feedback skills, Ability to hear, listen & understand, Openness to other points of view, Ability to admit own mistakes and to correct them, Self-criticism, Leadership skills, Coaching/Mentoring skills, Ability to explain, Professional culture (quality of speech, emails, calls), Ability to make decisions and take responsibility for it, Pro-activity, Task management skills, Delegation skills, Execution control skills, Personal effectiveness, Time management skills. Вторая хорошая новость — всему этому тоже можно научиться на соответствующих тренингах.
Составим сводную таблицу, в которой будут присутствовать три кандидата:
- внешний без знания IT-отрасли
- внешний со знанием IT-отрасли
- внутренний со знанием IT-отрасли и специфики компании
Таким образом, становится очевидным, в каких пунктах можно пытаться конкурировать.
Мое мнение, что без погружения в IT-среду невозможно овладеть IT-шным языком хотя бы на уровне понимания. Таким образом с первым пунктом конкурировать нет смысла. Вы (внешний не IT кандидат) тут гарантированно проиграете. Остальные три области — вполне поддаются конкуренции. Причем если вторая (знание SDLC) тоже требует погружения в среду для полного понимания, то хотя бы примерно разбираться в ней не работая в IT — научиться можно. Недостаток знаний SDLC можно компенсировать за счет знаний толкового технического-лида, архитектора да и вообще любого технически грамотного человека из вашей будущей команды. А вот чтобы найти с таким человеком общий язык и получить его помощь — нужны очень серьезные навыки в PM Soft Skills.
Остаются PM Hard Skills и PM Soft Skills — и это ровно те области, где не IT-кандидат может значительно переиграть кандидата из IT-отрасли. Почему я так считаю? Многие руководители из IT — выросли из разработчиков, аналитиков, тестировщиков. Да, среди них есть очень крутые специалисты. Многие такие кандидаты в менеджеры из IT отрасли — они в глубине души остаются теми же самыми программистами, аналитиками и тестировщиками. А это говорит о том, что как раз PM Hard и Soft Skills у них могут быть развиты слабее, чем у внешнего кандидата. Ведь обе эти области (PM Hard Skills и PM Soft Skills) не зависят от IT специфики. Их можно и нужно развивать независимо от области, где вы сейчас работаете.
В итоге, что получается? Какой может быть наша сводная табличка, чтобы у внешнего кандидата ранее не работавшего в IT появился шанс?
План действий, который может помочь (а может и не помочь). Но если совсем ничего не делать — не поможет гарантированно.
1. Поговорить с кем-то из ТОЛКОВЫХ знакомых айтишников (разработчиков, тестировщиков, аналитиков, а еще лучше тим-лидов или менеджеров) про SDLC. Дополнительно почитать об этом в Интернет. Возможно, стоит поговорить не раз и даже не два.
2. Попробовать выбрать роль ассистента project manager’a в IT, либо роль младшего PMO-специалиста (там важнее знание процессов управления, чем знание этапов и нюансов и терминов разработки). Попав на любую из этих ролей — необходимо будет уже изнутри изучать терминологию и специфику IT, если действительно есть сильное желание двигаться и развиваться именно в этой области.
3. Объяснить на собеседовании, что «Твои сильные стороны — это умение решать конфликты, навык работы со сложными ситуациями, успех в переговорах, знание английского языка. А технические пробелы в знаниях ты будешь закрывать за счет правильной коммуникации и помощи от технических специалистов, которые будут твоими подчиненными. Ведь работа с людьми — это твой конек». Примерно такими словами. Важно, чтобы это была действительно правда про сильные стороны, а не бравада для прохождения собеседования. Поверьте — любой толковый руководитель определит на собеседовании, если вы обманываете. И на этом все закончится. Но допустим вы получили работу — тогда необходимо срочно искать союзника среди технарей, который будет помогать полностью покрывать и регулярно объяснять техническую сторону работы, задач и возникающих сложностей.
Грубо говоря — вы + технарь союзник будете таким сборным менеджером о двух головах (может быть союзников потребуется больше одного). Многие нанимающие руководители (ваш будущий начальник) это понимают и могут не захотеть идти на это, ведь вы будете «отъедать» время технических специалистов, что уменьшит продуктивность команды в целом. Так что отсутствие у вас некоторых навыков и знаний будет на одной чаше весов, а на другой чаше — ваш будущий руководитель взвесит возможное уменьшение эффективности и продуктивности команды, куда вас планируют взять. И чем больше будет перевешивать чаша эффективности — тем меньше шансов, что вас возьмут. Учитывайте это.
Резюмируя. Чтобы конкурировать с ребятами, которые разбираются в IT и тоже стремятся стать project manager’ами — необходимо серьезно превосходить их в PM Soft Skills.
P.S.: оригинал этой статьи (и другие интересные материалы) можно прочесть в моем блоге: consultpm.com
P.P.S.: мне резонно заметили, что IT не ограничивается разработкой. Это верно. В таком случае второй пункт (знание SDLC) будет менее значим, либо совсем заменен на какой-то свой, специфичный именно для вашего направления.
Поделитесь этой статьей с друзьями.
Спасибо и успехов вам!
habr.com
Менеджер проектов (project manager): функции и должностные обязанности
Ключевой проектной ролью, должностью и профессией в компании обладают специально назначаемые люди. Они избираются среди особой группы кандидатов и становятся ответственными ресурсами по проектным задачам. Организационно и формально центром компетенций и центром проектной архитектуры является фигура project manager, или по деловым обычаям российского бизнеса – руководитель проекта. В настоящей статье мы разберем подходы к формированию требований к портрету данного менеджера, его основные функции и возможные ошибки.
Функции проект-менеджера
Под менеджером проекта мы рассматриваем лицо, ответственное перед руководством компании за достижение целей, наделенное для этого полномочиями, достаточными для решения принятых задач в условиях ограничений и рисков. Международные организации, издающие стандарты в области PM, серьезное внимание уделяют также и требованиям к компетенции, профессиональным и личностным качествам проект-менеджеров. Так, ассоциация IPMA, в которую также входит РФ, издала стандарт международных требований к компетенции менеджеров проектов (PM ICB IPMA Competence Baseline). Последняя 3-я версия стандарта издана в 2010 году, в состав ICB в общей сложности вошло 46 компетенций в различных областях, разделенных на группы технической, поведенческой и консенсуальной компетентности.
На основе ICB в СОВНЕТ разработан стандарт НТК (Национальные требования к компетенции менеджеров проектов). Сертификация, пройденная по данному стандарту, признается IPMA. Институт PMI в меньшей степени, но все же уделяет этому вопросу внимание. В данном стандарте особо подчеркивается растущая роль проект-менеджера в решении стратегических задач бизнеса. В PMBOK акцент делается не только на знаниях и навыках PM, но и на его личностных компетенциях и лидерских качествах. Далее приведена выписка из Руководства PMBOK относительно руководителя проекта и сфер его компетенций и ответственности.
Выписка из Руководства PMBOK о роли и компетенциях руководителя проекта
Стать профессиональным руководителем проектов на первом этапе несложно. Достаточно иметь высшее экономическое или даже среднее профессиональное образование и получить небольшой управленческий опыт. В зависимости от организации требования к опыту от 1 года до 5 лет. Последние годы набирает популярность сертификация специалистов по двум международным стандартам IPMA (IPMA-СОВНЕТ) и PMI. Сертификация существенно повышает не только компетентность менеджера, но и его профессиональный статус.
Выписка из типовой должностной инструкции РМ: Раздел «Должностные обязанности руководителя проектов»
Выше представлен пример должностных обязанностей менеджера проектов производственной компании среднего уровня. Следует заметить, что должностные обязанности РМ во многом определяются организационной формой выполнения проектов, их типом, масштабом организации и отраслью ее деятельности. Функции проект-менеджера коммерческой организации делятся на семь групп, схема содержания которых размещена далее.
- Функции, основанные на выполнении задачи стратегического управления.
- Обеспечение связи между руководством компании и проектной реализацией.
- Воспроизводство системы управления проектом.
- Разработка плана проекта.
- Организация исполнения проекта.
- Контроль и анализ хода реализации.
- Функции, связанные с закрытием проекта.
Схема функциональных составов менеджера проекта
О чем следует помнить руководству?
Как известно, инициатором проекта могут выступить любые заинтересованные лица. Часто ими являются заказчик, функциональные руководители или руководитель проектного офиса. Назначенному высшим руководством компании куратору предстоит стать наиболее близким в проектном окружении руководителем и уделять управлению проектом существенное время. Именно ему заказчик предоставляет полномочия по выделению ресурсов, поддержке проекта и передает ответственность за успех этой уникальной задачи.
Должностные обязанности куратора предполагают разработку устава проекта, регулирование спорных вопросов, утверждение вносимых изменений в проектные параметры и многое другое. Два руководителя (куратор и менеджер проекта) составляют его руководящий состав. Один из них действует внутри реализации задачи, а другой – выше нее в задачно-целевой иерархии бизнеса. Реальные события свидетельствуют, что действовать безупречно не всегда удается, особенно когда проектное управление только разворачивается в компании, а руководители еще не имеют достаточного опыта. Даже если «проштудирована» методология, разработаны должностные инструкции и описаны функции, никто не застрахован от ошибок.
Опираясь на опыт, можно с уверенностью утверждать, что основные проектные ошибки следует разделить на две большие части: недоработки вышестоящего руководства по отношению к проекту и ошибки руководителя проекта. Типовые ошибки руководства компании на этапе инициации, планирования и сопровождения проекта собраны в отдельную таблицу, представленную далее.
Классификационная таблица ошибок руководства компании в проекте
Основная доля ошибок куратора приходится на этап инициации, включая процедурные затруднения при выборе PM и постановки ему задачи. Выдержать регламентные процедуры инициации полноценно в российских реалиях часто непросто. Большое значение имеет властное «хочу». Многократно приходилось наблюдать положительные эффекты, если протокол соблюдался с самого начала. Когда такое удавалось, то независимо от масштаба проектной задачи, успех сразу начинал «брезжить» впереди.
Если цели проекта не сформулированы, не соизмерены со стратегией фирмы, если предпосылки не выражены и устав не разработан, шансы, что более или менее серьезный проект дойдет до результата, малы. Менеджер проектов, даже находящийся в статусе кандидата на эту роль, обязательно должен быть привлечен к управлению проектом на стадии инициации. Это очень важное правило требует соблюдения.
Блок управленческих ошибок на стадии инициации
Возможные упущения менеджера проекта
Менеджер проектов, включенный в штат предприятия, в своей работе опирается на должностные обязанности и функции, прописанные в инструкции. Другое дело, менеджер проекта, который выполняет ролевую установку, являясь при этом сотрудником функционального подразделения, например, отдела маркетинга. В своей обычной практике такой специалист или даже руководитель выполняет функции, связанные с комплексом маркетинга и рекламы. Стать штатным PM в одночасье такой сотрудник не может.
Независимо от функциональной привязки, менеджер проекта, приступая к управлению, должен рассматривать требования и установки устава, которые раскрывают ему содержание, цели, результаты, продукт и критерии успешности проекта. Устав является главным документом, которым руководствуется менеджер проектов. Типичные ошибки PM представлены вашему вниманию далее, среди них вторым типом рассмотрены ошибки во взаимодействии с куратором.
Классификационная таблица ошибок РМ в проекте
Требования по управлению проектом накладывают на PM серьезную ответственность не только за результаты, но по существу и содержанию его действий как ресурса и руководителя. Переговоры с куратором – важный момент в постановке-принятии задачи. Куратору нужно соблюсти требования минимального уровня таких ограничений проекта, как «бюджет» и «сроки» при максимальном содержании (качества) результата.
Менеджер проекта, в свою очередь, нуждается в полной информации по условиям проектной задачи для того, чтобы соизмерить все возможные риски и достаточность предполагаемых ресурсов. И он свободен отказаться, если ресурсная база окажется мала, а риски слишком велики. Таковы требования задачной парадигмы. Менеджер проектов, хоть и находится в штате, но вполне может отдавать себе отчет, что такой сложности проект «не потянет».
Честь и хвала РМ за то, что он найдет в подобной ситуации мужество отказаться. В этот момент исключается ключевой риск проекта и куратор перестает «как бы надеяться», что проект реализуется. Менеджер проекта при этом перестает соглашаться с предложением, по которому он «как бы решит задачу». Исключается потенциальное двусмыслие между переговорными сторонами. Управлению проектом вскоре может быть придан новый импульс с лучшим кандидатом, но задача при этом не будет загублена.
Свобода и ответственность проект-менеджера выступают гарантией управленческой ясности того, что результат выполняемой уникальной задачи состоится. Давление или пренебрежение такой важной процедурой, как постановка и переговоры по задаче и ее условиям, не допустимы. Условия задачи комплексно развернуты в уставе проекта. В нем не хватает только бизнес-плана, но есть все, чтобы PM мог принять взвешенное решение.
Задачный и личностный контекст успеха PM
Все, что было сказано до сих пор относительно упущений в постановке задач проект-менеджеру, в полной мере может относиться и к нему самому. Приступая к управлению командой, PM должен отобрать в нее исполнителей. Привлечение и отбор происходит на основе той же задачной доктрины. В рабочей группе, затем в команде управления проектом декомпозиция задачи проекта на подзадачи достигает своего оптимального уровня. Если формат не соблюден и проектные мероприятия не обретут формулировок с количественными параметрами, успеху не быть.
Если при отборе команды рассмотрен только один состав кандидатов (обычно так и есть), то это не нарушение. Но! Если проект-менеджеру удастся так построить процесс формирования команды, что возникнет минимальный конкурс, пусть с одним лишним кандидатом всего на одно место, качество команды резко улучшится и по составу, и по ее настроению. Не следует показывать людям, до какой высокой степени в них нуждается компания. Это – «мое хочу» руководства бизнеса: «хочешь – берись», «не хочешь – найду другого»!
Часто такое кажется невозможным из-за дефицита хороших исполнителей. Однако это иллюзия, часто имеющаяся у PM. Требования соблюдения условий ограничений проекта по срокам и по бюджету также могут быть результативно выполнены в ходе постановки задач в команде. Делается это достаточно просто. На совещании проектной команды устраивается конкурс между условными звеньями по 2-3 участника. Каждому звену поручается найти минимум три способа решить подзадачу. Затем предъявленные решения обсуждаются всей командой, звенья меняются местами и снова ищут новые пути решения. Лучший способ переводится в задачный формат.
Почему-то во многих источниках личностно-психологические затруднения руководителя проекта не акцентированы. Однако есть основания полагать, что это весьма важный аспект деятельности PM для его успешности. Получить современное образование по project management не так сложно любому экономисту, технологу или линейному руководителю. А изменить личностные стереотипы, особенно если человек длительное время действовал как исполнитель или, напротив, как «большой начальник», не так просто, как кажется. Удивительно, но оказывается, что быть уравновешенным, способным без страхов попросить помощи, учиться у молодого знающего коллеги, очень ценно.
В настоящей статье мы рассмотрели вопросы требований к профессиональным и личностным качествам PM, их должностных обязанностей, основных функций и типовых ошибок управления проектами. Мы разобрали подходы международных и российских систем стандартизации к данным аспектам управления. Уточнены основные недоработки и упущения со стороны кураторов и проект-менеджеров. Мне представляется, что в условиях роста значения проектного управления в современном бизнесе актуальность этой темы будет только возрастать.
projectimo.ru
Менеджер проектов — это… Что такое Менеджер проектов?
| В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена. Вы можете отредактировать эту статью, добавив ссылки на авторитетные источники. Эта отметка установлена 13 мая 2011. |
Менеджер проектов — это специалист в области управления проектами, который несет ответственность за планирование, подготовку и исполнение конкретного проекта. Обычно такая должность и деятельность имеет место в отраслях, склонных к проектным работам, например: IT-области, строительстве и др.
При этом, к основным навыкам (помимо профессиональных навыков в конкретной отрасли) менеджера проектов в первую очередь относятся навыки управления ресурсами, планирование работ, а также управление рисками.
Управление проектом
Управление проектом — довольно сложная задача, требующая от специалиста тонкого чутья в области организационных и межличностных вопросов. Хороший специалист должен уметь координировать работу многих специалистов, которые до этого не имели опыта совместной работы. Как правило руководителями проектов становятся люди, имеющие технический опыт работы.
Роль руководителя проектов
В недалёком прошлом во многих организациях существовали традиционные принципы работы: начальник выдавал задание, менеджер проекта его выполнял. Все дополнительные вопросы воспринимались как ваше незнание мат.части и некомпетентность. На сегодняшний день ситуация кардинально изменилась:
- вам дают идею, а вы обдумываете, как её осуществить;
- вам объясняют идею и цель замысла, устанавливают временные рамки. А вы сами уже определяетесь, возможно ли и необходимо ли выполнение такого проекта и думаете как воплотить эту идею в реальность.
Образование и сертификация
Основная статья: Виды сертификаций в управлении проектами
В Москве существует по крайней мере один центр, авторизованный на сертификацию PMI.
Прочие ресурсы
См. также
- Проектный офис
dic.academic.ru
Менеджер проектов — это… Что такое Менеджер проектов?
| В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена. Вы можете отредактировать эту статью, добавив ссылки на авторитетные источники. Эта отметка установлена 13 мая 2011. |
Менеджер проектов — это специалист в области управления проектами, который несет ответственность за планирование, подготовку и исполнение конкретного проекта. Обычно такая должность и деятельность имеет место в отраслях, склонных к проектным работам, например: IT-области, строительстве и др.
При этом, к основным навыкам (помимо профессиональных навыков в конкретной отрасли) менеджера проектов в первую очередь относятся навыки управления ресурсами, планирование работ, а также управление рисками.
Управление проектом
Управление проектом — довольно сложная задача, требующая от специалиста тонкого чутья в области организационных и межличностных вопросов. Хороший специалист должен уметь координировать работу многих специалистов, которые до этого не имели опыта совместной работы. Как правило руководителями проектов становятся люди, имеющие технический опыт работы.
Роль руководителя проектов
В недалёком прошлом во многих организациях существовали традиционные принципы работы: начальник выдавал задание, менеджер проекта его выполнял. Все дополнительные вопросы воспринимались как ваше незнание мат.части и некомпетентность. На сегодняшний день ситуация кардинально изменилась:
- вам дают идею, а вы обдумываете, как её осуществить;
- вам объясняют идею и цель замысла, устанавливают временные рамки. А вы сами уже определяетесь, возможно ли и необходимо ли выполнение такого проекта и думаете как воплотить эту идею в реальность.
Образование и сертификация
Основная статья: Виды сертификаций в управлении проектами
В Москве существует по крайней мере один центр, авторизованный на сертификацию PMI.
Прочие ресурсы
См. также
- Проектный офис
dik.academic.ru