wicharek
Оказавшись в данный период времени у руководства не большой, но стремительно растущей, IT-компании, я начинаю понимать зачем вообще нужны менеджеры проектов. Пока что я только в начале этого понимания, но могу точно сказать, какие менеджеры проектов не нужны.
Во всех компаниях, где мне приходилось работать, эти самые менеджеры были абсолютно бесполезной прослойкой между заказчиками, начальством и командой. Они только усложняли жизнь разработчика. Будучи абсолютно неспособны разобраться в сути процессов, которыми они «управляли», они были вынуждены как-то оправдывать своё существование (и зарплату), вмешиваясь в рабочий процесс там, где от него следовало держаться подальше (подсказывать программисту, как ему починить баг, sic!), или просто регулярно отвлекая разработчика необходимостью предоставлять абсолютно бессмысленные отчёты (не всякие отчёты одинаково бессмысленные, я знаю).
Что характерно, топ-менеджмент тех же компаний был, как правило, значительно более квалифицирован. Это, конечно, можно объяснить и тем, что работа таких людей не столь заметна и далека от простого программиста или дизайнера. Но есть и другое объяснение: на должность менеджера проектов в украинский компаниях склонны брать кого-попало. Мне приходилось работать с людьми, абсолютно не знакомыми с технической стороной информационных технологий. Это не приемлемо. Должность менеджера проектов далека от должности сферического администратора в вакууме, которому якобы всё равно чем управлять: мясокомбинатом, салоном итальянской сантехники или полигоном для испытаний ядерного оружия. Это безусловно техническая должность, а получается, что людей туда берут, как в IT-Crowd:
Boss: “I'm going to put you in IT because you said on your résumé that you have a lot experience with computers.”
Jen: “I did say that on my résumé, yes. I've got lots of experience with the whole computer thing. You know, e-mails… sending e-mails, receiving e-mails, deleting e-mails, um… I could go on…”
Boss: “Do!”
Jen: “The Web. Using mouse, mices, using mice. Erm. Clicking… double-clicking, the computer screen, of course, the keyboard, the grrls on the floor down there.…”
Boss: “The hard drive?”
В компании, где я работаю, никогда не будет неквалифицированных менеджеров проектов.
ахахаха, потому что вет переквалифицируется МП и перестанет наконец заниматься программированием:))
Сейчас вообще с эти сложно. Я например имею опыт и программирования и администрирования. Опыт управления ИТ проектами. При прохождени конкурса обычно берут иех у кого в книжке записано больше времени управления чемто. Хоть этот человек работал на ферме, но у него больше опыта в управлении. Они путают управление проекта и управление бизнесом. В итоге получается у них хрень а не проект. Но что поделаешь... так просто же им ничего не докажешь... Пусть учатся на своих ошибках...
В общем и целом, согласен с твоими выводами, хотя видел разных менеджеров, в том числе и «правильных». Ситуация, что на менеджера ставят кого попало, как правило, все же более актуальна для небольших девелоперских контор. В более-менее серьезных организациях к этому относятся намного серьезнее.
Ну, и с чем не согласен, так это с тем, что менеджер должен быть технически подкованным человеком. Нет, не должен. А иногда это вообще только мешает. Как раз описанный тобою пример, когда менеджер вмешивается в работу программистов или QA, говорит КАК делать, иллюстрирует эту особенность. Менеджеры из программистов, как правило, грешат этим, забывая, что их задачи совсем другие. Другой вопрос что для того, чтобы быть эффективным IT-менеджером, нужно понимать процесс создания ПО, специфику, но это просто т.н. предметная область, собственно, этим IT отличается от с/х, разных видов промышленности и т.д. Везде свои процессы, аспекты, детали, но основные принципы менеджмента, активности, подходы, принципы — одинаковы. Еще одно важное отступление: это все хорошо работает, конечно же, только на тех проектах, где роль ПМ четко выделена и он не обязан заниматься архитектурой, принятием технических решений, юзабилити, и в меньшей степени даже созданием документации (хотя тут есть разные варианты). Если же человека, который выполняет роль ПМ, обязуют заниматься еще всем вышеперечисленным (небольшой проект, нет более опытного человека в технической части, или почему-то еще), то конечно, нетехнический ПМ здесь не подходит. Ну, и еще одно доказательство: на собственном опыте видел нетехнических ПМ'ов, которые очень эффективно вели большие и серьезные проекты, и видел технических ПМ'ов, которые вышли из программистов/QA и не могли понять, в чем же все-таки заключается ИХ работа :)
Да самое смешное, что я как раз видел менеджеров-нетехнарей, лезущих с советами. А под началом менеджера «из программистов» работал лишь однажды, и он как раз-таки тупо самоустранился от управления. А проект как раз был такой, где необходимо было организовать чёткое взаимодействие четырёх команд: разработчиков графического клиента (хаотичные гейм-девелоперы — это была моя команда :)), разработчиков игровых серверов (это были жёсткие сиплюсплюсники, смотрящие на мир из UNIX-консоли), веб-разработчиков (типичные PHP-педаллеры, привыкшие писать веб-магазины) и художнико-дизайнеров, которые для всего этого дела делали графику. В итоге получился хаос и полный провал проекта, как следствие. Вот ты говоришь, что ПМ не должен быть технарём. Я не понимаю, как нетехнарь мог бы организовать эффективное взаимодействие этих команд. Или это не работа менеджера? А в чём тогда вообще его работа?
Хм, давай разберем твои примеры.
1. Менеджеры-нетехнари лезут с советами
Не думаю, что они лезли с советами программисткого характера :) Если же вопрос касался UI или чего-то в этом духе, то это приемлемо при условии, что менеджер является спецом в этом деле. Кстати, лезть с этими же советами могут и менеджеры-технари, да и вообще все, кому не лень. Поэтому нужно четко разграничивать сферы ответственности и полномочий.
2. Менеджер-технарь самоустранился от управления
Устранился от управления или от низкоуровневых советов и микроменеджмента? Если первое — то гнать в шею, раз он ничего не делает. Если второе — то это как раз правильные действия менеджера. Именно поэтому я и говорил, что менеджеру-нетехнарю сложнее лезть к программистам, так как он не сильно разбирается в вопросе и сфокусирован на управлении, организации работы и процесса. Но это, конечно, не значит, что менеджер-технарь не может делать того же самого. Может, но все-таки есть склонность и желание вмешаться. Знаю по себе :)
3. Твой пример про взаимодействие
Не вижу, почему менеджер-нетехнарь не справится с этой задачей. Все, что ему нужно — это организовать работу, построить какой-то план, наладить взаимодействие, коммуникации, создать обратную связь, по которой он будет получать информацию о ходе работы и прогрессе. Ну, и общаться с клиентами (если есть). Что из вышеперечисленного требует наличия технических знаний? Вроде бы ничего. Другой вопрос, что если какая-то из команд была настолько слаба, что ей нужно еще и управлять с технической стороны, то здесь, конечно, нужен технический лид. Хотя в каждой команде так или иначе этого человека можно найти или нанять со стороны. Но решение о наеме нового человека — это как раз решение ПМ'а и нетехнический ПМ справится с этим заданием не хуже технического (разве что техническую часть собеседования нужно делегировать кому-то техническому).
Менеджмент — это целая область знаний и навыков. IT-менеджмент — это еще и специфика IT-индустрии, процессы разработки. Нетехнический менеджер должен понимать эту специфику и процессы, но это не требует технических знаний.
Собственно, поэтому получается такая канитель, когда ставят людей, которые в этом ничего не понимают. Поэтому лучше толковый нетехнический менеджер, который будет опираться на сильного технического лида/архитекта, чем бестолковый технический, который, не понимая своих задач и обязанностей, будет еще хвататься не за свою работу...