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

Управление идеями требует твердой руки

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

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

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

Рис. 6.1. Пространство решения проблем по мере приближения к контрольной точке должно сужаться

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

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

Причины этого явления могут быть разными.

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

 План разработчиков становится яснее, уточняются примерные расчеты объема возможных работ. На смену первичному осмыслению приходит более глубокое вторичное. Иногда оно идет на пользу проекту, а иногда – во вред. Например, программист может найти новую стратегию реализации продукта: «Если мы выполним эту работу, используя новый способ, мне не придется заниматься пятью другими работами – так мы выкроим дополнительное время для оставшихся работ или сможем завершить весь проект раньше срока». Или: «Поскольку мы не сможем сделать данную работу первоначально задуманным способом, нам придется заниматься пятью дополнительными работами, а значит, для других работ останется меньше времени или завершение всего проекта будет отложено на более поздний срок».

 Обнаруживается конфликт двух решений двух разных проблем, и эти решения при объединении идут во вред друг другу. Это может произойти по разным причинам, касающимся потребительских качеств, деловых интересов или конструкторской несовместимости. У Джо может быть фантастическая конструкция автомобильного двигателя, а у Салли – великолепная конструкция трансмиссии, но когда все это объединяется в единую конструкцию, они видят, что по некоторым показателям их создания конфликтуют друг с другом, например трансмиссия не подходит к двигателю.

Оглавление книги