×Закрыть

PM — нервная работа!?

Здравствуйте!

Хочу спросить вашего совета! Я работаю практически что называется Project Manager. Но в компании, которая занимается производством тракторов! Компания можно сказать государственная (ну и соответственно, и имеет функциональную структуру с отделами, подразделениями и т.д.), но зарабатываем мы сами, пытаясь что-то продать или разработать. Так вот я закончил ВУЗ по специальности технолог, пошел работать конструктором, сейчас руковожу подразделением 8 человек. Организация большая, почти 1000 человек, и у нас на предприятии принята система управления проектами PMBok. Я кроме нее использую в своей команде Scrum и Kanban. В общем все бы хорошо, но в последнее время, года три, работа стала очень стрессовая и нервная. Иногда работаем над иностранными проектами, и на меня постоянно давит начальник. Часто у меня на руках по три проекта одновременно бывает! Смежники, начальники, и подчиненные постоянно чего-то хотят и требуют. Постоянные дедлайны! В общем началось повышаться давление и нарушился сон. Короче сижу на антидепрессантах почти! Вот не могу уже там работать, хотя мне эта деятельность — управление людьми и персоналом — нравится. Хочу поменять работу, вот обратил взор в IT.

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

Заранее спасибо за ответы! Надеюсь на вашу искренность!

Лучшие комментарии пропустить

Кодить ещё страшнее. Ты постоянно пользуешься чужим кодом, от людей которые тебе не подчинены. Сказать что они «гуманитарии» — не сказать ничего. Они индусы и цыгане, пытавшиеся работать вместе, а потом бросившие недоделанным без документации и потом допиливали болгары совместив с с проектом ХЕЗ, который вы знаете если пользовались ЖПЧ который тоже недопилен но является прототипом ЖБЖ который стоит 2000 баксов чтобы только посмотреть — и вот там (говорят) есть документация.

И всего одна настроечка, или константа, или хрен знает что — готовы похоронить проект над которым вы год работали, просто потому что оно сломалось, и не говорит где, и не говорит как должно быть. А те примеры что есть — относятся к 2006 году, и с тех пор всё уже по-другому, но те методы тоже оставлены, но работают тоже по-другому, про что если вы погуглите — найдёте баг #97325 который обещали исправить, но индженеры (из Японии) через два года отписали что ничё не знают у них всё работает.

Но начальник уверен, что это потому что ты нихера не делал, пока он cyка «страдал» общаясь с иностранцами.

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
-Все понимают что без кнута иногда никак, но без его разумного применения а таким «колхозным» методом как я увидела в вашем сообщении — от Вас все сбегут :)

Уточните пожалуйста о каком таком колхозном методе идет речь и в каком моем сообщении? Я вроде бы никаких жестких методов не предлагал, а только спрашивал, есть ли в вашей сфере кнут и какой?

-ПМ бук и методологии — такое чувство что Вы услышали несколько слов и мнений о них и говорите о воздушных замках.

Мне действительно не понятно почему я не могу использовать Scrum совместно с PMBOK в моей ситуации, которую я описал выше? Расскажу еще раз: на предприятии принят PMBOK. Вашей команде поручили задание разработать часть нового трактора, у которого двигатель как у БЕЛАЗА. И Топ незнает как этот трактор должен выглядеть. У вас инновационная, новая разработка. Он, да и вы не можете внятно расписать WBS, и к вам приходит просто задание — разработать пол трактора. У тебя на руках срок, 10 человек в команде и задание — сделать трактор по габаритам с БЕЛАЗ. И все — PMBOK уже отработал для вас — сроки определены, риски частично тоже, деньги с Заказчика взяты. Ты сидишь и думаешь «блин, че делать, с чего начать? куда бежать?» Я уже человек с опытом в проектировании и знаю, что надо начать с поиска аналогов, анализа патентов, определения главных характеристик трактора и проведения других расчетов и работ. Я беру, собираю команду, мы разбиваем наши задачи на маленькие, выбираем главные, раздаем или ребята сами берут работу, намечаем спринты и т.д. Я НЕ ПОНИМАЮ, почему я не могу использовать SCRUM? Объясните мне пожалуйста!?? Ну и заодно — сколько слов мне нужно услышать, чтобы не «говорить о воздушных замках»?

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

 Ну у молодых людей постарше уже выработалась такое чувство как «профессиональная этика». За ними контроль не нужен, кто помоложе — да нужен такой контроль. Я уже писал, что контора государственная, и не все дорожат своим местом. Кто-то может и схалтурить! НУ а вообще людей объединяет не опенспейс, а общая идея и цель!

«я слышал что человек ничего не делает получает косари зелени и вообще в шоколаде», Вас дезинформировали.

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

«Вот приду в ПМ ИТ и будут у меня полномочия всем резать зарплату и увольнять за проступки», к сожалению нет, вероятно Вас снова дезинформировали. Далеко не в каждой компании у ПМ есть такие полномочия — он может дать свои рекомендации и авторитетное мнение но не управлять. Это снова попахивает тотальным контролем.

Я нигде не призывал резать зарплату. И ежу понятно, что если махать шашкой налево и направо — никого рядом не останеться. Я просто спрашивал — есть ли в вашей отрасли кнут и какой! С мотивацией и печеньками мне все понятно! И все! С другой стороны, как тут писала Morgun, как она танцует с Заказчиком, встает в 3 ночи по его звонку, а потом, наверное, вы приходите на работу, составляете сроки, занимаетесь бюджетом, рисками, разбиваете работы и т.д., а потом приходите к команде и со стеснением говорите «может быть поработаем, вот тут есть интересный проект...», и при этом у вас нет полномочий — вы не управляете ничем! Вы интегратор, мотиватор, уговариватель и т.д. но не менеджер! НУ и потом, а кто отвечает «головой» за проект? Все и никто одновременно?Менеджер? А как же совершать усилия по движению проекта, если у тебя нет никаких полномочий? Я не утверждаю о повсеместном использовании этого права (увольнять или нанимать сотрудников и т.д), а говорю о самой возможности такого со стороны мененджера. Хотя в условиях среды высокомотивированных сотрудников, наверное все подругому и они все поймут вас с полуслова! Поэтому не буду лезьть со своим уставом в ваш моностырь.

«Я не буду понимать в разработке но смогу заменеджерить ВСЬО», Вам верно подсказали ниже, в этом случае Вы окажетесь передаточным звеном между командой и клиентом, соответственно ни авторитетом, ни правами которые Вы хотели бы получить, тут и не пахнет.

Мне тут сказали, что я вовсе и не мененджер (я кстати и не утверждаю), но пусть меня умные люди поправят. Я не помню, чтобы в руководстве Project Management Body of Knowledge было разделение на менеджеров IT или менеджеров текстильной промышленности, или тракторной. Менеджер — это профессия, набор навыков, которым вы обучились по управлению проектом и людьми для достижения цели в любой отрасли. Ваши же коллеги привели ниже пример, что у людей были случаи, когда это работало. Так что многое зависит, как тут однажды прозвучало, от уровня эиоционального интелекта. Я кстати с вами согласен, что лучше знать ремесло. Поэтому и спрашивал, а не утверждал, допустимо ли чтобы технарь без знания кодинга пришел в IT PM. Я вот разбираюсь в тракторах, и мне ни подчиненные, ни Заказчик не может навешать лапшу на уши.

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

