ПМ. Как ими становятся?

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

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

Немного о себе:

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

Так вот, хотелось бы услышать ответы на такие вопросы

1. Каков самый типичный алгоритм становления ПМом в нашей стране ?

2. я заканчиваю вуз, мне 23. по проектному менеджменту в голове у меня хорошо усвоеный вузовский курс + к примеру 2-3 года самообучения нужными книгами. Есть ли у меня возможность устроится ПМом сразу (не обязательно с командой в 100 чел, и стоимостью проекта в сотни тыс. $), без опыта работы, минуя программистские должности?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Не советую идти в ПМы. Лучше в программисты. Разницы по ЗП практические нет. А вот рынок для поиска работы больше.

Обычно профессию и род занятий не только исходя из ЗП выбирают.
Но, если мыслить только мерками «ЗП», то лучше всего идти в депутаты, наркодилеры, торговцы оружием, киллеры,... И упомянутые вами «рынок» на порядков на 10 выше!

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

Ого, камент через 5 лет! ТС наверное уже выпустился и работает вовсю. Интересно, к чему он пришел? )

Собственно, судя по Линкдину, он работает iOS девом.

Технический опыт скорее -, чем плюс.
Крайне оригинально такое читать, особенно от РМ-а.
пм должен вести коммуникацию с заказчиком и всячески ограждать команду от поползновений в ней поковыряться, а не сам ковыряться там.
Список задач ПМ-а несколько шире, а для того чтобы понимать проблемы членов команды и их «боль», необходимо обладать техническим опытом, желательно каждой из ролей, хоть на каком-то уровне.

ПМ без профильного образования и дев-опыта считает, что это скорее минус. Сюрприз-сюрприз.

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

Вас сильно удивит министр транспорта который не был машинистом или водителем автобуса?

Я управленец на западе, если что.

На западе управленец это управленец, разработки это разраб.
Чушь какая. Это относиться разве, что к топ-менеджменту. И то не всегда.
технический бэк появился как побочка от того, что не было управленцев физически для Айти сферы, зато были кьюа, джуны, мидлы и тд, с них и ковали кадры. На западе управленец это управленец, разработки это разраб.
Я смотрю Вы разбираетесь в «глубинах глубин»! :D Вот что странно, в компании, где я работаю (с НЕукраинским менеджментом), как и во всех компаниях где работал 10+ лет, все МЕНЕДЖЕРЫ — бывшие инженеры, большинство — разработчики. Они просто «не шарят», с тобой не общались, вот и не в курсе, кто нужен в управленцы! :D
Вас сильно удивит министр транспорта который не был машинистом или водителем автобуса?
Это имеет отношение в IT? Ок. Вы когда «употребляете», хотя бы пишите что именно...

Странная у Вас манера общения, я выразил своё мнение, основанное на мыслях тех разработчиков, с которыми работал, но в ответ на него услышал «гневный глас истины». Не могу похвастаться опытом в 10+ лет работы в сфере ИТ, но за то время, что там работаю, я не чувствовал особой потребности быть в прошлом разработчиком для выполнения своей работы. Я не ходил в ваших сапогах и не могу смотреть на мир с вашей колокольни, чего не можете и вы в отношении меня.Каждая компания имеет свои представления об обязанностях и функциях пм, исходя из этого и требования разные.
Вы пример своей команды экстраполируете на всю индустрию, представляя это истиной для всех, а это ведь не так.
Что употребляю не скажу — дразниться нехорошо=)

Да я вообще странный по сравнению с Вами. Не берите в голову.

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

Я теперь понимаю почему на каждую позицию РМ-а под 60 соискателей. Видимо, 95% из «вашей песочницы»...

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

Себе и, наверное, команде с которой работает. Или проблема разраба это исключительно его проблема?

Может да, а может и нет. Как договорятся. Вам он — ничего не должен, а вы уже его впрягли в обязы. Предполагать, что есть некая «правильная» система разделения работ, которой все люди должны следовать, еще и построенная на тайтлах — наивно для практикующего менеджера и преступно для аджайл-практика. People over process, yo.

Я счастливчик, со мной работает лид, который без просьбы сам проявит инициативу и поможет, если у кого ступор, так что это скорее не правило и навязывание обязанностей, а хорошая и полезная практика.
Звания и лычки присутствуют везде, в той или иной мере, в скраме роли, в любом коллективе есть лидеры и тд.
Help devteam take responsibility, give them the environment and support they need, and trust them to get the job done.

Удивительно, как один и тот же человек пишет «менеджер должен, тимлид должен», и тут же — «help take responsibility and trust them»...

а что свобода выбора путей решения задачи отменяет обязательства?

Просто надо определиться: или крест снять или трусы надеть.

технический опыт скорее -, чем плюс.
ПМ должен знать основы програмирования, специфику каждой должности кто входит в команду
Мило.
но ни при каких не лезть в процесс — это уже выпадение в микроменеджмент
«РМ, который не лезет в ПРОЦЕСС» — Ок. Я даже спорить не буду с Вами и продолжать общение дальше (сколько человек на вашем аккаунте? Или как отвертеться не знаете?!), — всего хорошего :)

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

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

