Менеджмент программных проектов

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

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

Однако с какими вопросами предстоит столкнуться менеджеру в реальной жизни? У одного сотрудника заболел ребенок и сегодня он придет только после обеда. Кому сотрудник звонит в этом случае? Менеджеру. Другой сотрудник собрался в отпуск, третьему сегодня к врачу, четвертый с пятым поссорились, шестого не устраивает ширина туалетной бумаги в туалете офиса. Плюс завтра приезжает иностранный партнер, нужно его встретить в аэропорту. Послать можно кого-то из сотрудников, но решать то этот вопрос должен все равно менеджер. Заказчик захотел еще раз обсудить требования. Дизайнеры сообщили, что оформление сайта не будет готово в срок и т.д.

Массу таких абсолютно нетехнических вопросов необходимо решать менеджеру. Все это каждый день. Все эти важные вопросы нельзя игнорировать. Еще бы, ведь это работа с людьми, ведь это – заказчик, ведь это – партнеры! Подобные проблемы нельзя решить в комплексе, ведь у каждого сотрудника свой собственный ранимый внутренний мир. Он не потерпит, если на него не обратят внимания. Не говоря уже про заказчика. Эти вопросы невозможно решить и забыть про них. Каждый день возникает несколько новых. Драгоценное время менеджера оказывается ими занято.

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

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

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

Вариант первый, оптимистичный. Менеджер понимает, что не способен непосредственно руководить технической частью и старается не делать это, чтобы хотя бы не навредить. Ему и без того есть, чем заняться. В итоге техническая часть проекта остается без грамотного руководства, что сильно сказывается на качестве конечного результата или вообще не позволяет его, конечный результат, достичь. В качестве примера можно рассмотреть ситуацию, когда два продвинутых сотрудника проекта не сходятся во мнениях по какому-нибудь ключевому для проекта вопросу. Как же принимать решение? Они идут к менеджеру. Причем менеджер может уже и не понимать, ключевой этот вопрос или не особо ключевой. Соответственно может либо не уделить достаточно внимания, либо принять решение наобум, считая, что оба решения, в принципе, хорошие. Часто такой менеджер занимает пассивную и, якобы, конструктивную позицию. Он говорит сотрудникам "вы предлагайте, а я рассмотрю варианты". Но, к сожалению, это только видимость управления проектом, т.к. вовсе необязательно правильный вариант вообще будет предложен, а если будет, то вероятность, что его примут, никак не повышается от того, что он правильный. Чаще всего принимается вариант того человека, который кричит громче остальных.

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

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

Однако, это противоречие между административным и техническим руководством можно разрешить. Как? Продолжение следует...