ИМХО, в Мск в ИТ — 100 — это начинающий миддл, 200 — хороший синьор. С нормальным, перспективным стеком. У вас как я понял стек не подразумевает рост в долгосрочной перспективе, следовательно вам надо за этот фактор платить. Т.е. для вас эти люди будут стоить больше чем 100\200к.
Мы на редкий стек брали людей, с техническим образованием и мозгами, но не из ИТ. Учили их, и давали нормальную ЗП в перспективе. В итоге и мы были в плюсе (редкие спецы за обычные деньги) и люди в плюсе (на ИТ-зарплатах сидят, хотя год назад и не мечтали войти).
Уходили конечно, но массовых или перманентных уходов не было.
Насчет природы — согласен, хотя в Мск есть вариант сел в пятницу вечером на Жигули и с утра кушаешь шашлык на Грушинксой поляне.
Насчет дачи — это дело на любителя, мне например она даром не нужна.
А вот деньги на покупку дачи\билетов на отдых\машины и т.д. в Мск намного быстрее можно заработать, хотя Самаре еще по зарплатам довольно нормальный город.
Между Мск и регионами разница в основном в стоимости жилья, раза в 2-3, не больше.
Остальное — почти так же, не считая услуг — всякие стрижки, пошив одежды, массаж и т.д. — дороже раза в два.
В целом же — можно очень даже много выиграть — бесплатные митапы один из способов, есть еще бесплатный инглиш в библиотеках, куча концертов на открытом воздухе, да и наличие метро по всему городу делают машину ненужной.
Вот прям люто плюсую.
Нафига человеку ехать из Самары в Казань на +20% к ЗП, если можно поехать в Мск на +70%, которая от Самары не то что бы принципиально дальше, а возможностей для отдыха и дальнейшего роста в разы больше?
Для самарца — Казань — такой же чужой город, как и Москва, и даже более чужой (в Мск то как то все знакомо по фильмам и командировкам).
Возьмите за привычку час в день всегда учить язык (лучше с утра, после завтрака, если встать пораньше) — уже 7 часов в неделю наберется, да и язык будете знать (если знаете инглиш, учите дойч, или что то еще).
Планируйте в конце года обучение на следующий год. Сейчас, кстати, самое время. Подумайте, что вам нужно — PMP, PSM, MBA, еще одна вышка, повышение квалификации, ITIL, Goethe B2, или что угодно еще. Выделите бюджет, и смотрите куда пойти учится (лучше по субботам, это будет еще 6-10 часов занятий в неделю). И так каждый год. Каждый. Обрастете быстро новыми знакомыми, научитесь быстро получать навыки и не боятся задач любой сложности, будете уверенны в своих силах.
Вроде как яндекс.здоровье — это не проект, это продукт. Судя по всему — не совсем успешный, по сравнению с едой или такси или картами или чем то еще. Может быть, дело в том что сама по себе идея продать разговор с врачом по скайпу в России за 2,5 тысячи рублей, при цене посещения специалиста в регионе меньше тысячи рублей ну никак не пахнет большими посещениями сервиса. Может быть, дело в том, что когда у тебя болит зуб, ты какой то частью интуиции понимаешь, что сходить и запломбировать к самому плохому врачу, будет лучше, чем писать в скайп самому хорошему. Может быть, дело в том, что медицина конкретной страны вообще заслуживает мало доверия со своей гомеопатией, а может дело в обскурантизме большинства болеющих, все еще верящих в хиропрактиков и бабок.
В любом случае — ИМХО — с разработкой у вас все отлично, но вот именно продуктового и проектного менеджмента грамотного не хватает.
Понятно, у меня, увы, наоборот — ПМить идти на реально хорошие условия — надо поискать, зато звонят с предложениями поархитекторить, хотя я не архитектор ни разу.
Про скрам-мастера — вопрос сильно спорный, в правильной скрам команде мастер близко на ПМа не похож, роли у него совсем другие — коучить команду фреймворку, следить за временем. Но не указывать что делать, и точно — не брать ответственность на себя, это явно прописано в scrum guide. Но в плохих командах, да, СМ и жнец, и чтец, и пофронтендить может, и протестить, и на скраме, и на уотерфолл, и еще и полы помоет после работы.
Хм, проектов без архитектора нет, но вот продукты есть (а ПМы так вообще там не нужны). Если именно как software architect — очень странно, что спроса нет, казалось бы любой банк и интегратор забирают за любые деньги (особенно, Java). А вот РП не так нужны в разработке — работать без них можно, например по scrum, и в банках они почти не нужны. С Head of PMO ситуация еще хуже — если проекты разные, команды большие и ПМы самостоятельные — хэда им не берут.
Насчет команды, и замены ее участников — это верно. Выше, я писал, что ПМ — это в идеальном мире, тот человек к которому люди приходят поговорить об увольнении. И не писал, подразумевая, что это должен быть тот человек к которому приходят за прибавкой, с косяками, за отгулами и т.д. И, да, в СД не работает — иди и реши задачу. Работает — давайте сядем и разберемся, что НАМ нужно сделать, что бы мы завершили проект и что мы получим с этого (бонусы, экспириенс, повышения и т.д.). Менеджеров, которые просто говорят иди и делай — я в приличных местах не встречал давно даже не в ИТ. Но и разрабов, которые бы делали только то, что интересно им я встречал нечасто (хотя да, смузихлебов, занимающихся изучением нового фреймворка, вместо скучного багофикса и работы с легаси за деньги заказчиков хватает).
Ну по опыту могу сказать, что менеджера меряют закрытыми проектами. Много хорошо сделанных, закрытых проектов, которые ты можешь подтвердить — платить будут хорошо (много и часто). Проектов закрытых и хороших нет — блеять менеджер будет уже на собеседовании.
Как правило, референсы может дать не только заказчик (пусть мы ему все вылизали в ущерб собственной компании), но и текущий работодатель — если менеджер нормально делал проекты, а потом ушел и теперь просит референс-колл — почему бы и нет? Серьезные западные компании при найме обязательно просят контакты бывших работодателей (не обязательно директора, это может быть и Head of PMO) и заказчиков (менеджер проекта со стороны очень даже ок).
Про МВА — напишите, битте, в личку куда ходили — сейчас как раз думаю пойти. Не рекламы для, а продолжения разговора ради — интересовался управлением проектами в вышке
Скажу что у меня фид положительный, учат не только планы-графики в проджекте делать и диаграммы рисовать (но и этому учат, курсы ведут PMP/CSM /PMI-ACP etc), но и полезным для руководителя скиллам — конфликтологии, управлению ожиданиями, и т.д. Приятный плюс — приглашенные с реально крупных и известных компаний эксперты и экзотика типа lean'a. Никаких книжек 97 года нет, матан так же присутствует в необходимой концентрации. С кейсами — полный порядок, живые и разнообразные, из практики, они в общем то и являются критерием приемки работ.
Объективный минус — деньги, 600к — организация, наверное, может это вычесть из налогов, а вот частное лицо не способно потратиться.
Так то оно так, но вот людей, способных взять на себя ответственность и управлять ресурсами — много. А людей, способных спроектировать и реализовать ядро сложного и современного, конкурентоспособного приложения — мало, ой как мало. Это рынок.
Грустно, это когда мешки из СТ живут в центре в трехкомнатной квартире, а ты с двумя детьми в однушке из Жуковского каждый день по 2 часа туда и 2 обратно ездишь.
Хороший ПМ на проекте — хозяин. И с Заказчиком ему общаться интересно, и команду он не пускает к нему — не только потому, что З умеет давить, но и потому, что команда тоже может наобещать с три короба (ой, мы сейчас верификацию номера телефона сделаем, там на полчаса, а потом выясняется что надо архитектуру БД перекраивать, а заказчик сидит и ждет — ему же представитель исполнителя обещал).
Просто именно ПМство как искусство управления стейкхолдерами у нас слабо развито. Либо технические люди, кто не привык быстро ответственность брать в условиях неопределенности на себя, либо функциональные менеджеры, привыкшие к системе «я начальник, ты дурак» и не умеющие договариваться и искать win-win. Статью пилите, интересно будет почитать )
Не знаю как в стране, но во всем мире наблюдаю одну и ту же ситуацию — как заплачено, так и сделано.
Если к тебе пришел хороший разраб, даже не важно джун или миддл или синьор и ты его взял к себе в команду, будь добр — мотивируй его работать. Если не можешь сделать это без денег (а в 95% случаев так и есть) — плати. Не будешь платить — человек будет шастать по собеседованиям, учить не относящиеся к работе фреймворки, в лучшем случае — сделает тебе фичу на том стеке, который интересен лично ему. Будешь платить — человек будет фигачить, что бы не потерять хорошее место.
С менеджерами ситуация еще хуже — мало того, что они знают ЗП команды, они еще часто знают ЗП в других командах. Однако очень часто руководство компаний думает что достаточно мотивировать только команду, а менеджер и так мотивирован. Ага, если бы.
Конечно, менеджеры и команды есть разные. Есть команды типа звезды разработки и обычный ПМ, есть звезды разработки и менеджмента (редко встречал), есть обычные разработчики и сияющий на их фоне ПМ (самый фиговый вариант).
Самый лучший вариант — нормально оплачиваемый ПМ, выбивающий у руководств ставки своей команде, взамен дающих руководству проекты в срок и в бюджете. Это мечта всех, но такой ПМ дорогого стоит, да и найти еще его надо.
Насчет учебы — могу даже отдельный коммент написать.
Найти наставника — хорошо, если в компании есть сильный менеджмент — для ПМа это проектный офис, с среднесрочным и долгосрочным планированием ресурсов и проектов, с хорошей методологией. Я таких видел немного, но видел. В разработке — это самый грамотный способ, в менеджменте (особенно в ПМстве) надо будет скорее всего не одну компанию обойти.
Книги — вариант наверное для людей, способных прокрутить проект от начала до конца в голове во всех деталях. Обычным людям лучше сломать грабли на 2-3 проектах. Ну и смотрите материалы (и порталы) на английском (и немецком) — они как правило годные. Группы в телеграме тоже в помощь — насоветуют митапов на тему, будет что обсудить.
3. ВВ — по менеджменту — зверь редкий, магистратура — тоже мало что дает, шанс найти что то стоящее за пределами Москвы стремиться к нулю. Про фишечку ВУЗов — отмечено совершенно правильно, руководству ВУЗа надо по программе, преподаватели очень часто не видят дальше собственного носа, считая себя экспертами без единого дня опыта работы в сфере (да, у меня преподавали экономику те, кто работал после вуза преподавателем сразу, и разработку те, кто не работал ни над одним боевым проектом в группе). Опять же про курсы — мало людей умеет хорошо делать дорогие проекты, но предпочитает вместо этого тратить деньги на курсы. Встречал одни, достойные курсы после которых можно выпускать ПМа в поле под внимательным присмотром, но не более того.
4. MBA — сам думаю, но пока мысли следующие — для работодателей это не принципиально, самостоятельно можно несколько сотен часов потратить на обучение гораздо более эффективно.
И напоследок — о бедной зарплате замолвите слово. Хороший разработчик (синьор или лид) получает выше менеджера проекта, с гораздо меньшим геммороем (обычно нет командировок, оплачиваемые переработки, нет перманентных стрессов от давящих дедлайнов и заказчиков) и гораздо более светлым будущим — таков спрос на рынке. Так что всем, кто думает перейти из SD в менеджмент — с точки зрения поднятия доходов это плохая идея. Только по велению сердца.
Хм, статья интересная безусловно, спасибо.
Принципы звучат отлично, но надо понимать их применение к реальности. Например, пример про собственные KPI — показателен. Например, компания нанимает менеджера на фикс и бонусы от KPI, при этом бонусы от проектов — могут быть 50% и выше, и будут только при условии соблюдения KPI. Надо думать, что разумный человек вряд ли пойдет на встречу команде — он играет по другим правилам, которые ему навязала компания. А внутри компании от него разрабы бегут как от огня — зная, что он всех принуждает к переработкам и людей держит за расходный материал.
Другой вариант — KPI менеджера зависит от процента проектов. Есть проекты и заказчики — менеджер получает деньги, нет (или мало) проектов и заказчиков — денег (почти) нет. Надо понимать, что в этом случае задницы заказчиков будут вылизаны до блеска, а команда опять останется с носом? В итоге — косяки менеджмента компании выдаются за косяки ПМов.
С менеджерами из разработки тоже не все так просто. Я сам люблю писать пример о Королеве, но есть и другой пример.
Канал Эри.
В конце 17 века город Нью-Йорк представлял из себя небольшой городок, и говорить о том, что этот поселок городского типа будет известен на весь мир, было бы все равно что говорить о том, что Сызрань через 100 лет станет самой развитой столицей.
Дело в том, что экономика обмена в тот момент была такова, что перевозить товары было выгодно по реке, спуская их на юг, а не через Нью-Йорк — сухопутный путь был долог и дорог. От постройки канала федеральное правительство отказалось, президент и множество известных в то время людей не верило в возможность постройки, и казалось бы на этом все должно было закончиться — но история распорядилась иначе. Город использовал собственные деньги на строительство, а во главе проекта стояли… два судьи и школьный учитель. Двое из них, на тот момент, не имели никакого представления о строительстве каналов, третий же имел небольшой опыт инжинеринга. В результате — канал построен (на тот момент второй по величине в мире), стоимость перевозки товаров к Атлантике была снижена примерно в три раза, население Нью-Йорка выросло вдвое за десять лет. По ходу проекта, все трое прокачали инженерные навыки, доработали гидроцемент и поставили на ноги сферу строительства подобных объектов в США. Всю эту эпичную историю можно прочитать в Wiki.
В общем, ПМ должен понимать боли разработки (и тестирования, и внедрения, и аналитиков, и заказчиков/спонсоров, и руководства, и государства и т.д.), понимать как делаются оценки, тестирование и рефакторинг и еще очень много всего. Но, это не значит что ПМ всегда разработчик — ПМ выстраивает отношения между собой и командой, а хороший ПМ выстраивает отношения еще и внутри команды, а как высший пилотаж — еще и между командой и руководством (хороший показатель, когда тиммемберы начинают разговор об увольнении с ПМа — это значит между ними есть доверие). Про отношения с заказчиком даже говорить не буду — просто нормальный ПМ не допустит общения заказчика с участниками вида «хочу так, делайте, я же деньги плачу», да и вообще управление заказчиком позволяет избежать такого подхода.
Уходили конечно, но массовых или перманентных уходов не было.
Насчет дачи — это дело на любителя, мне например она даром не нужна.
А вот деньги на покупку дачи\билетов на отдых\машины и т.д. в Мск намного быстрее можно заработать, хотя Самаре еще по зарплатам довольно нормальный город.
Остальное — почти так же, не считая услуг — всякие стрижки, пошив одежды, массаж и т.д. — дороже раза в два.
В целом же — можно очень даже много выиграть — бесплатные митапы один из способов, есть еще бесплатный инглиш в библиотеках, куча концертов на открытом воздухе, да и наличие метро по всему городу делают машину ненужной.
Нафига человеку ехать из Самары в Казань на +20% к ЗП, если можно поехать в Мск на +70%, которая от Самары не то что бы принципиально дальше, а возможностей для отдыха и дальнейшего роста в разы больше?
Для самарца — Казань — такой же чужой город, как и Москва, и даже более чужой (в Мск то как то все знакомо по фильмам и командировкам).
Планируйте в конце года обучение на следующий год. Сейчас, кстати, самое время. Подумайте, что вам нужно — PMP, PSM, MBA, еще одна вышка, повышение квалификации, ITIL, Goethe B2, или что угодно еще. Выделите бюджет, и смотрите куда пойти учится (лучше по субботам, это будет еще 6-10 часов занятий в неделю). И так каждый год. Каждый. Обрастете быстро новыми знакомыми, научитесь быстро получать навыки и не боятся задач любой сложности, будете уверенны в своих силах.
В любом случае — ИМХО — с разработкой у вас все отлично, но вот именно продуктового и проектного менеджмента грамотного не хватает.
Если вы так называете уровень «intermediate», вам лучше еще походить на курсы…
Про скрам-мастера — вопрос сильно спорный, в правильной скрам команде мастер близко на ПМа не похож, роли у него совсем другие — коучить команду фреймворку, следить за временем. Но не указывать что делать, и точно — не брать ответственность на себя, это явно прописано в scrum guide. Но в плохих командах, да, СМ и жнец, и чтец, и пофронтендить может, и протестить, и на скраме, и на уотерфолл, и еще и полы помоет после работы.
Как правило, референсы может дать не только заказчик (пусть мы ему все вылизали в ущерб собственной компании), но и текущий работодатель — если менеджер нормально делал проекты, а потом ушел и теперь просит референс-колл — почему бы и нет? Серьезные западные компании при найме обязательно просят контакты бывших работодателей (не обязательно директора, это может быть и Head of PMO) и заказчиков (менеджер проекта со стороны очень даже ок).
Скажу что у меня фид положительный, учат не только планы-графики в проджекте делать и диаграммы рисовать (но и этому учат, курсы ведут PMP/CSM /PMI-ACP etc), но и полезным для руководителя скиллам — конфликтологии, управлению ожиданиями, и т.д. Приятный плюс — приглашенные с реально крупных и известных компаний эксперты и экзотика типа lean'a. Никаких книжек 97 года нет, матан так же присутствует в необходимой концентрации. С кейсами — полный порядок, живые и разнообразные, из практики, они в общем то и являются критерием приемки работ.
Объективный минус — деньги, 600к — организация, наверное, может это вычесть из налогов, а вот частное лицо не способно потратиться.
Просто именно ПМство как искусство управления стейкхолдерами у нас слабо развито. Либо технические люди, кто не привык быстро ответственность брать в условиях неопределенности на себя, либо функциональные менеджеры, привыкшие к системе «я начальник, ты дурак» и не умеющие договариваться и искать win-win. Статью пилите, интересно будет почитать )
Если к тебе пришел хороший разраб, даже не важно джун или миддл или синьор и ты его взял к себе в команду, будь добр — мотивируй его работать. Если не можешь сделать это без денег (а в 95% случаев так и есть) — плати. Не будешь платить — человек будет шастать по собеседованиям, учить не относящиеся к работе фреймворки, в лучшем случае — сделает тебе фичу на том стеке, который интересен лично ему. Будешь платить — человек будет фигачить, что бы не потерять хорошее место.
С менеджерами ситуация еще хуже — мало того, что они знают ЗП команды, они еще часто знают ЗП в других командах. Однако очень часто руководство компаний думает что достаточно мотивировать только команду, а менеджер и так мотивирован. Ага, если бы.
Конечно, менеджеры и команды есть разные. Есть команды типа звезды разработки и обычный ПМ, есть звезды разработки и менеджмента (редко встречал), есть обычные разработчики и сияющий на их фоне ПМ (самый фиговый вариант).
Самый лучший вариант — нормально оплачиваемый ПМ, выбивающий у руководств ставки своей команде, взамен дающих руководству проекты в срок и в бюджете. Это мечта всех, но такой ПМ дорогого стоит, да и найти еще его надо.
Найти наставника — хорошо, если в компании есть сильный менеджмент — для ПМа это проектный офис, с среднесрочным и долгосрочным планированием ресурсов и проектов, с хорошей методологией. Я таких видел немного, но видел. В разработке — это самый грамотный способ, в менеджменте (особенно в ПМстве) надо будет скорее всего не одну компанию обойти.
Книги — вариант наверное для людей, способных прокрутить проект от начала до конца в голове во всех деталях. Обычным людям лучше сломать грабли на 2-3 проектах. Ну и смотрите материалы (и порталы) на английском (и немецком) — они как правило годные. Группы в телеграме тоже в помощь — насоветуют митапов на тему, будет что обсудить.
3. ВВ — по менеджменту — зверь редкий, магистратура — тоже мало что дает, шанс найти что то стоящее за пределами Москвы стремиться к нулю. Про фишечку ВУЗов — отмечено совершенно правильно, руководству ВУЗа надо по программе, преподаватели очень часто не видят дальше собственного носа, считая себя экспертами без единого дня опыта работы в сфере (да, у меня преподавали экономику те, кто работал после вуза преподавателем сразу, и разработку те, кто не работал ни над одним боевым проектом в группе). Опять же про курсы — мало людей умеет хорошо делать дорогие проекты, но предпочитает вместо этого тратить деньги на курсы. Встречал одни, достойные курсы после которых можно выпускать ПМа в поле под внимательным присмотром, но не более того.
4. MBA — сам думаю, но пока мысли следующие — для работодателей это не принципиально, самостоятельно можно несколько сотен часов потратить на обучение гораздо более эффективно.
И напоследок — о бедной зарплате замолвите слово. Хороший разработчик (синьор или лид) получает выше менеджера проекта, с гораздо меньшим геммороем (обычно нет командировок, оплачиваемые переработки, нет перманентных стрессов от давящих дедлайнов и заказчиков) и гораздо более светлым будущим — таков спрос на рынке. Так что всем, кто думает перейти из SD в менеджмент — с точки зрения поднятия доходов это плохая идея. Только по велению сердца.
Принципы звучат отлично, но надо понимать их применение к реальности. Например, пример про собственные KPI — показателен. Например, компания нанимает менеджера на фикс и бонусы от KPI, при этом бонусы от проектов — могут быть 50% и выше, и будут только при условии соблюдения KPI. Надо думать, что разумный человек вряд ли пойдет на встречу команде — он играет по другим правилам, которые ему навязала компания. А внутри компании от него разрабы бегут как от огня — зная, что он всех принуждает к переработкам и людей держит за расходный материал.
Другой вариант — KPI менеджера зависит от процента проектов. Есть проекты и заказчики — менеджер получает деньги, нет (или мало) проектов и заказчиков — денег (почти) нет. Надо понимать, что в этом случае задницы заказчиков будут вылизаны до блеска, а команда опять останется с носом? В итоге — косяки менеджмента компании выдаются за косяки ПМов.
С менеджерами из разработки тоже не все так просто. Я сам люблю писать пример о Королеве, но есть и другой пример.
Дело в том, что экономика обмена в тот момент была такова, что перевозить товары было выгодно по реке, спуская их на юг, а не через Нью-Йорк — сухопутный путь был долог и дорог. От постройки канала федеральное правительство отказалось, президент и множество известных в то время людей не верило в возможность постройки, и казалось бы на этом все должно было закончиться — но история распорядилась иначе. Город использовал собственные деньги на строительство, а во главе проекта стояли… два судьи и школьный учитель. Двое из них, на тот момент, не имели никакого представления о строительстве каналов, третий же имел небольшой опыт инжинеринга. В результате — канал построен (на тот момент второй по величине в мире), стоимость перевозки товаров к Атлантике была снижена примерно в три раза, население Нью-Йорка выросло вдвое за десять лет. По ходу проекта, все трое прокачали инженерные навыки, доработали гидроцемент и поставили на ноги сферу строительства подобных объектов в США. Всю эту эпичную историю можно прочитать в Wiki.
В общем, ПМ должен понимать боли разработки (и тестирования, и внедрения, и аналитиков, и заказчиков/спонсоров, и руководства, и государства и т.д.), понимать как делаются оценки, тестирование и рефакторинг и еще очень много всего. Но, это не значит что ПМ всегда разработчик — ПМ выстраивает отношения между собой и командой, а хороший ПМ выстраивает отношения еще и внутри команды, а как высший пилотаж — еще и между командой и руководством (хороший показатель, когда тиммемберы начинают разговор об увольнении с ПМа — это значит между ними есть доверие). Про отношения с заказчиком даже говорить не буду — просто нормальный ПМ не допустит общения заказчика с участниками вида «хочу так, делайте, я же деньги плачу», да и вообще управление заказчиком позволяет избежать такого подхода.