Я здесь прочитал разные мнения и я задавался таким же вопросом: нужен ли программистский бэкграунд или нет. И побывав на 10 собеседованиях на вакансию PM в аутсорсинговых компаниях я услышал примерно 7 ответов «за» необходимость программистского бэкграунда и 3 — «нет». Без опыта вообще могут взять на PM только при наличии хорошего английского. Начинайте с того, что вам ближе, с PM. Не нужно делать «левых» вещей.

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

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

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

3. Компетенция проектного управления (необязательно в программировании) для понимания процессов, которые необходимо в той или иной степени применять в проектах .

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

Без опыта работы и минуя ИСПОЛНИТЕЛЬНЫЕ (не только программистские) должности малореально, да и не к чему такая спешка.

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

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

главное, не стань иди отом (ДОУ не любит слова иди от)?. и еще универ можешь пропустить. он бессмысленнен.

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

Сорі, не впримався, згадав шутку на тему менеджменту.

Якщо 1 жінка родить 1 дитину в 9 місяців то багато менеджерів вважають, що 9 жінок зможуть народиту ту саму дитину за 1 місяць :)

А еще — про статистику (препадша по статистике рассказывала: ) один алкоголик выпил стакан водки, другой — томатного сока. По статистике, оба выпили стакан «Кровавой Мери». Один сьел две курицы, второй — ни одной. По статистике, каждый сьел по одной курице. Отсюда вывод: есть ложь, есть наглая ложь, а есть — статистика :)

Вот поэтому в статистике чаще применяют медиану а не мат ожидание.

формулировка не верна. но суть похожа.

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

Есть ли у меня возможность устроится ПМом сразу (не обязательно с командой в 100 чел, и стоимостью проекта в сотни тыс. $), без опыта работы, минуя программистские должности?

Тобі буде бракувати розумінння процесів. Хоча успішному менеджеру посуті побарабану чим управляти.

Хоча успішному менеджеру посуті побарабану чим управляти.

не удержусь — напомнило

soapthriller.ru/...o-menedjera.jpg

если есть хорошее знание английского можешь слать свое резюме в Харьковский Геймлофт уже сейчас.

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

по ощущениям, работать с теми ПМ кто хоть что-то понимает в программировании намного приятнее. мнение ПМов аналогичное.

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

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

это самые «невинные» вопросы с которыми столкнется ПМ. и как на них ответит выпускник ВУЗа без менеджерского опыт и без идеального знания технических деталей? да никак.

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

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

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

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

Обратите внимание — Fake Dev говорит о смешивании ролей. Да, в маленькой команде из 3-4 человек один и тот же человек может выполнять роли как ПМа, так и dev manager’а. В команде из 6-7 человек (а это вполне реалистичный размер команды) я бы раздал эти роли разным людям, совместив, например, dev manager’а с архитектором, а ПМа — с бизнес-аналитиком.

В руководстве по Microsoft Solutions Framework, помнится, была даже табличка, указывающая, какие роли совмещать можно, а какие — лучше не надо.

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

Но при этом стоит помнить про Билла, который таки да :)

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

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

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

PS: это ответ Fake Dev

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

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

убедил?

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

Вот вы говорите что БЕЗ опыта в програмировании ему никуда, он не сможет менеджить програмистов, хорошо тогда как он с таким опытом будет менеджить БА? тестировщиков? ХРов? вседь при работе над проетом взаимодествуют все, кто-то найм, кто-то пишет, кто-то проверят, кто-то собирает.... или как ПМ с опытом БА будет управлять девами, тестами? почему если есть опыт БА то опыт дева, теста уже не нужен? почему если есть опыт дева, то опыт БА, теста не нужен, итд.....

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

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

а почему не технический директор к примеру?

в идеале, тех дир подбирает ПМов, а ПМы подбирают исполнителей, разве нет?

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

еще, полностью согласен с комментом на эту тему www.developers.org.ua/...ic/4285/#128671

Я уже написал, почему для того что бы понять как работает процесс расзработки нужно тратить годы на построение карьеры програмиста/QA/БА, или как на старте этой самой карьеры ковыряние в багах приблизит вас к понимаю, планированию, управлению? можете это обьяснить... ПМ подбирает людей с которым ему комфортно работать, или вы считаете что ПМ должен быть достаточным гуру что бы технически прособеседовать девелопера, технически прособеседовать теста, и аналитически аналитика, граматически и стилистически тех писателя итд...? неужели для этого нет специалистов в компании? задача ПМа определить набор людей которых он может сорганизовать работать вместе, а не определить кто знает мат.часть а кто нет.

Я не сравнивал Глав. врач против врача, я сравнил глав врача против професионала в области — хирурга, кардиолога, итд....

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

в Украине ПМ это глав врач то есть человек который и не много врачует и за хозяйством следит, то есть совмещеная позиция с Дев-менеджментом

в Украине ПМ это глав врач то есть человек который и не много врачует и за хозяйством следит, то есть совмещеная позиция с Дев-менеджментом

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

