Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Чи це Реально: Project Manager без програмістського бекграунда?

Так, я знаю, що не раз піднімався цей холівар. Але вважайте це моєю прихоттю (хочу щоб іконкі були на робочому столі...).

Так чи може бути проджект манагер без програмістського досвіду, але з навичками роботи з клієнтами, партнерами (також для самопіару, по вимозі, можу надати список своїх навиків :)?

Якщо таке явище присутнє, будь ласка, покажіть хоча б одного працедавця з такими вимогами.

Якщо ні, то чому?

Дякую.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

В Украине ПМ-ов практически нет.

Вообще говоря, кто девушку платит, тот её и танцует. Всё руководство в аутсорсе всегда на стороне заказчика. Соответственно и руководитель проекта (project manager, ПМ) там же. Тут только техлид команды. Названия только поменялись местами, со стороны заказчика руководитель проекта называется project officier, со стороны разработчика технического лидера зовут project manager.

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

Ты хочешь стать такой прокладкой?

ЗЫ. Если ты ищещь место ПМа, начинай с того места, где раздают деньги. Не с девелоперов, которые эти деньги проедают.

ИМХО: лучше всего когда техническое и административное руководство на проекте разделены. У тех-лида (архитектора) обязательно должен быть технический опыт и хорошая теоретическая база знаний по технологиям. У ПМ наоборот — не должно быть «программистского бекграунда» что бы он смотрел на приложение со стороны пользователя и мог понимать бизнес не-технического заказчика. Из основных требований ПМ — хорошее владение языком. При этом не только в смысле английского, а так же в смысле «язык хорошо подвешен» (а для некоторых и «лизнуть», если придется). Харизма, коммуникабельность, применение психологии (и для заказчика и для команды), «лидерство» и настойчивость, когда надо.

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

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

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

чтоб тебя уважали нужно Lead by Example

В Украине, чтоб тебя уважали нужно Lead by Example или «делай как я» по-нашему. По этому если хочешь стать PM, который стоит денег, а не носит кофе и выступает предметом шуток девов, не поленись хотя бы Hello World написать на нескольких языках: уже будет о чем рассказать в команде :-)

Мав недавно схожу ситуацію (знайомий шукав роботу ПМ, мав IT освіту але без досвіду в IT, досвід комунікацій і всі софт скілс на місці). І я щиро вірив, що ПМ може бути без девелоперського бегграунда. Виявилося — це практично не можливо в аутсорсі. Чому ?
ПМ (згідно PMP) це людина що керує проектом — великим проектом, з великим бюджетом та іншими ресурсами. А ми в аутсорсі — це так «прораби». У нас маленькі команди, невеликі проекти, а інколи ми просто підрядники. Власникам бізнесу не потрібні прораби без знань предметної області, це ризиковано.

Якщо ви хочете бути ПМ в ІТ, то я раджу почати з ВА. Якщо задатки справді є — то за рік можна говорити про пм.

Ну почему же, в GlobalLogic, Cicklum и может быть EPAM есть достаточно большие проекты, с командами по 50-60 человек.

На SoftServe є також кілька проектів з командами 50+

Крім того, я би дуже застерігав того, хто хоче зробити кар’єру PM-а вихдячи з BA. Зовсім різні способи мислення, зовсім різні способи сприйняття дійсності. Найбільший ризик тут полягає в тому, що найімовірніше, що ти так і не станеш ні нормальним BA ні нормальним PM в тому випадку.

Кто то заметил, что ни один ПМ тут особо не засветился ? :-)

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

Именно поэтому генерал Гровс справился с Манхеттенским проектом и эпически бы облажался, если ему нужно было бы сколотить команду из 3 девов, 2 КУА и бизнес аналитика чтобы написать новую версию энгри бердс под Андроид.

задача любого специалиста — «выполнить задачу в рамках имеющихся ограничений»
— какие задачи?

— какие ограничения?

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

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

И при этом команду менеджить, контролировать и отвечать головой

За навигационное оборудование взялся бы -) и можно ли только сроки немножко расширить ? каков бюджет проекта ? -))))

Я не троллю, и работу предложить не могу =(
Но все таки:
— Какое оборудование необходимо закупить для каллибровки и тестирования оборудования? (каждая установка равна как минимум вашей годовой зарплате)
— Где вы будете производить свое навигационное оборудование (навскидку)

— Состав комманд (грубо список специалистов и их количество навскидку)

Первое что пришло в голову )

Вопросы — чисто размять мозги, по желанию ессно..

я не буду работать бесплатно-)

Активы процессов организации должны помочь. Из PMBOK4
Входы:
.1 Описание работ проекта
.2 Экономическое обоснование
.3 Контракт
.4 Факторы среды предприятия
.5 Активы процессов организации