Да не переживайте вы так сильно. Я абсолютно не приверженец жестоких мер (кстати и у вас в IT есть механизм по которому сотрудника тоже могут увольнить за непрофессионализм), и думаю, что только в условиях определенной свободы, свободы возможности ошибаться, свободы выражать свое мнение без критики можно проявить креативность. Я все равно могу все оценивать только со своей колокольни, так что как говориться ИМХО!

Желаю Вам удачи в развитии, Ваша целеустремленность и желание действовать приятно удивляют.

Спасибо!

Можете. Но это будет уже совсем не скрам. Вы ведь не получаете ГОТОВЫЙ ПРОДУКТ (трактор) на выходе после каждого спринта, верно? У вас спринты будут до месяца? Но, допустим, если все же задаться целью.... Попробуйте сесть с командой, создать WBS , и на основе WBS рассмотреть, что реально нужно сделать. Из WBS выберете то, что можно и целесообразно делать итерационно или инкрементально (я бы не ставил эти элементы на критический путь). Вот и будет, условно, у Вас waterfall с живущим в нем «agile».

Из личного опыта могу сказать, что скрам, даже в более-менее чистом виде, в engineering может быть использован. Были такие проекты. Некоторые моменты из скрама (но тогда теряется ценность самого фреймворка!!) могут быть использованы. Только вот вопрос: у вас есть команда, которая самоорганизованна, не требует внешнего управления и ориентированна на результат?

На то Вы менеджер, чтоб Вам лапшу на уши не вешали. И дело тут совсем не в знании тракторов.

Можете. Но это будет уже совсем не скрам. Вы ведь не получаете ГОТОВЫЙ ПРОДУКТ (трактор) на выходе после каждого спринта, верно?

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

У вас спринты будут до месяца?

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

Попробуйте сесть с командой, создать WBS , и на основе WBS рассмотреть, что реально нужно сделать. Из WBS выберете то, что можно и целесообразно делать итерационно или инкрементально

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

Только вот вопрос: у вас есть команда, которая самоорганизованна, не требует внешнего управления и ориентированна на результат?

Это самый интересный и трудный вопрос! Я бы сказал 50/50. С молодежью полегче — в этом случае Scrum — как элемент игры! Результаты, которые мы хотим достичь сразу дикларируем при инициации проекта. Вывешиваем их и стараемся достичь. Здесь мое влияние минимально, но если совсем молодежь или безинициативные — раздаю задания сам. Вот такие реалии. С людьми постарше (50-60 лет) — потруднее. Их никакие рассказы про Scrum и Kanban не тронут. Это как раз в ту тему про колхоз. Так и хочеться сказать, Господи, кем вы там управляете? Коллективом людей, которые «из шкуры вылезут» за 1000-2000$ ? Пришли бы поуправляли людьми, которые получают 5000 грн!? Когда ты ему даешь работу, а он ноет тебе что ему меньше заплатили, чем другим. Или людей постарше смотивировать. Они тебе расскажут, что они таких людей видели и с такими работали....а я тут с каким-то инновациями и заданиями. Или придут кинуть тебе на стол выполненный «наот***сь» чертеж, в которой даже виды изделия не правильно выполнены. Поэтому и получается, что инженерные отрасли, как правило, не такие багатые, как IT. Закрыть потребности чуть выше базовых деньгами не получается. Отсюда много недовольных людей и невысокая мотивация! А талантливые, которые смогли-бы преломить ситуацию, уходят. И менеджмент вот такой получается...с внешним управлением, по-научному его еще называют директивным мененджментом, но тут на сайте его обозвали колхозным! Безусловно все технологии и методологии применяется в разумном пределе (хотя мне кажеться и с перекосами иногда) — иначе бы организация распалась бы уже! С другой стороны — или уйти и сдаться, или поробовать улучшить себе процесс проектирования и сделать его интересным!
Получается у меня что-то вроде «Agile собственного приготовления»! Главное, что есть результат!

Не совсем так. Одна из идей скрама — ограничение рисков до рисков одного спринта. На примере трактора. Спринт 1: берем существующий трактор, пересчитываем раму, ставим другой двигатель. На выходе: трактор с другим двигателем, на котором можно работать. (да-да, я понимаю, что необходимо пересчитать валы, коробку, охлаждение и прочее, но мы рассматриваем пример). Заказчик посмотрел, одобрил, внес поправки. Спринт 2: ставим коробку. На выходе: трактор с двигателем из спринт1 + коробка. Заказчик посмотрел, одобрил. Спринт 999: у заказчика закончились деньги, ему срочно нужно вывести новый трактор на рынок, да мало ли что, но у него есть от вас готовый трактор с двигателем, коробкой + 996 других опций (улучшений), изменений. Получая каждый раз на выходе трактор, а не коробку, двигательный блок и т.д. Таким образом у него после каждого сринта есть то, что можно использовать, и если цели его компании изменятся и он решит закончить проект, у него все равно есть трактор. Он его может использовать как трактор, продать как «трактор».
Если же заказчик хочет получить лишь коробку, то на первой итерации это может быть, условно, готовая коробка с показателями А, на второй — с дополнительными возможностями, меньшей массой и с показателями А+5% и т.д. То есть, прервав проект, заказчик все равно останется с готовым к использованию продуктом.

Вы сами мжете определять инструменты и техники. Но это уже не будет скрам.

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

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

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

Эту идею нужно будет донести до 20-25 человек, которые подписывали этот документ. В силу специфики организации так просто документ не исправить!

Тогда это не скрам. А использование некоторых элементов скрам в Agile, почему бы и нет? Вы сами выбираете, что Вам удобно и как. В 90% те люди, которые говорят, что у них скрам фреймворк, на самом деле достаточно далеки от самой концепции скрама и тех преимуществ, которые он даёт. Допустим, по Скрам Гайд SM не управляет командой. Команда работает сама, ведет учет затараченых часов сама! Вы часто такое видели?:) По статистике только около 12% работников способны к самоорганизации.

Ну, если у Вас хорошие отношения с заказчиком, попросите его отправить вам и-мейл, где он мягко намекает, что именно это вот необходимо для него, чтоб ему удобней было. :) И с этим имейлом и приговаривая: «Шеф, все пропало!» Идите к принимающему решения в Вашей организации. И тогда либо правила могут изменить, или дадут Вам дополнительные полномочия. Это как вариант.

Engineer, мы с Вами, своего рода, коллеги (я являюсь CPEng, Mechanical), так что многие Ваши вопросы близки и понятны, но могу сказать, что все это решаем.

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

И у меня мало примеров использования именно Scrum или Kanban в разработке технических проектов, может у вас есть что почитать (на английском или на руском все равно) или описать свой какой-нибудь опыт?

Нервы будут всегда. Выгорание... У меня суббота, 16:04 — я на работе. Так что это... специфика работы такая.... Разница — в оплате. Я стараюсь брать контракт (проект), полгода-год. За красивую шестизначную цифру в год. Выполнить его. И поехать в отпуск отдохнуть-восстановиться месяца на 2-3. Будет желание — напишите в личку скайп — поболтаем :)

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

