Почему так популярна профессия руководителя проекта?

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

Причин много, но хотелось бы выделить главную.

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

Почему не умеют?

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

Есть шутка, что хороший тестер - это программист-неудачник ;) Конечно, это неправда: хороший испытатель должен иметь системное, глобальное видение, чтобы находить и вскрывать слабые места "с полпинка".

Так вот плохой менеджер это и есть, условно говоря, "программист-неудачник". Тот самый средний программист, увидевший свой потолок и потому решивший перейти "в манагеры". Переход в менеджеры для программиста - это отнюдь не преодоление потолка, а имитация, суррогат "преодоления". Имитация в условиях, когда ему некуда расти по технической вертикали. Нет надежды стать не то чтобы Глушковым или Виртом, а хотя бы Хейлсбергом или Керниганом. А в фирме зачастую даже нет понятия главного инженера.

Называть же естественным путь эволюции инженера в наемные управленцы так же неуместно, как путь таксиста в директоры таксопарка.

С одной стороны, в РФ сложилась культурка, когда менеджер независимо ни от чего должен получать намного больше подчиненных (это напрямую следует из функций "командования" и "надзирания" накладываясь на народные традиции "паханов" и "вертухаев"). С другой, местная ИТ-индустрия отнюдь не кишит стартапами и наукоемкими инновационными проектами, где хороший инженер ценится намного выше плохого "манагера".

Базар на SQL.Ru и достаточно типичная, на мой взгляд, история оттуда.

Меня подключили к проекту, который вели два разработчика под непосредственным руководством двух представителей заказчика и начальницы их отдела. Внедрялась архивно-документооборотная система. Проблема спустя год от начала проекта была сформулирована той начальницей: год идет работа, бюджет проекта съеден, а завершить его никак не могут. определить, сколько времени разработчиков туда надо еще вложить невозможно. Ситуация осложнялась тем, что договора не было, проект был полностью на устных договоренностях. Половина оплаты застряла, так как заказчик был недоволен прогрессом. Начальница пробовала все, включая дневную отчетность. В отчетности исправно писалось что-то типа "2 дня крутили гайку №8 ключом 16 на 18" и так несколько месяцев со сменой номеров гаек и названий инструментов.

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

Меня представили всем руководителем проекта. Что было сделано:
- все контакты с заказчиком пошли через меня
- были проведены переговоры, на которых заказчику были объявлены новые условия завершения проекта
- написано ТЗ на последний этап, которое долго и болезненно согласовывалось, но пока оно не написалось, никто не прикоснулся к гаечному ключу
- по ТЗ написали функционал последнего этапа и выполнили сдачу-приемку (самый быстрый этап получился :) из всего проекта )
- была написана спецификация системы
- была достигнута договоренность, что мы поддерживаем систему в состоянии, соответствующем спецификации, доработки за бабло
- По дороге было выскоблено около 40-50ти ошибок. Так как контакты шли через меня, нам удалось развернуть обратно еще 30 попыток внести в систему дополнения и хоть как-то систематизировать исправление того, что было признано за действительные ошибки (хотя бы ввели порядок тестирования у себя, затем обязательного тестирования у заказчика и формального подтверждения заказчиком, что ошибка исправлена)
- И по мелочи: репозитарий с версиями, хранение, учет переписки и некоторые другие упорядочивающие вещи, которые служили снятию недоразумений за счет того, что "все ходы записаны".

Худо-бедно сегодня проект считается "почти" завершенным. Сейчас заказчик уже год вычитывает нашу спецификацию :), но задача снять напряженность (если угодно, повысить удовлетворенность заказчика) была выполнена. То есть, они заплатили почти все, что обещали и не долбают нас новыми требованиями, что позволило переключить людей на другие проекты. В общем, руководитель проекта - это человек, сдерживающий и упорядочивающий внешнее давление на команду с одной стороны, и придающий усилиям направленность к единой цели с другой. И здесь ничего нет, связанного с программированием. А в запущенных случаях - это человек с лопатой в куче навоза и это действительно трудная работа.

Комментарии

Тезисы

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

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

3. Плохих ПМов в % соотношении даже меньше, чем плохим программистов (ИМХО). Но их плохая работа видна большему числу людей. При хорошем ПМ плохой кодер вообще не повлияет на проект - его аккуратно и тихо заменят или найдут ему адекватную задачу.

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

5. Базар на SQL.ru отстойный. Хотя бы потому, что манипуляция - это нормальный прием, когда разных людей надо мотивировать на общюю задачу. Альтернативы: насилие/принуждение или подбор одинаково мотивированных пихологически совместимых людей (но мы тут программы пишем, а не отряд космонавтов формируем).

Изображение пользователя Serguei_Tarassov.

По пунктам

По пунктам спорить не буду, хотя, конечно, есть над чем поспорить (например, я говорил о соотношении маткомпенсации "хороший инженер-плохой ПМ").
Старика Брукса помнишь? :)
Мне нравится его метод/метафора хирургической бригады. Там роли технического и административного руководителя проекта четко отделены (они на деле практически несовместимы). В такой модели и степень ответственности сравнимая.
Разумеется, это не панацея и не религия типа "наживульки", но, по меньшей мере, мои самые удачные проекты делались именно так.

по п.4: так ведь

по п.4: так ведь все ПМ вначале белые и пушистые, про методологию рассуждают. Тогда и ЗП им назначается. В одном проекте принцип, который я описал. А вот в разных: хороший инженер легко будет работать в "дорогих" проектах и получать больше ПМ, руководящего малозначимым проектом в маленькой конторе.

Разделение имеет смылсл в большой команде (ИМХО, больше 10 человек). До этого порога разделение необязательно, и может быть не эффективно. На своих проектах мне больше нравиться разделение на системного архитектора и РП/прикладного архитектора. Если РП может не знать всех тонкостей используемых технологий (КАК), то ЧТО эти технологии должны делать он должен знать лучше всех.
В дополнение к Бруксу рекомендую вот это почитать.

Изображение пользователя Serguei_Tarassov.

Именно такое разделение

Именно такое разделение. У французов обозначается как MOA/MOE (Maîtrise d'ouvrage / Maîtrise d'oeuvre).
Maîtrise d'ouvrage - формирование требований, функциональная архитектура (постановка задачи), взаимодействие с заказчиком, приемка
Maîtrise d'oeuvre - разработка системной архитектуры, техническое проектирование, разработка системных/интеграционных тестов