×Закрыть

7 признаков того, что вы не готовы стать менеджером проекта

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

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

Итак, 7 признаков того, что вы не готовы стать менеджером проектов.

Вам не комфортно от постоянных изменений и неопределенности

Постоянные перемены и изменения — это часть ДНК работы Project Manager’а, поэтому умение оперативно реагировать на них, трезво принимать решения в любых сложившихся обстоятельствах и корректировать стратегию — обязательный навык.

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

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

Вам больше нравится работать с техникой, чем с людьми

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

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

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

Вы не умеете управлять конфликтами

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

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

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

Вы не обладаете лидерскими качествами

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

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

Вы не знаете, что такое тайм-менеджмент

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

Вы не можете работать в многозадачном режиме

Если посмотреть вакансии, то можно увидеть, что умение работать в режиме многозадачности — одно из основных требований для менеджера проектов. Как ни крути, а хороший Project Manager — это сторукий Шива и Юлий Цезарь в одном лице. Представьте себе, что вам нужно распределить задачи по участникам нового проекта, утвердить с одним клиентом техническое задание, а другим — макет, выслушать разработчика и дизайнера, которые никак не могут прийти к единому «знаменателю», и при этом проконтролировать качество выполнения текущих работ. Успеть по всем пунктам и при этом не сойти с ума поможет только грамотная организация времени.

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

Вы не готовы брать на себя ответственность

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

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


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

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

LinkedIn

64 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Неплохая статья, но, местами, некорректные сравнения/аналогии/метафоры + шаблонные/избитые выражения сильно режут глаза.

... вы должны смело занять оборонительную позицию, быть инновационным и порой даже агрессивным в решении проблемы, а не отсиживаться в «окопах» ...
А?
«Занять оборонительную позицию», но при этом «не отсиживаться в окопах»? А как по-Вашему занимают оборонительную позицию? Именно что в окопах, блиндажах, перекрытых щелях. Видимо, стоило сказать «атаковать проблему, а не отсиживаться в глухой обороне».
.
Постоянные перемены и изменения — это часть ДНК работы Project Manager’а
Сейчас модно стало указывать/ссылаться на «ДНК». Но тут Вы НЕ использовали некоторое устоявшееся выражение, а сконструировали новое, которое выглядит, как устоявшееся, но никому не известное. Режет глаза.
ДНК всякого торта — хороший заварной крем.
ДНК детской коляски — хорошие надежные колеса.
.
План — это всего лишь модель поведения
План — это схематическое представление, развернутое во времени. План постройки моста.
Модель — это схематическое представление БЕЗ времени. Модель моста.
.
иметь техническую грамотность
БЫТЬ технически грамотным.
.
график как по уставу
Фразеологизм собственного производства?
Опять же, большинство разделов (не все), скажем, «Устава строевой службы » указывает на СТАТИЧНЫЕ взаимоотношения между частями. Вот пример:
1. Строй — установленное Уставом размещение военнослужащих, подразделений и частей для их совместных действий в пешем порядке и на машинах.
2. Шеренга — строй, в котором военнослужащие размещены один возле другого на одной линии на установленных интервалах.
...
Строевой смотр проводится прямыми начальниками или лицами, назначенными для руководства инспектированием (проверкой).
...
181. Для строевого смотра рота строится в развернутый двухшереножный строй: командир роты становится в семи шагах перед серединой роты, старший техник — в двух шагах правее группы управления, сигналист-барабанщик — в двух шагах правее старшего техника, заместители командира роты — в двух шагах правее сигналиста-барабанщика, старшина роты становится на левом фланге роты.
.
Хорошие менеджеры проектов — это харизматичные лидеры
Спорное утверждение.
Сейчас стало популярным в американской поп-исследовательской литературе уповать на «лидерство», да еще и «харизматичное». Вообще-то «харизматичное лидерство» — это редкий феномен, это — Наполеон, Ленин, Троцкий, Гитлер.
Например, Обама — НЕ харизматичный лидер. Но вот второй срок занимает пост ПМ.
.
сотрудники объединятся под вашим началом, плохая — объединятся они против вас
Фразеологизм (устоявшееся выражение) «объединятся под вашим началом» — предполагает, что люди ЗА Вас, а НЕ против.
Заключенные, объединенные под началом охраны лагеря, подняли бунт и вырезали охрану лагеря. Как-то странно звучит, не находите?

В целом с комментариями согласна. Но в этом выражении: " сотрудники объединятся под вашим началом, плохая — объединятся они против вас ", мне кажется важна не логика. Меня -эта фраза улыбнула, по- моему реалистично ;) Харизма.... очень сложно объяснить, что это такое, но обычно весьма заметно есть она или нет. Насколько она критична для достижения цели-это другой вопрос.

