как говориться «хороший человек» не профессия ^_^
Круто когда менеджменту удалось настроить процесс коммуникации так, что на большую часть вопросов отвечает документация (уже созданная или создаваемая) или сам заказчик (если компетентен и доступен) — так сказать прямой канал. Задача менеджмента в такой структуре поддерживать эти каналы чистыми, открытыми, вседоступными и понятными, но и по возможности не забывать про blameless, чтобы как раз было и желание и возможность задать вопрос. И только иногда вмешиваться, когда обсуждение задачи-модуля-стори убежало не в ту сторону (опять же тогда и сам менеджер должен быть и компетентен и в курсе)...все мы люди и это норм и всякое бывает ^_^
«Ни даже если», а в принципе) подтягиваешь матчасть и сразу становится легче жить!
Ещё как бывает)) главное самому таким не стать ^_^
Полностью поддержу Егора, хотя сам сталкивался с тем, что не редко бывает так, что PM начинает свою карьеру почти без технических знаний. При этом, не смотря на якобы низкий порог входа, в процессе работы сложность задач увеличивается, начинают всплывать неоднозначные детали. Разработчики всё больше устают от глупых вопросов и отвечают резко или неохотно. В результате PM, который не хочет погружаться и вникать в происходящее очень скоро перестаёт понимать, что на самом деле творится в его проекте.
Это действительно серьёзная проблема. Рынку труда нужны проектные менеджеры и бывших программистов на всех не хватит. Поэтому PM-ам важно самим повышать техническую грамотность... Мои мысли по этому поводу не уместились в формат комментария, поэтому написал статью
Из книг...знаете, лучше для начала определиться с «технологиями», которые будут вам ближе по духу. Как говорят самураи — «познайте дух самой вещи» ;)
После этого вы найдете массу литературы. Интернет просто переполнен сейчас различными практиками и кейсами. Но цель — найти именно свой способ применения инструментов. Как не существует одинакового кода, так и не существует одинакового стиля видения проектов. Технологии — это лишь рекомендации. То как вы ведете свои проекты — есть Вы сам. Но это слова. Начните вести проекты и вы поймете, о чем я говорю.
Прогнозов давать не буду — я не аналитик рынка. Хотя как проектный менеджер я умею использовать достаточно большую базу метрик и ПО для сбора и анализа данных, что кстати относится к навыкам must have. Но скажу вам другое.
Себе и своей команде я ставлю цель именно развивать IT PM на Украине. Брать лучшие практики из-за границы и развивать у нас. Поверьте, у нас достаточно большие шансы. Пускай сейчас не все гладко, но я знаю, что наши разработчики способны реально на очень многое. И недооценивать нас как будущего сильного игрока на рынке IT просто будет не правильно. Поэтому я призываю всех, кто читал или читает эту статью, так или иначе, принимать посильное участие в наведении порядка в своих собственных проектах.
П.С.
Господа, можете мне поверить (я думаю вы и так это знаете), если у нас в проектах порядок, то и Заказчики к нам тянутся с «порядком в голове», что, как следствие, дает нам более интересные проекты. И дальше по циклу =)
Но для этого нужно что-то делать. Нужно как-то развивать себя и свои команды. Искать там, где еще не искали. Пробовать и внедрять. Знаю, иногда лень, иногда нет поддержки или бюджета, или просто банально нет времени. Но надо...
Простите за много букафф...тема проектного управления в Украине это тема для отдельного разговора за чашкой чего-то крепкого =)
Отличный вопрос ) Есть ряд причин:
1. PMBok — «тяжелая технология», курс базируется на «гибких технологиях»
2. Есть PMBok-Software Extension, которая является адаптацией PMBok под «гибкие технологии» современного IT, но только сам ее разбор я бы вывел в отдельный курс
3. Далеко не обязательно штудировать эти трактаты в начале своей карьеры ПМ-а. Я до них дошел только на втором году активной деятельности. Для старта. тем, кто планирует вливаться в проектный менеджмент, как ни странно, но я бы советовал начать с полу-художественной литературы:
— Элияху Голдратт — цикл книг «Цель»
— Том ДеМарко — роман «Deadline»
— Алексей Головин — «Искусство ведения проектов» на основе трактата китайского стратега и мыслителя Сунь-Цзы «Искусство ведения войны»
Данная литература позволит понять во что вы ввязываетесь. Особенно рекомендую Голдратта. Думаю большинство здесь уже с ним знакомо. Я успел уже несколько раз перечитать его работы, и по мере выполнения уже своих проектов, я каждый раз открываю для себя новые грани его теории ограничений систем, только уже в практической плоскости.
Господа всем спасибо за критику )
Постараюсь ответить в порядке очереди желающих откусить кусочек от моей статьи:
— у нас нет пресс-секретарей
— игру про программистов уже сделали
— спасибо, что верите хотя бы на счет кладбища проектов
— господа я понимаю, что все мы циники, но не стоит так легко обвинять человека во лжи
— наша команда не собирается никого учить — цель — поделиться знаниями, это разные вещи
— на счет людей согласен, их нельзя упускать из виду, особенно таких начитанных ;)
— я просто человек, которому есть чем поделиться с коллегами и теми кто хочет стать на путь проектного управления, и самоуверенность здесь не причем (думаю и вам есть что сказать)
— за сравнение меня с Браном спасибо — порадовали =)
Еще раз всех благодарю господа за такое обилие внимания, и за то, что каждый из вас нашел минутку своего рабочего времени дабы потролить с моей статьи ;)
П.С. Таки да, вы правы в том, что статью разместил наш HR. Викуля огромное тебе спасибо, так как ты сэкономила мне время. Но в следующий раз я буду постить сам, так как это вызывает волну негодования =)
П.С.С. Господа я с радостью продолжу переписку...продолжайте в том же духе...
И мне имейл пожалуйста...
спасибо за линк! забрал себе)