Немного удивляет некоторая степерь «зазнайства» людей, работающих в IT в Украине... По меркам Украины, в IT, бесспорно, применяются гораздо более прогрессивные методы PM. Но если сравнивать с мировым уровнем (а зп у вас близки к ним), то пока что не очень. Пример: PMP — это норма, the must. Многие компании не будут рассматривать спеца как ПМ без какой-либо сертификации (хотя бы в соотвтетствии с местными стандартами) от слова совсем. Да, вы можете выполнить проект. Но насколько хорошо? Сколько из ПМ в Украине PMP даже в IT? Scrum? PSM1 хотя бы или от Альянса сертификат. Есть спецы в Украине, однозначно. Но сколько их в общей массе? Я не говорю уже о сертификации Agile с PMI. Ну и второе образование (PM) (сейчас пойдут, наверное, комменты: а зачем нам это надо? И так все хорошо!)
Удивляет относительная «закрытость» отрасли. Я уверен, что у Engineer, например, есть свой опыт, который мог бы быть очень полезен в IT, однако, «необходим опыт в IT». Могу сказать, что мне пришлось выполнять проекты в самых разнообразных отраслях, условиях и т.д. Везде есть своя специфика. Но, чтоб понять специфику, нужны месяцы, а чтоб стать PM — годы.

To: Engineer. У Вас очень правильный подход, на мой взгляд. Вы пытаетесь разобраться, пытаетесь использовать практики, методологии, фреймворки и т.д. PM в инженеринге, да простят меня IT, ну никак не проще. Так что, если есть английский достойного уровня, не будете останавливаться — все у Вас получится!

To: Engineer. У Вас очень правильный подход, на мой взгляд. Вы пытаетесь разобраться, пытаетесь использовать практики, методологии, фреймворки и т.д. PM в инженеринге, да простят меня IT, ну никак не проще. Так что, если есть английский достойного уровня, не будете останавливаться — все у Вас получится!

Спасибо за поддержку!

не нада называть себя проджект менеджером если пару раз увидел слово пмбук

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

Я работаю практически что называется Project Manager

Мне необходимо выполнять много проектной работы: я действительно из последних 6 проектов только на 2 общался напрямую с заказчиками, и это были долгие годичные проекты. Я занимаюсь командообразованием — привлекаю иногда людей из соседнего подразделения, их мотивацией, иногда рисками и т.д. Как вам будет угодно, можете не называть меня PM!

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

Может быть и нельзя, вам виднее, но я расскажу как это работает у нас! PMBOK от версии к версии тоже становиться все гибче и гибче, и клиентоориентированным. Но у нас он работает до крупных систем, как я писал выше, поскольку и топы не вкурсе всех моих процессов разработки, да и если надо че то новое и инновационное придумать, никто не сможет написать WBS вменяемо. Поэтому приходиться на месте с командой разбираться. Зато произошла инициация проекта, Заказчику показали какие-то цены и сроки с приблизительными очень укрупнеенными характеристиками трактора. Это спасает от постоянного изменения исходных данных в общении с ним при использовании Scrum. Хотя, если серьезно и строго подходить, может это и не Scrum использум — ведь Заказчик в наших стендапах не участвует, мы только даем ему с оределнной переодичностью результаты при встречах. Зато, когда ясно, что мы можем улучшить какие-то процессы или характеристики трактора — мы общаемся с Заказчиком, предлагая ему какие-то улучшения, и мне не надо пересоглавывать дерево документации и собирать 150 подписей, если я хочу выпустить дополннение. Как-то так и работаем...Да и я не преверженец ограничиваться какой-либо технологией и вот только с ней работать.
А так да, мои топы не зуб ногой в PMBOK.

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

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

-«Вот приду в ПМ ИТ и будут у меня полномочия всем резать зарплату и увольнять за проступки»

Нет, не будет таких полномочий.
Взять чувака на место уволенного — иногда может занять несколько месяцев.
Резать зарплату — то же самое. Каждого разработчика с опытом от года и больше заваливают предложениями всяких разных вакансий. Чувак, которому порезали зарплату, найдет новую работу в течении пары недель, и свалит от вас :D
Если вы будете воплощать все ваши подобные идеи на практике — команда моментально разбежится. Угадайте, кто будет виноват и кому сделают а-та-та? :)

Решил отписаться в этой теме. Уважаемые PMы, поясните, пожалуйста, так как в Украине многое отличается от... остального мира...
1. У вас у многих титулы Senior, Head, Lead и т.д. Иногда даже PrgMn и Portfolio Mng. При этом в подчинении зачастую всего 1-2 PMа, а то и джуна, program budget, в лучшем случае, пара сотен тысяч долларов (до миллиона-двух, ок) и всего 2-3 небольших проекта в «программе». Просто как бы это нонсенс.... Готовишься к собеседованию в Украине. Собеседовать будет Senior PM. Заходишь на Linkedin в его профиль.... и понимаешь, что... ничего не понимаешь..... Как с ним обсуждать PM, если он максимум в лучшем случае немножко читал про скрам?
2. У многих нет ни сертификаций, ни PM образования, ни даже прочитанных PMBOK или Scrum Guide. Но гордо носите титул PM. Это как?
3. Как можно быть Scrum Master (команда до 9 чел) и PM (по PMBOK тому же — это проекты с сотнями stakeholders и сотнями-тысячами людей, вовлеченных в project execution) одновременно? В скраме НЕТ PM. Скрам мастер — это, условно, «сержантская» позиция, а PM — уже занимается бюджетированием, анализом рисков, как минимум ( по тому же PMBOK — проекты в несколько миллионов). Это принципиально разные уровни.

Есть еще много вопросов... Но пока, если можно, поясните по тому, что выше.... Спасибо.... Так как я и правда несколько.... удивлен.... Меня эти вопросы действительно очень интересуют, так как рассматриваю возможность вернуться в Украину, но пока не совсем понимаю требований к позиции PM, проектам, вот и пытаюсь выяснить «из первых рук»...

...так как рассматриваю возможность вернуться в Украину

Довольно-таки глупая идея. Хочется порулить крупными проектами? Иди на работу в западный концерн — через год уедешь от него рулевым в какой-нибудь Китай или Индию.

А в Украине всё провинциальненько. Выпускники «гарвардов» с МБА от «стэнфордов» мало кому нужны (если вообще).

Я рулю сейчас крупными проектами. По ряду личных (семейных) обстоятельств хотел бы вернуться в Украину. Потому и интересуюсь.Нужны ли вообще такие PM в Украине. Какие нужны. Каков уровень знаний и требований. К сожалению, IT в Украине — это единственная отрасль, где теоретически можно использовать умения PMa. Потому я здесь, на этом форуме. :)

Экие, переборчивые дауншифтеры пошли. :)

П.С. В Украине, из крупного кроме ИТ — есть металлургия, энергетика, агропром. В конце-концов, министерства/чиновничество тоже. В общем, не ИТ единым для толкового ПМа. :)

Изменение места проживания не всегда есть дауншифтинг. За возможность поработать в IT и получить новый опыт, я готов потерять в ЗП. Вот и пытаюсь понять, какой опыт можно приобрести, на сколько он relevant, можно ли чему-либо научиться.

можно ли чему-либо научиться

Научиться в Украине? Можно. 1) Пить водку и другие алкогольные напитки, по разным поводам и в большом количестве 2) Давать/брать взятки и заниматься прочей коррупцией.

Опыт релевантный (можно сказать, необходимый), для работы на недоразвитых рынках.

Абсолютно не согласен. Мне довелось пообщаться со спецами действительно высокого уровня, у которых есть, чему поучиться именно в IT.

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

