Эта статья родилась из череды споров с руководством на тему того, должен или не должен РП глубоко разбираться в технической стороне проектов, которыми он руководит. Фактически она является конспектом моих аргументов на тему того, что руководитель проекта должен досконально понимать, что делает его команда. Желательно, на уровне способности полноценно заменить любого ее участника.
Небольшое предисловие: если вы работаете в крупной организации и руководите многомиллионными, а то и миллиардными проектами, то это читать вам явно не стоит да вы со мной и не согласитесь, т.к. уровень проблем у нас разный. И я прекрасно понимаю, что мои тезисы зачастую идут вразрез с общепринятыми практиками проектного управления, но я лично могу гарантировать успешность проекта, только если соблюдаю их.

Команда

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

1. Говорим с командой на одном языке

Если вы не разбираетесь в том, что делают конкретные люди в вашем проекте, в определенный момент вы не сможете с ними общаться. Причем, скорее всего, это будет самый критичный момент вашего проекта. Заметил по себе: даже самые умные, ответственные, прекрасные и т.п. коллеги в определенный момент, заметив, что вы не понимаете, о чем они говорят, переходят на стиль общения «Мама – неразумный ребенок». Т.е. разработчики начинают вам говорить что-то вроде: «Мы не можем использовать в этом проекте базу данных, потому что а-та-та и будет бо-бо». И более логичного объяснения вы от них не дождетесь. Согласитесь, что это не самый хороший стиль общения особенно в той ситуации, когда вы являетесь для них каким-никаким, но руководителем.

2. Пожар на проекте – горим вместе

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

3. Работаем с лучшими

Если руководство позволяет вам подбирать команду под конкретный проект (а если не позволяет, то или вы, или ваша компания нифига не «проектоориентированы»), то вы должны набирать себе людей, идеально подходящих именно под этот проект. Конечно, можно полагаться на отзывы и рекомендации других людей, но они могут быть крайне ошибочными. Пример: есть гуру-разработчик, которого кидают в те проекты, где заказчик уже готов сжечь напалмом всю вашу контору. Послужной список такого разработчика – одни провальные проекты, про которые и вспоминать стыдно. Если спросить других РП о качествах такого разработчика, они не вспомнят, т.к. в тот момент надо было пожар тушить, а не о личных качествах думать. Да и вообще не известно, выправляют за счет этого гуру-разработчика критичные проекты или просто кидают его пушечным мясом.

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

Заказчик

1. Говорим с заказчиком без переводчика

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

2. «Мистер Вульф»

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

Есть еще одна неприятность, которая может вырасти из такого общения. Сотрудник, обладающий нужными коммуникативными качествами, а в душе примеряющий на себя роль РП, может полностью «выдавить» вас из проекта и взять управление на себя. А мы же помним про эгоизм?

3. Моментальная продажа

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

Прочие проектные плюшки

1. Бюджет проекта

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

2. Объем проекта

Вы точно будете уверены, что объем работ в проекте не поменяется без вашего ведома. Потому что заказчик не договорится с командой за вашей спиной; не пропихнет в проект какую-то дорогостоящую «штуку», которая вам покажет сущей мелочью (из-за вашего незнания), а в итоге окажется занозой в заднице; руководство не навяжет вам заведомо невыполнимый проект, воспользовавшись вашей интеллектуальной беспомощностью. И так далее.

Руководство

Что же получат ваши руководители от всех тех «побочных» знаний, которые вы будете иметь? Они получат: успешный проект, отсутствие необходимости в постоянном контроле происходящего, довольного заказчика, довольную команду, и довольного вас с зашкаливающим чувством ЧСВ :)

Минусы подобного подхода

Как бы мне не нравился этот подход, в нем, конечно же, есть минусы:

1. Опасность скатиться в микро-менеджмент. Если вы во всем прекрасно разбираетесь, то есть вероятность, что начнете контролировать каждую разработанную строчку кода, каждое написанное в ТЗ слово. Лечится исключительно повышенным самоконтролем;
2. Необходимость параллельно развиваться в двух-трех «должностях». Вы должны становиться лучше и как РП, и как разработчик-инженер-аналитик-кто_угодно_еще в вашей команде. Времени это будет отнимать слишком много, поэтому придется искать золотую середину. Ну или плюнуть на технические знания, и стать классическим «тупым менеджером» (слово «тупой» в этом месте характеризует не интеллект, а подход);
3. Отсутствие возможности руководить «стройками века». В них, к сожалению, такой подход не работает, потому что в сутках всего 24 часа, да и вообще – жизнь слишком коротка. Если на горизонте замаячит возможность поруководить чем-то великим, а у вас еще и желание будет, то подобный подход придется забросить и обрастать всевозможными помощниками. Но, думаю, если у вас действительно на горизонте есть такая возможность, то мои советы вам не нужны.