как по мне, то сравнивать глав врача и ПМ некорректно, потомучто:
1. главврач — управленец среднего или высшего уровня (не уверен точно, но скорее среднего), а ПМ — низового

2. гав врач в своей работе применяет что-то из «советской школы управления», ПМ — применяет (должен) менеджмент.

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

Можно, конечно, стать архитектором, без опыта работы на стройке, а сразу идти в архитектурный универ (хотя, точно знаю, что на кафедре ПГС проходят практику на стройке: ). А проработав всю жизнь на стройке, архитектором не станешь. В этом же и отличается тактическая работа, от стратегической. Только, в некоторых областях можно стать хорошим стратегом, имея богатый опыт тактической работы, а в некоторых — нет. Так что все грести под одну гребенку — немного неверно, ИМХО

сравнение ПМа с зав отделением подходит больше, имхо

три функции управления — это планирование, анализ и контроль

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

Ну, когда я учился — в менеджменте было три функции управления :) Даже был такой билет — «Три функции управления» :) Глянул в Вики — там их уже больше. А мотивация... А нах она нужна в классической теории управления? Ведь глагол to Manage — он был сформирован от 2 слов: man и edge изначально (потом второе слово трансформировалось), что означало синтез слов ЧЕЛОВЕК и ГРАНИЦА, т.е. управление на грани возможного исполнителем (по-максимуму, все соки выжать). И безо всякой мотивации :)

а анализ куда делся? Без анализа не будет обратной связи, соответственно, не будет эффективной управленческой модели.

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

обратная связь осуществляется функцией контроля (своевременное выявление отклонений от плана и разработка мероприятий для минимизации последствий)

так в том-то и дело, что «управление» и «менеджмент» — два абсолютно разных понятия

Да ну? Менеджмент — это и есть управление, только звучит не по-русски, функции — те же самые :) Менеджер — это управляющий. вот, не глядя, с гуглА:
bibliotekar.ru/...iznes-38/41.htm
Вводный курс по экономической теории
«Слово „management“ буквально переводится как управление, заведование, организация»

В чем отличие?

ИТ — очень сложная среда для менеджмента (намного сложнее производства например)

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

обратная связь осуществляется функцией контроля

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

по поводу менеджмент/управление — тут трудности перевода , я, наверное, не так выразился. моя мысль, в том, что не каждый руководитель является менеджером. командир армейского подразделения — руководитель, но не менеджер. глав врач — то же. корни этого еще в примерно 30-х годах советской реальности, когда после великой депрессии подходы к управлению на западе шагнули далеко вперед и зародился менеджмент в современном виде, в то же время в советском союзе менеджмент был вне закона. и, так получилось, что сами принципы менеджмента и советского управления стали очень сильно отличаться, вот в чем эти понятия разные. tourlib.net/...en/meskon02.htm

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

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

Мне кажется, вы немного идеализируете, отделяя управление и народное хозяйство, от менеджмента и IT :) Я лично не вижу разницу в словах УПРАВЛЕНИЕ и МЕНЕДЖМЕНТ, окромя произношения. Либо вы вкладываете в эти слова разницу в свободе принимать решения. Есть оперативное управление, и есть — стратегическое (как и менеджмент). Разница — в полномочиях, скажем так, исходя из вашего примера про командира. Командир — это линейный менеджер среднего / нижнего звена, который вправе принимать самостоятельные решения, но только согласно устава (он же не будет звонит генералу за инструкциями что делать, если, скажем, нарушитель пересек границу). Офис-менеджер — это тоже менеджер, и который не будет же советоваться по каждому пустяку с начальством, типа какую покупать туалетную бумагу, который самостоятельно принимает решение, но которому делегировали для этого очень небольшую часть полномочий. Так что, ИМХО, все мы являемся в той или иной степени управленцами, вопрос в объеме делегированных полномочий ИМХО. Ну а как же в идеале, без волосатой руки, люди идут наверх? Благодаря способности самостоятельно и правильно принимать решения: сегодня тебе делегировали ограниченную часть полномочий — ты задачу выполнил, далее, тебе могут делегировать еще больше. И так далее. А если командир части по каждой мелочи будет генерала задалбывать — может и вопрос у генерала возникнуть — а нафиг мне такой командир несамостоятельный и глупый нужен. Каждый начальник является подчиненным (генерал и то, подчиняется маршаллу рода войск, тот в свою очередь — главнокомандующему, и им все равно, чем будут мыть в казарме туалеты — эти полномочия делегированы командиру части, в пределах сметы, который, в свою очередь, делегирует этот ответственный процесс духам), и наоборот, это целое искусство быть в иерархии управления. Но это, конечно, в идеале, но мысль свою я постарался донести.

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

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

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

Образование ничто, главное самообразование. Учиться, учиться и еще раз.

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

У нас мало крупных проектов, поэтому мало должностей типа PM Assistant, Project Administrator и т.д., которые хороши как для старта. Насчет того, что ПМом можно стать только через программиста — ерунда. ИМХО лучшие ПМы получаются как раз из тех, кто сам программировать и не умеет ;) Это, однако, не отменяет необходимости понимания процесса в целом, а для этого, конечно, нужно в нем «повариться».