решение- основа деятельности командира. командир отвечает за принятое решение.
главное-ответственность за результат, всё остальное в списке уже из этого вытекает: таймменеджмент, кнут, пряник, уймазадач...
решение всегда должен принимать человек, который за всё отвечает. но надо уметь выслушать всех и принять правильное решение. плохое решение- то, которое не принято. если все пиндят и ни за что не отвечают- это украинская политика.
поменяйте командира на менеджера, бой на бизнес, в общем здесь всё доходчиво militera.lib.ru/...science/stecuk_ls/01.html

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

8. У вас есть семья и личная жизнь

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

На мой скромный взгляд

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

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

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

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

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

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

Дело не в идеальности, а в ответственности и надежности. Если не можешь сделать — не обещай и не берись. Не смог донести руководителю — значит или ты не прав и спроси какой способ видит руководитель выполнить проект с данной командой, или неправ руководитель, аргументируй ему, покажи почему не получится, убеди, или не бери проект, скажи «я не знаю как его выполнить с данной командой». Не стоит полагаться на магию и думать «ну ладно, сами виноваты, потом скажу „я же вас предупреждал, что команда плохая“».
Уверены в своей правоте, но не можете аргументировать? Конечно популярно думать, что в руководстве одни самодуры, которые ничего не смыслят в этой жизни (и именно поэтому мы работаем на них, а не наоборот). А может имеет смысл прокачать скил убеждения, походить на тренинги, поменять профессию? :) Лично я не особо вижу, что может наменеджить человек, который не может убедить других в своей правоте и при том, что ему это не удалось, продолжает считать, что он прав и не слушает аргументов другой стороны и не хочет их принимать. Как по мне, хуже нет ситуации, когда ты просто подвешиваешь вопрос посередине, либо убеди, либо дай убедить себя и работай на одной стороне, а не друг против друга.

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

Какая тогда ваша роль в этом проекте? Быть начальником одного подчиненного?)

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

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

Насчёт «Сроки ему спустили» хорошо рассказано тут: stratoplan.ru/get/free/mbb
Только осторожно, там мат, причём адресованный читателю.

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

+4, −3
Ок, согласен, что это не моё

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

Нет лучшего способа продемонстировать свою некомпетентность в проектном менеджменте, чем утверждать, что все можно спланировать/регламентировать/расписать/определить и этим перекрыть ключевой фактор в любом проекте — фактор неопределенности будущего.

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

Вот кусок из Википедии
ru.wikipedia.org/...5.D0.BA.D1.82.D0.BE.D0.BC

Ну так что теперь?

О какой фразе идет речь?

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

Мне ясна Ваша позиция.
Полностью поддерживаю :)

Простите, а вы правда видели систему, которая

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

1. Нет, такой системы в природе не существует, но понимание идеальной системы важно для понимания — что такое «идеальный проектный менеджер».
2. «Забавная штука»? Что забавного в «учете рисков»? Хотя, очевидно вы пытаетесь написать об управлении рисками в проекте. Позволю вам сказать, что управление рисками в проекте никоим образом не влияет на неопределенность будущего.

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

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

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

Автор gjcnf по всей видимости подразумевает концепцию «(само)обучающейся организации»

Если речь обо мне, то я пишу не о теорях/концепциях, а об управленческих системах, коими являются проекты (или организации).

Это был ответ на

"

Речь идет о ситуации, когда система (в данном случае — проект) абсолютно саморегулируется и не требует управленческого вмешательства
"

Обучающаяся организация в тексте

ru.wikipedia.org/...D.D1.8F.D1.82.D0.B8.D1.8F

Все ок :)

Прочитавши ваші тези, якраз і складається враження, що перед нами більше не практик (яким якраз і має бути ПМ), а теоретик, причому з доволі песимістичним настроєм. Виправте, якщо я помиляюсь.

Я маю під 20 років реальної практики, тому бачу речі глибші, ніж ви можете собі навіть уявити. Питання в тому, що я професіонал а не дилетант с поверхневими судженями.

Валерий, здесь скорее дело не в том, что автор статьи пишет

о проектном менеджменте, не будучи профессиональным проектными менеджером
но в том, что по сравнению с вами, автор стоит в начале Пути. Это не хорошо и не плохо, все это проходили, в том числе и вы.
Пройдет некоторое время, и автор перестанет видеть проектного менеджера этаким терминатором, поймет, что ему нужно просто любить свою команду, снять акцент с себя и своих качеств (умею-не умею), стать прозрачным для команды, чтобы его деятельность была невидимой, а действия — сравнимы с дуновнием теплого весеннего ветра. И вдруг окажется, что падая, оступившийся разработчик приземлится уже в подушку, заботливо подстеленную проектным менеджером заранее.
Такому менеджеру благодарны все, команда стоит за него горой, проекты делаются успешно, заказчики хотят работать только с ним. Но эта идиллия длится не долго, забирает такого менеджера изменчивая жизнь на релокейшн в дали заморские. Лишь прошедшие год-два в памяти разработчиков отдают спокойствием, стабильностью и уверенностью перехода на новую профессиональную ступеньку. А заботливый HR уже знает, кто будет следующим кандидатом.
Вам не комфортно от постоянных изменений и неопределенности

