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

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

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

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

 Открывается доступ к новой информации.

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

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

 Обнаруживается конфликт двух решений двух разных проблем, и эти решения при объединении идут во вред друг другу.

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

Изменения вызывают цепную реакцию

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

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

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