Но в Аксапте, например, функционал знать ПМу не помешает)

Кстати, ПМ-ом может и трудно стать в 23, хотя возможно вполне. Но зато, как выяснилось на этом сайте, в 23 легко стать Синьором! Конечно, рынок перегрет и все такое, и это все навернется и т.д. но сейчас то не вопрос! И коль уж путь в ПиЭмы в наших условиях лежит через синьорство (хотя мне кажется это не совсем правильным), может это и есть путь?!

Не иди в ПМы, нервов оно жрет кучу, зп не окупает. -)

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

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

в смысле? зарплаты ПМ и SE/SSE вполне себе сравнимы. хороший программер действительно часто получает больше чем «обычный» ПМ. В правильной конторе.

www.glassdoor.com/...ries-E40772.htm

хороший программер действительно часто получает больше чем «обычный» ПМ.

А если сравнивать «хорошего» с «хорошим», а «обычного» с «обычным».

www.glassdoor.com/...ries-E40772.htm

При том что рамки у синьора ниже чем у ПдМ, среднее больше, но это в одной конторе (фейсбуке) и всего 4 человека и там и там.

Кстати, на глассдоре бонусы учитывают? Мне кажется, что нет, хотя я и не знаю.

На загнивающем Западе это вполне обычная ситуация.

То, что тут полно ПМ-ов — бывших программистов, совсем не означает, что надо повторять их путь. Он совсем не оптимальный, очень не оптимальный.

Я бы советовал сразу идти в ПМы хоть тушкой хоть чучелом, если именно это нравится. Обязательно будут трудности с «сеньорами», лучше сразу готовиться. Довелось побывать на Peopleware с Эдом Йордоном, спросил об этой проблеме — молодой менеджер vs. сениор около 40. Тот честно сказал — «не знаю, как это разруливать, по разному может быть». (кстати, его Deathmatch — must read).

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

Ну кто знает — может молодой талант.

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

Несправедливо и нечестно, но такова селяви.

:) Вот Вам еще более интересный case.
Во время войны эвакуированные заводы разворачивались прямо в поле, и персонал для них набирали отнють не по объявлениям в газету.
Была такая практика (по крайней мере — в некоторых случаях): просто развешивали таблички с должностями «слесарь 4-го разряда», «инженер-технолог», «снабженец» и каждый кто приходил на завод — просто подходил к табличке и забирал с собой, нес ее в отдел кадров и там оформлялся без проверок и разговоров. В 41 году каждый день простоя был катастрофой, запускать производство нужно было любой ценой и в кратчайшие сроки.
А затем жизнь в течении пары недель, максимум месяца показывала — достоен ли человек той таблички, которую он принес в отдел кадров. Догадайся с трех раз что было в последствии с теми, кто выбрал табличку исходя из голых амбиций и надежды на «а вдруг прокатит» ;-)

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

такая ситуация была да 2008, до кризиса. сейчас снова подъём и гребут всех подряд. но потом снова кризис — и всех расставит по местам.

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

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

Прилипнет характеристика «пустышки с замашками большого начальника» — кто потом возьмет? Даже на обычную должность.

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

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

Впрочем, сколько людей, столько мнений. Жизнь — она вся такая разная, у каждого свой путь в старость :)

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

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

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

А детали не расскажешь? Ну, хотя-бы в общих чертах.

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

Игорь, берут ведь...

«пустышки с замашками большого начальника»

могут сделать виноватыми кого угодно и самим остаться белыми и пушистыми.
Критерии и требования к ПМ в IT... IMHO падают катастрофически... И этот тезис о том что ПМ не должен разбираться в деталях... Забывают что это нижнее звено менеджмента и по «сроку службы» не положено ещё в абстрактных облаках (ROE, EBIDTA etc) витать. Надо быть лидером. Каким лидером может быть «ПМ» для синьйоров с многолетним опытом, которые к тому же старше его и зачастую имеющие опыт в управлении? Только формальным, опираясь на огромный кредит доверия вышестоящего начальства. Кто может получить такой кредит???

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

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

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

Я бы не взял. Две причины:

1) Нет опыта в области, ни как ПМ, ни как программистом. Теория без практики ничего не стоит.

2) Если вы задаете такие вопросы — значит вы не готовы.

А давно это ты нанимаешь ПМов? ))

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

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

Во втором сначала уволились программисты, потом уволили PM и стали набирать новых программистов.

ИМХО не будет.

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

Нет ничего практичнее хорошей теории © Не помню
Главное чтобы зерна знаний падали в плодородную почву практики

Образование будет скорее минусом. К сожалению, в ХПИ управлению проектами учат люди, никогда не работавшие «в поле», а в жизни всё несколько не так, как в учебниках. И тем более управление проектами в IT отличается от «управления проектами вообще», которому обычно учат...