Решается СВОТ анализом + метод экспертных оценок + определение допусков по рискам.

Вам больше нравится работать с техникой, чем с людьми

Пишется меморандум о взаимопонимании, на подпись для всех участников проекта.
Когда определены процедуры и правила, то всеполучается само по себе :)

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

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

Мне особенно понравилось про

конфликту просто негде возникнуть.
Вот он, сферический проект в вакууме! Рисков нет, конфликтов нет, задачки расписал и справился )

в оригинале было так:

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

Ваша версия:

конфликту просто негде возникнуть.

Вот он, сферический проект в вакууме! Рисков нет, конфликтов нет, задачки расписал и справился )

Обоснуйте пожалуйста почему должен возникнуть конфликт в описанный мною условиях?

Ну, во-первых, ситуация когда все люди

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

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

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

Мне ясна Ваша ситуация.
Без обид, но очевидно, что наш опыт существенно различается.

У меня в практике были подобные ситуации как Ваша.
Описанная Вами ситуация решалась дублером + увеличение времени на выполнение проекта.
А если Петя делал работу Васи, то Петя и получит Васины деньги :)
Были эпизоды когда Артем получил за неделю работы 176 грн, ибо отпрашивался, а Максим заработал 500 юсд, ибо работал :)

Оплата по выработке творит чудеса :)

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

Артем, курс доллара на месяц вперед я не знаю :(

Эх... Жаль. А у меня уже такие планы созрели....)

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

Какие причины конфликтов по Вашему здесь есть?

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

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

На деле же в 99 из 100 проектов подвержены внешним факторам и рискам типа перевода части команды на другой проект, назначение нового лида навязаного продукт оунером и прочих менеджерских радостей.

Так это уже не проджект менеджмент, это называется «рыгала, срала, мазала» :)

Прочитал только заголовки, расстроился

Хорошие вещи освещены в статье, но мне кажется, что они все касаются внешней стороны управления. Стиль управления в статье такой, как-будто люди для менеджера — ресурс, а проект — цель. Но мне, сужу по своему опыту, кажется, что успешному менеджеру нужно быть Опытным Психологом в первую очередь. Это значит, что ему нужно научится понимать своих разработчиков и помогать каждому из них проявлять себя в наиболее комфортных для него задачах. Например: холерики в команде, — это люди фантанирующие идеями, но им становится тяжело и неинтересно, когда нужно с чем-то глубоко разобраться и все тщательно проверить. В таких задачах — флегматики золотые люди. Так вот, когда команда сбалансирована и люди в команде будут чувствовать себя востребованными и на своем месте, они начнут доверять своему менеджеру. И таким образом лидерство, конфликты и другие баззворды будут решаться сами собой. P.S Я думаю ключевой момент в моем сообщение-это доверие и подход к каждому члену команды. Я думаю вы сами можете вспомнить миллион случаев, когда вчерашняя выпускница иньяза или сейлз управляли командой успешнее, чем авторитетные дядьки-программисты. Матерые и незгибаемые, считающие, что их опыт вправе решать все:)

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

На счет

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

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

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

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

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

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

Согласна полностью, что люди — это главная ценность в компании. И сама всегда отстаиваю это утверждение. Поэтому и ответила на счет понятия «ресурса».

Ну да. Ты либо работаешь с машинами, либо с людьми.

Очевидна стаття про очевидне =)

Смотрю на себя. Какой я к черту лидер. А потом на некоторых других сравнивая с собой и думаешь: «Майн гот, как они в ПМы прорвались».

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

Кто-нибудь, кроме меня обнаружил у себя все семь?

Когда за окном четверг и на ДОУ выходит статья с подобным заголовком, я всегда вздрагиваю, и по шкуре пробегает холодок: «Чу, не Юрий ли вернулся?!»

Ушел поднимать IT-"целину :D
В места с благодарными читателями :)))

«Но дело его живёт!» (к) (тм)

А вот у меня были все необходимые качества, особенно я умею срабатываться с теми, кто ни с кем не срабатывается. Только не было одного — понять, что заказчику в определенный момент нужно либо сказать «нет, сейчас этого делать не стоит, лучше сначала запустить бета-версию», либо объяснить, что это займет слишком много времени. Особенно когда по 2-3 раза меняется куча незначительных для функционала и интерфейса мелочей, но в коде приходилось заморачиваться. В итоге чуть не завалила проект, потому что на все соглашалась, а время шло. Но кое-как вытянули. Больше такой ошибки не сделаю)) Очень полезный опыт был.

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

Статья — тру. Но все же есть коммент:

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

Подписаться на комментарии