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

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

К примеру, как-то утром, работая над проектом IE 5.0, я заглянул в офис Фрэда. Он спорил со Стивом, другим программистом, о том, как они собираются заставить заработать элемент управления для просмотра списка, после того как утром внезапно обнаружились проблемы его совместимости с другими компонентами.

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

Разумеется, здесь речь не о том, что я избавил или уберег человечество от глобальной катастрофы. Если бы я их не направил в нужное место, было бы потеряно впустую несколько часов или половина рабочего дня (хотя, как показано в главе 8, рабочие графики всегда имеют некоторые отклонения от запланированных сроков).

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