Выход — Устав проекта.

А дальше все пойдет как по маслу.

Все, что сложно и непонятно можно разложить на понятные части, понять эти понятные части и систематизировать.

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

ПМ — это все-таки не генерал, а унтер-офицер.
Генерал скорее топ-менеджер :)

Не пойму, почему все так возбуждаются на бирки? senior developer, tech lead, team lead, project manager, project owner..
Вопрос стоит по другому: может ли челоек называть себя «Старший Куратор Ордена Кленового Листа»?
Может
Может ли он провести операцию на сердце?
Нет

А почему? Обязанности слабо привязаны к «бирке» и сильно привязано к обязанностям в комманде/компании.

почему все так возбуждаются на бирки? senior developer, tech lead, team lead, project manager, project owner..

Потому, что в оутсорсе чем больше к твоему имени прикреплено погремушек, тем дороже тебя можно загнать клиенту. Соответственно, тем больше ты получишь бабла :)

это понимаем мы, это понимают компании-аутсорсеры, это понимают заказчики...
где интрига то?

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

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

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

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

конечно, да! главное — компетенции управленца, лидера. хрестоматийный пример: генерал Лесли Гровс, реализовавший Манхеттенский проект.

оставил шикарные мемуары, must read каждому ПМу.

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

В третьих, даже если допустить что во-первых и во-вторых не хватает, с чего вы вобще взяли что он не провалил проект — все сроки сорвал: ядерное оружие практически не сыграло роли в войне, безопасность не обеспечил — СССР получил ядерную бомбу через четыре года в разы «дешевле»?

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

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

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

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

Так как отечественной школы менеджмента, фактически, нет, то прорваться «из девелоперов» — весьма востребованный канал. Но это не везде так.

гораздо полезнее иметь “за плечами” несколько успешных проектов в роли ПМ.

Для того щоб бути ПМ-ом треба бути ПМ-ом :) Геніально! Універсальна порада...

Занимать должность «ПМ» и окончить успешно несколько проектов — это совсем не одно и то же.

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

Ще додам, що під бекграундом розумію не конкретно програмістський б., а загальний software development так би мовити

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

Тільки дещо ,що знайшов

Колишній Директор програми F22 Raptor — Sean Frisbee
Дивимося про нього — acdis.illinois.edu/...html&pid=71

Ну зовсім людина без бекграунда так сказати....

Проект создания ЗРС С-400 «Триумф» с дальней границей зоны поражения около 400 км был рассмотрен в 1988 г.
Разработка системы, способной решать задачи ПВО и нестратегической ПРО,
была поручена ЦКБ «Алмаз» под руководством генерального конструктора А.А. Леманского.
Стосовно Леманского:
ru.wikipedia.org/...андр_Алексеевич

Знов людина без бекграунда....

А тепер дивимося на Windows Phone
conversations.nokia.ru/...-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 растет лишь у единиц. А это, имхо, — одно из самых важных достоинств РМ-а, откуда он бы не вышел — из ИТ или из других отраслей. Удачи!

Вы зря восприляли мои слова в штыки, я нисколько ни хотел. Просто представьте себе скрипача, выпускника Глиера, но, поскольку у него была военная кафедра на потоке, его поставили командиром в военной части. Он много накомандует? Удачи! :)

кто умнее самых умных своих коллег.

Это — профессиональный вид спорта :)

...А мне кажется, я четко уловил тон Вашего месседжа. Ну, неважно.
Давайте разберемся со скрипачем. Я ведь кстати, тоже поддерживаю мысль о том, что матчасть в некотором фундаментальном виде нужна. Если кого-то поставили руководить, пусть в/ч, значит, он должен соотвествовать, по моему мнению, таким критериям: а) заслуживать доверия как подчиненный; б) правильно понимать цели проекта (чего достичь); в) уметь управлять людьми (Менеджер); г) уметь управлять ограниченными ресурсами, в первую очередь, временем; д) иметь тактики, методы, навыки, управляя людьми и другими ресурсами, дотигать подобных поставленных целей; е)иметь представление, а возможно и план, как достичь конкретных в данному случае целей; ж) уметь предвидеть риски, но не бояться рисковать, в т.ч. с помощью интуиции...

Как Вам?

По поводу скрипача и в/ч — тут ИМХО сработает п.ЖЭ, где интуиции нужно быть 99% (экстрасенс, накачанный психотропами :)