Как стать директором, не имея опыта работы директором? Очень просто. Открыть свою фирму. Для ПМ придумать и свой проект, нанять людей и руководить ими. Сможете? Если да, то хорошо. Но маловероятно.
То что хотите Вы, это чтобы Вам дядя с деньгами доверил руководить командой людей, которые просырают 10к+/- долларов за неделю работы. Найдёте такого? Сомневаюсь.
Поэтому ответа на ваш вопрос не последует, пока у вас не будет хотя бы какого-либо опыта приближенного к отрасли. будь то тех. писатель или программист. Не говоря уже о том, что нужно обладать действительно впечатляющим набором различных личностных и професиональных качеств, для этой должности.

Бывают ли ПМ в 23 года? Бывают. Но не после университета, а после n-лет опыта.

Но не после университета

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

невірю що книжка може замінити стаж живих проектів

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

Ключевое слово -

стал выглядеть
Можно -ли устроиться ПМ-мом без работы программистом?
Я-бы не взял.
Как, наверное, и 90% моих коллег.
Со своими теоретическими знаниями Вы, извините за прямоту — ноль, и скорее принесете вред команде и компании, чем пользу. К тому-же работа ПМ во многом завязана на личный опыт и знание людей, а они, как ни банально, приходят с возрастом. Никто не говорит, что надо ждать до 30, но сразу после института человек «сыроват» для управленческой должности, в этом возрасте и некоторым программерам голову рвет, когда они на сеньёрские должности попадают :) Рисковать проектом и командой — я бы не стал, да и никто не стал-бы. Мне гораздо проще и вернее вырастить ПМ-а из своих провереных сотрудников, имеющие соответствующие задатки.

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

1 Поработайте кем-нибудь (не ПМ). Годика три минимум.
2 научитесь хорошему английскому
3 Научитесь понимать и ценить людей
4 Научитесь говорить «нет»
5 Научитесь не подавать вида, даже если все плохо
6 Много и активно читайте
7 Научитесь грамотно общаться, излагать свои мысли, делать презентации
8 Смените пару-тройку работ, расширьте кругозор

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

И будет вам счастье :)
И напоследок — небольшой хинт по рынку труда на сегодня.

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

Присоединяюсь по всем пунктам :)

Потому девелоперы всё реже и реже продвигаются в ПМ. В качестве причин отказа их начинают троллить за отсутствие «human skills» и знаний в области управления. На самом же деле —

найти толкового программиста — проблема. И не потому что их нет, а потому, что уже все трудоустроены :)

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

А в вузе дипломные/курсовые есть возможность делать пачкой программистов ?
У меня такого небыло, но гдето я о таком читал.
Или можно например просто любительский проджект... гамес например какой.
Берите эту пачку и пытайтесь скоординировать =)

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

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

+1

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

Есть ли у меня возможность устроится ПМом сразу (не обязательно с командой в 100 чел, и стоимостью проекта в сотни тыс. $), без опыта работы, минуя программистские должности?

джуниор ПМ однако :) если задумаешся, сам поймеш почему не выйдет. Подобный вариант возможен только для держслужбовців в случае когда у “джуниора” мама/папа “синиор пм”

Не только у

держслужбовців

, в бодишопах тоже это не редкость

По 1: есть схема, ссылку уже давали.

По 2: да, легко. Мелкая конторка какая-то, мелкий проект (3-4 человека),1-1.5 года сидите там, потом идете в более крупную компанию на должность что-то типа «младшего помощника главного помощника ПМ-а». Через 3 года становитесь каким-то там Junior PM-ом в этой конторе, ну и еще через пару лет полноценным PM-ом. Ну это при всем при том что ты будешь очень гениальный и все будет получаться :)

1. Вырасти или путем перехода из одной команды в другую.

2. Есть. Теоретически все возможно. Да и в жизни всякое бывает. А Вы готовы к этой ответственности?

Сейчас Вы упустили то, о чем не пишут в книгах и не упоминают на лекциях: опыт работы как таковой. Это именно общение с начальством и сотрудниками, это нестандарнтые ситуации, это корпоративы, переработки, приятные и не приятые рабочие моменты, это много всего, чего не раскажет никто, это, что нужно узнавать самому. Это раз.
То, что у Вас будет хорошо усвоеный вузовский курс + к примеру 2-3 года самообучения нужными книгами это замечательно, но в реале не работают по книгам. А поянть где можно применить книгу, а где это будет во вред поможет опыт работы. Это два.

Хотите закончить институт и найти работы ПМом? Ставьте такую цель и работйте помимо учебы на 3, 4, 5 курсе.

Кафедра стратегического управления? 7этаж У2?

Я ее закончил, например.

Что могу сказать по существу.

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

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

3. Отсюда же и традиция «шарящего в коде» менеджера. Менеджер, который в прошлом программист, конечно, имеет преимущество, для него это не абстрактные работы, он хорошо понимает суть программирования. Но очень быстро выясняется, что «программистские» идеалы работы очень плохо подходят для менеджерской позиции, приходится менять мировоззрение. Я в прошлом программист, у меня свой путь к признанию командой. Я могу посоветовать, обсудить, участвовать в тех. процессе. У менеджеров без такого бекграунда (их тоже много, и хороших) — другой путь к завоеванию авторитета. Сделать так, чтобы у команды и у ПМ была в самом деле одна цель — большой талант ПМа.
Дело в том, что у ПМ работа — вовсе не управлять людьми, так же, как у пианиста работа — не жать на клавиши рояля. ПМ — это мастер GTD, getting things done. Сделать так, чтобы все получилось. Как? Как умеешь, как сможешь. Нет одного верного способа. Первый шаг — взять на себя эту ответственность и не облажаться. И вот с ответственностью приходят и полномочия. Сильно зависит от компании, и стиля (топ-)менеджмента, принятого в ней. Разница в разных компаниях и правда огромна. Постарайтесь увидеть разных менеджеров.

