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

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

Безусловно, менеджеры пытаются применять принципы быстрой разработки приложений (Rapid Application Development, RAD) и другие методики оперативного управления проектами, но это вовсе не значит, что они готовы при?нести в жертву скорости тщательное тестирование и гарантии качества.

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

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

Это особенно актуально в тех случаях, когда число сотрудников невелико и менеджерам приходится оперативно решать, какие из имею?щихся специалистов могут выполнить данный проект. «Вам необходимо подчеркнуто ясно сформулировать задачи каждого человека, определить, с кем из них вы будете взаимодействовать, причем придется проявлять определенную гибкость при планировании. Вам также необходимо определить стратегическую линию и следить за тем, чтобы все участники проекта ее придерживались», — посоветовала Марго Виситасьон, аналитик компании Forrester Research.

Быстрее, еще быстрее

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

Например, один из менеджеров, под давлением руководства компании ускорив внедрение системы ERP, не реализовал в ней поддержку крити?чески важных бизнес-процессов.

«Руководители всегда пытаются максимально ужать ИТ-проекты», — заметил Кен Макленнен, первый вице-президент по бизнес-решениям компании Fujitsu Consulting. Он отметил, что менеджерам проектов приходится играть роль посредников и объяснять руководителям, насколько рискованна такая гонка.

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

Полтора года назад компания E.W. Scripps внедрила технологию «максимально сокращенного» жизненного цикла проекта, получившую название FastTrack.

По словам Оскара де Джонга, уп?равляющего директора отдела руководства проектами компании E.W. Scripps, благодаря подходу FastTrack описание проекта в почтовом сообщении умещается в один-два абзаца, затем следует список повторяемых, контролируемых процессов, которые выполняет группа разработчиков, в частности определение требований к проекту, оценка ресурсов и тестирование. Эти процессы должны быть завершены до окончания проекта. Данный подход объединяет характеристики так называемого «лавинообразного» управления проектом, при котором задачи ставятся последовательно, но таким образом, чтобы они перекрывались друг с другом, причем сроки выполнения этих задач в рамках проекта составляют от 2 до 20 часов.

Такой подход применяется даже к небольшим проектам, например, изменение размера рекламного окна на одном из сайтов E.W. Scripps. Де Джонг подчеркнул, что «этот подход оправдывает себя при восьмичасовом рабочем дне и его можно назвать ?изменением культуры? в той же степени, в какой и любую другую методологию».

Компания Nationwide Insurance применяет технологию оперативного управления проектами с мая прошлого года для замены распределенных систем, рассчитанных на работу непосредственно с клиентами, и используемых ее агентами, предлагающими страховку собственности и жизни от несчастных случаев. Как отметил Джек Пробст, заместитель руководителя отдела ИТ-процессов, вместо того чтобы сразу предоставить всем 25 тыс. агентам новый набор систем, Nationwide использовала оправдавший себя подход, предложив протестировать отдельные возможности некоторым агентам, прежде чем распространять прототипы системы по всей стране.

Основу этого проекта составляет платформа Solution Delivery, в которой ключевым приоритетом является качество.

Платформа, которую Nationwide начала использовать в 2003 году, создана на базе методологии Rational Unified Process, предложенной корпорацией IBM и опирающейся на подход оперативного управления проектом. По мнению Пробста, Solution Delivery обеспечивает значительное повышение качества.

Пробст отметил, что Nationwide планирует начать аудит своих проектов к концу марта, как только в платформу Solution Delivery будет интегрировано программное обеспечение управления портфелем проектов компании Niku.

Вынужденная необходимость

Иногда главным стимулом создания новаторского решения является насущная необходимость.

Дэвид Блейр, директор по информационным службам агентства Primary Industries and Resources SA (PIRSA), сказал, что в его компании традиционный подход к замене 20 унаследованных систем на Primary Industries Information Management System себя не оправдал, поскольку в итоге проект затянулся слишком надолго и оказался не способен удовлетворить бизнес-требования, выдвигаемые пользователями.

Поэтому PIRSA, которая начала разрабатывать системы нового поко?ления в конце 2001 года, вместе со своим партнером по проекту, компанией Fujitsu Consulting, приняла решение о том, что Fujitsu за?вершит базовую систему, придерживаясь традиционного подхода, а затем разработает дополнительную функциональность, используя методологию RAD.

