О вреде излишеств

Дисциплина и самоограничение —главные условия успеха проекта в области ИТ.

Помните парадокс Зенона? Представьте себе, что вы входите в комнату. Чтобы добраться до противоположной двери, вы должны прежде дойти до середины комнаты; чтобы пройти вторую часть, нужно сначала преодолеть половину этого расстояния и т. д. — отсюда логически следует, что вам так никогда и не удастся пройти через всю комнату.

Безусловно, подобный парадокс — не более чем упражнение для ума, иллюстрирующее возможность вывода абсурдных заключений из безусловно здравых предположений; и, вместе с тем, он очень точно описывает состояние, в котором зачастую пребывают многие проекты в области ИТ. Аналогия будет еще более точной, если речь пойдет о тщетных попытках приблизиться к двери, которая понемногу, но неуклонно отодвигается от вас.

Это явление принято называть «разбухание проекта». Обычно так характеризуют проект в области разработки программного обеспечения, когда он выходит из-под контроля. Не в меру усердные разработчики придумывают все новые и новые функции и возможности, так что продукт катастрофически распухает, становится мистически сложным и запутанным и даже перестает соответствовать первоначальным требованиям. В результате уходят в трубу бюджетные ассигнования, срываются все сроки, и рентабельность инвестиций в проект оказывается под вопросом.

Впрочем, понятие «разбухание проекта» вполне применимо к проектам в области ИТ вообще, а не только к написанию программного кода. В конце концов, с точки зрения управления ресурсами настройка конфигурации сети VPN или наращивание мощностей обработки Web немногим отличается от конструирования компонентов Java. Все это стоит денег, требует определенных людских ресурсов и тщательного планирования работ.

Опасность разбухания проекта становится особенно актуальной в условиях ужесточения требований к отделам ИТ: от них ждут максимальной отдачи при все более строгих бюджетных ограничениях. Имея скудные резервы времени, денег и личного состава, непозволительно тратить их на ненужную работу.

КАК ПРЕДОТВРАТИТЬ РАЗБУХАНИЕ

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

Разбухание проекта — это собирательный термин, охватывающий целый спектр ошибок в управлении проектом. К ним можно отнести следующие ошибки.

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

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

Включение функций, непомерно обременительных с точки зрения наличных ресурсов или временных рамок. Допустим, у вас есть список из 22 требований, которые помогут выполнить поставленную задачу и обеспечат отличное соотношение доходов и издержек, но, к сожалению, ваших денег, времени и штата сотрудников достаточно лишь для удовлетворения 19 требований из этого списка. Чем-то придется пожертвовать, что-то отложить до лучших времен — такова реальность. Если вы не в состоянии определить приоритеты, вас ждут трудности.

Включение функций, повышающих риск. Классический пример — недавнее фиаско альянса Nike/i2. Команда Nike, переусердствовав в стремлении выполнить запросы своего бизнеса, произвела, как утверждается, дополнительную настройку программной системы i2, выходящую за рамки рекомендаций разработчика. Такой шаг привел к многочисленным потерям и дублированию заказов, в результате чего Nike потеряла миллионы долларов. Этот казус, получивший очень широкую огласку, должен послужить для всех хорошим уроком: при работе над проектом следует принимать во внимание потенциальный риск, а также имеющиеся ресурсы и предполагаемые выгоды.

Чтобы успешнее контролировать разбухание проекта, нужно учитывать и другие факторы. Например, участники работ должны всегда считаться с тем, кто является «хозяином» проекта. Функция может превосходно выглядеть на бумаге, но не приглянуться менеджеру, финансирующему проект. Такие политические и личностные аспекты весьма существенны для налаживания взаимовыгодных долгосрочных отношений между представителями бизнеса и ИТ-подразделений.

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

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