4. Возраст имеет значение. Потому что ответственность и оценка последствий развиваются в человеке довольно поздно — ничего не поделаешь, физиология, бессердечная ты сволочь. Быть ответственным и надженым менеджером в 23 гораздо тяжелее, чем талантливым программистом. Скажем прямо — практически нереально. По многим причинам. Возраст и опыт дают много к главным скиллам менеджера — ответственности. Риски на менеджерской позиции велики, куда выше, чем на девелоперской. Менеджеру будет ОЧЕНЬ трудно работать без авторитета в команде, это колоссальное психологическое давление — когда твоя команда вся старше тебя. Тем более, если менеджер — не программист, и команда не говорит с ним как со своим, а то и презирает за глаза. Для них находиться под управлением «юнца» — тоже испытание не из легких. Это великолепная почва для того, чтобы из человека «полезли» все его тараканы и комплексы. Ничто так не портит человека как маленькая власть. Не торопитесь туда, там те еще жернова. You’ll never be the same again.

5. Что делать на втором курсе, когда до диплома еще далеко, как и до вменяемого менеджерского возраста? Стремительно умнеть и не по годам матереть.
— PMBoK, на который молятся на кафедре — вовсе не библия. Это, конечно, американский национальный стандарт, и проштудировать его вовсе не лишне, но есть огромное количество других школ управления проектами. Википедия в помощь — там читать и читать. История вопроса и развития школ тоже очень поучительна и интересна. Выбирайте ту школу, те практики, те способы, которые понимаете, и с которыми внутренне согласны. Не понимаете, с какими согласны — гребите пока все скопом, дальше нужное прилипнет, остальное отвалится.
— стать менеджером самому сейчас нереально (и, пожалуй, ненужно) — но можно втиснуться в команду, где есть классный ПМ. Стажировкой, подаваном, ассистентом, носить кофе — как угодно. Бесплатно, за копеечку, самому приплачивать своим временем и силами. Посмотреть, как работает реально тот или иной настоящий менеджер. Попрограммировать, потестировать, поделать любую маленькую «студенческую» работу — это способ получить опыт управления, на своей шкуре. Но не надо думать, что совершенство в программировании — это путь в менеджмент.
— искать свой путь к авторитету и лидерству. Знать много и не делать детских ошибок — не так уж сложно. На эту тему есть куча книжек, читайте все. Элия Голдратт, Том ДеМарко, Тимоти Листер, Джоел Спольски, Джим МакКарти, Фредерик Брукс и прочие, прочие, прочие — это кладезь опыта очень-очень-очень умных и талантливых людей (если, конечно, говорить о менеджменте в ИТ). Будет глупо не «загрузить» их себе в голову. Не печальтесь, если не все понятно — это не очень важно. Понять можно и позже.
— учиться брать ответственность и оправдывать доверие. Учиться не брать ответственность, если не сможешь выполнить задачу. Опыт вожатого в пионерлагере, волонтера на конференции, координатора каких-то движений дает много представления о людях и их отношении к обязательствам и ответственности. Придумайте проект и воплотите его — именно этим занимается ПМ, даже если проект — это поездка с друзьями за город. Организуйте факультетский сайт. Выпустите газету. Устройте сорервнование. Набейте свои шишки на таких «плюшевых» проектах.
— внимательно прислушивайтесь к себе — «оно мне надо?». Если такая работа не приносит удовольствия, возбуждения, приятной усталости и гордости за сделанное — может, просто, надо заняться чем-то другим. Без внутреннего удовольствия от проделываемого никогда не стать звездой. В этом случае, чем быстрее это понимаешь — тем лучше.

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

Отличный ответ. Особенно про «You’ll never be the same again».

Плюс один.

ваш ответ добавлю в свои заметки. впринципе вопрос мой уже исчерпан :)

главное побольше читать и интересоваться. попробуйте на 5м курсе пойти на второе высшее по финансам. там и до СЕО недалеко

Можете пойти на бизнес-аналитика, я видел джуниорские позиции для них. Через пару лет — ПМ и 20 личных рабов-программистов:).

Ух ты... Скоро нами будут ПМить выпускники ВУЗов?

Надо чтобы вас укусил PM ;-) Ну а по сути...что за дурная тяга к халяве? Я конечно понимаю, что плох тот солдат, что не мечтает стать генералом...но надо сначала побыть солдатом... У вас нет не соответсвующего опыта экспертизы проектов, нет опыта управления командой, нет опыта ведения переговоров с заказчиком, как вы собераетесь работать PM-ом если у вас нет вообще ничего за плечами кроме незаконченного образования? Да, и не обязательно идти к PM через девелоперские должности...можно начать с QA, или Technical Writer (еще как вариант бизнес аналитик).

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