У меня в RACI на сейчас — 168 и это только тех, с кем действительно нужно считаться :) И это небольшой проект. На счет металлургии и энергетики Вы несколько... заблуждаетесь. В чем специфика украинского IT с точки зрения PM? В чем отличия от других отраслей? Что в целом PM в Украине «воспринимается» несколько... иначе... я уже понял.

На счет металлургии и энергетики Вы несколько... заблуждаетесь.

Отнюдь. В украинском ИТ крутится много денег — но они все размазаны тонским слоем на куче проектов/людей. В итоге, крупных проектов действительно нет.

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

а шо в РАКИ стейкхолдеров записывают ?

А разве нет? :) Тогда зачем нужна RACI matrix? :)

слово одних пропущено, в раки не должны быть одни стейкхолдеры

А кто там еще должен быть? :)

я думал она в основном для тех кто работу делает и кто за нее отвечает

А они не являются stakeholders?????? Понятие stakeholder как бы одно из базовых в PM. Или Вы не считаете так? Это базовые! знания.
Вот именно это меня и удивляет...

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

Внезапно :) 5th Edition PMBOK® Stakeholder: An individual, group or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity or outcome of the project. Let’s consider first the scope of the definition. The first group of stakeholders to be considered are those within the project, i.e., the project team.
Они всегда! являются stakeholders!
Если Вы — PM, то я, мягко говоря, удивлен....

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

An individual, group or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity or outcome of the project.

Мнэээ... в таком определении любой пользователь Windows является Stakeholder — потому что он perceive itself to be affected by решениями типа «а из следующей версии мы уберём половину приложений, а цену умножим на 10».

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

А разве конечный пользователь не является Stakeholder?? Чем концепция оригинальна???? Все это азбука PM..... И что можно убрать, а что нет, можно ли поднять цену — все это делается с учетом влияния на пользователей как stakeholders. 4squareviews.com/...​e-chapter-2-stakeholders. Да, я немножко читал PMBOK, являюсь немножко PMP, немножко PSM. Так что очень надеюсь, что трактую PMBOK относительно верно.

OK, понял. Тут таки сомнительно применённый термин. Я ожидал бы для этой роли чего-то вроде interessant, последний не имеет сильного намёка на прямое материальное участие.

Попробуем иначе: у Вас заказчик не принял продукт, так как людям, которым предстоит с ним работать не нравится:
— Цвета интерфейса
— Расположение кнопок
— Посто не нравится что-то.
Это материальное участие? Если таких людей у заказчика 3 из 10.000 — тогда это, возможно, не будет учитываться. А если пользователей 10 и 9ти не нравится? Вам внести изменения будет стоить денег. Верно? Но это очень простой пример.
А, скажем, другой пример. Люди рабтали с програмным обеспечением А. Вы поставили обеспечение Б. И все классно... Но пользователям просто лень учить новое. И они начнут «вставлять палки в колеса». Я не знаю, как в Украине, но проработать все эти варианты — работа ПМа, вообще-то... Чтоб проект выполнялся проще, быстрее и без лишних ненужных проблем.
Как я понял, большинство ПМ в Украине — это или бывшие технари, или люди, как-либо связанные с IT. В этом разница.

IT в Украине — это единственная отрасль, где теоретически можно использовать умения PMa.

Да ладно, топик читали? Там вроде автор ПМ и не из ИТ.

Читал. Только вот на сколько в других отраслях применяется, скажем, PMBOK, PRINCE2 ? На сколько компании готовы их использовать? :)

В СКМ, наверняка, применяется. В принципе, менеджмент там говорят, довольно сильный.

Спасибо, учту. Но, думаю, IT перспективней при возврате назад, в страну, где я сейчас проживаю.

Как с ним обсуждать PM, если он максимум в лучшем случае немножко читал про скрам?

По-моему среднестатистический украинский синьёр ПМ прочитал чуть-чуть больше чем «немножко про скрам». Хотя стоит заметить что чистых ПМ в Украине не так много как и применения методик из ПМБОК относительно ограниченно спецификой рынка. Как разговаривать? Что за странный вопрос от менеджера?

А так на все остальные ваши вопросы ответ один — местная специфика.

Если не ПМБОК, то какая методология используется? Как раз и хочу понять эту специфику.

Я бы сказал что наибольшей популярностью пользуются методологии «на коленке» и «ковбойского менеджмента». О том, что существенная доля проектов не дотягивает по размеру до масштабов к которым Вы привыкли вы уже знаете. Есть ещё большие и масштабные проекты на которых можно применить Ваш опыт, но тут возникают ньюансы — во первых зачастую на них работают команды распределенные по локейшенам а менеджмент остается на стороне заказчика. По-этому 90% менеджеров в наших реалиях — Аккаунт менеджеры, Деливери менеждеры, Инжениринг менеджеры. При всем при этом они местами могут фрагментально использовать ПМ компетенции как то например управление рисками. Есть конечно и случаи когда в ИТ проектах в Украине работают и чистые ПМ, но они встерчаются сравнительно редко.

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

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

Прошу прощения.... Вы — PM? То, что написано выше, по меньшей мере... странно.....

То, что написано выше, оно, помимо всего прочего, еще и написано со множеством ошибок, что тоже, в общем-то, говорит само за себя.

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

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

С одной только разницей — у нас в IT ПМ-ам нервы трепят обычно кастомеры напрямую, а не какой-нить глав. менеджер. И объяснять например невыполнение их дедлайна тем, что проект А щас приоритетней проекта Б, им не получится :D

Для меня в этом даже плюс. В отличии от моей богоделни, где я имею кучу ответственности, и никаких полномочий. Вы практически рулите в этой ситуации бизнесом. От вас зависит успех бизнеса! Кроме ответственности какие у вас полномочия? Как у вас в IT наказывают сотрудников за неоднократные срывы проектов, низкое качество продукта? Я наверное по старинке рассуждаю, но мне кажеться, что пряник всегда ходит вместе с кнутом. Ничего лучше еще не придумали. У кого-то работает мотивация До, а у кого-то — От!

Как у вас в IT наказывают сотрудников за неоднократные срывы проектов, низкое качество продукта?

Неродивых порят на конюшне.
Неродивых менеджеров.

Неродивых

Чайлд-фри что-ли? ;)

Этих в первую очередь и с особым пристарстием.

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

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

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

Из специфики например — вы будете испытывать некоторые проблемы с наймом людей в такой офис т.к. многим некомфортно сидеть спиной к другим людям. При смене работы большинство предпочитает получить 2-3 оффера, и в итоге они уйдут к конкурентам, у которых нет такой проблемы. Я не шучу есличо, почитайте топики «обзоры офисов» и зацените количество комментариев «фу, опенспейс».

Как у вас в IT наказывают сотрудников за неоднократные срывы проектов, низкое качество продукта?

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

Я не шучу есличо, почитайте топики «обзоры офисов» и зацените количество комментариев «фу, опенспейс».

И судя по реакции — бизнесу абсолютно пофиг на эти отзывы.

Естественно — проще потерять Х вертящих носом девелоперов, чем вложить в 10 раз больше бабла в ремонт помещения)

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

в основном — не повышают зп, должность. выгоняют редко.

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

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

...

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

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

