Искусство управления IT-проектами - читать онлайн книгу. Автор: Скотт Беркун cтр.№ 46

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

По этим причинам период времени между завершением первичного планирования и составлением технических условий всегда и на любой стадии работы дается нелегко. Команды, естественно, испытывают крайнее напряжение, когда на горизонте замаячит первый основной контрольный срок (то есть срок сдачи технических условий). Даже если люди не говорят об этом, многие понимают, что не все пока еще обсуждаемые идеи могут выжить. Может не хватить времени, средств или людей для создания всего, что находится в сфере обсуждения. Люди начинают задумываться о способах, которые позволили бы снять с себя ответственность или сгладить углы. Хуже того, некоторые идеи и замыслы могут конфликтовать друг с другом. У автомобиля может быть только один двигатель, а у дома – лишь одна крыша, и если предлагаются три разных варианта, понятно, что большинство из них не пройдет.

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

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

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

В первые месяцы существования проекта IE 4.0 мы получили настоящий вал программ. Параллельно мы пытались перейти от небольших команд и релизов (а-ля IE 2.0 и 3.0) к выпуску главного продукта. Мы были вовлечены в гонки, развернувшиеся между компаниями Microsoft и Netscape, из которых пресса раздула войну не на жизнь, а на смерть. А затем наш продукт перешел в разряд стратегических уже в соответствии с внутренней политикой компании. В таких условиях любому было бы нелегко удержать судно на плаву. И, как и в большинстве проектов, стоило только наступить переходному моменту от планирования к разработке, как возникло столкновение мнений и амбиций. Людям пришлось принимать первые трудные для себя решения, они почувствовали груз ответственности. На фоне явного нарастания неуверенности и напряженности одно оставалось неизменным – сроки. На горизонте нетерпеливо маячила очередная календарная дата, приближавшаяся с наступлением каждого следующего дня. [35]

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

Наиболее распространенной ошибкой является представление процесса проектирования в виде своеобразного рубильника, который можно включать и выключать, когда захочется. Развивая эту фантазию, можно представить следующий ход событий: однажды вы обнаруживаете, что сроки поджимают, а в вашем распоряжении еще слишком много идей и замыслов (и слишком мало готовых решений), но вы говорите команде: «Итак, с идеями мы покончили. Берите проект и приступайте к программированию. Вперед!» Даже если представить, что в вашем распоряжении вполне зрелый проект (чего на самом деле быть не может), подобное непредсказуемое поведение собьет с толку и дезориентирует всю команду. Вплоть до этого момента все занимались проектом, для окончательной готовности которого требовалось время. Без указания конкретной даты у них могло сложиться впечатление, что они имеют право принимать важные решения вплоть до 23 часов 59 минут суток, предшествующих дате готовности технических условий.

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