После завершения базовой сис?темы в июне 2002 года PIRSA и Fuji???tsu разделили проект на этапы, которые, по словам Ванессы Бир, консультанта компании Fujitsu, предусматри?вали, начиная с ноября 2002 года, ежеме??ся?ч??ную реализацию для конечных пользо?вателей новых возможностей.

Подразделению Animal Health, например, были предложены функции, позволяющие отслеживать, из какого региона пришло больное животное.

Отказавшись от традиционного подхода к разработке в пользу методики RAD, как подчеркнула Бир, разработчики смогли предложить именно то, что требовалось компаниям, и никаких проблем с описанием и документацией не возникало.

Джо Зукчеро, директор по ведению проектов компании Casey Group, специализирующейся на ИТ-услугах, считает, что сильнее всего качество проекта страдает из-за перегрузки членов группы, участвующих в проекте. «Если ваши специалисты заняты на службе по 60-70 часов в неделю, качество их работы постепенно падает, — заметил Зукчеро. — Знающие руководители понимают это, но, к сожалению, они не всегда составляют планы с учетом наиболее эффективного распределения сил».

Для Хеда и его коллег по Clark?ston Consulting об экономии на качестве речь не идет никогда. «Качество никогда не должно становиться низким, даже если это приведет к увеличению сроков выполнения проекта», — подчеркнул Хед. 

Проектные офисы: о тех, кто не учится на своих ошибках

Примеров провалов ИТ-проектов по разработке корпоративного программного обеспечения довольно много. Можно вспомнить, например, крах внедрения системы подтверждения бронирования в AMR или ERP-системы в Hershey Foods.

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

Все эти причины собраны, описаны и проанализированы в книге Software Development Failures, изданной MIT Press в 2003 году.

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

Особенно обидно то, что ИТ-организации продолжают совершать те же ошибки и в последующих проектах. В большинстве подобных случаев проводится своего рода «вскрытие», которое имеет цель выяснить, что и почему было сделано неправильно. Это хорошая новость. Но в книге Software Development Failures говорится, что в половине случаев записи полученного горького опыта не ведутся вообще. И даже там, где этот опыт фиксируется, знание не применяется должным образом в новых проектах. Поэтому они тоже обречены на повторение прошлых ошибок.

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

Зачем ждать конца проекта?

Какими бы хорошими и полезными ни были ретроспективные обзоры проектов, очевидно, что они появляются слишком поздно, чтобы помочь чем-либо уже завершенному (или заброшенному) проекту. Как раз здесь, по мнению старшего консультанта компании Cutter Consortium Лин Никс, в бой вступают «интроспективы проектов».

«Интроспектива позволяет команде проекта оценить, что работает, а что не работает, и провести промежуточную корректировку хода выполнения задания», — пишет Никс.

Ее целью является пересмотр первоначальных установок: функционала, ресурсов и сроков, которые со временем, несомненно, меняются, так как вы получаете реальный опыт работы.

В какой момент нужно строить интроспективу? Никс рекомендует это делать по завершении очередного цикла итерации в разработке или в момент, когда в содержании проекта произошли значительные изменения.

Система раннего оповещения

Заранее узнать о проблемах в проекте — одна из главных задач для ИТ-менеджера. Это особенно важно, если члены команды не привыкли первыми заявлять о трудностях. Компания Harrah?s Entertainment решает эту задачу следующим образом. Рассказывает вице-президент по ИТ-услугам Хит Дотрей:

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

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

Около года тому назад в Harrah?s начали использовать программное обеспечение для управления портфелем проектов американской компании Niku.

По словам представителей Harrah?s, данный инструментарий позволяет полностью видеть ход работ над проектом и помогает менеджерам знать наверняка, что в них задействованы нужные люди с нужными навыками».

Три совета

Эрик Гиойа и Триша Давис-Маффет, руководители консал?тинговой компании Robbins-Gioia, специализирующейся в области управления проектами, советуют

  • Разделите проектный офис и команду разработчиков так, чтобы офис мог играть роль «честного брокера» и объективно говорить о проблемах.
  • Наделите проектный офис функцией управления знаниями (сбор информации о том, что в действительности происходило в прошлых проектах и передача этой информации в новые проекты).
  • Узнайте сколько вашей организации на самом деле, а не в идеале, требуется времени для выполнения задания. Это поможет составлять более реалистичные графики.