Никто также никому не должен платить или обещать платить вознаграждение натурой или деньгами больше обычного, как сказано выше, и никто его в ином размере не должен требовать или получать под страхом уплаты вдвое против того, что было так уплачено, обещано или потребовано или получено, тому, кто чувствовал от этого ущерб
ОРДОНАНС О РАБОЧИХ И СЛУГАХ
AN ORDENANCE CONCERNING LABOURERS AND SERVANTS
(1349 г.)

но, рынок труда плохо поддавался и тогда таким указам.

так что кнутом — эт можно. разбегутся просто, да и все :)

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

Поки з того що читаю — бачу правильний настрій і бажання добиватися результату. Цікаво буде подивитися, що вийде, коли з півроку в цьому напрямку попрацюєте.

Меня еще один вопрос беспокоит! Вот мне понятно развитие РМ как в моей области так и в IT: сначала ты хороший инженер, потом можеш организовывать не только себя, но и младших товарищей или небольшую группу, ну и потом ты превращаешся в мененджера. Я знаю ремесло и есть навыки управления проектами и людьми. В общем-то так было у меня, да я думаю, что и в большинстве случаев в IT так. Но вот вопрос, возможно ли управлять программистами не зная программирования? Понятно, что самообучение никто не отменял, и через пол года я в чем-то начну разбираться, но я не программист и им никогда не работал!? Были ли у вас такие случаи? Это сильно плохо (хорошо?) для менеджера и команды, если приходит человек со стороны, не знающий хорошо программирования?

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

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

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

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

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

Но вот вопрос, возможно ли управлять программистами не зная программирования?

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

Были ли у вас такие случаи?

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

Это сильно плохо (хорошо?) для менеджера и команды, если приходит человек со стороны, не знающий хорошо программирования?

Все очень сильно зависит. Где-то может и знание ПМ практик и умение рабоать с людьми пригодится. Где-то нужны будут технические компетенции.

Но вот вопрос, возможно ли управлять программистами не зная программирования?

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

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

С одной только разницей — у нас в IT ПМ-ам нервы трепят обычно кастомеры напрямую, а не какой-нить глав. менеджер. И объяснять например невыполнение их дедлайна тем, что проект А щас приоритетней проекта Б, им не получится :D
А так в целом то же самое — бабло побеждает зло. Только у нас еще имеются овертаймы, инфантилизм и прочие радости жизни.
Конечно, бывают проекты, где можно саппортить древний энтерпрайз и нифига не делать, но это скорее исключение.

На низком уровне — возможно и желательно знать IT. А если у Вас проект (программа), скажем, связан с медицинским оборудованием, где надо и оборудование разработать-произвести, и софт написать, и персонал обучить — как тут как быть?:) Одновременно быть и инженером, и спецом в медицине, и IT developerом и еще немножко преподавателям дипломированным? :):):)

Одновременно быть и инженером, и спецом в медицине

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

оно ж прямо по присказке
«в теории нет разницы между практикой и теорией. а на практике — она есть»

в теории менеджмент везде одинаков. ведение проектов — описано. и т.д.
а на практике — сила любого работника(и менеджера тоже) — в знании нюансов. которое с опытом начинает выражаться чутьем, «интуицией»
— а вот так точно не получится
— (новенький) ну почему? если сложить 2 + 3, ведь будет 5, верно?
— верно. в общем случае. но в нашем деле, обычно получается 4,95. а так округлять в нашем деле низя, то берем целое. значит по факту будет 2+ 3 = 4

Требования к медицинскому оборудованию с заказчиком обсудит спец по медицинскому оборудованию из моей команды и даст мне отчет. И об его особенностях. И на что обратить внимание. High level финансовые данные даст мой аккаунт менеджер, который работает с клиентом и с которым мы «продавали» клиенту проект. Нет понятия «интуиция». Есть анализ рисков, collection of the requirements. И работа PM — организовать эти процессы.

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

а по реализации отчет вам даст тех. лид.
и т.д.

И работа PM — организовать эти процессы.

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

Нет понятия «интуиция».

ну у вас может и нет :)

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

но не настаиваю. нет места интуиции в менеджерском деле, ну ок, значит нет.

Как можно в измеряемых величинах определить интуицию? Вот вы идет к СEO c бюджетом проекта на $15млн и говорите, что на основании интуиции в contingency reserve вы заложили 300к?

Как можно в измеряемых величинах определить интуицию?

никак конечно.

ну а раз что-то низя измерить, то этого конечно не существует.

Вот вы идет к СEO c бюджетом проекта на $15млн и говорите

я же согласился — раз у вас нет интуции, то ее нет вообще.

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

или, о наших реалиях:
ну пришел к вам тех. лид, и рассказал и показал что в архитектуру заложена устойчивая под такой-то нагрузкой.
ну вот один глянет — и да, все сходится, 2+3=5.

в contingency reserve вы заложили 300к?

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

А нельзя узнать мнение 3го, 4го? Если это действительно важный элемент, который уточнение которого стоит затрат времени и финансов? Нельзя перед тем, как формировать бюджет, использовать общепринятые техники risk assessmnet? Есть общепринятые инструменты, техники. У вас СЕО лично что-либо проверяет? У нас в компании более 30к людей работает. :):):) Так что СЕО немного не до проверок. Интересует только high-level information и то только по стратегически важным проектам

А нельзя узнать мнение 3го, 4го?

можно конечно.
оно ведь известно — что истинность чего-то определяется прямым голосованием :)

Так что СЕО немного не до проверок.

надо же. и он ничего в области где занимается ничего не понимает?

Интересует только high-level information и то только по стратегически важным проектам

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

что вы собственно хотите оспорить? что вы не достигли поста где нужно принимать решения на основе high-level information, то есть очень неполной?

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

но настаивать не буду. питаетесь радугой и какаете бабочками — значит так и есть, да.
значит вы особенный очень. бывает.

Скажите, а кто такой, в Вашем представлении, СЕО и каковы его задачи? :) По-моему, у нас концептуальное отличие в тайтлах....

Так и есть -коэффициент пр*еба в проекте -это чисто эмпирическая величина:
А что в вашем понятии слово интуиция значит? Это всего- навсего опора на прошлый опыт, а не вангование..

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

чисто интуиция редко пользуется

«чистое» существует только в теории.

обычно если интуиция говорит что то то не чисто

у кого какая — та о том и говорит.

Вы называете интуицией решения, которые принимаете исходя из субъективных взглядов и ввиду неиспользования классических инструментов PM? Чем интуиция отличается от метода 3П — «Пол-палец-потолок»? Работа PM — это разве не анализ рисков и поиска ответов на них?

я называю интуицией — «метод решения» а не решения.

а то что вы называете интуицией — решения, или «субъективные взгляды» ну дык, кто ж вам доктор.

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

как и вот так и знал
что мне будет приписана дурацкая дихотомия — теория ИЛИ практика.

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

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

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

Скрам мастер не является ПМ. И он не руководит. Это по скраму. У вас другой скрам? И при чем менеджеры к скраму???

Случаи в жизни встречаются разные. Случаи когда линейный руководитель за одно и скрам мастер сложно назвать исключениями.

И при чем менеджеры к скраму???

Я же о том и пишу, что нипричем. :)

ну а по вашему этим проектом можно управлять ничего не соображая в медицинском оборудовании вообще?

Вообще от «совсем» — будет сложно и затратно по времени, должна быть профессиональная команда (но ведь формирование команды — это и есть работа PM, правда?:)). Но тот же PMBOK утверждает, что да

Но тот же PMBOK утверждает, что да

