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

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

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

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

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

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

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

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

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

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

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

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

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

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

Меня представили всем руководителем проекта. Что было сделано:

все контакты с заказчиком пошли через меня

были проведены переговоры, на которых заказчику были объявлены новые условия завершения проекта

написано ТЗ на последний этап, которое долго и болезненно согласовывалось, но пока оно не написалось, никто не прикоснулся к гаечному ключу

по ТЗ написали функционал последнего этапа и выполнили сдачу-приемку (самый быстрый этап получился :) из всего проекта )

была написана спецификация системы

была достигнута договоренность, что мы поддерживаем систему в состоянии, соответствующем спецификации, доработки за бабло

По дороге было выскоблено около 40-50ти ошибок. Так как контакты шли через меня, нам удалось развернуть обратно еще 30 попыток внести в систему дополнения и хоть как-то систематизировать исправление того, что было признано за действительные ошибки (хотя бы ввели порядок тестирования у себя, затем обязательного тестирования у заказчика и формального подтверждения заказчиком, что ошибка исправлена)

И по мелочи: репозитарий с версиями, хранение, учет переписки и некоторые другие упорядочивающие вещи, которые служили снятию недоразумений за счет того, что "все ходы записаны".

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