Если от ПМ требуется просто наладить взаимодействие между самодостаточными специалистами в своей области, которые работают без волшебного пендаля — да, бэкграунд не очень и важен, главное — представлять что следует сделать каждому специалисту. Управение — это ведь по большому счету делегирование своих полномочий. Так сказать, подчиненный — это руки руководителя. Даже «руководить» — это в этимологии как «руками водить :)» А если руки что-то сделать не могут — то тут ни протез, ни делегирование ИМХО не поможет :) А если ни харизмы ни понимания в предметной области — один водитель, возивший баковских шишек как-то отгреб от банковских IT шников по физиономии за то, что пытался руководить работой IT сектора :)

с мощным программистским бэкграундом — нет, с мощным управленческим бэкграундом — да.

малореально в нашій реальності, якщо не по блату

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

Переходить между dev/BA/QA/PM — это не “расти”, а “переучиваться”. Не путайте эти понятия, плз.

Конечно же, чем шире бэкграунд у специалиста, тем он лучше, но глубокого знания своего дела это не заменяет.

А вообще, с “навичками роботи з клієнтами, партнерами” лучше идти не в ПМ, а в business development — меньше геморроя, больше общения с клиентами и денег.

В Украине ПМ-ов практически нет.

Вообще говоря, кто девушку платит, тот её и танцует. Всё руководство в аутсорсе всегда на стороне заказчика. Соответственно и руководитель проекта (project manager, ПМ) там же. Тут только техлид команды. Названия только поменялись местами, со стороны заказчика руководитель проекта называется project officier, со стороны разработчика технического лидера зовут project manager.

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

Ты хочешь стать такой прокладкой?

ЗЫ. Если ты ищещь место ПМа, начинай с того места, где раздают деньги. Не с девелоперов, которые эти деньги проедают.

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

Ну почему же нет. Думаю в любой хорошей команде есть такой «технический лидер», даже если нет такой формальной должности. Те, кто питает интерес к менеджерской работе как раз до техлидов не дорастают — уходят в ПМы. Техлид — это ведь карьерный тупик. А ПМу наоборот — есть куда расти по менеджерской вертикали.

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

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

И даже это в идеале.

Плюс мягкое сдерживание амбиций техлида, который всегда самый-самый умный, ведь он выполняет всю работу, и гораздо лучше разбирается в продукте, просто ему некогда, PM же ни строчки кода не написал, мнений членов команды, каждый второй из которой думает: «Ну чем я хуже!», мнений руководства PM-а, которые почти готовы согласиться с амбициями техлида, мнений заказчиков, которые за эти деньги наняли бы гораздо больше программистов напрямую, все бы им объяснили про красивый сайт с кошкой и сэкономили бы кучу денег на всех этих PM-ах и пр.

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

Но бывают приятные исключения... ;)

Интересная точка зрения! Я вот думал раньше, что надо расти из разработчиков в ПМ-ы.
А после того, как поработал немного ПМ-ом, задумался а надо ли оно мне и действительно ли это рост? Все-таки не хочется быть «прокладкой» между заказчиком и исполнителями, самому что-то разрабатывать и внедрять гораздо интереснее и приятнее, чем быть все время крайним и отвечать за все косяки разработчиков и «тараканов» в голове заказчика.

ИМХО: лучше всего когда техническое и административное руководство на проекте разделены. У тех-лида (архитектора) обязательно должен быть технический опыт и хорошая теоретическая база знаний по технологиям. У ПМ наоборот — не должно быть «программистского бекграунда» что бы он смотрел на приложение со стороны пользователя и мог понимать бизнес не-технического заказчика. Из основных требований ПМ — хорошее владение языком. При этом не только в смысле английского, а так же в смысле «язык хорошо подвешен» (а для некоторых и «лизнуть», если придется). Харизма, коммуникабельность, применение психологии (и для заказчика и для команды), «лидерство» и настойчивость, когда надо.

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

100%. Но, к сожалению, не все компании разделяют Ваше мнение. Например, СофтСерв...

Это не только возможно, но и правильно. Если уж PMу расти снизу, то лучшие PM получаются из QA, а не из девелопмента. Но еще лучше, если PM изначально имел профильное образование, потом изучал специально предметную область, а потом учился корпоративной ниндзюцу, на собственных ошибках. К сожалению такие PM встречаются тока среди западных заказчиков.

похоже, я на этой дорожке сейчас

как раз на этапе «учился... на собственных ошибках»

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

Знавал два вида не-технических ПМ

— Украинский. Обычно коза с образованием в виде иняза, взятая по знакомству\кумовству. Лезет везде где только можно, не знает продукт но принимает важные решения. Постоянно подставляет команду. Очень любит свешивать свою работу на програмистов.

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

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

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

Ха, помню на доу читал как кто-то собеседовал «синьора» из приватбанка у которого знания хуже чем у джуниоров оказались. Причем у них в команде из 30 человек даже системой контроля версий не пользовались.

