В необходимости проектирования дома никто не сомневается, и любой человек понимает, почему нельзя строить дом на глаз, добавляя фичи в процессе строительства. Полезно напоминать, что разработка сайта схожа со строительством дома. Начинать ее стоит с полного планирования того, что придётся разрабатывать, в какие сроки, с какими исходными данными и ожидаемым результатом.
Был период, когда разрабатывал сайты в небольшой веб-студии в Минске. Верстал и программировал лендинги, интернет-магазины, CRM и ERP системы. Полноценного этапа проектирования сайта в веб-студии не было по понятным причинам — дополнительные затраты.
Клиенты обращались со своими техническими заданиями, в которых каждый описывал свой проект как мог. Такого технического задания хватало на то, чтобы понять проект и просчитать затраты. В результате такой подход приводил к ряду проблем, которые сыпались как домино.
Долгие согласования
Зачастую клиент хорошо понимает ожидаемый результат, но подробные детали и четкие требования к готовому варианту описывает недостаточно детально со стороны технической разработки.
Из-за отсутствия детализации программисту приходилось часто уточнять детали у проект-менеджера. Проект-менеджер переводил запрос программиста на русский язык и спрашивал у заказчика. В лучшем случае получал ответ и переводил его обратно для разработчика, в худшем — начинались этапы согласований.
Срыв графика работ, увеличение багов
Новые уточнения приводили к необходимости править код, проводить рефакторинг отдельных модулей. Появлялись затраты на новые тесты модулей и багфиксинг.
Нередко бывали случаи, когда менеджер приходил в офис под конец рабочего дня с пиццей в руках и говорил “Проект горит, не расходитесь сегодня”. Тогда нам с небольшой командой разработчиков приходилось допоздна засиживаться в офисе, дорабатывать модули, убирать баги.
С опытом еще больше убедился в том, что программист — системный по характеру человек, ему нужна четкая постановка задачи со всеми нюансами.
Пришёл к выводу, что экономия времени и ресурсов на проектировании сайта — равно головная боль и стресс в дальнейшем для программиста, срыв сроков и нервы для клиента.
Позже, уже в моей компании EZTec, внедрили стадию проектирования сайта. Регулярно дорабатываем ее и сейчас: собираем обратную связь от программистов и менеджеров, узнаем что было удобно, что нет. Таким образом оптимизируем этап для каждого вида программного продукта, учитывая нюансы и сложности его разработки.
Проектирование сайта
Описание
При заполнении брифинга и общения с менеджером, клиент в удобной форме описывает свой проект с точки зрения пользы и требований. Менеджер формирует полное описание проекта.
Архитектура
Утверждаются инструменты технической реализации: сервер, язык программирования, фреймворки, база данных.
Техническое задание
Архитектор формирует документ на основе описания проекта, целей, требований и технической реализации. Пример технического задания.
Прототипирование
Разрабатываются макеты интерфейса и прототипы страниц сайта.
Контроль
Проект-менеджер контролирует на соответствие требованиям и описанию проекта.
Утверждение
Заказчик проверяет техническое задание, вносятся правки.
В среднем у нас уходит 5-10 дней на полное проектирование сайта. Столь небольшое временное вложение дает клиентам возможность “протестировать” нас, получить представление о ответственности и организованности до начала основных работ.
Полный этап проектирования сайта критически важен для проектов, где риски и цена ошибки возрастают. Например, маркетплейсы, новостные порталы, агрегаторы, CRM и ERP системы. Такие проекты можно сделать за квартал, но без проектирования они могут делаться почти год или так и не дойти до первого релиза на продакшен.
Для тех, кто хочет больше разобраться в процессе, рекомендую:
- Информационная архитектура в Интернете. Проектирование масштабных сайтов. Луис Розенфельд, Питер Морвиль
- Разработка требований к программному обеспечению. Карл Вигерс, Джой Битти
- Архитектура корпоративных программных приложений. Мартин Фаулер.
Проще с ластиком у чертежной доски, чем с кувалдой на стройке. Фрэнк Ллойд Райт
ainu
Сайт будет работать как надо, если хорошо выполнены задачи «ЧТО» и «КАК». Он ещё будет приносить пользу/деньги, если хорошо выполнены задачи «ЗАЧЕМ».
Проектирование отвечает только на вопрос «ЧТО», иначе это не проектирование, ибо текст, наиболее полно характеризующий ответ на вопрос «КАК» — это собственно код.
Проектирование необходимо, но не достаточно для гарантии успешной реализации. Особенно если успешной реализацией называть прибыльную.
ainu
Алсо. MySQL 6.0 (в примере ТЗ) не бывает. Определитесь, 5.7 или 8.0.
Алсо, ТЗ с подзаголовком «Идеология и терминология Битрикс» это или Vendor-lock, или просто «вода» чтобы сделать текст ТЗ длиннее. Больше склоняюсь в «воде» (там три строчки описания термина «кнопка», причем главное отличие кнопки от ссылки не названо).
Поддержка Safari (Win) это тоже конечно круто (2012 год!).
Нет информации о процессе оплаты (редирект после заказа, кнопка при просмотре, экваринг, не эквайринг). Видимо диктуется не проектировкой а Битриксом.
«Логотип на главной не должен быть ссылкой на главную» — это атавизм. См. Яндекс, Википедию, Kremlin.ru, Сбербанк, Хабр, comodosslstore, да кого угодно.
Вообще не описаны нарузки и архитектура. Если это действительно наполняемый людьми контент, то при достижении 50-100k записей этот ваш Битрикс просто загнётся, и начнет страницы выдавать по секунде на каждую (в требованиях к хостингу на минуточку, минимум 64 мегабайт ОЗУ).
Избранное — «сохраняется в браузере пользователя для неавторизованных пользователей». Без комментариев.
Будет ли на странице избранного фильт, фолксономия, что угодно — не указано. Попасть туда можно через ЛК. Как попасть туда анониму — не понятно.
Ну и лично от себя — бросайте axure для этого дела. Figma сделает проектировщика счастливым, обещаю.
vitektm
Как по мне, или поддерживать ie 8 или только ie 11.
Версии IE указаны, а версии других браузеров нет.
И вообще IE труп.
Ну и о настройках сервера тоже ни слова, оно и понятно на это многие забивают болт,
о да кеширование мы не включим, зато наш сайт открывается в ie9…
opCache/Redis/MemCache
О результатах в маяке тоже не слова? Правильно ибо боль!
ainu
Алсо, в оформлении заказа есть выбор курьера/службы доставки. В прототипе указана цена. Цену можно захолдить константой (такое себе), а можно получить по API. А для этого нужны габариты и масса. А создатель товара их не вводит.
(А ещё можно по старинке забить, и пусть программист ковыряется в битриксовском модуле «службы доставки». И страдает. И согласования. И правки. И тот ад, который описан в статье, и менеджер с пиццей, и остались на ночь, не не взяли денег с заказчика за интеграцию с API, а без доставки проект как бизнес невоможен, а с фиксированной суммой доставки убыточен.)