Скотт Беркун - Искусство управления IT-проектами

• Название: Искусство управления IT-проектами
• Автор: Скотт Беркун
• Жанр: Прочая околокомпьтерная литература
• Год: 2014
• ISBN: 978-5-388-00543-4

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

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

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

---

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

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

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

Преимущество собственного взгляда на происходящее

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

Я взял в привычку прохаживаться по коридору и заглядывать к программистам, держащим свои двери открытыми. Обычно все сводилось к краткому разговору, в процессе которого я старался их чем-нибудь рассмешить, а заодно и поинтересоваться, над чем они работают. С их согласия я просматривал демонстрационные образцы. Нанося подобные кратковременные визиты с периодичностью в несколько дней, я часто получал неплохое представление о реальном состоянии проекта (в главе 9 мы рассмотрим подобную практику «прогулочного» управления проектом).

К примеру, как-то утром, работая над проектом IE 5.0, я заглянул в офис Фрэда. Он спорил со Стивом, другим программистом, о том, как они собираются заставить заработать элемент управления для просмотра списка, после того как утром внезапно обнаружились проблемы его совместимости с другими компонентами. Никто из них не хотел с этим связываться. И, исходя из всего мною услышанного, на исправление элемента должно было уйти не менее половины рабочего дня. Я подключился к разговору и подтвердил все то, о чем они говорили. Они кивнули головами, словно спрашивая: «Зачем вам это нужно?» Я сказал, что им нужно пройти вниз и поговорить с Биллом. Они опять спросили, зачем, думая, что дело касается весьма тонких вопросов архитектуры проекта, в которых я не слишком-то разбираюсь. Я улыбнулся и сказал: «Дело в том, что я только что от него, и у него на машине есть уже новый великолепно работающий элемент управления. Минувшей ночью ему удалось решить проблему и все исправить попутно с выполнением других дел».

Разумеется, здесь речь не о том, что я избавил или уберег человечество от глобальной катастрофы. Если бы я их не направил в нужное место, было бы потеряно впустую несколько часов или половина рабочего дня (хотя, как показано в главе 8, рабочие графики всегда имеют некоторые отклонения от запланированных сроков). Но дело не в этом. Хорошие руководители проектов считают своей обязанностью быть в курсе всех полезных дел команды, как, впрочем, и всего полезного в окружающем мире, а затем применять эти знания, помогая людям справиться с их делами. Все эти, казалось бы, незначительные порции своевременно преподнесенной информации, наподобие той, о которой шла речь в моем рассказе, и делают из середнячков хорошие команды, а из хороших команд – великие. Никакая система отслеживания хода ведения проекта или обнаружения ошибок не сможет целиком заменить собой потребность людей в обсуждении друг с другом текущих событий, поскольку социальные сети всегда мощнее (а иногда и быстрее), чем сети технологические. Сложные задачи, наподобие концепции проекта, перечней функциональных условий и календарного плана, всегда сводятся к массе мелких задач, на которых благотворно сказывается простота обмена ценными знаниями и сведениями внутри команды. И главная роль в обеспечении активности и осмысленности этого обмена принадлежит руководителям проектов.

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

Руководители проектов создают уникальные ценности

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

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

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