Какова главная причина провала проектов с использованием RAD (быстрая разработка приложений)? По мнению экспертов, это слабое перспективное планирование.
"В наши дни слово планирование является ругательным, но, как мне кажется, это важный момент, - считает Карма Макклюр, вице-президент по исследованиям из чикагской консультационной фирмы Extended Intelligence. - Вам приходится управлять всем процессом. Опасной проблемой для методологии RAD являются быстро растущие требования".
Если вы выбираете для разработки вашего приложения методы RAD, вы становитесь уязвимым. У вас не будет увесистого пакета требований для защиты от пользователей. Причем те же пользователи, столь критичные в отношении оценки RAD, - это, как можно предположить, именно те люди, которые могут изменить свое мнение о том, чего же они хотят. Итак, как выдерживать сроки выполнения RAD-проекта и не сбиться с пути? Вот несколько мнений на этот счет:
Записывайте, что и как. Ясно, что вы избавились от обременительной задачи создания объемных документов с требованиями, предпочтя RAD традиционному подходу. Но не совершайте ошибки, пренебрегая необходимостью в самом начале проекта зафиксировать на бумаге цели разработки, а также удостоверьтесь, что ваши клиенты согласны с тем, какими должны быть ключевые требования.
"Многие застревают на том, что мы называем "протоциклированием" (создание "прототипа" процесса), - считает Ричард Хантер, директор по исследованиям из фирмы Gartner Group (Стэмфорд, шт. Коннектикут). - Они не ясно представляют себе бизнес-проблему, которую пытаются решить, и в таком случае вы затратите много времени на то, чтобы уразуметь, что же надо сделать".
Избегайте создавать "поверхностные" прототипы. Инструментарий RAD позволяет создавать прекрасные демоверсии, но сможете ли вы создать работающую систему? Убедитесь, что члены вашей команды разбираются в базовой архитектуре разрабатываемых ими прототипов и что они могут в заданные сроки реализовать функциональные возможности, которые реально работают, а не только славно смотрятся. "RAD помогает вам быстро строить модели, - отмечает Карма Макклюр. - Пользователи могут вносить предложения и "виртуально" видеть результаты. Но вам нужно контролировать свою команду".
Привлекайте пользователей к принятию решений по финансовым вопросам. Ваши пользователи видят интерфейс прототипа, изменения которого происходят, как им кажется, без усилий от одной итерации к другой. Возможно, они не представляют себе объема работ, требуемого для реализации этих изменений. Убедитесь, что они это понимают.
"Мы уже сняли проблему впадания в чрезмерную конкретику при оценке воздействия того или иного изменения и привлекаем команду пользователей к определению приоритетов", - сказал Рик Ирвинг, директор по системам международной торговли из фирмы American Express Stored Value Group (Солт-Лейк-Сити, шт. Юта).
Не разрабатывайте приложений изолированно. "RAD облегчает задачу улучшения чего-то для одной группы, но это вряд ли удовлетворит потребности других групп, - считает Карма Макклюр. - Хватит ли вас на то, чтобы отказаться и начать все заново?"
Чтобы не допустить кластеризации приложений с ограниченной полезностью, Макклюр советует до начала работы добиться совершенно четкого понимания того, как ваш RAD-проект вписывается в стратегические планы вашей компании по развитию систем. Последуйте этой рекомендации и начинайте работу, всегда помня о повторном использовании приложения.
К. Т.
