Крупные web-проекты: особенности и риски. Часть 6.

<<< Крупные web-проекты: особенности и риски. Часть 5.

Почему не стоит «автоматизировать бардак»?

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

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

Разработчик крупного web-проекта должен предлагать решения, а Заказчик, со своей стороны – не удивляться и рассматривать все предложения всерьёз. Парадоксально то, что обе стороны хотят успеха web-проекта, но представляют его себе настолько по-разному и при этом настолько не умеют обсуждать своё видение друг с другом, что проблема взаимодействия между ними может всё испортить, несмотря на отсутствие серьезных фактических разногласий.

Документирование крупного web-проекта

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

В чём заключается специфика крупного web-проекта:
— Огромное количество информации;
— Высокая сложность web-проекта;
— Детали в начале работы неизвестны, ведётся их постоянное уточнение.

Одна из возможных (хорошо срабатывающих) схем ведения документации для крупного web-проекта:
— Краткость постановки задачи в основном договоре. Шесть-семь листов текста, где прописаны все ограничения по web-проекту, к примеру, не более 40 типов объявлений; не менее 15 форматов файлов обмена; не более 200 полей в формах ввода данных. Эти ограничения являются очень важными для обеих сторон.
— Разработка собственно технического задания на базе Axure, поддерживающей возможность создания живых кликабельных макетов и диаграмм.
— Совместная проработка, обсуждение и правка текстовой части ТЗ в Google Docs.

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

Отслеживание процесса разработки крупного web-проекта

Когда техническое задание, наконец, подписано и начата разработка web-проекта, некоторые вещи оказываются просто необходимыми:

— диаграмма Гантта, в которой удобно отмечать реальные и фактические сроки сдачи очередного этапа;
— баг-трекер, к которому имеет ограниченный доступ и Закачик;
— регулярные встречи с Заказчиком (особенно при условии, что web-проект разрабатывается одним огромным куском);
— фиксация неизбежных правок ТЗ в листе изменений;
— проверка каждого сдаваемого в эксплуатацию этапа с помощью автоматических тестов.