Если человек не в состоянии бегло читать PMBOK на английском — тест на английском он не сдаст. Времени на подумать-перевести просто нет. По своему опыту сдачи могу сказать, что после полутора часов где-то уже начинаешь отвечать на автомате: ты или думаешь категориями PMBOK, имеешь реальный опыт, или нет. Опять же, ИМХО

Сдавать и учить PMP на русском — пустая трата времени. Абсолютно бесполезно. Скоро выйдет PMBOK 6 — вот это будет интересно :) Так что тем, кто думает сдавать, думаю, лучше поторопиться. ИМХО.

Нервы будут всегда. Выгорание... У меня суббота, 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, ну никак не проще. Так что, если есть английский достойного уровня, не будете останавливаться — все у Вас получится!

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

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

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

Да, конечно. Как 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млн), общение напрямую со стэйт менеджером со стороны клиента, да и джуны все уже в проекте А по самое нихочу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внезапно :) 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, то я, мягко говоря, удивлен....