Как стать прожект менеджером?

Ворвались )

Почему это?

этот пункт обязательный

А тому кто руководит людьми просто мастхев быть социализированным.

Во-вторых, социальные навыки и «Подружиться с SPM’ом.» — это как-то независимые понятия.

собственно так и есть...

лично для меня абсолютно ничего не поменялось.

Оттого и рассовая ненависть: Упырь вурдалаку не друг. :)

Расовая. Одна «с».

В пределах статистической погрешности. ;-)

почти так. Не вмешиваются до тих пор пока их вмешательство не нужно.

Какие?

Темплейт, паттерн, синглетон, обжект фектори, юэмэль, класс даяграм, обжект ориентед, итп. :)

не, то не тот уровень. SOA и вокруг как минимум.

Ответ неверный
Работать и нервничать придется больше при той же а то и меньшей зарплате. Пока не станете топом (ЕСЛИ станете — вакансий топов на всех не напасешься). Тогда денег будет таки больше но работы и стресса не убавится.

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

И за «делегированную» работу отвечать придется таки самому. ;)

Коментар порушує правила спільноти і видалений модераторами.

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

или имелось в виду что-то другое?

ага. вон оно чё.

зачем звать? просто сказать что Вася виноват. Васе это знать не обязательно...

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

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

так что, если список найдется — обязательно опубликуйте ;)

Не ищите золотых гор там, где их нет. Менеджер — такая же работа, как и разработчик, со своими плюсами и минусами. Там (о ужас!) тоже нужно вкалывать

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

Жизненно :)

зарплата и наличие свободного времени разве не оправдывает?

Желающие поупиваться властью редко попадают в IT-менеджеры.
Одного желания «поупиваться» маловато.

Тимлид -> ПМ ?! По моему это «слив». ПМу не нужно и трети технических знаний техлида. Нафига тогда было столько лет девелопить?

Есть понятие технический ПМ ;)

ПМ это прежде всего начальник, руководитель (можно сказать ИТ-прораб). Его работа «водить руками» и показывать кому что делать.

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

Это и есть тимлид, ИМХО.

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

Но ИМХО хорошие технари редко становятся хорошими ПМами.

А у нас такие вот есть, я работал лично с ним около 10 месяцев, — куда лучше ПМ-ов описанных выше.

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

А если ПМ без девелоперского бекграунда, то по дефолту факап со заявленным эстимейтом

если ПМ без девелоперов — то да, а иначе ему нужно «просто» уметь слушать и добавлять коррекцию.

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

у нас очень разное видение роли и задач ПМа. С моей точки зрения, чисто абстрактный ПМ вообще не должен участвовать в технических обсуждениях, или быть requirements analyst. Разве что в роли фасилитатора сводить людей у которых есть возможности это обсуждать и потом follow-upить. То же что Вы пишете — не является в чистом виде ролью PM.

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

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

думаю если архитектор не знает в какой пропорции нужно цемент с песком мешать, то это Senior System Architect разве что

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

ПМ — это никак не прораб. Прораб — это тех лид скорее. Перед использованием аналогий рекомендуется научиться их использовать :)

впрочем, тут может быть путаница в терминологии.

Приведу еще один, знакомый всем пример. Может ли клиент, без технически-девелоперского бекграунда быть клиентом и заказывать разработку софта? Конечно, может. Только опыт говорит, что команде разработчиков намного кофмортнее и эффективнее вести дела с клиентом, который мало-мальски подкован в разработке софта, а не у которого «Там же всего одну кнопочку нужно добавить, почему неделя?».

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

в творческих коллективах, как правило, да.

C этим я согласен, а в ай-ти? :)

толсто

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

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

Сделать процесс контролируемым для кого? Что в этот момент делает техлид?

В общем, главное — адекватность и соображалка работающая.

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

Может для этого хватит опыта сравнения различных эстимейтов? Или технически подкованный пээм не просит эстимейты, во всем сам разбирается и с камандой по этому поводу не общается?

подкованный пээм может общаться с девелоперами на понятном им языке, а не на языке товарищей отсюда: clientsfromhell.ru

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

Врут, не слушайте их.

Java Developer->Senior Java Developer ->PM

В какой-то момент понял что кодить «это не мое»

Как по мне то легче...в смысле программистом быть легче. Но как уже говорил, понял не мое это.

то есть быть эникейщиком — это «твое»? не думаю, что это было бы сложно.

абсолютно(!) не понимаете. Но доказывать не буду

Кстати тут рядом коллега есть «23 года».....девушка . Красива, умна, и как ПМ сильна.

даешь статистику: столько-то красивых РМ, столько-то не очень красивых не-РМов... делим первое на сумму первого со вторым и доказываем «черезпостельность»!

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

исследований с такой постановкой вопроса не встречал :)

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

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

Потому карьера через постель суть есть нонсенс.

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

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

а у нас так 100%

100 не 100, но у нас больше чем на западе

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

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

крутой вброс!

ну наконец то HRов оставили в покое и перешли пинать других «бесполезных» работников :)

до ближайшего вброса

P.S. ПМов не считаю бесполезными.

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

тесты — девелопер, верстка — дизайнер.

А еще предлагаю убрать такое понятие как фронт-енд девелопер, пусть фронтами бекэндеры занимаются!

а самый упитанный будет готовить печеньки )))

так мы придем к рецепту абсолютно успешной компании!

Я не учу его жизни. Я говорю что надо что-то делать, а не три года задавать вопросы на ДОУ, метаясь в технологиях.
Если бы он проработал 1-2-3 года в разных командах с разными ПМ-ами то сам прекрасно бы знал что надо для того чтобы занимать позицию ПМ-а. Более того, он бы знал уже надо ему это или нет! Так как на этот вопрос тоже еще нет ответа у ТС-а.
Это моё ИМХО. Я не настаиваю на своей точке зрения как единственно верной и не склоняю ТС-а к ней прислушиваться, если он с ней не согласен.