Комментарии 32
Вспомнилась эта картинка
и часто вы видите ПМ-а, уходящего вовремя домой?
Классная картинка :) Мне кажется, у ПМ-а два варианта — либо уходить пораньше и спихивать все на подчиненных, либо делать очень много для проекта, чтобы всем там было комфортно, но при этом неслабо перерабатывать самому.
Судя по тому что я знаю от своих знакомых ПМ, это человек, работа которого заключается в том чтобы сделать так, чтобы программист/тестер/админ/не_важно_кто еще работал и не заморачивался другими вещами вроде «плюшки к чаю закончились», или «у нас дедлайн, сидим до утра, надо бы чего-то перекусить», вместо «надо бы поменять тормозящий компьютер» — «Вася, поменяй компьютер, тормозит» и ПМ Вася, который понимает что от скорости работы ПК напрямую зависит качество работы программиста, должен выбить у руководства машинку на замену, решить, чем кормить команду.
Тоже самое можно сказать и про админство и про всё остальное.
Иногда это нянька.
Может это и узкий срез, но все понимают, что делать задачи в комфортных условиях, не отвлекаясь на другие вещи (выходя из потока), быстрее и продуктивнее
Тоже самое можно сказать и про админство и про всё остальное.
Иногда это нянька.
Может это и узкий срез, но все понимают, что делать задачи в комфортных условиях, не отвлекаясь на другие вещи (выходя из потока), быстрее и продуктивнее
Ну вы уж прям передергиваете. Надеюсь, ПМ из примера не ходит с девелоперами в туалет.
Я про те проекты, где понимают, что программеры делают деньги компании и о программерах надо заботиться.
не, в туалет бегать и кормить с ложечки — это уже через чур.
не, в туалет бегать и кормить с ложечки — это уже через чур.
Ни разу не передергивает. ПМ нужен, во-первых, как «адаптер» между Product Owner'ом с его User Stories и командой девелоперов и QA. Во-вторых, его задача сделать девелопмент комфортным для всех членов команды. А в это уже многое входит. Начала назойливо моргать и щелкать лампа — он шлет письмо с красными буквами или идет пешкодралом до нужного кабинета, если через мыло все движется медленно. Это пример из практики.
Респект и уважуха таким ПМам!
Респект и уважуха таким ПМам!
Сам из менеджеров проектов вернулся обратно в разработку. Ну как вернулся — скорее решил, что в чистом виде менеджер не нужен и не интересен и в продуктовой команде тим-лид гораздо лучше справляется с этой задачей.
Но это слабореализуемо в аутсорсинговой компании.
Кстати, всем рекомендую по возможности чередовать места работы — аутсорсинговые компании и продуктовые компании.
Над продуктом работать гораздо интереснее, но в аутсорсе рост может быть немного быстрее.
Но это слабореализуемо в аутсорсинговой компании.
Кстати, всем рекомендую по возможности чередовать места работы — аутсорсинговые компании и продуктовые компании.
Над продуктом работать гораздо интереснее, но в аутсорсе рост может быть немного быстрее.
Опять зависит от проекта и ассессмента. Если проверка годности на повышение сводится только к пачке вопросов к твоему текущему ПМу, то может быть и так и сяк, в зависимости от личностных отношений с ПМом.
Если проверка объективная, то динамика будет зависеть от тебя.
Считаешь, что готов к повышению — запроси конкретные требования к следующей ступени и дерзай.
Если проверка объективная, то динамика будет зависеть от тебя.
Считаешь, что готов к повышению — запроси конкретные требования к следующей ступени и дерзай.
Полностью солидарен, у меня как раз продукт-аутсорс продукт :) Но я не стал бы сильно грешить на аутсорс — все же, и там есть свои плюсы в отношении продукта.
Я не говорю, что аутсорс плохо. Там обычно больше разных задач и проектов, а если они еще и интересные — заскучать не успеваешь. Но очень часто это бывает тупая поддержка…
Что я люблю в продуктовы компаниях — ты можешь любить свой продукт и болеть за него, даже будучи винтиком-разработчиком. Ты видишь как им пользуются, как он развивается и как ты на него влияешь.
На аутсорсе просто не успеешь влюбиться в проект :)
Что я люблю в продуктовы компаниях — ты можешь любить свой продукт и болеть за него, даже будучи винтиком-разработчиком. Ты видишь как им пользуются, как он развивается и как ты на него влияешь.
На аутсорсе просто не успеешь влюбиться в проект :)
>> Никогда не соглашайтесь вести низкобюджетные проекты
И с треском заваливайте свой крупный проект из-за отсутствия необходимых навыков переговоров, организации работы целой кучи людей и банального опыта. Не согласен я с такой установкой. Всегда нужно с чего-то начинать. И пусть у вас будет хотя бы два-три не самых крутых программиста, а роль аналитика вы исполните сами, зато с большей вероятностью добьетесь успеха.
И с треском заваливайте свой крупный проект из-за отсутствия необходимых навыков переговоров, организации работы целой кучи людей и банального опыта. Не согласен я с такой установкой. Всегда нужно с чего-то начинать. И пусть у вас будет хотя бы два-три не самых крутых программиста, а роль аналитика вы исполните сами, зато с большей вероятностью добьетесь успеха.
Уважаю вашу точку зрения, но с ней не согласен. Провалить малобюджетный требовательный проект проще, чем высокобюджетный требовательный проект, т.е. проект сравнимых масштабов. Вам ни холодно ни жарко, работаете вы на Intel или смоленское почтовое отделение, но с первыми проще и приятней работать. Чем выше бюджет проекта, тем более адекватные люди по ту сторону скайпа, и тем более хороших разработчиков вам выпишет руководство, боясь завалить такой хороший проект и расстроить заказчика.
И вполне вероятна ситуация когда из крутых разработчиков «выскочку» никто не уважает, каждый знает сам решает как сделать «лучше» и в итоге нормального рабочего взаимодействия не получается. И ещё мое личное наблюдение: чем больше проект, тем тяжелее вести переговоры с заказчиком, потому что общаться нужно со все более крупными шишками, а они не любят вникать в детали. Им нужно, чтобы вы сходу подписались по срокам и сметам, которые устраивают их, а дальше уже ваши проблемы. Не наработав опыта ведения переговоров с разными людьми можно отлично слиться. А может и повезти. По-разному бывает. Адекватность заказчика никогда не является величиной прямо пропорциональной сумме договора.
У меня есть, хоть и небольшой, опыт ведения маленьких проектов (кстати, как вы определяете маленький проект?) и я вижу как вокруг валят и крупные проекты, валят и мелкие. И проблемы, на мой взгляд, всегда и везде одни: недостаточный анализ, недостаточная квалификация и метания заказчика, который не знает что ему нужно.
У меня есть, хоть и небольшой, опыт ведения маленьких проектов (кстати, как вы определяете маленький проект?) и я вижу как вокруг валят и крупные проекты, валят и мелкие. И проблемы, на мой взгляд, всегда и везде одни: недостаточный анализ, недостаточная квалификация и метания заказчика, который не знает что ему нужно.
Маленьким я считаю проект, который уходит в стадию глухой поддержки через 3-4 месяца разработки, большой — через 2-3 года.
В целом, я согласен — чем больше шишка, тем меньше его волнуют детали, в которых вся соль. Тем меньше его волнует качество кода, и тем больше — дизайн логин скрина :)
Но все же на более высокобюджетных проектах полегче со сроками и давлением — по моему опыту, если нужно две недели на рефакторинг и ты убедишь в этом менеджмент заказчика — значит нужно, никто не будет спорить. А на малобюджетном, особенно стартапе скажут — ну да, мы все понимаем, вот эти фичи доделаем и порефакторите. И так может продолжаться месяцами, а долг-то растет…
В целом, я согласен — чем больше шишка, тем меньше его волнуют детали, в которых вся соль. Тем меньше его волнует качество кода, и тем больше — дизайн логин скрина :)
Но все же на более высокобюджетных проектах полегче со сроками и давлением — по моему опыту, если нужно две недели на рефакторинг и ты убедишь в этом менеджмент заказчика — значит нужно, никто не будет спорить. А на малобюджетном, особенно стартапе скажут — ну да, мы все понимаем, вот эти фичи доделаем и порефакторите. И так может продолжаться месяцами, а долг-то растет…
Мне 19 и я бородат уже определился, что хочу быть ПМом в области связанной с вебом. Учусь на смежной специальности в техническом вузе, не уверен что это мне очень поможет начать карьеру, поэтому спрашиваю здесь: что необходимо из теории знать прожект менеджеру, и как и где начать карьеру?
Лучше смотрите в сторону продакт менеджера.
Проджект — это agile и pmbok.
Проджект — это agile и pmbok.
Первая книга, которую стоит прочитать — Дейл Карнеги, да любая из его книг. Им 60 лет, но они актуальны и по сей день. После прочтения сразу понимаешь, что можно быть менеджером и не быть козлом — большой шаг! Я видел немало менеджеров, которые мнили себя богами либо выше всех, и они не обязательно были молодыми. Специалист может себе позволить скверный характер, менеджер — ни за что!
Меняйте работу и прислушайтесь к себе. Если Вы уже перешли на темную сторону — назад дороги нет. Если сомневаетесь — может быть, не поздно в девелоперы назад. А вообще аутсорсинг — так себе бизнес. Лучше работать в продуктовой компании.
Могу только посочувствовать и посоветовать поискать работу в нормальной компании.
Не понимаю, как в здравом уме разработчик может хотеть стать менеджером :) Сменить управление детерминированными системами на недетерминированными.
НЛО прилетело и опубликовало эту надпись здесь
Все так. Но наблюдал, когда такие компании начинают еще выше расти — скажем, от 70 до 200 человек. Своих людей на все должности уже не хватает, да и работа свинская начинается — поэтому на самое младшее менеджерское звено уже ставят обычных девелоперов, часто молодых, т.к. прокачанных программеров на такое сомнительное удовольствие уже не заманишь.
Насчет роста на 300% согласен — расти некуда, нужно просто перерасти такую конторку. Выхода два — или искать компанию классов повыше, и расти как специалист, или же открывать свою такую же — горизонтальный рост прекратится, но ты хотя бы знаешь, за что работаешь.
Насчет роста на 300% согласен — расти некуда, нужно просто перерасти такую конторку. Выхода два — или искать компанию классов повыше, и расти как специалист, или же открывать свою такую же — горизонтальный рост прекратится, но ты хотя бы знаешь, за что работаешь.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стоит ли идти в менеджмент и зона