или инжинером не побыв слесарем? или архитектором не побыв строителем? итд...?

расскажите как кодирование, работа програмистом помогает сделать экспертизу проекта и почему без 5 лет опыта написания скриптов на ВБ ее нельзя научиться делать? или как кодирование, програмирование помогает научиться управлять командой? вы имеете ввиду командную строку билд системы и СКВ? или как кодирование и програмирование помогает вести переговоры с заказчиком? почему всему этому нельзя научиться там где этому учиться програмист?

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

Бывают конечно таланты, но как вы обоснуете свои претензии?

дипломом

Понятно, что диплом есть. Что это должно значить для работодателя? Почти нулевые знания и красный диплом — вполне реально.

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

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

Зачастую ПМ просто обязан как минимум понимать технологии и инструменты, которые используют разработчики на проекте

Что вы подразумеваете под словом понимать?
Должен знать названия и характеристики? — зачем для этого быть програмистом? или машины продают/создают гонщики, а фотоаппараты фотографы?
Должен умень научить програмистов пользоваться и помогать если будут траблы? а это точно работа ПМа?
Должен уметь установить настроить? а это точно работа ПМа?

итд...

или машины продают/создают гонщики, а фотоаппараты фотографы?

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

Так что без изучения предметной области трудно добиться в ней успеха. Вы можете потратить несколько месяцев, общаясь с разработчиками и пытаясь понять, как скоординировать их действия, чтобы на выходе получился полноценный продукт. Но это врядли сделает из вас ПМ`а. Или же сами принять участие в командной разработке и понять, что то, что мы видим со стороны — roadmap`ы, диаграммы Ганта, раздача заданий и т.д. — всего лишь верхушка айсберга. Разработка ПО — забавный процесс — есть куча методологий, паттернов, приёмов, которые превращают его в несложный процесс, состоящий из простых итераций. Как будто идешь по дороге и через каждые 10 метров указатель с направлением. Только вот дорога постоянно пытается увильнуть из под ног. И это нужно прочувcтвовать. Иначе, каким образом вы сможете заниматься планированием и управлением рисками?

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

Посмотрите на это с другой стороны. Опыт работы в IT для вас — не помеха, а неоспоримый плюс. Как с точки зрения трудоустройства, так и в плане полезного опыта.

Хм, предметная область это область проекта, причем тут работа програмистом? или например ПО пишеться для бухгалтерии (1С например) то предметная область бухгалтерия, причем тут програмисты? или софт пишеться для програмистов: отладчик, ИДЕ, компилятор, анализатор, СКВ итд... то да, но таких проектов на Украине очень мало, чаще проекты для бизнеса соотетсвено предментная область здесь это область бизнеса.

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

Хм, предметная область это область проекта, причем тут работа програмистом?

Я имел в виду не предметную область проекта. Предметная область — объект деятельности. В случае ПМ`а — управление проектом, связанным с разработкой ПО. Наверное, неудачно подобрано словосочетание.

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

скорее всего да

и в полном обьеме

наверное, нет :)

Попробуйте спросить следующее: много ли ПМ`ов есть на DOU, не имеющих опыта работы в IT.

Ну с тем же успехом можно спросить сколько ПХП-народу на ДОУ народу работает в Фейсбуке и после чего никчему не стремиться, а начинать учить очередную ЦМС и готовиться кодить за еду

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

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

Ну с тем же успехом можно спросить сколько ПХП-народу на ДОУ народу работает в Фейсбуке и после чего никчему не стремиться, а начинать учить очередную ЦМС и готовиться кодить за еду

Вопрос стоял в следующем:

1. Каков самый типичный алгоритм становления ПМом в нашей стране ?

Ответ на вопрос выше просто показал бы, что ПМ без бэкрграунда в IT — нетипичный алгоритм получения позиции ПМ в нашей стране. Знание этого само по себе не обязывает ни к чему. А кодить или не кодить за еду, стремиться или нет — это уже другое дело, тут каждый сам себе решает.

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

Кто вам такое сказал :)

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

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

Вопрос стоял в следующем:

и вы пропустили 2ю часть вопроса :) о которой в этой часте треда говорят, есть ли такая возможность

Кто вам такое сказал :)

Это не трудно проследить по топикам, народ интересует какая ЦМС лучше что бы кодить за еду на ПХП или что лучше Жава или Шарп что бы чтать типичным програимстом аутсорса и косить о боже целые 2.5к сеньером в 23года, мало кто спрашивает как например попасть в Гугл, Фейс, Яндекс после универа вместо месного бодишопа и получать нормальные деньги и опыт... вы такие темы встречаете?

Вы обратили внимание состав аудитории и средню квалификацию большинства активных поситителей?

Это не трудно проследить по топикам, народ интересует какая ЦМС лучше что бы кодить за еду на ПХП или что лучше Жава или Шарп что бы чтать типичным програимстом аутсорса и косить о боже целые 2.5к сеньером в 23года

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