угу, значит утверждение «в теории нет разницы между практикой и теорией. а на практике — она есть» ложно. бо в теоретической книжке так написано!

Чтобы управлять процессом приготовления омлета нужно знать технику несения яиц?

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

и выбор этот будет делаться — интуитивно.
и интуитивно же будет определяться — эта аналогия годится, или нет.

но вы да, подобрав нужную вам аналогию доказали что интуиции — нет :)

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

Тот, кто хорошо несет яйца, зачастую не умеют готовить омлет. Потому что они хороши именно в несении яиц. Это разные работы.

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

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

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

Для начала вопрос: нравится ли лично вам такой офис? Почему? Что можно (если нужно) исправить?

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

1. Чаще болеют. Один заразу принёс

и такое есть!

2. Хуже работают и концентрируются на сложных вещах.

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

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

Openspace:
1. blogs-images.forbes.com/...​11/IMG_2969-1940×1455.jpg
2. www.blogcdn.com/...​edia/2012/04/newsroom.jpg
3. wins.softwareadvice.com/...​es/2013/05/SWA-office.jpg
Это не IT-жаргон, такие помещения могут быть где угодно.

Все, разобрался! Да, у нас именно такой офис, но я его не выбирал. Меня уже в такой офис приняли. Не могу ответить, как это влияет на проект и работоспасобность!?

или вы всё слишком близко берете к сердцу,

Это в точку. В этом проблема — в характере! И поэтому, чтоб не рубить с плеча и не менять кардинально деятельность, хочу попробовать сменить декорации, обстановку и внешние условия!

1. в разных местах и у разных людей все по-разному. Где-то жесть где-то может быть и жизнь-халява.

Так можно про любую сферу деятельности сказать, но даже и без описаний моего друга, мне казалось, что в IT, как то поспакойней, что-ли. Интересно, а как же работают компании из топа лучших в Украине? Уверен HR работают лучше, чем у меня на работе, контингент по мотивированее будет. Кроме того бизнес и управленческие процесы должны быть оптимальными! Чтобы стать лучшими уже необходимо предоставлять интересные, порой инновационные, решения, а с директивным мененджментом и затравленным мененджером это врядли получится!

Все, разобрался! Да, у нас именно такой офис, но я его не выбирал. Меня уже в такой офис приняли. Не могу ответить, как это влияет на проект и работоспасобность!?

Для начала вопрос: нравится ли лично вам такой офис? Почему? Что можно (если нужно) исправить?

Как правило, в таких офисах люди:
1. Чаще болеют. Один заразу принёс — на днях десять человек отправились болеть.
2. Хуже работают и концентрируются на сложных вещах. Почитайте про состояние потока www.verywell.com/what-is-flow-2794768 и подумайте, где здесь вредит опейнспейс
3. Повышенный уровень тревожности и раздражительности из-за нарушения личного пространства. Перегородки слегка помогают. Другие проблемы есть — о них ниже.

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

но даже и без описаний моего друга, мне казалось, что в IT, как то поспакойней, что-ли.

Очень может быть, что это так, а также очень может быть, что друг ваш сам по себе поспокойней чем Вы.

Интересно, а как же работают компании из топа лучших в Украине? Уверен HR работают лучше, чем у меня на работе

Хр работает? Оксюморон какой-то. Хотя и такое я тоже в жизни видел. Ну и кто его знает, что там у Вас вообще твориться.

контингент по мотивированее будет

Может быть, но не факт. Люди они везде ведь одинаковые. А с мотивированными может возникнуть ещё вот какой ньюанс — они обычно не только мотивированные а ещё и амбициозные. И тут уже встает вопрос перед менеджером — а как удовлетворять эти амбиции, так что бы и волки целы и овцы сыты были.

роме того бизнес и управленческие процессы должны быть оптимальными!

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

У админов есть такое поверье: «Хороший админ ничего не делает». Вобщемто у менеджеров есть тоже что-то подобное :)

Ну не в большей степени, патамушо IT конторы все-таки приватные, и средний по конторе IQ там повыше ... но я Вам, пане Engineer, скажу так: Вы свой стресс с собой нОсите :( А Вы чиста забейте, не срывайтесь на подчиненных, пошлите лесом своего мудака началника, и делайте то, что в посадовій іструкції прописано, точка. Не исключено, что он Вас даже уважать будет больше и стиль опщения поменяет. Поверьте, говорю с сопсного хренового опыта: мне тоже управление людьми и персоналом нравицца ... мало того, я им нравилССо :8)) ... но здоровье дороже, и взЪепки на ровном месте и ежегодные отлежки в больничке не окупаюЦЦа даже в IT.

Добро пожаловать в мир PM =)
Многозадачность, куча проектов на руках, быстрое переключение, ответственность перед начальством, нервотрепка с клиентом, прогулка по лезвию между клиентом и командой, БОЛЬШАЯ ответственность перед командой. Все таже куча обязанностей и минимум прав (не факт, но вероятно).
Поверь мне на слово — в IT нервов будет даже больше тратиться, т.к. разработчики — не трактористы (это я образно), к людям нужен свой подход и терпеть ущемления в работе не особо будут рады (да и я не рада если меня ущемляют). Тот как ты это разгребешь и как будешь на это реагировать — зависит только от тебя. Проблемы которые ты описал особо не исчезнут, только новые появятся.
Мало того, по тексту автора я вижу что он особо с клиентами не общается, это больше задача руководителя? Если это так — то готовься лишиться сна полностью, т.к. в IT — это твоя задача, «танцевать» с клиентом, соблюдать дедлайны, и тут уже ты будешь давить на окружающих ими (зависит конечно от тебя).
Ну и совет — ПМ без технического бекграунда — обуза для команды, придется много учиться, прежде чем работать.

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

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

Кстати да, есть конторы, где очень даже приветствуется общение менеджера с клиентами в их таймзоне. То есть менеджер едет домой, чтобы в 10 вечера успеть на митинг)) а на 11 утра обратно в офис, потому что у команды стендап.

Да, помню в W3 в свое время это было так.

Всё то же и может в большей степени.

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

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

В связи с чем вопрос: в вашей отрасли тоже такая стрессовость присутствует? Тоже такая нервотрепка?

о, еще какая...

Кодить ещё страшнее. Ты постоянно пользуешься чужим кодом, от людей которые тебе не подчинены. Сказать что они «гуманитарии» — не сказать ничего. Они индусы и цыгане, пытавшиеся работать вместе, а потом бросившие недоделанным без документации и потом допиливали болгары совместив с с проектом ХЕЗ, который вы знаете если пользовались ЖПЧ который тоже недопилен но является прототипом ЖБЖ который стоит 2000 баксов чтобы только посмотреть — и вот там (говорят) есть документация.

И всего одна настроечка, или константа, или хрен знает что — готовы похоронить проект над которым вы год работали, просто потому что оно сломалось, и не говорит где, и не говорит как должно быть. А те примеры что есть — относятся к 2006 году, и с тех пор всё уже по-другому, но те методы тоже оставлены, но работают тоже по-другому, про что если вы погуглите — найдёте баг #97325 который обещали исправить, но индженеры (из Японии) через два года отписали что ничё не знают у них всё работает.

Но начальник уверен, что это потому что ты нихера не делал, пока он cyка «страдал» общаясь с иностранцами.

Кодить не страшнее, потому как у кодерка ответственности == 0.

