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

В наше время позиции руководителя или владельца бизнеса настолько притягательны, что боюсь лет через 10 некем будет управлять… Не знаю почему, но бытует мнение, что если есть знание английского языка, да еще и прочитано несколько бестселлеров о лидерстве, мотивации и управлении, то готов идеальный кандидат на место PM. Как часто вам приходилось слышать подобные рассуждения «Да что там управлять проектом – раздал задания, проконтролировал (серьезно и ооочень строго), поболтал с заказчиком вот и вся работа, делов то!»?

Спешу вас огорчить. Область знаний по управлению проектами не менее обширна, чем у разработчиков. Как и другие IT специальности, роль PM требует приложения усилий для постоянного самообучения и самосовершенствования. Ах да, вам ведь еще предстоит работать с людьми во многом превосходящими вас по знаниям и навыкам, так что в лучшем случае дело закончится игнорированием «указов» новоиспеченного «лидера».

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

Действие №1«Не поручить ли кому-то задачу»
Типичная ситуация, когда менеджер поручает кому-то из команды задачу, не предоставив при этом всей необходимой информации или даже не вникая, а что собственно понадобится человеку для ее выполнения. Такой подход он конечно же именует «делегированием» — передачей задачи с ответственностью за ее результат.
Последствия. Выполнение задачи будет затягиваться или она будет выполнена не совсем правильно, что негативно скажется на проекте (ведь на такой сценарий не рассчитывали). И, ясное дело, подчиненный, который не сделает «все как надо», окажется виноватым.
Отправная точка для размышлений. Для начала ознакомимся с термином делегирование:

Делегирование — это передача задания, власти или ответственности, постановка перед кем-то цели с одновременным предоставлением средств для ее достижения и несение исполнителем ответственности за качество результатов.
В.В. Глухов («Менеджмент». Учебник для вузов, 3-е издание)

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

Действие №2 «А давайте помогу…»
Из самых добрых побуждений некоторые менеджеры считают своим долгом помочь чем только смогут. И сверку верстки с дизайном провести, и требования подправить, и декомпозицию на сабтаски сделать, и потестировать и еще работы найдется всякой… Вместо выполнения своих прямых обязанностей менеджер просто превращается в многорукого Шиву, который героически овертаймит в одиночку, а проблем в проекте почему-то не становится меньше, а скорее наоборот.
Последствия. Утопая в тоннах чужой работы PM теряется фокус и уже не в состоянии справиться с главной своей задачей: вместе с командой успешно реализовать проект.
Отправная точка для размышлений. Данная тема прекрасно раскрыта в книге «Одно-минутный менеджер и обезьяны» Кена Бланшара. Основная идея заключается в том, чтобы не распылять свои усилия на выполнение чужой работы, а стараться максимально освободить время для занятия своими непосредственными обязанностями (производство результатов, администрирование, интеграция, проработка и имплементация новых идей).

Действие №3 «Мы с заказчиком обо всем договорились»
К сожалению, очень распространена практика просто «спускать» задачи команде. PM не считает нужным доводить до всеобщего сведения дополнительную информацию о целях, о приоритетах, о том почему-то что делается так важно для компании или заказчика. Работаем по принципу «нет времени объяснять». А зря!
Последствия. Команда, находясь в неведении, часто идет не в том направлении, не имеет возможности поделиться своими идеями (а поверьте, это очень большая потеря) и в результате получаются провальные спринты или даже проекты.
Отправная точка для размышлений. Постарайтесь всегда доносить до команды не только ЧТО ей необходимо сделать, но еще и ПОЧЕМУ. Во-первых, такой подход поможет построить доверительные отношения, ведь вы не просто раздаете указания, а увлекаете людей и мотивируете их принять максимальное участие в создании проекта. Во-вторых, вы страхуете сами себя от провала перед заказчиком. Чем лучше команда понимает к чему идет, тем быстрее могут быть выявлены ошибки, противоречия, риски.

Действие №4 «С понедельника живем по-новому»
Здесь речь пойдет об опрометчивых изменениях, которые так часто любят внедрять молодые PM. Почти в каждой книге, статье или докладе можно встретить призыв к экспериментированию и опробованию изложенного материала у себя на проекте. Я полностью согласна с таким эмпирическим подходом, но все же он таит в себе опасность. Многие опытные разработчики часто скептически относятся к подобным переменам, потому что на своем опыте им уже доводилось переживать подобное.
Последствия. Обилие новых модных терминов и натягивание разрекламированных способов работы as is на свой проект в лучшем исходе просто не даст никакого результата. В худшем — такие глобальные, необдуманные изменения могут привести к полной остановке работ, к хаосу и неразберихе, если хотите, к параличу проекта.
Отправная точка для размышлений. Удостоверьтесь, что вы достаточно глубоко изучили вопрос и понимаете суть и цели нового подхода. Подумайте, как адаптировать новый подход в вашем проекте с учетом сложившихся особенностей, культуры и политики компании. Проводите внедрение поэтапно. Это позволит не перегрузить команду (ведь их текущие задачи никто не отменял), вовремя заметить, что требуется дополнительная корректировка, суметь измерить результат и сделать объективные выводы. Презентуйте новый подход команде и поинтересуйтесь их мнением. Очень важно чтобы команда стала вашим сторонником – ведь именно им придется каждый день работать с новым процессом.

Действие №5 «Я все сделал правильно»
Частенько наблюдала случаи, когда вина за провал обязательно должна найти своего обладателя среди членов команды. И самое печальное то, что сам этот человек вполне согласен, что проблема именно в нем. Позволю себе заметить, что чуть ли не в 90% случаев косвенно или прямо вина за случившееся лежит на менеджменте. Ведь именно PM отвечает за организацию и соблюдение оптимальных процессов на проекте, которые призваны служить для гладкой работы. И сбой процессов – это зона ответственности менеджера, который просто вовремя не заметил, что что-то пошло не так.
Последствия. Из-за неверной интерпретации случившегося аналогичные проблемы возникнут в будущем, ведь никаких действия кроме «тушения пожара» не будет предпринято.
Отправная точка для размышлений. Анализируйте подобные отклонения с особой тщательностью. Ищите реальные причины проблемы и имейте смелость разделить ответственность за негативный результат со своей командой. Только устранив причину вы можете быть уверенны, что больше вас эта проблема не побеспокоит. Признанием своей ошибки вы также заработаете уважение со стороны команды. А без уважения о лидерстве не может быть и речи.

Действие №6 «Я уже 3 года так делаю и это работает»
Еще один случай, связанный с самоуверенностью менеджера – нежелание учиться. К примеру вы уже имеете некий опыт работы и считаете, что уже владеете всеми необходимыми навыками и знаниями. Но на самом деле нет никакой гарантии, что выработанные в прошлом способы помогут в новом проекте (компании) достигнуть результата. Вам наверняка понадобятся свежие идеи и взгляды.
Последствия. Если упрямо игнорировать достижения IT сообщества, то ваш способ ведения проекта попросту может не устроить новых заказчиков или работодателей. Вы станете похожи на динозавра, внезапно очутившегося посреди мегаполиса.
Отправная точка для размышлений.Всегда будьте открыты к новым знаниям. Следите за новыми тенденциями, читайте литературу, блоги, смотрите видео конференций. Благо в интернете доступно огромное количество различной полезной информации. Нужно только иметь желание.

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