Крупные web-проекты: особенности и риски. Часть 4.
<<< Крупные web-проекты: особенности и риски. Часть 3.
Основные риски крупных web-проектов
Существуют как общие рискованные аспекты, характерные для всех больших проектов, так и специфические, относящиеся лишь к сфере web-технологий. Выделим самые значительные из них:
— Неверная оценка задачи разработчиком и неоправданное доверие со стороны Заказчика.
В данном случае губительным является даже не то, что разработчик ошибся в оценке поставленной задачи и собственных сил. Плохо то, что он не осознаёт слабую обоснованность собственных оценок.
— Риски, связанные с разночтениями брифов, технического задания и других описаний крупного web-проекта.
Существуют две основные проблемы:
— Заказчик может не понимать языка ТЗ или отказываться в принципе работать над ним. Мол, «я Вам всё сказал, надеюсь, Вы меня услышали — теперь делайте».
— Для крупного web-проекта создаётся ТЗ, содержащее сотни листов, множество схем и таблиц. Такой документ в любом случае будет содержать неточности, противоречия и ошибки, даже при условии идеально слаженной и мотивированной работы как разработчика, так и Заказчика. Техническое задание в любом случае будет неполным, а местами даже неактуальным, потому как во время работы над web-проектом изменятся приоритеты, а также появятся новые идеи.
В теории можно разработать непротиворечивое, полностью исчерпывающее и устраивающее обе стороны техническое задание, но на этот процесс будет затрачено огромное количество времени, за которое текст ТЗ в очередной раз устареет, да и сам web-проект будет уже не столь актуален.
— Утрата контакта между Заказчиком и разработчиком из-за больших сроков этапов работы над web-проектом.
Не стоит вести разработку крупного web-проекта большими этапами, пытаясь работать «сразу по большому ТЗ», так как в процессе работы может утратиться контакт между Заказчиком и разработчиком, выпасть из памяти многие важные детали и аспекты web-проекта. А также Заказчик может просто устать ждать и начать испытывать скорее негатив по отношению к разработчику, нежели предвкушение успеха.
Эта опасность относится не столько к рациональной, сколько к эмоциональной сфере взаимодействия, от того она становится лишь опаснее.
Последствия такого подхода к работе – проблемы при сдаче/приёмке очередного этапа, связанные с потоком пожеланий, которые Заказчик будет считать ошибками разработчика или своими логичными требованиями, а разработчик — чистой воды «хотелками».
Этот риск может нанести вред не только web-проекту, но и человеческим отношениям между сторонами.
— Изменение требований к web-проекту и цена его развития.
Изменения в проекте являются совершенно естественными для Заказчика, равно как и для бизнеса и жизни в целом. Ничего константного в реальной жизни нет. Потому, вне зависимости от того, какой метод управления web-проектом выбрал разработчик — изменения будут.
Вероятно, что грамотно составленным договором или практикой отношений между Заказчиком и разработчиком их удастся минимизировать, а возможно, что и зарубить на корню, но это противоестественно. Каждый следующий день разработки крупного web-проекта до момента его запуска будет только накапливать эти изменения.
Общая рекомендация такова — этапы как можно меньше, запуск каждого этапа после его разработки как можно быстрее.
Иначе события могут развиваться сразу по двум неприятным схемам:
— «проект всегда готов на 90%»;
— цена развития web-проекта (качество проекта страдает; относительно него принимаются сиюминутные решения без необходимого тестирования).
— Реальный объем данных, размещаемых на крупном web-проекте, и общая производительность проекта.
Отдельной достаточно значимой задачей, о которой часто забывают или прорабатывают её лишь поверхностно, является тестирование проекта целиком на реальном объёме данных, просмотров и пользователей. Такое нагрузочное тестирование несложно технологически, но крайне полезно для будущего web-проекта.
Крупные web-проекты: особенности и риски. Часть 5. >>>