А судя по вашей осведомленности, работа РМ вам в Штатах точно не светит в ближайшие 5 лет, поскольку без РМР, по моему мнению, ловить вообще нечего ни там, ни тут.
А почему именно 5, а не 10 или 3?
PMP хорош, но как показывает опыт, его не всегда спрашивают, счас больше спрос именно на профильных спецов - если в телеком, то будут гонять по телеком-опыту, если разработка, то принципы и процессы разработки.
Более того скажу вам по секрету, я несколько лет заведовал развитием проектной методологии в очень крупной международной IT компании, без всяких там PMP.:yahoo:
Опыт участия в качестве руководителя проекта или аналитика не менее 36 месяцев
И реальный опыт участия в проектах, без него вам экзамен не сдать.
Да вы шо гаварите, а пацаны то не знали У мня опыта как и PDU на несколько сертификатов :russian:
Ибо, если вы не в курсе то для допуска к экзамену надо:
Минимум 35 PDU
Ну поковырявшись в своих сертификатах…их там у меня это…на пару PMP точно будет :strong: Более проблематично набрать 60PDU для продления, но ничего пацаны знают где их купить:dirol:.
Как показывает анализ социальной активности: обилие смайликов в ваших постах и использование сленгового лексикона говорит о том, что вам не более 25 лет.
Я очень сильно сомневаюсь что вы выдающийся проджект менеджер, поскольку вопросы вы задаете на уровне человека, однажды листавшего PMBOK Guide.
Бесплатный совет: Измените манеру общения, так не разговаривают проджект менеджеры, так разговаривает гопота.
Если не трудно, скиньте ваш профиль PMI Member мне в ЛС. Хочу воочию убедиться в ваших достижениях и количества PDU.
Ну тут все смайлики любят, независимо от пола, возраста и соц. положения
Я очень сильно сомневаюсь что вы выдающийся проджект менеджер, поскольку вопросы вы задаете на уровне человека, однажды листавшего PMBOOK Guide.
Какие вопросы? Я где то задавал вопросы по теме проджект менеджмент? Ссылочку пожалуйста.
Бесплатный совет: Измените манеру общения, так не разговаривают проджект менеджеры, так разговаривает гопота.
А вам бесплатный совет - будьте проще, и люди к вам потянуться, в Штатах люди любят больше общение а не понты и “мерение пиписьками” (ну если только в каких нибудь черных кварталах Бронкса или Детройте )
Спасибо за совет, воспользуюсь.
Прочтите первое сообщение в данной теме.
Ответ на ваш вопрос:
Проведите анализ вакансий и требования к ним
Составьте план который бы отвечал на вопросы не только “что делаем?” но и “как делаем?” “сколько это стоит?”
Потом задавайте вопрос, не что светит проджекту в Штататх ( я бы ответил, что и всем: Солнце), а чего мне не хватает для того, что бы устроиться.
Для работы проджектом, мне ответили и я делюсь с вами выводами, необходим прежде всего отличный английский не Upper и не Advance а Fluent (Native). Ну и умение им пользоваться .
Для работы проджектом, мне ответили и я делюсь с вами выводами, необходим прежде всего отличный английский
Спасибо капитан Кэп
Кстати, если хотите могу вам задать тестовый вопрос для собеседования которому меня научили американские коллеги из области IT project management. В России 90% PM’ов заваливаются на нем :dirol:
И этот вопрос (точнее кейс с вопросом) не из области какого там эфемерного PMP, а четко по IT Software Engineering и показывает уровень знаний и опыта PM’а
Вопрос простой как “сибирский валенок”:
Интерпритируйте фразу (напишите, что она означает):
“Процент готовности функционала в части разработки (кодирования) некого функционального модуля (например - модуля авторизации, хотя это не принципиально) - равен - 60%, при том что кодирование оценено изначально на 200 человеко-часов (других оценок нет).”
Честно признаюсь, прочитал вопрос три раза. Почемуто возникли ассоциации с вопросом из книги «The Hitchhiker’s Guide to the Galaxy»: Главный вопрос вселенной о жизни и вообще… Ответ на него был 42 (Если изучали PMP. то будет понятно почему)
Теперь ответ на вопрос: Как я понял его в вашей интерпритации: Процент готовности модуля закончен на 60%, при этом на создание модуля заложено 200 ч\часов, других данных нет.
Данная фраза означает следующее: До завершения фазы кодирования осталось 80 ч\часов. Это единственное, что мне пришло в голову.
Теперь мне хотелось услышать вашу интерпретацию, то есть правильный ответ.
Коллеги, не стесняемся, пишем свои мысли. Даже если вы не PM, а всего лишь программист или QA, но мечтаете о PM’стве, то это ваш шанс проверить свои знания в Software Engineering management
Для завершения модуля потребуется еще как минимум 133 человеко-часов, с точки зрения арифметики (ну а если учесть, что обычно оценку человеко-часов нужно умножать на значение числа пи , то … )
В PMы не собираюсь, но жизненный опыт подсказывает, что 30% - займут 120 чч, а оставшиеся 10% будут завершены тогда, когда будут пофикшены критические баги.
Тут все зависит от работы команды. По своему опыту могу согласиться. Был у меня один проект, который задержали на 3 месяца, по причине того что ПМ-Архитектор настоял на разработке собственного ORM и первый этап разработки закончился тогда, когда должен был закончится второй. Проект перешел мне по наследству. Пришлось сократить часть функционала и опоздали мы на 3 месяца. Пришлось сдавать без тестирования. Но система (Система Документооборота) работает до сих пор и заказчик доволен. Больше этот ПМ к руководству не допускался изанялся своей прямой обязанностью программированием. Как программист он отличный.
О сколько ответов…и …и не одного верного, принцип 90% работает на все 100%.
Даю подсказку: “Процент готовности функционалав части разработки (кодирования)” :dirol:
Ладно не буду вас мучить, в общем ответ на данный кейс таков – данная фраза вообще не имеет смысла. Вы удивлены? Обескуражены? А давайте посмотрим внимательней, на первую часть: «Процент готовности функционала», в чем измеряется объем функционала на стадии кодирования, в человеко-часах, отнюдь нет. В человке-часах измеряется объем трудозатрат, а объем функционала измеряется в SLOC или по русски - строчки кода. Source lines of code - Wikipedia, the free encyclopedia
Ну или накрайняк можем измерить в «функциональных точках», но мы ведь написали что «других оценок нет». Поэтому если при оценке процесса кодирования, размер трудозатрат взятый из «опыта программистов», а не посчитаный например с помощью COCOMO II, в дальнейшем то и мерять завершения работ по кодированию в процентах абсолютно бессмысленно. Мы можем потратить 90% трудозатрат из 100% сделав только 10% из запалнированного объема SLOC!
Кстати именно поэтому Метод освоенного объема из PMBoK не применим в Software Engineering (ну или очень ограниченно применим). :dirol:
Так что вот такой вот кейс с подвохом, ясно и четко показывающий знания PM в области программной инженирии и управления проектами.
Хороший вопрос. А термин KIS вам знаком? Kit It Simple… У нас трудозатраты не измеряют в строчках кода. Программист может написать 200 строчек кода, но они будут не работоспособны, а хороший программист решит задачу в 100 строчек кода и он будет работать. Поставлена задача и определен срок, а сколько строчек кода напишет программер это не важно. Обычно промежуточные результаты не оценивают так, для этого есть итерации.
По вашему ответу (правильному) можно сказать, что готовность стены дома (трудозатраты) оценивается в количестве кирпичей, которые уложил каменьщик, и это будет применимо на 100%. Потому что это можно посчитать и это промежуточный результат.
Видите и никакой Софтвер Инженеринг
Ответный вопрос: Чем отличается функция от метода?
Поставлена задача и определен срок, а сколько строчек кода напишет программер это не важно.
Нет важно, потому что:
В зависимости от технологии и языка количество строк имеет определенные пределы. Посему некоторые системы пишутся именно на определенных технологиях и языках, например никто не будет писать интернет-магазин на C++ или на делфи (хотя теоритически это возможно).
Слишком большое количество строк может привести к проблемам с производительностью, а слишком малое (если в угоду краткости принесена в жертву- оптимизация кода) проблемы с интегрируемостью и развитием.
Совершенно согласен,“Америку вы тут не открыли”
Но честно сказать, только идиот будет считать строчки кода. Я конечно понимаю, что если делать шаблонные однотипные приложения (сайты например) то трудозатраты можно определить по строчкам кода
Но когда все создается с нуля или создается SDK, то тут посчитать не возможно в принципе…
