Как стать автором
Обновить

Менеджер проекта с ТЗ в руках — это ещё не признак управления проектом

Время на прочтение 11 мин
Количество просмотров 26K
Всего голосов 26: ↑24 и ↓2 +22
Комментарии 7

Комментарии 7

Очередная статья о том что проектное управление это круто.
Сразу возникает вопрос — в каких условиях НЕ эффективно использовать проектное управление?
Кстати, реально круто. Приходилось видеть проекты разного масштаба, и если были хотя бы ТЗ и управление ДДС, уже выходило удачно. Проектная работа не годится для краткосрочных задач, для рутинных операций, для очень долгосрочной работы с размытыми перспективами (какая-то крупная сложная разработка) — в силу того, что всё равно в проект не влезет. Ну это моё видение. У автора оно может и отличаться. Хотя лично я многое бы сводил к проекту, но без фанатизма.
Например, в условиях низкой маржинальности (так как проектное управления — это не дешево), в операционной и функциональной деятельности. Но проектное управление позволяет справиться с более высокой степенью неопределенности и интенсивностью изменений, чем это обычно бывает при стандартной операционной деятельности.

Вы, конечно, простите, но описанные проблемы, и, особенно, фраза
". Но горе ИТ-компании, если менеджером технического проекта становится гуманитарий или выпускник «Менеджмента»."


Выглядят именно как недопонимание Роли Project Manager и отсутсвия необходимого бищнес бэкграунда для данной профессии.


Понимание контекста и сферы бизнеса, безусловно, важны, но профильное образование в проектном управлении, рисками и процессами гораздо важнее для этой роли.
Отрицание этого равносильно утверждению того что SCRUM и Agile это исплючительно про ПО, забывая что оба этих направления вышли в основном из TPS (Toyota Production System), а сам SCRUM изначально разрабатывался для проектов не связанных с ПО — это то что сам Jeff говорит на своих выступлениях, тренингах и в своих книгах.


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

Когда я учился, мне рассказывали байку про руководителя в СССР, которому поручили провести новый год. Он подготовился, речь подготовил, товарищам дал рекомендации. И прошло все так: Каждый вставал, зачитывал что-то. В духе совещания. И вроде и люди есть и речи произносят и ёлка стоит. Только это праздник, а не митинг трудящихся. Ни танцев, ни музыки, ни веселья. Поэтому если нету соответствующего бекграунда, то ты можешь сделать все в лучшем виде, но не соответствующе данной отрасли.
OMG, зачем я это прочитал?
Вы спорите с голосами в своей голове.

Сначала вы описываете или махровые заблуждения о проектном управлении или типичные ситуации поломанного проектного управления. Но дальше я не увидел объяснения как ваша CRM (предлагаемая в качестве информационной систему правления проектами) позволяет избегать вышеописанных проблем? Т.е. ваша CRM магически должна приложить подорожник к брешам в корпоративной методологии проектного управления (если она вообще есть). Методология первична, инструмент — вторичен. Инструментом может быть и листок бумаги и Excel и физическая канбан-доска. Чем вы лучше этих вариантов? А чем вы лучше Trello или Open Project или кучи другого похожего бесплатного софта?
Среди типичных проблем вы упоминаете игнорирование рисков. Как ваша система помогает решить эту проблему? Не увидел на скриншотах и в описании функционала ни чего про риски.

«Не бойтесь стартовать одновременно несколько проектов» — как ваша система помогает не бояться мультипроектной работы? Как менеджер или его руководитель с помощью вашей программы может контролировать ход 5-10 проектов или вех по ним?
Ребят статья классная, объемная подготовленная, проработанная.
Но я вижу много противоречий. Вначале набор таких клише, которые в целом есть везде. Но мне одно непонятно — статья же написана разработчиками, так почему разработчики указывают управленцам какие у них ошибки?) Ну серьезно. Или вы думаете топ-менеджмент в больших компаниях не в курсе про эти проблемы?

Более-менее неплохо дела обстоят в ИТ, где большинство (но, увы, не все) проджектов растут изнутри, из среды разработчиков.


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

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

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

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

Тоже клише. Что за пренебрежение к другим сферам? Выглядит так будто в IT мы тут все умные, а другие лаптем щи хлебают. Опять же вопрос — насколько авторы в курсе о том что происходит в других сферах? И в скольких.

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

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

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