Со временем приходит понимание того, что платформы, языки и технологии — это всё не так важно ( они важны только с точки зрения «right tool for the right job» для конкретного проекта), как возможность развиваться, не стоять на месте.

, мало кто спрашивает как например попасть в Гугл, Фейс, Яндекс после универа вместо месного бодишопа и получать нормальные деньги и опыт... вы такие темы встречаете?

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

Вы обратили внимание состав аудитории и средню квалификацию большинства активных поситителей?

Аудитория довольно-таки разнородная, про квалификацию ничего сказать не могу — сам ещё студент :). Да и трудно об этом судить по активности на форуме — в реальной жизни все немного другие.

зря держат. вам бы другого дали.

В Гугл і Амазоні кандидати на позицію ПМа проходять технічне інтервю практично такого ж рівня складності, як і деви. ПМи роблять код ревю, деколи пишуть код і беруть участь в дизайні архітектури. Команда получається більш монолітною та ефективною. Чисто менеджерський ПМ буде розводити більше бюрократії, менше розбиратиметься в стані проекту, не зможе бути прикладом для команди

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

Кстати там ПМ это скорее БА чем ПМ в Украине, а ПМов как раз они любят нанимать со стороны и управленческим уклоном

Не путай ПМ-ов и дев менеджеров, в теории это очень разные роли.

+1 это разные роли, ПМ — это бизнес аналитик, можно сказать секретарь проекта, а дев манагер он конечно девелопер в прошлом и растет из него

Бизнес-аналитик — это все таки отдельная специализация. Он требования пишет. А то, что ПМ — это очень продвинутая секретутка, это 100%! Просто таких продвинутых и классных очень мало, что и оправдывает их вознаграждение.

ПМ (это Program Manager, не Project Manager) в таких компаниях эти роли и выполняет: организовывает митинги и взаимодействия команд, ведет развитие проекта и саксес метрик намберс, собирает фидбеки и формирует требования итд...

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

Как написали выше, именно опыт программиста необязателен. Но опыт работы в IT — будь-то QA, BA и т.п. — для менеджера необходим. Почему? Да просто не возьмет никто. Вы же сами пишете — "

опыт не всегда переносим

". Но откуда возьмется переносимый?

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

А почему что бы этому научиться нужно обязательно тратить время на програмирование? почему это нельзя узнать более эфективно? неужели все совали пальцы в розетку что бы узнать что этого делать нельзя? или все доктора прежде чем назначать лекарства пробуют их на себе?

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

А почему что бы этому научиться нужно обязательно тратить время на програмирование?

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

Ну вот наверное это и интересует топикастера, как максимально эфективно получить этот опыт и какой опыт нужно получать, потому что советы нужно поработать, это чем-то смахивает на дедовщины ты должен пройти через то что и мы что бы мы тебя приняли, чем дельные советы зачем это нужно и с такой же легкостью можно спросить что такого полезного принесет для управленца например ковыряение в каких-то багах или ЦМС? или нужно понять как разрабатываеться софт, то почему нельзя просто пока учишся в универе сделать свой стартап проэкс пусть достаточно простой от начала и до конца, и при возможности не самому а в тусовке однодумцев что бы поучиться комуникации и управлению, почему ковыряние багов с 9 до 6 на каком-то скучном проекте должно принести больше пользы?

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

А скучный проект или нет это уже как товарищ сам найдет, если он трудолюбивый, талантливый и проактивный я думаю выбор будет получше.

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

Вам уже несколько раз говорили в комментах — необязательно программировать, можно быть QA, можно быть BA, главное увидеть процесс ИЗНУТРИ. Опять же — поскольку у нас существуют конторы, в которых ПМами берут девочек с инъяза — можно быть ПМом и без понимания процесса, просто шишек с большой долей вероятности будет больше, чем если бы Вы, скажем, работая QA’ем, смотрели как выходит из сложных ситуаций ПМ. По сути то, о чем я говорю — это не пробование лекарств на себе, а интернатура, работа бок о бок с более опытными специалистами.

Мое мнение такое — можно быть «просто ПМом», не понимая процесса изнутри, но «хорошим ПМом» без этого понимания быть намного сложнее (но не невозможно).

То есть стать лейтенантом и командовать солдатами нельзя не побыв солдатом?

есть такое мнение
один из примеров ru.wikipedia.org/...iki/Мухтар_Кент

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

кроме того как это сьест львиную долю времени на не релевантные обязаности

не работал на 100 разных работах

об этом речь и не шла

он просто изучил как это работает

некоторые вещи можно изучить только на практике

вообще в менеджементе (и в ИТ в частности) нет универсальных решений и 100% рабочих правил в силу человеческого фактора, поэтому спор ниочем %) извините, если задел Ваши убеждения

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

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

раскажите что может рассказать опыт в БА или КуА или еще где о том какой вы лидер, менеджер итд? можно быть идеальным специалистом и при этом при ужаснейшим менеджером

Скорее не архитектором, а прорабом не побыв строителем. — Прорабом да, будет тяжеловато управлять.

Потрібно кілька років досвіду в реальних проектах перед тим, як Вам довірять керувати командою. Ідіть працювати до того, як закінчите вуз

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