Ну, если таких как ты уволить, то и менеджеру не страшно.

Выражайся яснее, кодерок. Что там у тебя в контракте за ответственностъ прописана?

Ой а можно подумать у среднего менеджера в контракте прописана ответстственность. Что тут что в вашей Германии. Ага. Щас.

Разве? А, допустим, в фреймворке скрама разве не development team несет в значительной мере ответственность, не? А репутационные риски мы не считаем?

разве не development team несет в значительной мере ответственность, не?

Нет, конечно. Что там у разработчиков за ответственность? Без печенюшек оставят? :)

Спорное утверждение, но спасибо за комментарий. Постепенно специфика работы PM в Украине в IT благодаря комментариям, начинает вырисовываться.

Ты же работаешь (как пишешь) менеджером проектов. Сколько у тебя пунктов контракта занимает «ответственность»?

Скажем, в моих германских контрактах — это, как правило отдельный параграф, называемый «Haftung» — где прописаны 2-4 пункта, общим размером в пол-листа (при этом, я кодерок, без каких-либо руководящих функций).

Ничего такого, в контрактах у обычного наёмного кодерка нет и близко. Mаксимум, за фэйл (любого размера и ущерба) — команда печенюжек лишит. :)

То есть, репутацию ты в расчет не берешь? Или же считаешь, что ответственность должна (может) быть исключительно материальной (финансовой)? А ведь проваленный серьезный масштабный проект (в том числе, и по причине ошибок PM) может серьезно повредить репутации и дальнейшей карьере разработчика. Если по вине разработчика провалятся 2, 3, 5 проектов, его в шестой пригласят?

В скраме-то, даже репутационную ответственность несёт команда, а не кодерок. :)

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

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

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

Ради среднего кодерка, никто не будет заморачиватъся звонками к бывшим работодателям, итп. К тому же, мнение «бывших» тоже субъективное.

В общем, если материальной ответственности нет — можно считать, что никакой ответственности нет и очередная работа находится с пол-пинка.
(это вообще, если кодерка за фэйл уволят — что далеко не факт)

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

А PM не интересуется когда команду формирует? Какая у человека репутация, бэкграунд, где до этого работал? Это как бы тоже работа PM

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

Бывает. На самом деле, как раз PM на серьезных проектах команду и формирует, исходя из специфики проекта, необходимых качеств, знаний и умений потенциальны членов команды. Нет, ну можно конечно «работать с тем, что дали»... Но кому в этом случае будет комфортно?

Ответ подразумевает как бы на «серьезных» проектах именно пм и формирует.
Что значит серьезные? Размер?
Ответ бывает меня устраивает, возможно это не в тех индустриях где это бывает. Примеры будут?

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

Коряво очень написал. Имел в виду может не в тех индустриях где я работал. Поэтому хотелось бы примеры.

Да, конечно. Как PM я отвечаю за выполнение проекта. В рамках проектах, в основном, необходимо использовать специалистов из очень разных областей (от маляров — покрасить фасад здания, до специалистов по электронике и «умных систем»). Потому, когда нет внутренних ресурсов ни в одном из дивизионов компании, я, как PM, выбираю сабконтракторов, с кем мне удобно работать и в чьем проф. уровне я уверен. Это моё право. По employees: на стадии планирования я уже вижу, какие люди мне будут нужны. Шлю запрос HR department. Мне дают список с описанием навыков каждого из возможных членов команды ( как из моего департамента, дивизиона, так и из других, если необходимо). Я выбираю интересных мне, провожу небольшое интервью, объясняю специфику проекта, мои личные требования как PM и принимаю решение. Если мне нужен кто-то конкретный из другого департамента — я иду к его functional manager и договариваюсь, на каких условиях я его могу получить (перекупить). Не хватает полномочий — иду к своему State manager — и объясняю, почему мне нужен именно этот человек. Один из аргументов: я отвечаю за проект ультимативно. Хотите перевыполнить бюджет — мне эти люди нужны. Вопрос не стоит, смогу ли я уложиться в бюджет ( это обязательно с любым набором людей), вопрос стоит в том, сколько мы сможем получить сверху. Да, PM формирует бюджет, оперирует финансами в рамках проекта. И если речь идет о 100-500к сверху в месяц чистой прибыли просто лишь потому, что мне нужны эти конкретно люди — вопрос решается. Кроме прибыли, говоря о «серьезности», я имею ввиду стратегические цели компании. Если проект является ключевым — то я получу любые ресурсы, которые нужны. ПМ в компаниях, где я работал и работаю, это более стратег, чем тактик. Командами по 5-20 человек у меня управляют leading hands, JunPM и так далее. Вот мне и нужно, чтоб они обладали знаниями, навыками, необходимыми для выполнения проекта. Если любой из них приходит и говорит, что в его команду нужен какой-либо спец, сабби или конкретный человек из другого департамента и объясняет, почему это так, я ему его даю.
Судя по комментариям на форуме, задачи PM в Украине более ограничены и они имеют меньше power. Там, где я работал и работаю, я участвую наровне с Account Manager в «продаже» проекта заказчику, я вижу и оперирую всем бюджетом проекта(ов), подписываю договора с сабконтракторами и обсуждаю стоимость их работ, определяю зп для эмплоис в рамках проекта, вижу абсолютно все расходы и вношу корректировки, вижу все доходы, определяю совместно с Account manager, cost baseline. То есть реально УПРАВЛЯЮ проектом. Как на высоких уровнях, так и на уровне исполнителей. Есть маленькие проекты, 200-300к, где работаешь непосредственно с небольшими командами, 10-30 человек (думаю,это уже ближе к задачам ПМ в Украине в IT). Но права и обязанности у меня те же. Фанкшенал менеджеров (State, National и выше) не интересует, как я выполняю проекты. Их интересует результат и как они могут помочь мне это делать с точки зрения организации процессов ( перевод человека из одного департамента в другой, ведение финансовой документации, корректировки или изменеия условий с нашими national партнерами-поставщиками продуктов и услуг, где есть действующие контракты высокого уровня и т.д.). Утром делаешь отчет (скажем, EVM) по проекту А, в котором задействовано 400-500 человек и бюджет $5млн, а после обеда едешь на объект проекта Б ($10тыс), в котором 10 человек, где надо уточнить, в каком месте вешать вывеску, какого цвета должна быть краска и как должны проходить коммуникации. А еще Джон сегодня приехал на работу( на объект) не в 7 утра, а в 8-30 и все должны были его ждать. И если в проекте А я не знаю даже имен исполнителей ниже 2го уровня, то в проекте Б я знаю, что Робу по пятницам надо дочь забирать из школы и он может работать только до 4:30, Трэвис разводится и у него не очень с концентрацией, а Уильям — аппрентис 2го года и не очень skilled. А скинуть этот проект джуну нельзя — клиент важный (прошлый его проект был на $1.2млн), общение напрямую со стэйт менеджером со стороны клиента, да и джуны все уже в проекте А по самое нихочу.

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

Тогда почему бы PM не разработать систему ответственности? Как часть team building process?

Вот мне и интересны украинские реалии, как осуществляется ПМ, какие процессы, каковы «отраслевые стандарты для ПМ» в Украине в IT. И по чуть-чуть, благодаря ответам, уже появляется общее представление об используемых методологиях, использовании фреймворков, отношении к team building, managing stakeholders engagement, да и об общих обязанностях и объеме необходимых знаний ПМ, чтоб работать ПМ в Украине.

