Так, я знаю, що не раз піднімався цей холівар. Але вважайте це моєю прихоттю (хочу щоб іконкі були на робочому столі...).
Так чи може бути проджект манагер без програмістського досвіду, але з навичками роботи з клієнтами, партнерами (також для самопіару, по вимозі, можу надати список своїх навиків :)?
Якщо таке явище присутнє, будь ласка, покажіть хоча б одного працедавця з такими вимогами.
Якщо ні, то чому?
Дякую.
В Украине ПМ-ов практически нет.
Вообще говоря, кто девушку платит, тот её и танцует. Всё руководство в аутсорсе всегда на стороне заказчика. Соответственно и руководитель проекта (project manager, ПМ) там же. Тут только техлид команды. Названия только поменялись местами, со стороны заказчика руководитель проекта называется project officier, со стороны разработчика технического лидера зовут project manager.
В этой стройной картине мира есть только один изъян — техлид плевать хотел на ПМа, так как бабло ему платит не ПМ, а руководство аутсорсера. Поэтому аутсорсеры приспособились и между ПМом и техлидом вставляют прокладку в лице бывшего QA, которого гордо называют руководителем проекта. Бывший QA на деле руководить проектом не может: у него нет ресурсов (они у заказчика) и нет влияния (с людьми работает техлидер, на то он и лидер). Бывший QA просто надувает щеки и передает приказы ПМа техлиду.
Ты хочешь стать такой прокладкой?
ЗЫ. Если ты ищещь место ПМа, начинай с того места, где раздают деньги. Не с девелоперов, которые эти деньги проедают.
Девелоперами обычно становятся люди с другим складом характера (если, конечно по призванию, а не ради карьеры). Неплохой ПМ — менеджер из нужной предметной области (супермаркеты, финансы, медицина, железо), пусть даже без опыта работы в IT. Но для не-технического начальника будут прежде всего смотреть на опыт успешного руководства. Сразу после института (даже с «навыками работы») в ПМ не возьмут.
Бывает такое. Видал. ПМ — гуманитарий, знающий несколько иностранных языков, основы менеджмента, имеющий логическое мышление и хорошие коммуникативные способности. В роли программисткого бекграунда и решателя технических вопросов выступал помощник-техлид. Связка довольно удачно работала.
Мое imho применительно к управлению: никогда не требуй от людей того, чего не можешь сделать сам. Офицер должен быть на передовой, в окопах, со своими людьми, за которых он отвечает.
Александр очень метко выразился:
чтоб тебя уважали нужно Lead by Example
В Украине, чтоб тебя уважали нужно Lead by Example или «делай как я» по-нашему. По этому если хочешь стать PM, который стоит денег, а не носит кофе и выступает предметом шуток девов, не поленись хотя бы Hello World написать на нескольких языках: уже будет о чем рассказать в команде :-)
Якщо ви хочете бути ПМ в ІТ, то я раджу почати з ВА. Якщо задатки справді є — то за рік можна говорити про пм.
Ну почему же, в GlobalLogic, Cicklum и может быть EPAM есть достаточно большие проекты, с командами по
На SoftServe є також кілька проектів з командами 50+
Крім того, я би дуже застерігав того, хто хоче зробити кар’єру PM-а вихдячи з BA. Зовсім різні способи мислення, зовсім різні способи сприйняття дійсності. Найбільший ризик тут полягає в тому, що найімовірніше, що ти так і не станеш ні нормальним BA ні нормальним PM в тому випадку.
Кто то заметил, что ни один ПМ тут особо не засветился ? :-)
А если серьезно — то задача менеджера — это обеспечить выполнение проекта в рамках имеющихся ограничений. Чем больше проект\программа — тем меньшую роль играет тех беграунд менеджера, но тем более важны его коммуникационные и лидерские задатки.Именно поэтому генерал Гровс справился с Манхеттенским проектом и эпически бы облажался, если ему нужно было бы сколотить команду из 3 девов, 2 КУА и бизнес аналитика чтобы написать новую версию энгри бердс под Андроид.
— какие ограничения?
В случае с менеджером ответы такие
1. Ответить на вопрос «какие задачи нужно выполнить, чтобы проект был выполнен»
2. Ограничения это время , деньги, люди, качество, скоуп
И при этом команду менеджить, контролировать и отвечать головой
За навигационное оборудование взялся бы -) и можно ли только сроки немножко расширить ? каков бюджет проекта ? -))))
— Состав комманд (грубо список специалистов и их количество навскидку)
Первое что пришло в голову )Вопросы — чисто размять мозги, по желанию ессно..
я не буду работать бесплатно-)
Выход — Устав проекта.
А дальше все пойдет как по маслу.
Все, что сложно и непонятно можно разложить на понятные части, понять эти понятные части и систематизировать.
Я думаю, искусство менеджмента не в том, чтобы уметь лучше подчиненных, знать ответ на любой вопрос и поддавливать этими знаниями иногда, чтобы делали так как я хочу, потому что я знаю лучше, а координировать работу команды, члены которой зачастую обладают гораздо большим профессионализмом в своей области знаний.
ПМ — это все-таки не генерал, а унтер-офицер.
Генерал скорее топ-менеджер :)
А почему? Обязанности слабо привязаны к «бирке» и сильно привязано к обязанностям в комманде/компании.
почему все так возбуждаются на бирки? senior developer, tech lead, team lead, project manager, project owner..
Потому, что в оутсорсе чем больше к твоему имени прикреплено погремушек, тем дороже тебя можно загнать клиенту. Соответственно, тем больше ты получишь бабла :)
это понимаем мы, это понимают компании-аутсорсеры, это понимают заказчики...
где интрига то?
Так что опыть вроде бы как и не нужен, а то и вреден, но активное понимание кухни обязательно.
От себя хочу заметить, что сфера IT по косности сравнима с медициной. Пока кто то не возьмёт на себя ответственность и не поставит во главе департамента разработки балетного плясуна и не достигнет успеха — все остальные будут считать что ПМ-ом может быть только человек который ещё дырки в перфокартах сам делал. имхо
Из десятки лучших проджект менеджеров с которыми мне доводилось работать 6 не имели и не имеют никакого не только программистского, но и технического бэкграунда. Напротив — худший менеджер с которым я работал — очень крутой программист, но как менеджер — никакой. Для себя сделал вывод — умение управлять людьми и наличие/отсутствие технических скиллов никак не коррелируют.
конечно, да! главное — компетенции управленца, лидера. хрестоматийный пример: генерал Лесли Гровс, реализовавший Манхеттенский проект.
оставил шикарные мемуары, must read каждому ПМу.
В третьих, даже если допустить что во-первых и во-вторых не хватает, с чего вы вобще взяли что он не провалил проект — все сроки сорвал: ядерное оружие практически не сыграло роли в войне, безопасность не обеспечил — СССР получил ядерную бомбу через четыре года в разы «дешевле»?
СССР получил ядерную бомбу через четыре разы «дешевле»Спасибо супругам Розенберг, которых казнили на электрическом стуле
Ну, если судить по мемуарам Фейнмана, секретность (одна из по идее приоритетнейших задач этого проекта) блестящим менеджером Гровсом была обеспечена в стиле «бронированные ворота в середине чиста поля». Финал, разумеется, немного предсказуем.
Менеджера нанимают, чтобы он решал больше проблем, чем создавал. Программистский бекграунд совершенно не при чем, гораздо полезнее иметь «за плечами» несколько успешных проектов в роли ПМ.
С программистами обычно больше проблем, чем приятностей — они тяготеют к такому управлению, под которым им самими как программистам было бы удобно работать, а не к эффективному с точки зрения управления проектами. Но зато знают специфику, многих ошибок из-за этого не делают.Так как отечественной школы менеджмента, фактически, нет, то прорваться «из девелоперов» — весьма востребованный канал. Но это не везде так.
гораздо полезнее иметь “за плечами” несколько успешных проектов в роли ПМ.
Для того щоб бути ПМ-ом треба бути ПМ-ом :) Геніально! Універсальна порада...
Занимать должность «ПМ» и окончить успешно несколько проектов — это совсем не одно и то же.
Я думаю, что такой опыт разработки на самом деле мешает. А зачем он на ваш взгляд нужен ПМу?
Ще додам, що під бекграундом розумію не конкретно програмістський б., а загальний software development так би мовити
Тільки дещо ,що знайшов
Колишній Директор програми F22 Raptor — Sean FrisbeeНу зовсім людина без бекграунда так сказати....
Проект создания ЗРС С-400 «Триумф» с дальней границей зоны поражения около 400 км был рассмотрен в 1988 г.Знов людина без бекграунда....
А тепер дивимося на Windows PhoneІ знов людина без бекграунда.....
Моя точка зору наступна — якщо проект типовий (прецендентність висока),а може його і не бути взагалі....
Якщо ж проект є «challenge»що "Локомотив"ом там є хтось інший і без лички ПМ...
генерал Лесли Гровс, типичный «сапог», не отличающий атом от молекулы, успешно управлял командой физиков и реализовал Манхэттенский проект.
А тепер дивимося на Windows Phone
conversations.nokia.ru/....-windows-phone
І знов людина без бекграунда.....
Так просрали ведь винфон :)
С моего опыта:
взял девушку с иньяза, которая «свободно говорит по английски», это я потом узнал какие у нее ошибки с английским, и это блин по конкурсу с 4 человек.
Уволил через 2 месяца, не знал как и под каким предлогом, но все-таки выгнал. Работы не делала как следует, все время в фейсбуке и в контакте, постоянно смех, постоянно какая она важная, «то не буду понимать», «то не тяжело тоже не хочу» в общем в расход.
взял парня с малым опытом работы на джуниора, через месяц вижу что его больше прет с клиентами общаться и доносить до программистов, что хочет клиент, на третий месяц полноценный ПМ, клиенты в восторге, программисты довольны, хотят только с ним, я тоже доволен как работает связка.
Вот так:)
его больше прет с клиентами общаться и доносить до программистов, что хочет клиент,
вообще-то это роль типичного бизнес аналитика. если у вас нет понимания таких базовых вещей (разница между ПМ и БА), то CEO вам быть явно рано.
Не вам решать быть СЕО или нет, нету у вас того уровня.
Речь шла о ПМе, который обязан общаться по тех.части в том числе, если он еще совмещает в себе обязанности тех.лида.
А вот где вы нашли не тех часть в моем месседже и где там вы увидели полноценного БА вместо ПМа, я не пойму.
Поздравляю, вы взяли не ПМ-а, а роутер сообщений между клиентами и программерами с помесячной абонплатой. ;-)
С таким тупым выводом, можно предположить что на вы не СЕО, а прокладка между заказчиками и подчиненными.
Не знаю чему их там учат...
Так сложилась жизнь, что еще в 18 лет, бедным студентом, попал в крупную корпорацию, по направлению внешнеэкономической деятельности. За пару месяцев вник в терминологию, которую до этого и на русском не знал. Потому что было желание работать и не было зашкаливающего ЧСВ а-ля «я дипломированный специалист!».
При мне сколько пытались брать «выпускников» и «выпускниц» — диагноз тот же, что вы описали. Больше месяца никто не задерживался.
А вы могли бы с мощным программерским бэкграундом управлять командой конструкторов ракет, не зная, как работает реактивный двигатель?
При соответствующей команде проекта (создание которой — как раз часть компетенции ПМа) — легко.
Получился бы продукт, запланированный на стадии предппоектного анализа.
Вы путаете тех. лида, тим. лида, ГИПа и ПМа, как и прочие здесь присутствующие.
З.Ы. Подсказка, если вы работаете в украинском аутсорсере, то ваш ПМ, скорее всего, ПМом не являецца.
А как можно провести предпроектный анализ и составить план разработки, вообще не ориентируясь в человеко-часах? И как можно ориентироваться в человеко-часах без бэкграунда? На авось? Или пригласить тех-лида? :) Иными словами — три кита управления: планирование, анализ и контроль, как можно провести без бэкграунда? Используя пятое колесо тех-лида?
> И как можно ориентироваться в человеко-часах без бэкграунда?
А что делать, если стек технологий не тот, с которым работал ПМ, когда был программером? Чем ему бекгранд поможет? Например, чем бекграунд разработки вин32 пиложений поможет ПМу в предпроектном анализе распределенного приложения на какой-нить скале?
>Иными словами — три кита управления: планирование, анализ и контроль, как можно провести без бэкграунда? Используя пятое колесо тех-лида?
Бинго! Вы начинаете понимать самые базы управления проектами. Как вариант, можно не лида, а кого-то из проектной команды, либо эксперта со стороны. Вариантов множество, но большинство из них никак не связаны с бекграундом ПМа. Более того, если вдруг бекграунд у ПМа тот, что нужен, то он включает себя в работы не как ПМа, а как эксперта, либо составляющую команды проекта. Только, вот трабла, обычно так не делают в силу того, что ПМ сильно дороже стоит найма экспертов.
Ну а что делать, если я умею водить на механической коробке, а на коробке-автомат не пробовал. Наверное, есть риск куда-то впиляться? Если рядом пассажир подсказывать не будет :)А что делать, если стек технологий не тот, с которым работал ПМ, когда был программером?
Чего далеко за примерами ходить, вот вспомните недавних министров, без соответствующего бэкграунда в домене, и президента-пчеловода :)
>Ну а что делать, если я умею водить на механической коробке, а на коробке-автомат не пробовал. Наверное, есть риск куда-то впиляться? Если рядом пассажир подсказывать не будет :)
То, о чем вы сейчас говорите — это переезд при разработке с вин32 с++ приложений на шарповые десктопные приложения. Но ведь вопрос был не в том, не так ли? Повторюсь:
>Например, чем бекграунд разработки вин32 пиложений поможет ПМу в предпроектном анализе распределенного приложения на какой-нить скале?
>Чего далеко за примерами ходить, вот вспомните недавних министров, без соответствующего бэкграунда в домене, и президента-пчеловода :)
Президент пчелвоод показал нам, что такое демократия. ДРугое дело, что народец не оценил и выбрал самое лучшее из всего, что было. Так что пчелвоод, как ПМ был годным, т.к. целям проекта своего, в принципе (кроме пересажать бандитов, т.к., в отличии от нынешней власти действовал демократическими путями, а посему накопать на посадку кого-нить не смог), следовал и их выполнил.
А вот министров — это уже годный вопрос, котоырй подтверждает мои слова, т.к. министры в контексте президента пчеловода — это не ПМы, а команда проекта, которая была весьма хреновой, это те самые эксперты, тех- и тимлиды, от которых здравый ПМ должен был избавицца.
>Например, чем бекграунд разработки вин32 пиложений поможет ПМу в предпроектном анализе распределенного приложения на какой-нить скале?
Практически ничем, я ж об этом и говорю свою мысль, на примере реактивного двигателя, коробки передач. Посему нужен бэкграунд, как вы сами подтверждаете. Если вы водить вообще не умеете — вам сильно поможет инструктор (это провожу аналогию про экспертов, как вы предлагаете), даже если у инструктора педали будут под ногами?
т.к. министры в контексте президента пчеловода — это не ПМы, а команда проекта,
ИМХО, през — заказчик, министры — пиэмы (они с народом не общаются, а поскольку заказчик должен где-то быть, и с которым общаются, посему, заказчик-през), каждый пиэм ведет свой проект,типа Налоговый Кодекс 2.0 (перевели типа на другой фреймворк, запланировали увеличение производительности побольше доходов содрать, а поскольку пиэм был геологом — он не смог эффективно руководить командой писателей, на архитекторов типа Ли Якоки средств не хватило в бюджете проекта, и гвнопроект на старых технологиях их не интересовал, и пошли баги и косяки. А на диаграммах все выглядело красиво и счастье было так близко
Ну или в разрезе product ownerа: през — заказчик, PM и principal architect в одном лице, Мыкола Яновыч — solutions architect (если рассматривать министерства как гетерогенные системы), министры — software architect, и так далее по ниспадающей :)
ИМХО, просто методологиями без базиса пользоваться абстрактно это как-то бессмысленно, иначе это просто получается лишнее передаточное звено. Как руководить без конкретики, а? Чисто «по интерфейсам?»
Ну а министры — это ближе к тех.лидам. Там бекграунд больше требуется.
Там чуть ниже умный человек привел ссылку на вики, которая подтверждает мой опыт мои слова
Кстати, так ИТ-шники, которые немного поднимаются над кодингом, и «меряются» — кто умнее самых умных своих коллег... А maturity level растет лишь у единиц. А это, имхо, — одно из самых важных достоинств РМ-а, откуда он бы не вышел — из ИТ или из других отраслей. Удачи!
Вы зря восприляли мои слова в штыки, я нисколько ни хотел. Просто представьте себе скрипача, выпускника Глиера, но, поскольку у него была военная кафедра на потоке, его поставили командиром в военной части. Он много накомандует? Удачи! :)
кто умнее самых умных своих коллег.
Это — профессиональный вид спорта :)
Как Вам?
Если от ПМ требуется просто наладить взаимодействие между самодостаточными специалистами в своей области, которые работают без волшебного пендаля — да, бэкграунд не очень и важен, главное — представлять что следует сделать каждому специалисту. Управение — это ведь по большому счету делегирование своих полномочий. Так сказать, подчиненный — это руки руководителя. Даже «руководить» — это в этимологии как «руками водить :)» А если руки что-то сделать не могут — то тут ни протез, ни делегирование ИМХО не поможет :) А если ни харизмы ни понимания в предметной области — один водитель, возивший баковских шишек как-то отгреб от банковских IT шников по физиономии за то, что пытался руководить работой IT сектора :)
с мощным программистским бэкграундом — нет, с мощным управленческим бэкграундом — да.
думаю, PM обязан быть не только хорошим психологом-менеджером, но и понимать технические процессы (иметь опыт). Не понимая, что делает команда — невозможно ориентироваться во времени выполнения и тут два варианта или давить на команду или подставлять заказчика. В обоих случаях такой PM — головная боль для всех.
Переходить между dev/BA/QA/PM — это не “расти”, а “переучиваться”. Не путайте эти понятия, плз.
Конечно же, чем шире бэкграунд у специалиста, тем он лучше, но глубокого знания своего дела это не заменяет.
А вообще, с “навичками роботи з клієнтами, партнерами” лучше идти не в ПМ, а в business development — меньше геморроя, больше общения с клиентами и денег.
В Украине ПМ-ов практически нет.
Вообще говоря, кто девушку платит, тот её и танцует. Всё руководство в аутсорсе всегда на стороне заказчика. Соответственно и руководитель проекта (project manager, ПМ) там же. Тут только техлид команды. Названия только поменялись местами, со стороны заказчика руководитель проекта называется project officier, со стороны разработчика технического лидера зовут project manager.
В этой стройной картине мира есть только один изъян — техлид плевать хотел на ПМа, так как бабло ему платит не ПМ, а руководство аутсорсера. Поэтому аутсорсеры приспособились и между ПМом и техлидом вставляют прокладку в лице бывшего QA, которого гордо называют руководителем проекта. Бывший QA на деле руководить проектом не может: у него нет ресурсов (они у заказчика) и нет влияния (с людьми работает техлидер, на то он и лидер). Бывший QA просто надувает щеки и передает приказы ПМа техлиду.
Ты хочешь стать такой прокладкой?
ЗЫ. Если ты ищещь место ПМа, начинай с того места, где раздают деньги. Не с девелоперов, которые эти деньги проедают.
По текущему опыту собеседования на позицию техлида я бы сказал наоборот: в Украине напрочь нет техлидов, есть только ПМы. Потому что настоящий техлид — это который, во-первых, *тех*, который шарит в технологиях и любит их, который любит программировать и делать это хорошо. И, во-вторых, *лид*, т.е. он хочет подтягивать команду, чтобы она тоже писала хороший код, использовала хорошие технологии. А у нас техлиды в основном как раз видят свою роль и интерес в менеджерской работе: раздавать задачи, налаживать процессы — никакое это не лидерство: лидер делает сам и показывает пример другим ;)
Ну почему же нет. Думаю в любой хорошей команде есть такой «технический лидер», даже если нет такой формальной должности. Те, кто питает интерес к менеджерской работе как раз до техлидов не дорастают — уходят в ПМы. Техлид — это ведь карьерный тупик. А ПМу наоборот — есть куда расти по менеджерской вертикали.
Может ПМ и работает «прокладкой», но это тяжелая, нервная и неблагодарная работа, которую я не стал бы делать сам (даже за большую зарплату ПМ) и благодарен что есть кто-то, кто делает ее за меня.
И даже это в идеале.
Плюс мягкое сдерживание амбиций техлида, который всегда самый-самый умный, ведь он выполняет всю работу, и гораздо лучше разбирается в продукте, просто ему некогда, PM же ни строчки кода не написал, мнений членов команды, каждый второй из которой думает: «Ну чем я хуже!», мнений руководства PM-а, которые почти готовы согласиться с амбициями техлида, мнений заказчиков, которые за эти деньги наняли бы гораздо больше программистов напрямую, все бы им объяснили про красивый сайт с кошкой и сэкономили бы кучу денег на всех этих PM-ах и пр.
На самом деле мне кажется, что действительно PM — это продолжение карьеры хорошего QA, а техлид — хорошего программиста. Просто даже потому, что доказать среднестатистическому техлиду, что PM выполняет важную работу и без него не получится так же сложно, как доказать среднестатистическому кодеру, что нужен тестировщик(и совсем не потому, что он плохо работает).
Но бывают приятные исключения... ;)
Интересная точка зрения! Я вот думал раньше, что надо расти из разработчиков в ПМ-ы.
А после того, как поработал немного ПМ-ом, задумался а надо ли оно мне и действительно ли это рост? Все-таки не хочется быть «прокладкой» между заказчиком и исполнителями, самому что-то разрабатывать и внедрять гораздо интереснее и приятнее, чем быть все время крайним и отвечать за все косяки разработчиков и «тараканов» в голове заказчика.
Девелоперами обычно становятся люди с другим складом характера (если, конечно по призванию, а не ради карьеры). Неплохой ПМ — менеджер из нужной предметной области (супермаркеты, финансы, медицина, железо), пусть даже без опыта работы в IT. Но для не-технического начальника будут прежде всего смотреть на опыт успешного руководства. Сразу после института (даже с «навыками работы») в ПМ не возьмут.
100%. Но, к сожалению, не все компании разделяют Ваше мнение. Например, СофтСерв...
Это не только возможно, но и правильно. Если уж PMу расти снизу, то лучшие PM получаются из QA, а не из девелопмента. Но еще лучше, если PM изначально имел профильное образование, потом изучал специально предметную область, а потом учился корпоративной ниндзюцу, на собственных ошибках. К сожалению такие PM встречаются тока среди западных заказчиков.
как раз на этапе «учился... на собственных ошибках»
Если расти до ПМа в своей компании то тут имеются два варианта (может не везде конечно), расти из программиста и расти из тестера. Пару раз встречались «ПМы из тестеров», то есть, без знания программерской части. Если коротко — ничего хорошего, головная боль для комманды (или наоборот, пустое место для комманды).
Знавал два вида не-технических ПМ
— Украинский. Обычно коза с образованием в виде иняза, взятая по знакомству\кумовству. Лезет везде где только можно, не знает продукт но принимает важные решения. Постоянно подставляет команду. Очень любит свешивать свою работу на програмистов.
— Импортрый, обычно с ПМ образованием. Как правило таки знает продукт и тянет всю административную часть и как правило не лезет в тех часть. Варьируется от пасивной медузы(попадалово) до дятла в хорошем смысле слова- будет долбить до победного выхода продукта.
Второй вариант как по мне может иногда лучше пм’а программера быть, особенно в молодых командах.
самый худший ПМ что я видел был с тех бекграундом как раз. но из приват банка. Уникальное сочетание пафоса, козлизма и попыток рулить всеми тех решениями не слушая никого.
Ха, помню на доу читал как кто-то собеседовал «синьора» из приватбанка у которого знания хуже чем у джуниоров оказались. Причем у них в команде из 30 человек даже системой контроля версий не пользовались.
ну кто то там таки должен свой rectum хоть с фонарем и двумя руками но находить. Все таки худо бедно а онлайн банкинг у них работает. Правда до ANZшного клиент банка им еще много лет по удобству... Подозреваю неравномерное распределение знаний и талантов.
... треба такі то тачьки, допомогу такого то чувака з вашого боку
Усе. Далі дістають все, що треба.Це вони називають removing roadblocks. За допомогою цієї нехитрої техніки вони роблять усе, щоб ви все зробили :-)
Если нет, то нетехнический ПМ сделает мир хуже и где то умрет котенок.
Еще можно пойти на ПМ который product manager, через карьеру qa,business analyst.
Нет, нереально. А если кто то всунеться, надо понижать...
б). Собственно, предыдущего опыта.
В первом случае значительным бенефитом может быть хорошее знакомство с предметной областью, для решения задач в которой разрабатывается проект. Причем чем сложнее и специфичнее эта область, тем больший это бенефит.
Во-втором играет опять же несколько факторов:б). насколько хорошо потенциальный PM представляет себе то, что он передаст команде на входе и заберет от неё на выходе?
А так — принципиальных проблем, в общем-то нет. Впрочем, возникает дополнительный вопрос: если такой переход связан с переквалификацией из чего-то иного в IT, то в чем, собственно, смысл (кроме «лежит душа») — специалист, способный эффективно управлять командой в
Навыки работы с клиентами хороши для ПМа при общении ПМ — заказчик. Но есть еще и общение ПМ — команда. А вот здесь могут быть ньюансы. Как по мне, ПМ должен иметь авторитет и уважение в команде, а для этого ему следует иметь хорошие технические знания в области, ведь именно он должен подсказывать решения в сложных ситуациях в девелопменте исходя из своего опыта. К тому же, как ПМ, не ориентирующийся в тех части, будет планировать сроки выполнения тасков или оценивать адекватность плана при скрам-схеме? Но, конечно, все зависит от компании и человека, проще ли опытного рекламиста обучить тех части или же программера обучить общению с клиентами :)
а team lead или тех дир тогда для чего?ведь именно он должен подсказывать решения в сложных ситуациях в девелопменте исходя из своего опыта.
по-моему, именно они должны заниматься разруливанием подобных вопросов
Большинство ПМ с которыми работал — именно такие бывшие толковые девелоперы. Выучили английский, их поставили ПМ ... Планирование, технические решения — все на высоте. Только вот с клиентом бывший девелопер на разных языках говорит. И получается вроде бы проект неплохой — а клиент всегда недоволен.программера обучить общению с клиентами
Не надо переучивать программеров на ПМов — потеряете хорошего специалиста а получите посредственного начальника.
Знаю одного хорошего девелопера, который когда-то мне сказал, что ПМ-ом быть хорошо потому, что код писать больше не нужно... :)
>Как по мне, ПМ должен иметь авторитет и уважение в команде, а для этого ему следует иметь хорошие технические знания в области, ведь именно он должен подсказывать решения в сложных ситуациях в девелопменте исходя из своего опыта.
Fucking shit. В циклуме нет архитекторов, тим. и тех. лидов, а всех их заменяет ПМ?
В циклуме нет архитекторов, тим. и тех. лидов, а всех их заменяет ПМ?Нет, есть все «породы», и да, — иногда тех. лид и ПМ — одно лицо, но не «все в одном» конечно, отдельный тим лид программистов при этом есть конечно.
Так накой ПМу выполнять обязанности, которые ПМскими не являюцца тогда?
2. «Сложная ситуация» — это та, которая не смогла быть решена тем же архитектором/тех лидом.
2. Весь PMI поспешно умер и начал юлой вращацца в гробу. Если любая техническая ситуация не была решена архитектором/тех. лидом (в чьи компетенции как раз и входит выполнение такого рода заданий), то ПМу не надо лезть в то, к чему он отношения не имеет, а стоит задумацца о качестве команды проекта и найти замену бесполезным и неумелым кадрам, благо, при проектном подходе риски несоответствия кадров занимаемым должностям учитываюцца в журнале рисков, как неизбежные (ибо работа с людсским фактором — вещь непредсказуемая).
Вы так размышляете о бекграунде программерском. ХОрошо, предположим, что ПМ должен быть с программерским бекграундом. Дял адекватных оценок и т.п., он должен был бы работать со всеми технологиями, котоыре есть в команде, ибо даже смежные технологии на разных языках имеют свои сложности и нюансы и требуют разной длительности. В итоге, если бы ваше утверждение о том, что ПМ должен хоть что-то смыслить в проггерстве, было верным, то ПМов должно бы было быть 150 видов (ВМ ява проектов, шарп проектов, мобайл проектов). Логично утверждать, что везде в проектах разная специфика, соответственно, ПМ не может работать вне своей предметной области. Как мы видим на джоб — сайтах, к ПМам нет требований по знаниям технологий, соответственно, ваше изначальное утверждение не подтверждено рынкам.
И да, возможно, что у вас попаболь именно от того, что вы работаете в украинском аутсорсе, где ПМы — это либо знакомства, либо бывшие проггеры и очень редко, кто-то стоящий и с профильным образованием, которого дийсно можно считать ПМом.
полностью согласен
из опыта скажу, там где нет «разделения труда» — со временем начинается хаос и бардак
Все команды проекта, где ПМ — это тоже, что и тим./тех. лид — это кал.
Вы знакомы со всеми командами девелоперов в Украине? Я поражен :)
то ПМу не надо лезть в то, к чему он отношения не имеет
Он не имеет отношения к выполнению проекта? Архитекторами не рождаются, ими становятся. А пока ими становятся, вовсе не грешно обратится за советом к более опытному специалисту в команде. О «бесполезности» тут говорить не стоит)
Взял навскидку пару вакансий с rabota.ua, требования к ПМам:Как мы видим на джоб — сайтах, к ПМам нет требований по знаниям технологий
«candidate needs good understanding of full technology stack and up to date with recent technological developments.»
И да, возможно, что у вас попаболь именно от того, что вы работаете в украинском аутсорсе
Fucking shit. В циклуме нет архитекторов, тим. и тех. лидов, а всех их заменяет ПМ?
Кажется, у кого-то неприязнь к аутсорсу :)
>Вы знакомы со всеми командами девелоперов в Украине? Я поражен :)
Извините, но зачем утруждать себя знакомствами, если результат очевиден?
>Он не имеет отношения к выполнению проекта?
К тому, что вы писюкаете там он не имеет никакого отношения, пока не наступят вехи или иные точки контроля качества/сроков/т.п.
>А пока ими становятся, вовсе не грешно обратится за советом к более опытному специалисту в команде.
Ну так обращайтесь к тому, в чьей это компетенции. Т.е., к архитектору. Если архитектор хреновый, сообщите об этом ПМу, чтобы он пофиксил свою команду проекта. Очевидно же.
>Взял навскидку пару вакансий с rabota.ua, требования к ПМам:
Про украинский ПМ читайте выше, ибо я уже писал. Так что ваши вакансии немногого стоят. Может, покажете вакансию в гугль, где на проекты на го требуецца ПМ с бекграундом в го?
>Кажется, у кого-то неприязнь к аутсорсу :)
Да нет. Прост забавно, что такая «типа» крутая конторка совмещает ПМов с техническими должностями. В то же время, ваша попаболь очевидна, ибо вы под руководством годных ПМов почти наверняка просто не работали, вот и не можете себе представить ПМа, как ПМа, а не как старшего товарища — программера.
Извините, но зачем утруждать себя знакомствами, если результат очевиден?
Я так и думал :)
К тому, что вы писюкаете там он не имеет никакого отношения, пока не наступят вехи или иные точки контроля качества/сроков/т.п.
А к чему же он тогда имеет отношение, а?)
Ну так обращайтесь к тому, в чьей это компетенции. Т.е., к архитектору. Если архитектор хреновый, сообщите об этом ПМу, чтобы он пофиксил свою команду проекта. Очевидно же.
Вы читали заквоченную фразу?
Про украинский ПМ читайте выше, ибо я уже писал. Так что ваши вакансии немногого стоят.
Во-первых, это не мои вакансии, а во-вторых, зачем ТСу обсуждать неукраинский ПМ, если он планирует стать ПМом здесь?
Может, покажете вакансию в гугль, где на проекты на го требуецца ПМ с бекграундом в го?
Покажите вакансию, где не требуется, а то мне лень искать :)
Прост забавно, что такая «типа» крутая конторка совмещает ПМов с техническими должностями.
Интересно, откуда получились такие выводы?) Вы наверняка пропустили начало предложения в виде «Как по мне». Так что не стоит привязывать свою ненависть к «типа крутой конторке» к моему личному мнению :)
Это все лирика. Открываем вики: ru.wikipedia.org/...неджер_проектов
При этом, к основным навыкам (помимо профессиональных навыков в конкретной отрасли) менеджера проектов в первую очередь относятся навыки управления ресурсами, планирование работ, а также управление рисками.
Как правило руководителями проектов становятся люди, имеющие технический опыт работы.
Роль руководителя проектов:
— вам дают идею, а вы обдумываете, как её осуществить;
— вам объясняют идею и цель замысла, устанавливают временные рамки. А вы сами уже определяетесь, возможно ли и необходимо ли выполнение такого проекта и думаете как воплотить эту идею в реальность.
Что может понимать человек, далекий от тех-бекграунда, о том, как воплотить в реальность техническую задачу?
если бы ваше утверждение о том, что ПМ должен хоть что-то смыслить в проггерстве, было верным, то ПМов должно бы было быть 150 видов (ВМ ява проектов, шарп проектов, мобайл проектов)
А вы никогда не видели описаний вакансий с заголовками вида «Требуется ПМ .NET проектов»? :)
ПМ должен иметь авторитет и уважение в команде, а для этого ему следует иметь хорошие технические знания в области, ведь именно он должен подсказывать решения в сложных ситуациях в девелопменте исходя из своего опыта.
Технические решения ПМ команде подсказывать как раз-таки и не должен — для этого есть тех. лид/архитектор. Более того, ПМу, если он по совместительству не тех. лид, в инженерную часть решения лучше не лезть вообще. Авторитет и уважение команды ПМ зарабатывает несколько другими способами — экранированием от «бзыков» клиентов и высшего руководства, разруливанием конфликтов внутри команды, созданием продуктивной рабочей обстановки и т.п.
К тому же, как ПМ, не ориентирующийся в тех части, будет планировать сроки выполнения тасков или оценивать адекватность плана при скрам-схеме?
Начнем с того, что в SCRUM такой роли, как ПМ, нет вообще :) Планированием сроков занимается вся команда, Scrum Master лишь «дирижирует» этот процесс. На вопрос про оценку адекватности плана пока не могу ответить, т.к. не понятно, какую именно проблему мы решаем — недоверия оценкам команды или подгонки плана под ожидания заказчика?
По факту, есть два течения ПМов. Одни (те, которые умные) утверждают, что для управления проектом знание специфики проекта необязательно, т.к. важным показателем ПМа являецца как раз умение создаватьл такие команды проекта, при которых сам ПМ может непосредственно занимацца управлением проектом, а не решением технических задач, другие (те, которые вышли из программеров и пр.), орут, что без знаний специфики проекта никак.
Теперь, внимание, финт ушами, те, кого я назвал умными — это PMI. Те, которые вышли из программеров — это 23х-летние синиоры, т.е юноши. без соответствующего образования, знаний и умений, а зачастую, и без достаточного количества знаний и в ИТ.
ЗАмечу, что умные дяди говорят, что знание предметной сферы упрощает жисть ПМа, если с командой проекта пробелмы, однако, не есть обязательным пререквизитом.
На украинском рынке — без понятия, т.к. на нем не работаю, на зарубежных, редко когда встретишь в пререквизитах на ПМа знания предметной обалсти.
а вы бы взяли на работу прораба без опыта работа в строительстве? зато с опытом общения с клиентами, партнерами и навыками самопиара
программистом можешь ты не быть, но разбираться в области обязан!
Правильно. І чим більше ти компетентний, тим більше у тебе шансів.
Насправді, базовий досвід є. Навики управління часом та ресурсами, підтримка проекта і т.д. зустрічається і на інших посадах, але не є там пріоритетним.
Возможно, но желательно иметь опыт разработки или тестирования (читай — самому повариться в этом “супе” в прошлом, чтобы понимать процессы изнутри и подводные камни этих процессов в том числе).
А разве мало вакансий на PM-ов без требования программерского бекграунда?покажіть хоча б одного працедавця з такими вимогами.
Если вы с нуля хотите стать РМ-ом, то, конечно, сложнее. Скорее всего прийдется идти “помошником”, стажироваться и учиться, естественно, за небольшие деньги как для начала.
В любом случае, — стоит создать хорошее CV, написать что вы умеете делать на практике и что уже делали, а так же то, что понимаете в теории; указать свои “остальные” скиллы и ожидания от работы (в том числе и финансовые, но тут не стоит “ломить цену”), закинуть его на популярные ресурсы по трудоустройствуи разослать в интересующие вас компании, и... ждать, попутно читая полезную литературу.
Тільки от практика показує, що просто залишити CV не дуже дієво. По досвіду роботи і уміннях — я продакт менеджер і в першу чергу надходять відповідні пропозиції. А компанії котрі шукаю РМів, обходять моє CV через відсутність відповідного досвіду. Замкнутий круг :)
може, знаю таких.
company.yandex.ru/...blog_search.xmlЯкщо таке явище присутнє, будь ласка, покажіть хоча б одного працедавця з такими вимогами.
і там ще багато таких
Ну це ж московський яндекс! Там да... А у нас кукіш :)
Та реально кругом полно ПМов и ТЛов которые бывшие тестировщики.
Перебирав сьогодні вакансії. Всюди є вимога про прог. бекграунд. На практиці що важливіше?
Те тестеры которых я знаю которые стали ПМами/ТЛами стали ими спустя какое-то время работы в своём проекте. Не знаю тестеров которых взяли на ПМов сходу, без опыта работы. Программеров таких знаю, да.
Что важно на практике — не знаю, я не ПМ :) . Подозреваю что всё зависит от проекта. Но по-моему вообще мало где берут ПМов без опыта работы ПМами. Так же как мало где берут программеров без опыта работы программерами :) .
Про цей чортовий круг мені вже говорили :) містика...
тут больше встает вопрос — зачем вам хочется стать ПМ?
Подобається. Працюючи з командою над задачею, я отримую задоволення. Точніше отримую його при виконанні задачі. Але зараз там де я працюю, таких випадків мінімум.
может лучше свой бизнес, не?
Roman Brunets
Beaver Green
Valter Scott
anonymous
Oleksand Maksymets
Ruslan Seredyuk
Ivan Pomidorov
Andriy Mudryy
Eugene Veselov
Illia Khabibrakhmanov
Eugene Veselov
Denys Kostin
anonymous
Illia Khabibrakhmanov
Владимир Кожаев
Олександр Петров
Alexander Pshenichniy
Yuri Bilyk
св Антоний
Aleksey Kolupaev
Oleksa Stelmakh
Aleksey Kolupaev
Crayder Crayder
Alexander Pshenichniy
Alexander Sokhanych
Alexander Sokhanych
Firster
св Антоний
trimm
Владислав Собко
Олександр Петров
flyman
Andrii Tropin
Sergiy Prokhorenko
Vsevolod Dyomkin
Beaver Green
Станислав Скребцов
flyman
Andriy Krot
Marina Ryabova
Andrey Morskoy
Нестор Иванович
Нестор Иванович
Viacheslav
Punk Floyd
reality_hacker
Dymytriy Dushkevych
Iurii Vasylenko
Oleksii Mukha
Alexander Kuznyak
Oleksii Mukha
Dmytro Lapshyn
trimm
Vova Mirnenko
Alexander Kuznyak
Леголас Трандуилович
Bogdan Verbenets
Bogdan Verbenets
Станіслав Малкін
Найкращі коментарі пропустити