Комментарии 32
спрашивают о стрессоустойчивости и способности работать в неопределенности— по личным наблюдениям, это часто идет в паре с:
Или у компании нет и не было до этого ни одного ПМ-а. Первым быть удовольствие ниже среднего — все привыкли работать и так, и не понимают зачем по итогу вы им нужны.
Если в технические компании, то исходя из моего опыта, почти всегда это либо плохо, либо очень плохо, если у руководителя нет технического бэкграунда.
Я скажу так — зависит.
В телекоммуникациях к примеру — да, без него делать особо нечего, в enterprise проектах тоже, хотя я к примеру такие веду сейчас.
Если речь об IT аутсорсинге — где разрабатывают пользовательский софт — вполне достаточно общей технической грамотности, базового понимания разработки, тестирования, сетей.
Менеджер — он 90% своего времени общается с людьми, его задача организовывать, договариваться, контролировать выполнение. Технические задачи — лежат на плечах технических специалистов, есть ведь разработчики техлиды, архитекторы. Больше скажу — плохо или очень плохо когда менеджер при наличии всех этих людей лезет в условно в код, потому как это не его епархия в целом. Да и нехорошо когда у него нет конкретно управленческого бэкграунда. Это отдельная профессия, которой надо учиться и в которой своя теория есть, исследования, практики, инструменты.
В телекоммуникациях к примеру — да, без него делать особо нечего, в enterprise проектах тоже, хотя я к примеру такие веду сейчас.
Если речь об IT аутсорсинге — где разрабатывают пользовательский софт — вполне достаточно общей технической грамотности, базового понимания разработки, тестирования, сетей.
Менеджер — он 90% своего времени общается с людьми, его задача организовывать, договариваться, контролировать выполнение. Технические задачи — лежат на плечах технических специалистов, есть ведь разработчики техлиды, архитекторы. Больше скажу — плохо или очень плохо когда менеджер при наличии всех этих людей лезет в условно в код, потому как это не его епархия в целом. Да и нехорошо когда у него нет конкретно управленческого бэкграунда. Это отдельная профессия, которой надо учиться и в которой своя теория есть, исследования, практики, инструменты.
У нас в проекте был и javascript и python и c++. И вот фронтэдщики говорят менеджеру нужно код javascript обфусцировать. И им на это время надо. Окей. Потом менеджер приходит к к сишникам и спрашивает, когда они собираются свой код обфусцировать. Посмеялись.
От себя скажу — это ужасно, когда менеджер не понимает суть технических проблем и не знает, что возможно, а что нет.
От себя скажу — это ужасно, когда менеджер не понимает суть технических проблем и не знает, что возможно, а что нет.
Менеджер мог погуглить что это значит или спросить напрямую. Это его конкретно менеджерский косяк, технический бэкграунд непричем.
В том то и дело — суть он понимать должен быть способен, просто для этого серьезного бэкграунда не требуется, достаточно грамотности.
В том то и дело — суть он понимать должен быть способен, просто для этого серьезного бэкграунда не требуется, достаточно грамотности.
Тоесть обфусцировать Си код невозможно? =)
Хм… хорошая статья. Практически один в один мои действия после первого семестра 3го курса политеха и 2 месяцев удаленного обучения по управлению проектов.
Успехов автору! Главное не прекращать учиться и повышать планку.
Успехов автору! Главное не прекращать учиться и повышать планку.
НЛО прилетело и опубликовало эту надпись здесь
Мое мнение — наоборот. Атавизм — это совмещение.
Прогресс идет — и вместе с ним специализация. Когда есть достаточно бюджета и проекты большие — можно выделить отдельного бизнес-аналитика, можно на продукте держать прожекта и продакта, с разным функционалом.
Я не говорил что их вообще описывать не надо — так или иначе надо, таски, стори. Но полноценную документацию BRD, SRS и прочее лучше и качественней пишут специализированные бизнес-аналитики. Также и с продакт менеджментом, по хорошему это вообще другая специальность, для нее нужны другие знания, навыки и опыт.
Если совмещать — то все равно в чем то будет проседать менеджер, или это будет уникум который всеми навыками владеет одинаково, но таких единицы.
Прогресс идет — и вместе с ним специализация. Когда есть достаточно бюджета и проекты большие — можно выделить отдельного бизнес-аналитика, можно на продукте держать прожекта и продакта, с разным функционалом.
Я не говорил что их вообще описывать не надо — так или иначе надо, таски, стори. Но полноценную документацию BRD, SRS и прочее лучше и качественней пишут специализированные бизнес-аналитики. Также и с продакт менеджментом, по хорошему это вообще другая специальность, для нее нужны другие знания, навыки и опыт.
Если совмещать — то все равно в чем то будет проседать менеджер, или это будет уникум который всеми навыками владеет одинаково, но таких единицы.
НЛО прилетело и опубликовало эту надпись здесь
все больше компаний идут к структуре Яндекса или Гугла
У яндекса судя по их каналу на YouTube как раз есть продакты и прожекты, первый рулит продуктом и его стратегией, метриками, развитием, второй занимается операционкой. И в целом, даже при наборе в их Школу Менеджеров там про тех скиллы почти ничего не было, общие понятия которые нагуглить можно и очень много продуктовых вопросов.
Про гугл не скажу, но думаю это и не столь важно — там другие реалии абсолютно.
Ну и сравнение конверсии с hh.ru по 2м резюме (проджекта и проджекта+продакта, есть оба опыта) не в пользу первого.
Тут мне кажется все на поверхности — больше скиллов, отсюда больше интереса. Все таки все хотят экономить, при небольших бюджетах эт вполне нормально. Просто одно дело ситуация на рынке, и другое как оно было бы правильно и эффективно в той или иной ситуации.
Ну и еще я не питаю иллюзий по поводу понимания этих моментов владельцами и топ-менеджерами компаний. Да, есть очень толковые и опытные люди, но много тех кто управление в целом, проектное в частности — представляют себе очень смутно. Оно и за последние то 5 лет изменилось очень сильно.
Я так смотрю по рейтингу самой статьи и конкретно моих комментов про уровень технических скиллов у ПМ-а — людям не нравятся такие как я, кто не программировал, не учился в политехе и не обладает технической специальностью и при этом приходят в IT, пусть и на менеджерскую позицию. Притом что мало кто знаком со мной лично, и знает мой уровень. Скорее у всех резонирует личный опыт.
Написать про это отдельную статью товарищи?
Написать про это отдельную статью товарищи?
НЛО прилетело и опубликовало эту надпись здесь
А это следствие того о чем я говорил выше — у большинства проджект ассоциируется (в жизни чаще всего так и есть) с техническим менеджером проекта который за катку релизов, декомпозицию тасок на компоненты, последовательность работ (надо понимать межкомпонентную архитектуру чтобы нарисовал сетевой график).
Есть такая мысль тоже. Хотя бывает и проще — разработчику всегда проще договориться с разработчиком. Слышал интересную идею — профессия больше сближает людей чем принадлежность к одной нации (хотя я за интернационал). К примеру россиянин-программист с высокой долей вероятности быстрее найдет общий язык с условным датчанином-программистов, чем к примеру с россиянкой, но другой профессии.
Но тут и обратная сторона медали: тру проджект по науке планирует и управляет коммуникацией, втч слушает экспертов и принимает решения а не погружается по уши во все нюансы. Кроме того по Бруксу написание кода это сколько там 30% от успеха продукта? Поэтому 70% времени проджект вообще не про тех бэкграунд. Вобщем про классический проджект менеджмент в разработке и его плюсы VS сложившаяся практика — таких статей ту пока не увидел. Дерзайте.
В точку. Просто по моему опыту, мало кто заморачивается всей нетехнической стороной, маркетингом там, бизнесом клиента и профилем юзера. Неинтересно — что и нормально в целом. Хотя проект по сути всегда делается для кого-то, чтобы решить чью-то боль, на него дает кто-то деньги, кто-то проверяет, кто-то пользуется. Непосредственно разработка без этих вещей существовать не может, ну разве что в личных проектах, и то рано или поздно стают вопросы стартаповские, а для кого, а как лучше, где тут монетизация.
В общем спасибо за мнение. Буду писать.
Такой лонгрид, а внутри ноль смысла и вода в ступе. Настоящий ПМ)))
Отличный коммент, полон смысла. Полностью компенсирует его отсутствие в моей публикации.
Вы бы хоть один аргумент привели для приличия, а то право как-то голословны.
Вы бы хоть один аргумент привели для приличия, а то право как-то голословны.
Проблема статьи в том, что в ней можно заменить менеджера проекта на любую другую профессию и никто не заметит разницы :). Очень мало специфики.
"пусть и на менеджерскую позицию" — это такой троллинг? Для многих переход на менеджерскую позицию является единственным способом зарплатного и карьерного роста и когда приз уходит новому человеку извне — это чертовски неприятно. Есть конечно и менеджерские позиции, которые никто не хотел, но там все относятся с пониманием.
Проблема статьи в том, что в ней можно заменить менеджера проекта на любую другую профессию и никто не заметит разницы :). Очень мало специфики.
Специфика с моем личном опыте, и в том что когда выбирает себе работу разработчик — это совсем другая история. Но за мнение спасибо.
позицию является единственным способом зарплатного и карьерного роста и когда приз уходит новому человеку извне — это чертовски неприятно. Есть конечно и менеджерские позиции, которые никто не хотел, но там все относятся с пониманием.
На западе — возможно. В наших реалиях менеджеры получают часто меньше разработчиков, и у последних пропадает интерес идти переходить в управление. Поэтому думаю конкретно на нашем рынке это не актуально.
MBA для ПМ без подчиненных — это жуткий оверквалифаед. MBA это сотни подчиненных, десятки-сотни миллионов долларов инвестиций.
Мне как человеку так же получившему MBA, только имеющему серьезный бэкграунд в разработке некоторые вещи бросаются в глаза.
«В случае конкретно ПМ-ов — еще я считаю важным понять, реально ли вы будете руководить проектом, или только координировать его.» — а собственно чем PM собирается руководить?
PM это не полноценный руководитель, как по мне так эта роль переоценена.
PM не отвечает за конкретную команду/подразделение — его скоуп это «проект».
PM не влияет на рабочие процессы — он временное явление рядом с командой.
PM не имеет профильного технического опыта — в следствие чего вопрос, а как подобный менеджер может повлиять на качество и сроки?
«Руководить» должен руководитель команды/подразделения, формальный и не формальный лидер, имеющий видение и стратегию развития своей команды, инструменты для мотивации и стимулирования, опыт работы в сфере и самое главное имеющий доверие своих людей.
Без этого все желания «поруководить» приводят к «чайка» менеджменту, разваленым командам и не выполненным обещаниям перед людьми.
По моему мнению PM не нужен команде разработчиков, его вполне может заменить секретарь/секретарша выполняющий административные функции. Грамотный тимлид в легкую убирает PM и растет вместе со свеой командой.
К слову большинство разработчиков имеют серьезные перспективы в росте в руководители и MBA может помочь в этом. Бизнес — это framework, MBA — документация и bootcamp
«В случае конкретно ПМ-ов — еще я считаю важным понять, реально ли вы будете руководить проектом, или только координировать его.» — а собственно чем PM собирается руководить?
PM это не полноценный руководитель, как по мне так эта роль переоценена.
PM не отвечает за конкретную команду/подразделение — его скоуп это «проект».
PM не влияет на рабочие процессы — он временное явление рядом с командой.
PM не имеет профильного технического опыта — в следствие чего вопрос, а как подобный менеджер может повлиять на качество и сроки?
«Руководить» должен руководитель команды/подразделения, формальный и не формальный лидер, имеющий видение и стратегию развития своей команды, инструменты для мотивации и стимулирования, опыт работы в сфере и самое главное имеющий доверие своих людей.
Без этого все желания «поруководить» приводят к «чайка» менеджменту, разваленым командам и не выполненным обещаниям перед людьми.
По моему мнению PM не нужен команде разработчиков, его вполне может заменить секретарь/секретарша выполняющий административные функции. Грамотный тимлид в легкую убирает PM и растет вместе со свеой командой.
К слову большинство разработчиков имеют серьезные перспективы в росте в руководители и MBA может помочь в этом. Бизнес — это framework, MBA — документация и bootcamp
PM это не полноценный руководитель, как по мне так эта роль переоценена.
PM не отвечает за конкретную команду/подразделение — его скоуп это «проект».
PM не влияет на рабочие процессы — он временное явление рядом с командой.
PM не имеет профильного технического опыта — в следствие чего вопрос, а как подобный менеджер может повлиять на качество и сроки?
Хм, мне странно что с MBA вы такое говорите. Если он не руководит то это не менеджер, это координатор — другая роль.
Он отвечает за проектную команду, не функциональную. Не буду вдаваться нюансы разных орг.структур — но если проекты и ПМ, то уже появляется матричная структура, где ПМ руководитель — проектной команды.
Проект в целом временное явление — но то как построена разработка проектов это бизнес-процесс. Я хотел передать в публикации что для ПМ-а этот самый процесс у потенциального работодателя — очень важен.
Влиять на качество — очень просто, управлением. Руководитель чего бы то ни было в целом не занимается исполнительской деятельностью, это делают другие — он управляет. И без технического опыта не значит совсем никакого понятия об этом. Уже подготовил опрос на эту тему — там можно будет обсудить как опубликую.
«Руководить» должен руководитель команды/подразделения, формальный и не формальный лидер, имеющий видение и стратегию развития своей команды, инструменты для мотивации и стимулирования, опыт работы в сфере и самое главное имеющий доверие своих людей.
Без этого все желания «поруководить» приводят к «чайка» менеджменту, разваленым командам и не выполненным обещаниям перед людьми.
Да, все так — в рамках функционального подразделения, но при той же матричной структуре руководит и ПМ.
По моему мнению PM не нужен команде разработчиков, его вполне может заменить секретарь/секретарша выполняющий административные функции. Грамотный тимлид в легкую убирает PM и растет вместе со свеой командой.
Это и есть координатор — другая роль. Про то что бывает когда его нет в другой статье писал, бывает когда все его обязанности перераспределяются, но вопрос хотят ли этого сами разработчики — выстраивать коммуникацию, принимать общие решения по проекту, общаться с заказчиком по бизнес-вопросам, заниматься досками, тасками, решать проблемы. И еще более важно — могут ли, есть ли у них навыки общения, управления, насколько они клиентоориентированы.
К слову большинство разработчиков имеют серьезные перспективы в росте в руководители и MBA может помочь в этом. Бизнес — это framework, MBA — документация и bootcamp
Не соглашусь. Руководителями в целом могут быть немногие, будь то разработчики или представители других специальностей. Это специфическая работа с большим набором как скиллов которые нужно на том же MBA получать, так и компетенций — которые надо развивать и то не у всех получится, ибо это сложнее и дольше. И вдобавок не все хотят этого. Я бы даже сказал что большинству разработчиков неинтересно много общаться с людьми, вникать в маркетинг, финансы, управление, брать на себя ответственность за результат команды, подразделения, компании. Это далеко не для всех.
Хотя конечно есть исключения — которые преуспевают в обоих сферах, но это уникальные люди, их очень немного.
Хм, мне странно что с MBA вы такое говорите. Если он не руководит то это не менеджер, это координатор — другая роль.
Тут важно не перефразировать, в моем комментарии PM обозначен как не полноценный руководитель.
Проект в целом временное явление
В точку, при этом работа с персооналом является постоянной обязанностью и привелегией руководителя — что и является для меня доводом что PM не совсем руководитель.
Влиять на качество — очень просто, управлением.
Что бы управлять — нужно понимать чем управляешь, особенно когда мы говорим о специфичных отраслях. В противном случае любой достаточно хитрый подопечный в легкую одурачит подобного «руководителя».
но при той же матричной структуре руководит и ПМ
Отчасти да, в теории все красиво работает. Но думаю вы согласитесь что это своего рода костыль в системе управления. 2 руководителя у одного подопечного? Кто приоритетнее? За кем идти? Что делать? Неоднозначности ни в процессах, ни в задачах, ни в приоритетах не должно быть.
но вопрос хотят ли этого сами разработчики — выстраивать коммуникацию, принимать общие решения по проекту, общаться с заказчиком по бизнес-вопросам, заниматься досками, тасками, решать проблемы. И еще более важно — могут ли, есть ли у них навыки общения, управления, насколько они клиентоориентированы.
На самом деле это очень хороший вопрос, не все хотят, не все могут.
Навыки общения и управления — развиваются, вопрос возможности и времени.
Мой посыл был в том что у разработчиков из за профессиональной специфики шансы стать профессиональным руководителем чуть выше. То что большинство не захочет — скорее всего.
Но это уже личный выбор.
К вопросу о двух руководителях. В крупных (да и не очень) компаниях применяется подход — линейный менеджер + операционный менеджер (в случае проектной деятельности — это проджект менеджер).
Линейный менеджер — это тот самый руководитель, который нанимает и увольняет людей и следит за их развитием. А проджект занимается управлением проектом. Говорить о том, что проджект не руководит ничем — нельзя, его власть просто ограничена его полем деятельности. Линейный тоже не император))
Тут важно не перефразировать, в моем комментарии PM обозначен как не полноценный руководитель.
Я просто утверждаю что менеджер и руководитель это синонимы. Если нет руководство — в названии позиции слова «менеджер» быть не должно. Привет всем менеджерам по продажам )
В точку, при этом работа с персооналом является постоянной обязанностью и привелегией руководителя — что и является для меня доводом что PM не совсем руководитель.
Если имеется в виду работа с персоналом в плоскости найма/увольнения, развития — то не везде и не всегда. Это безусловно дает ему больше пространства для маневра — когда он контролирует подбор и работу с персоналом. Это происходит когда внедрена сильная матричная структура. Но при этом не является обязательным атрибутом. То что он не контролирует персонал не исключает то что он будет руководить командой. Да, это будет сложнее, полномочия ограничены, но они есть.
Что бы управлять — нужно понимать чем управляешь, особенно когда мы говорим о специфичных отраслях. В противном случае любой достаточно хитрый подопечный в легкую одурачит подобного «руководителя».
Согласен. Я больше скажу — все отрасли специфические, потому и отрасли. Если погрузиться — куча нюансов, технической составляющей, специалистов и специальностей. В этом надо разбираться, надо понимать точки контроля, и тогда обмануть будет сложно. Плюс есть же тимлид, который в этом разбирается глубоко, и разработчик попытается обмануть и его.
Отчасти да, в теории все красиво работает. Но думаю вы согласитесь что это своего рода костыль в системе управления. 2 руководителя у одного подопечного? Кто приоритетнее? За кем идти? Что делать? Неоднозначности ни в процессах, ни в задачах, ни в приоритетах не должно быть.
Нет, не костыль. Но сложно — согласен. И мало кто умеет нормально строить такую систему. 2 руководителя вполне нормально, если организация гибкая и руководители толковые. А условиях неопределенности без гибкости никак — потому что функциональное подразделение заточено на выполнение одних и тех же функций регулярно, минимум неожиданностей. Когда сделать надо что-то новое, непонятное — нужны проекты. И так уже другая специфика, другое руководство. Если разделить грамотно и распределить время — то вполне можно организовать чтоб работало нормально. Насчет неоднозначности — не надо пытаться ее убрать, это невозможно, потому что весь мир неоднозначен, есть куча факторов которые влияют, черные лебеди вон с коронавирусом. Выход — научиться работать в таких условиях, вот матричная структура как раз так и появилось, когда стало понятно что не выгребают и надо как-то менять процесс. Её не ввели просто потому что кому так вздумалось — таковы были условия.
Навыки общения и управления — развиваются, вопрос возможности и времени.
Тут есть момент. Пресловутые хард скиллз и софт скиллз, вторые по русски это компетенции. Так вот компетенции развиваются сложнее — потому что это по сути личные качества, проявляемые на работе. Вы видели когда нибудь чтобы личные качества людей быстро менялись? На это уходят годы работы над собой, по исследованиям в год можно прокачать на уровень одну, максимум две компетенции. А их десятки.
Второй момент — есть нулевой уровень компетенции, когда её у человека нет, и не будет. То есть нет потенциала её развития, он просто не может и всё. Шансы что он её разовьет настолько мал, что проще сфокусировать на других. Это я говорю про общение например. Управление это хард скилл который можно развить быстрее.
Мой посыл был в том что у разработчиков из за профессиональной специфики шансы стать профессиональным руководителем чуть выше. То что большинство не захочет — скорее всего.
Но это уже личный выбор.
Ну вот я с этим не согласен. Единственный аргумент такого подхода — хорошее знание сферы. Но это лишь одна составляющая управления, и не первого порядка. Именно по причине вышеперечисленные нюансов софт скиллов/компетенций — она не настолько важна. Еще раз — важна, но не самая важная.
Потому что коммуникация и управленческие навыки важнее. И потому это хард скиллы, их развить проще, чем научиться общаться.
Разработчики которые выходят в тим лиды, ПМ-ы, СТО, СЕО — это как правило люди у которых изначально был потенциал к этому, у них не было проблем с общением, они неплохо ориентировались в неопределенности, брали на себя роль неформального лидера. Это моя позиция.
Но тем не менее — если есть еще аргументы против — пишите, для меня интересно всегда подискутировать на эту тему. Не считаю свое мнение истиной в последней инстанции.
Я так смотрю по рейтингу самой статьи и конкретно моих комментов про уровень технических скиллов у ПМ-а — людям не нравятся такие как я, кто не программировал, не учился в политехе и не обладает технической специальностью и при этом приходят в IT, пусть и на менеджерскую позицию.
Нет, дело не только в «нравится — не нравится». ПМ это прежде всего коммуникация, а она приходит с опытом. То, что вы описали — это поиск работы на позицию координатора проектов, очень джуниор ПМ. Нормальный проджект должен уметь отличать бэк от фронта, знать технический бэкграунд, но прежде всего — понимать процесс разработки. Что на входе, что на выходе, как организовать требования заказчика, как заказчика убедить строить небоскрёб не из фанеры, а скворечник не башенным краном. Я не могу отправить моего прекрасного тимлида общаться с заказчиком в одно лицо: тимлид слишком дофига знает, умеет и может, в итоге мы можем получить непредсказуемый набор работ с непредсказуемый сроками. ПМ должен, не обидев заказчика, уметь говорить «нет», равно как и «да, но после MVP», и не забывать про «вот вам бесплатная плюшка за то, что оплатили нашу работу вчера».
А с другой стороны у меня тимлид и набор девелоперов, каждый со своими плюсами и особенностями, и мне надо понимать, как с ними общаться, какой информацией их порадовать, и кто горит желанием выйти 8 марта за двойную оплату, а кого не пинговать до конца короткой недели.
Совсем не вижу связи между вашим тезисом что это для джуниор ПМ-а или координатора.
И с тем что должен отличать бэк от фронта, и понимать разработку — абсолютно согласен. И сам этими вещами владею. Про коммуникацию аналогичной позиции придерживаюсь что и вы, и про все остальное. С клиентами я работаю именно так как вы описали. Тимлид занимается техническими вопросами, и оказывает поддержку ПМ-у своей экспертизой, но не проводит за него переговоры с клиентом.
Просто отличать бэк от фронта условно, и разбираться глубоко, имея за плечами опыт и профильное образование — это разное. Под техническим бэкграундом я подразумеваю системную подготовку. То что вы описали я называю общей технической грамотностью, которую можно развить даже самостоятельно и работая бок о бок с сильными техническими специалистами которые делятся знаниями.
И с тем что должен отличать бэк от фронта, и понимать разработку — абсолютно согласен. И сам этими вещами владею. Про коммуникацию аналогичной позиции придерживаюсь что и вы, и про все остальное. С клиентами я работаю именно так как вы описали. Тимлид занимается техническими вопросами, и оказывает поддержку ПМ-у своей экспертизой, но не проводит за него переговоры с клиентом.
Просто отличать бэк от фронта условно, и разбираться глубоко, имея за плечами опыт и профильное образование — это разное. Под техническим бэкграундом я подразумеваю системную подготовку. То что вы описали я называю общей технической грамотностью, которую можно развить даже самостоятельно и работая бок о бок с сильными техническими специалистами которые делятся знаниями.
Для российского IT не нужен MBA. Это я понял и по рынку и на собственном опыте. Посмотрите вакансии на HH. Там только котируется PMP, и то, достаточно редко.
Если вы его получили — это плюс для вас, но лучше помалкивать. Как минимум на собеседовании. Иначе столкнетесь с негативом. У меня было такое неоднократно, когда собеседующий, потенциальный начальник, осознает, что у меня управленческого опыта больше чем у него, да еще и МБА.
Культура управлением проектов в IT, где делают веб вообще низкая. И разработки зачастую тоже (большая часть веб-разработчиков — самоучки). Культура годного менеджмента и качественной разработки в вебе стала пропагандироваться только в последние годы. Затраты на её поддержание и развитие часто не по карману интернет-компаниям. Но оправданием обычно служат не затраты, а стремление к Lean и Agile (на самом деле это чаще приводит к халатности «И так сойдет»).
В web IT PM — это тот, кто связывает бизнес и разработку, а функция управления скопом — это приятное дополнение. И результат от него ожидают каждый свой. Разрабы — чтобы меньше было работы и она была четче, бизнес — чтобы быстрее и больше было сделано. Соответственно, вы должны уметь говорить на одном языке и договариваться с этими разными группами людей. А как это будет реализован процесс проекта — мало кого волнует.
Если вы его получили — это плюс для вас, но лучше помалкивать. Как минимум на собеседовании. Иначе столкнетесь с негативом. У меня было такое неоднократно, когда собеседующий, потенциальный начальник, осознает, что у меня управленческого опыта больше чем у него, да еще и МБА.
Культура управлением проектов в IT, где делают веб вообще низкая. И разработки зачастую тоже (большая часть веб-разработчиков — самоучки). Культура годного менеджмента и качественной разработки в вебе стала пропагандироваться только в последние годы. Затраты на её поддержание и развитие часто не по карману интернет-компаниям. Но оправданием обычно служат не затраты, а стремление к Lean и Agile (на самом деле это чаще приводит к халатности «И так сойдет»).
В web IT PM — это тот, кто связывает бизнес и разработку, а функция управления скопом — это приятное дополнение. И результат от него ожидают каждый свой. Разрабы — чтобы меньше было работы и она была четче, бизнес — чтобы быстрее и больше было сделано. Соответственно, вы должны уметь говорить на одном языке и договариваться с этими разными группами людей. А как это будет реализован процесс проекта — мало кого волнует.
Для российского IT не нужен MBA. Это я понял и по рынку и на собственном опыте. Посмотрите вакансии на HH. Там только котируется PMP, и то, достаточно редко.
Если вы его получили — это плюс для вас, но лучше помалкивать. Как минимум на собеседовании. Иначе столкнетесь с негативом. У меня было такое неоднократно, когда собеседующий, потенциальный начальник, осознает, что у меня управленческого опыта больше чем у него, да еще и МБА.
Тоже были такие прецеденты, но это проблема руководителя. Моя личная позиция — мой MBA помимо того что это было отличное образование, еще дал громадный опыт жизни в другой культурной и языковой среде, оба фактора для меня важны — и если потенциальный работодатель комплексует по этому поводу, то скорее всего нам с ним не по пути.
Были с другой стороны и положительные примеры — когда руководители цеплялись этот пункт из резюме, и использовали мои знания и опыт во благо. В целом это проблема управленческой культуры — но это отдельная большая тема.
Культура управлением проектов в IT, где делают веб вообще низкая. И разработки зачастую тоже (большая часть веб-разработчиков — самоучки). Культура годного менеджмента и качественной разработки в вебе стала пропагандироваться только в последние годы. Затраты на её поддержание и развитие часто не по карману интернет-компаниям. Но оправданием обычно служат не затраты, а стремление к Lean и Agile (на самом деле это чаще приводит к халатности «И так сойдет»).
Увы, это так. Про разработчиков не скажу точно — но про управление абсолютно так. Мобайл аналогично, и энтерпрайз туда же. Мне кажется дело даже не в том что пропагандируется, хотя и это тоже. Просто растем, и когда растет сложность, становится больше неопределенности — без толкового руководства совсем никуда. Нельзя просто собрать программистов, тестировщиков и надеяться что они сами все построят — их надо еще и организовать, создать условия. Управлять тоже надо уметь. И ждать от технического специалиста этого по умолчанию, без какой либо подготовке — наивно.
В web IT PM — это тот, кто связывает бизнес и разработку, а функция управления скопом — это приятное дополнение. И результат от него ожидают каждый свой. Разрабы — чтобы меньше было работы и она была четче, бизнес — чтобы быстрее и больше было сделано. Соответственно, вы должны уметь говорить на одном языке и договариваться с этими разными группами людей. А как это будет реализован процесс проекта — мало кого волнует.
Абсолютно так.
Из всех ваших описаний ясно, что вы видите РМ только в аутсорсной разработке (клиент в продуктовой это конечный потребитель, заказчик в продуктовой больше ставит цель верхнеуровнево и не ходит к кодерам). РМ в аутсорсе отвественнен за «проект», в том чтобы он не провалился, но часто полномочий у него мало — влиять напрямую на кол-во людей в команде он не может (бюджет определяет клиент), увольнять людей может только в рамках проекта. «Просто по моему опыту, мало кто заморачивается всей нетехнической стороной, маркетингом там, бизнесом клиента и профилем юзера.» — этого РМ-у в аутсорсной и вовсе не будут давать, так как никто не поверит что он что-то может. Чаще всего РМ ответственен за коммуникацию, за мотивирование, координацию. Но если команда небольшая, то это всё прекрасно закрывает ВА, если команда большая, то он просто следит за организацией процесса, и пытается закрывать проблемы по мере возможностей. Плюс общение с заказчиком на старте, но тут и составление договора, и проработка первоначальной документации. Ну и быть ответственным, что заказчик «рад» заплатить по счёту.
В продуктовой компании РМ больше имеет полномочий, за счёт того что команду можно набирать и увольнять, и чаще нужно вести людей в плане их развития (курсы, ревью знаний, рост по позициям). Опять же в продуктовой компании это может совмещать продакт в себе. Отдельный продакт и РМ возможны, но это означает что РМ номинальный и чаще всего он слишком похож на тимлида (Яндекс в пример, всё именно так).
Нужен ли для координации и организации небольших команд разработки до 15-ти человек (большие всегда будут дробить на небольшие) МВА? С моей точки зрения — он не бесполезен, но не нужен в полной мере.
К самой статье есть ряд замечаний, но в целом она слишком «общая». Изучение компании лучше начинать с человека который уходит с вашей позиции или работает на аналогичной, так же не стесняться задавать эти вопросы при собеседовании — «Почему ушёл предыдущий? Чем занимается другой РМ сейчас? Могу ли я с ним пообщаться, чтобы лучше понять организацию работы?».
В продуктовой компании РМ больше имеет полномочий, за счёт того что команду можно набирать и увольнять, и чаще нужно вести людей в плане их развития (курсы, ревью знаний, рост по позициям). Опять же в продуктовой компании это может совмещать продакт в себе. Отдельный продакт и РМ возможны, но это означает что РМ номинальный и чаще всего он слишком похож на тимлида (Яндекс в пример, всё именно так).
Нужен ли для координации и организации небольших команд разработки до 15-ти человек (большие всегда будут дробить на небольшие) МВА? С моей точки зрения — он не бесполезен, но не нужен в полной мере.
К самой статье есть ряд замечаний, но в целом она слишком «общая». Изучение компании лучше начинать с человека который уходит с вашей позиции или работает на аналогичной, так же не стесняться задавать эти вопросы при собеседовании — «Почему ушёл предыдущий? Чем занимается другой РМ сейчас? Могу ли я с ним пообщаться, чтобы лучше понять организацию работы?».
Из всех ваших описаний ясно, что вы видите РМ только в аутсорсной разработке
Я говорю именно про менеджера проекта, и из этого следует что мое видение непричем, по факту в IT — проекты имеют место зачастую именно в аутсорсе. Не берем крупные не IT компании со своим проектным офисом — это другая истории. Это следует из самого понятия проекта.
РМ в аутсорсе отвественнен за «проект», в том чтобы он не провалился, но часто полномочий у него мало — влиять напрямую на кол-во людей в команде он не может (бюджет определяет клиент), увольнять людей может только в рамках проекта. «Просто по моему опыту, мало кто заморачивается всей нетехнической стороной, маркетингом там, бизнесом клиента и профилем юзера.» — этого РМ-у в аутсорсной и вовсе не будут давать, так как никто не поверит что он что-то может. Чаще всего РМ ответственен за коммуникацию, за мотивирование, координацию. Но если команда небольшая, то это всё прекрасно закрывает ВА, если команда большая, то он просто следит за организацией процесса, и пытается закрывать проблемы по мере возможностей. Плюс общение с заказчиком на старте, но тут и составление договора, и проработка первоначальной документации. Ну и быть ответственным, что заказчик «рад» заплатить по счёту.
Согласен, сплошь и рядом так — но считаю это минусом. Недостатками организации, и к этому постепенно приходят компании.
В продуктовой компании РМ больше имеет полномочий, за счёт того что команду можно набирать и увольнять, и чаще нужно вести людей в плане их развития (курсы, ревью знаний, рост по позициям). Опять же в продуктовой компании это может совмещать продакт в себе. Отдельный продакт и РМ возможны, но это означает что РМ номинальный и чаще всего он слишком похож на тимлида (Яндекс в пример, всё именно так).
В продуктовой компании ПМ — это продакт менеджер, посколько в ней нет проектов. Совсем другая роль, которую я не берусь описывать, там своя специфика. Продуктовая разработка не предполагает окончания, по крайней мере не планирует его. Проект же это предполагает всегда. И согласен что ПМ в продуктовых компаниях, это номинально, если развернуто называть его менеджером проектов, то терминологически это неверно. Скорее это как вы справедливо заметили — тимлид, либо зам продакта по операционке, либо координатор.
Нужен ли для координации и организации небольших команд разработки до 15-ти человек (большие всегда будут дробить на небольшие) МВА? С моей точки зрения — он не бесполезен, но не нужен в полной мере.
Не нужен абсолютно, я в принципе нигде и не говорил что нужен. Концепт MBA это в целом подготовка менеджером топ звена. Проектного управления к слову там почти нет, общие понятия не более. Польза скорее в том что даются достаточно четкие абстрактные закономерности и схемы, которые применимы практически в любой отрасли.
К самой статье есть ряд замечаний, но в целом она слишком «общая».
Это сделано вполне осознанно. Я в целом специализируют на общих вещах, стараясь выявить в них закономерности, попытаться сориентироваться в тумане.
Если уж совсем точно не общая, она просто не конкретная. Поскольку при выбора места работы информации мизер — конкретики нет и быть не может. Этот процесс нельзя уложить в четкую схему, так как для него недостаточно данных. В любом случае мы знаем очень мало и ориентируемся наощупь, с высокой вероятностью неожиданностей. В жизни в целом мне кажется все так и происходит — мы очень многого не знаем. Выражаясь терминологией системного мышления по Леванчуку — это уровень схемоида, но точно не схемы.
К слову хочу написать про это — может там товарищи хабровцы увидят высокий технический уровень.
Изучение компании лучше начинать с человека который уходит с вашей позиции или работает на аналогичной, так же не стесняться задавать эти вопросы при собеседовании — «Почему ушёл предыдущий? Чем занимается другой РМ сейчас? Могу ли я с ним пообщаться, чтобы лучше понять организацию работы?».
Замечание справедливо. Я этот момент не осветил, хотя он важен.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как менеджеру проектов выбирать себе работу