Понимание

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

Передача знаний

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

Делегирование

С моей точки зрения, предпочтительнее семантически близкое слово «поручение», но будем использовать более «современный» термин. Хороший руководитель тот, кто умеет организовать работу, а не выполнять её за каждого сотрудника. Конечно, иногда сам быстрее сможешь сделать, чем объяснить, но, во-первых, всю работу всё равно не сделаешь, а во-вторых – важнее научиться и самому объяснять, и сотруднику понимать: вы же не над последним проектом работаете! Для руководителя необходимо умение оценивать качество выполнения поручения: и содержание работы, и сроки её исполнения. Стремление всё сделать самому характерно либо для начинающего руководителя, либо для того, кто не доверяет команде. И в том, и в другом случае надо менять стиль руководства.

Проверка

Проверка (а это тот же контроль, о котором говорилось ранее) – необходимая деятельность в руководстве командой для получения обратной связи. Она вызвана не недоверием команде или подозрением, что кто-то отлынивает от работы, а стремлением не потерять управляемость процессом. Неуправляемые процессы при разработке программного проекта прямым ходом ведут его в категорию «безнадёжных». Не припомню случая, чтобы проверка не дала нужной информации, а проверяемому не принесла пользу, если, конечно, не сводить её к мелочным придиркам.

Участие

Руководителю проекта приходится заниматься и непосредственной разработкой. Есть деятельность (анализ требований, проектирование), которая предусматривает детальное знание проекта в целом, что и предполагает участие руководителя. Кроме того, нередко (точнее, в моей практике всегда) приходится заниматься и непосредственным кодированием, отчасти из-за недостатка персонала, порой для демонстрации технологии, но чаще из-за страстного желания тоже что-то написать. Не нужно только забывать, что прежней производительности достичь, скорее всего, не удастся: у руководителя много отвлекающих факторов. Особо нужно обратить внимание на проекты, которые попали в разряд «безнадёжных» [4]. Здесь основной ресурс, позволяющий спасти проект – сверхурочное время. Руководитель должен нести бремя тяжёлого труда наравне с командой, а, возможно, и больше. В противном случае команда вряд ли будет управляема в той мере, как необходимо. Да и сплочённости поубавится. Это слишком большая цена за возможность расслабиться.