ну кто то там таки должен свой rectum хоть с фонарем и двумя руками но находить. Все таки худо бедно а онлайн банкинг у них работает. Правда до ANZшного клиент банка им еще много лет по удобству... Подозреваю неравномерное распределение знаний и талантов.

Вброс такой отличный получился

Плюсую до дятла.
Навіть кухарка може бути ПМ-ом.
Для цього їй достатньо навчитися регулярно задавати 2 питання
1) чому не зроблено?
... тому то
2) чи треба якісь додаткові ресурси (людські чи технічні) і де їх дістати?

... треба такі то тачьки, допомогу такого то чувака з вашого боку

Усе. Далі дістають все, що треба.

Це вони називають removing roadblocks. За допомогою цієї нехитрої техніки вони роблять усе, щоб ви все зробили :-)

Если в компании есть понятие development manager, то в не техническом ПМ-е нет ничего плохого.

Если нет, то нетехнический ПМ сделает мир хуже и где то умрет котенок.

Еще можно пойти на ПМ который product manager, через карьеру qa,business analyst.

Нет, нереально. А если кто то всунеться, надо понижать...

Зависит от
а). Проекта(тов), которыми предполагается управлять.

б). Собственно, предыдущего опыта.

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

Во-втором играет опять же несколько факторов:
а). был ли опыт, собственно, управления командой (роль PM-а — это не только общение с заказчиком)?

б). насколько хорошо потенциальный PM представляет себе то, что он передаст команде на входе и заберет от неё на выходе?

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

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

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

а team lead или тех дир тогда для чего?

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

программера обучить общению с клиентами

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

Не надо переучивать программеров на ПМов — потеряете хорошего специалиста а получите посредственного начальника.

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

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

Fucking shit. В циклуме нет архитекторов, тим. и тех. лидов, а всех их заменяет ПМ?

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

Так накой ПМу выполнять обязанности, которые ПМскими не являюцца тогда?

1. Команды бывают разных размеров и комплектаций в зависимости от проектов.

2. «Сложная ситуация» — это та, которая не смогла быть решена тем же архитектором/тех лидом.

1. Все команды проекта, где ПМ — это тоже, что и тим./тех. лид — это кал. Это абсолютно разные знания и предметные области.

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

Вы так размышляете о бекграунде программерском. ХОрошо, предположим, что ПМ должен быть с программерским бекграундом. Дял адекватных оценок и т.п., он должен был бы работать со всеми технологиями, котоыре есть в команде, ибо даже смежные технологии на разных языках имеют свои сложности и нюансы и требуют разной длительности. В итоге, если бы ваше утверждение о том, что ПМ должен хоть что-то смыслить в проггерстве, было верным, то ПМов должно бы было быть 150 видов (ВМ ява проектов, шарп проектов, мобайл проектов). Логично утверждать, что везде в проектах разная специфика, соответственно, ПМ не может работать вне своей предметной области. Как мы видим на джоб — сайтах, к ПМам нет требований по знаниям технологий, соответственно, ваше изначальное утверждение не подтверждено рынкам.

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

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

Все команды проекта, где ПМ — это тоже, что и тим./тех. лид — это кал.

Вы знакомы со всеми командами девелоперов в Украине? Я поражен :)

то ПМу не надо лезть в то, к чему он отношения не имеет

Он не имеет отношения к выполнению проекта? Архитекторами не рождаются, ими становятся. А пока ими становятся, вовсе не грешно обратится за советом к более опытному специалисту в команде. О «бесполезности» тут говорить не стоит)

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

Взял навскидку пару вакансий с rabota.ua, требования к ПМам:
«Strong background in working with Java, J2EE and Oracle»
«Demonstrated experience and relevant expertise in the design and building of distributed and enterprise solutions»

«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
company.yandex.ru/...anager_serp.xml

і там ще багато таких

Ну це ж московський яндекс! Там да... А у нас кукіш :)

Та реально кругом полно ПМов и ТЛов которые бывшие тестировщики.

Перебирав сьогодні вакансії. Всюди є вимога про прог. бекграунд. На практиці що важливіше?

Те тестеры которых я знаю которые стали ПМами/ТЛами стали ими спустя какое-то время работы в своём проекте. Не знаю тестеров которых взяли на ПМов сходу, без опыта работы. Программеров таких знаю, да.
Что важно на практике — не знаю, я не ПМ :) . Подозреваю что всё зависит от проекта. Но по-моему вообще мало где берут ПМов без опыта работы ПМами. Так же как мало где берут программеров без опыта работы программерами :) .

Про цей чортовий круг мені вже говорили :) містика...

тут больше встает вопрос — зачем вам хочется стать ПМ?

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

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