Что за индустрия?
Я так понимаю это Австралия?
У меня последний опыт это Австралия, и я этого не вижу.
В основном semiconductors

Вы любите опенспейс? Почему?

Я прошу прощения не силен в IT жаргоне. Если Вы расшифруете — я возможно отвечу на Ваш вопрос!
В отпусках я был — мне не помогает уже! Мне в общем-то все нравиться, вот только бы с нервами справиться!
У меня были ситуации, в которых я до 2 часов ночи дописывал документ, что-бы на следующее утро его отдать заказчику. Я молчу про 10 часовой рабочий день в течении месяца иногда двух. Я прихожу домой поел, ложусь спать — а мне хочеться встать и доделать работу!!
У меня куча обязанностей и ответственности, но почти нет полномочий — я не могу уволить сотрудников или нанять новых, или урезать зарплату...Вот мне интересно...какое влияние или полномочия имеет РМ в IT для управления проектом и в том числе людьми?

какое влияние или полномочия имеет РМ в IT для управления проектом и в том числе людьми?

Как договоришься. Часто могут быть и такие варианты:

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

У всех бывает.

Я молчу про 10 часовой рабочий день в течении месяца иногда двух.

Это явно перебор, но тоже бывает.

Я прихожу домой поел, ложусь спать — а мне хочеться встать и доделать работу!!

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

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

Вобщем судьба начинающего менеджера.

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

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

Вот мне интересно...какое влияние или полномочия имеет РМ в IT для управления проектом и в том числе людьми?

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

Опенспейс, это что-то типа коровника, чистого, где программистов по головам считают.

А менеджерская работа во всех отраслях одинакова.

Не хватает еще легкого этажа сверху.

Да, потолки не мешало бы сделать ниже. А этаж и так сверху должен быть.
Не выход на летнюю террасу же.

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

Я прошу прощения не силен в IT жаргоне. Если Вы расшифруете — я возможно отвечу на Ваш вопрос!

Openspace:

1. blogs-images.forbes.com/...​11/IMG_2969-1940×1455.jpg
2. www.blogcdn.com/...​edia/2012/04/newsroom.jpg
3. wins.softwareadvice.com/...​es/2013/05/SWA-office.jpg

Это не IT-жаргон, такие помещения могут быть где угодно.

8. НУ еще поесть привозят. Трех разовое притание или двух не помню.
9. Ну кофе, приставка, бильярд, английский, йога или фитнес с тренером — бесплатно, тренажерный зал и все тебе оплачивают. И еще че то я уже даже забыл....

Я собственно чего спрашиваю...!? Я то тоже человек взрослый, и понимаю, что люди везде одинаковые, но у меня есть друг, который мне такие сказки рассказывает, что я и спрашиваю. Вот например.
1. У тебя на руках только один проект. Если ты хочешь больше денег — бери еще, если справишься! Более того у каждого из его команды — тоже только одна задача в работе!
2. Есть, говорит, дедлайн, но никто никого не гонит, заказчик тоже все понимает, что он не человек!!? Заказчик иностранный как правило!
3. Ты не начальник своим подчиненным и впринципе не можешь на них никак повлиять, а только распределить работу, а они уже сами берут задачи из пула задач. Чото я тут засомневался сильно, поскольку не понятно, кто виноват в провале или срыве сроков проекта. Ведь у каждой проблемы должна быть фамилия и имя!
4. Если ты устал, то можешь день не поработать! Тебе оплатят этот день! Это не отпуск! Если у тебя реально нет настроения кодить — пойди в приставку поиграй и не работай, пока вдохновение не придет.
5. Учета времени нет. Сколько ты за компом пробыл тоже нет.
6. Вроде все стараются, и нормально работают. Проекты сдают! Говорит уже штук тридцать сдал. Никого не увольняют. Но на шею не садяться, я думаю, что все таки кого-то в комании они все таки бояться.
7. Пересмотр зарпалты каждые полнгода. Причем реально повышают.
8.У него зарплата 1000 баксов. Говорит, что компания, один из лидеров Украины.

Я уже писал но повторю
1. в разных местах и у разных людей все по-разному. Где-то жесть где-то может быть и жизнь-халява.
2. В ИТ в целом таки да жизнь получше чем не в ИТ. Один вот знакомы советовал всем, когму мог идти работать в ИТ компании, если конечно есть такая возможность. Другой рассказывал, как ушел с зам-директорской работы в «реальном секторе» в тесторы и был доволен жизнью.
3. Менеджерская работа в целом и везде связанна со стрессом и многозадачностью. В ИТ оно может быть и попроще и посложней чем в других местах.

Буває різне. Як на мене ключове -

зарплата 1000 баксов

Тут це мало. Тому може бути спокійніше.
А, і влізти у ПМ-и геть не легко.

Это «срам-мастер», какой-нибудь. С менеджментом ничего общего (и з/п соотвесттвующая).

P.S. А так да, IT в Украине — область приблатнённая. Если сможешь — иди туда.

Еще таитянки в офисе ему массаж чресел 3 раза на день делают.

Не повсюду так. Будь готов что и в ИТ ты можешь попасть в Галеру.

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

Приходит дед лет к сексопатологу. Грит: это, доктор, с девками у меня проблемы, хочу но не могу :( Врач:
— А сколько Вам годков, дедушко?
— 78...
— ну так может отгуляли свое, га?
— почему Вы так грите? вот у меня сосед, ему 85, так к нему молодые девки приходят, он с ними и так, и так...
— а Вы откуда знаете?
— сосед рассказывает...
— ну и Вы рассказывайте!

Увы, да. Постоянно между молотом и наковальней.

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

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

Да. Если это реальная коммерческая компания, а не госбюджетная богодельня.

А об чём собственно, вопрос? Это обычные реалии менеджмента. Кому не нравится — всегда можно уйти в рядовые исполнители (без руководящей функции/ответственности), с соответствующим (существенным) понижением в зарплате и без бонусных плюшек.

Часто у меня на руках по три проекта одновременно бывает!

Бывает и больше))

Постоянные дедлайны!

Конечно, а какой же проект без дедлайнов, хотя для его этапов

Все-таки бизнес...и прибыль здесь главное?!

В общем — да. Ведь, если рассуждать логически, деньги платит не начальник, деньги платит клиент, и чем больше он заплатит — тем лучше.

Да, работа стрессовая и нервная, но пока справлюсь без антидепрессантов (котик не в счет)

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

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

Я работаю практически что называется Project Manager.

Вы любите опенспейс? Почему?

Короче сижу на антидепрессантах почти!

Как это почти? Это как быть почти беременной? Ну тогда ты настоящий менеджер, только они так умеют.

В связи с чем вопрос: в вашей отрасли тоже такая стрессовость присутствует? Тоже такая нервотрепка?

Тоже присутствует, да.

Многопроектность,

бывает

морозятся подчиненные

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

ачальник дает одновременно по два задания и делай как хочешь?

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

Все-таки бизнес...и прибыль здесь главное?!

Конечно да.

Хотя
1. в разных местах оно бывает по-разному.
2. люди приходившие в ИТ из других сфер рассказывали, что тут таки живется заметно по спокойней чем в среднем по экономике.

У меня знакомый из ИТ сбежал. Зам дира в конторе. Что ворота делает, ему там спокойнее работается в сравнении с ИТ.

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