Искусство управления IT-проектами - [12]

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

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

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

В главе 10 мы узнаем, что книжные предписания или указания руководителя на создание какого-то продукта или сам факт, что предписываемая методика использовалась в прошлом месяце или году, не являются основанием для того, что все это применялось и сегодня. Все команды и проекты отличаются друг от друга, поэтому существуют весьма веские основания, чтобы подвергнуть сомнениям все прежние положения. Причина консерватизма в применяемых методах и процессах кроется в том, что излишества в данном вопросе могут превратиться в снежную лавину, увлекающую за собой команду в вязкую западню сложных проектов, как об этом говорится в книге Фрэда Брукса (Fred Brooks) «The Mythical Man-Month». Когда от процессов требуется управление процессами, трудно понять, где осуществляется реальная работа. Именно руководителю команды или проекта чаще всего предоставляется великолепная возможность управлять командой без бюрократических излишеств или наоборот послать ее на полной скорости в нескончаемый водоворот различных процедур и заседаний.

Нужная степень вовлеченности

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

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

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