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

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

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

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

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

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

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