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

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

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

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

Если серьезно, то насчет экономии на зп бездельников вы очень неправы — зарплаты бездельников даже на протяжении 10 лет к ряду не составят сотой доли стоимости разработки своей olap-based системы аналитики. Btw, Microsoft и Oracle как раз вендоры таких систем, вам приходилось работать с чем-то из них? Если нет, то смотрите предыдущий пример с MS Project’ом.

P.S. хороший проектный менеджер делает еще одну незаменимую вещь — в силу того, что этот некомпетентный бездарь еще и гуманитарий, он в школе хорошо писал диктанты и изложения. И в итоге в письмах клиенту не делает орфографических и пунктуационных ошибок, без всякого спеллчекера определяя, как пишется, к примеру, слово «бессмысленный»:)

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

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

Вам приходилось работать в украинском аутсорсе:)? В большинстве случаев нельзя — это нерентабельно.

Грубая арифметика:
pm — 1500 $
2 джуниора — 1200 $ * 2
мид, который тянет весь проект — 2000 $
джуниор qa — 600 $ :)

Итого: 6400 $ только зп. А еще эти люди сидят в офисе, едят печеньки, работают за Apple Cinema дисплеями и хотят ездить на конференции, ах да — еще налоги. Суммарные затраты в месяц даже на такую команду могут легко составить 10 000 $. То есть бизнесу остается 14 000 $.

На проекте такая команда наработает за месяц порядка 800 часов. По рейту 30 $ (а такой просят средние аутсорсеры) получаем 24 000 $.
vs
аналитик — 2000 $
2 senior разработчика 3000 $ *2
тимлид — 3500 $
толковый qa — 1500 $

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

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

Как pm, присоединяюсь к мысли, что проектные менеджеры не нужны:
— для небольших, сильных, кросс-функциональных команд;
— при работе над продуктом, либо с бизнесом, который умеет формулировать свои требования, нанял бизнес-аналитика и заинтересован в результатах проекта;
— при наличии тимлида с хорошими скиллами фасилитатора, и фасилитатора суперуровня, к примеру, руководителя группы разработки;
— при наличии артдиректора (либо очень хорошего дизайнера со скиллами фасилитации, опять же), если в продукте важен ui, который будет сводить воедино работу дизайнеров
— при очень хорошей и тщательной организации инфраструктуры, где каждый человек на своем месте и предельно профессионален.

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

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

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

В аутсорсе же, зачастую, команда, в которой есть тимлид и аналитик — несбыточная мечта. Команда, в которой хотя бы один разработчик выше уровня mid’а — это очень и очень классно. И в условиях слабой или неопытной команды, которую удалось надергать на рынке , бизнесом принимается решение — нанять одного человека (стоящего в денежном выражении копейки по сравнению с профессиональной командой, в которой будет тимлид, аналитик, сильный qa и пара senior разработчиков).

Это, на самом деле, очень болезненное решение:) Человеку, которого наняли на такую должность, совсем несладко, и он слабо осознает, что теперь он и шнец, и жнец, и на дуде игрец — причем зачастую без нужных для этого навыков.
В плохом случае и при совсем грустной команде pm превращается в того самого ленивого подбрасывателя монеток и жалкого функционера. Тут все понятно, случай можно закрывать со штампом «вон из профессии».
В неплохом случае pm через полгода, может в проекте баг пофиксить, автоматизацию тестирования для приложения написал, стулья новые выбил для команды, режет макеты и верстает xml-ки, организовал для команды обучение и поездки на конференции.

Все это не очень хорошо, ведь такой на-все-руки мастер pm делает все эти задачи хуже других — разработчика, тестировщика, hr-a, функционального руководителя, тимлида, админа. Плюс в том, что он есть, а качественных владельцев ролей, которые он подгреб под себя — нет или не хватает (и все вместе они на порядок больше стоят). Огромнейший плюс — в том, что такой человек зачастую помогает команде сплотиться, развиваться и дает людям чувствовать, что они делают что-то нужное, их успехи видят клиент и руководство, а их неудачи — повод для совершенствования и обучения, а не показательных порок.

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

В моем случае, в большой продуктовой компании, где малейшее движение в одном сервисе вызывает волну изменений в других, а у проекта может быть очень много stakeholder’ов (которые что-то хотят от проекта, но при этом не являются его product owner’ом), проектный менеджер (такой уж тайтл, хотя суть работы где-то между бизнес-анализом) нужен для минимума действий, которые опробованы на себе и отвергнуты руководством разработки:)

А именно:
— вынимать из головы продуктового менеджера гениальные идеи и планы, и вместе с UX-инженерами, превращать их спецификацию и дизайны, по которым можно стартовать разработку архитектуры ровно в день их получения.
— убирать блокеры и камни с пути команды (для решения среднего вопроса нужно вовлекаться в общение в среднем с 3-5 людьми/отделами, займись этим тимлид и он не сможет заниматься своими должностными обязанностями).
— сдерживать напор stakeholder’ов — людей, которые на благо сервиса хотят прикрутить к нему миллион бантиков, анализируя, приоритезируя и формируя человеческие требования к этим бантикам.
— держать в курсе прогресса проекта верховное руководство — и делается это на основе тесного взаимодействия с тимлидами. Если бы высшим руководителям пришлось общаться со всеми тимлидами (их число может достигать 20 человек в одной группе) и сводить их планы воедино, было бы очень напряжно по сравнению с общением с 4 менеджерами, которые все принесли в диаграммках Ганта и по скрам-досочка разложенное:).

При этом такая работа:
— зачастую считается стартовой позицией (к примеру, в продуктовый менеджмент, где нужно и специфику разработки знать, и обладать глубокими знаниями о рынке);
— ее результаты нужны всем, но в разработке ни у кого нет настроения этим заниматься, это скучно;
— оплачивается достойно, но никак не на уровне с архитекторами и тимлидами.

P.S. Баснословные зарплаты pm’ов — хорошо разрекламированный миф:)

P.P.S. Дико прошу прощения за простыню, наболело после чтения комментариев как в защиту, так и в порицание роли pm-a.