Итак, на дворе 2024й, и Вы таки решились заказывать разработку сайта без конструкторов (Tilda, Wix, Ukit и тп), без использования многочисленных шаблонов для Wordpress или Битрикс, даже подумывали посмотреть в сторону плагина Elementor для Wordpress, но нет. Точно? Уверены? Тогда поехали!
А действительно - зачем этот квест может быть нужен в то время, когда ноу/лоу-код разработка большими шагами завоевывает мир?
- СтатусностьЕсли вы - бутиковое агентство, то вам просто не солидно использовать шаблоны и конструкторы.
- Автоматизация или интеграции с внутренним ПОНапример - сайт в определенном виде должен обмениваться данными с чат-ботом и мобильным приложением с помощью API, или нужно автоматизировать работу с большим количеством данных.
- Нетиповой личный кабинетНапример обмен данными с внутрикорпоративными системами через сервер очередей или возможность получать POST-запросы от сервисов, которые находятся внутри корпоративной сети за VPN.
- ДизайнНужен особый язык для общения с вашей ЦА и ни один шаблон не подойдет.
- БезопасностьХраним данные только на своих серверах, опасаемся решений на Wordpress по соображениям безопасности.
Кому в 2024 крайне противопоказана заказная разработка:
- Стартапы до того, как найден product/market fit (лучше усилить кастдев)
- Микро-бизнес (конструкторы помогут снизить издержки и выиграть время)
- Персональные проекты, особенно если Вы плохо разбираетесь в том, как устроены Интернет-проекты
- Типовые решения, разовые мероприятия (продажа билетов на 1 мероприятие, блог, сайт о книге или небольшое портфолио)
- Любой проект со сроком "вчера"
До того, как читать дальше - предлагаю еще раз подумать (пока не поздно) и рассмотреть вариант более быстрой и недорогой разработки web-проектов на конструкторах. Итак, вы все же решились обратиться к частным специалистам или в агентство для разработки сайта. На что я рекомендую обращать внимание:
- Готовим материалы для проекта:
- выжимку из маркетинговой стратегии, необходимую для разработки (группы ЦА, боли, УТП, конкуренты и т.д.)
- актуальные графические материалы в исходниках (логотип, брендбук если есть, презентации и т.п.)
- если есть текущая версия сайта - то указываем, что по материалам оставляем, что перерабатываем
- делаем акцент на том, какие материалы необходимо будет разработать в процессе создания сайта (графика/тексты/видео)
- размещаем все материалы по проекту в одном месте, готовим ссылочку
- Запрашиваем бриф и заполняем его, отправляя вместе со ссылкой на подготовленные материалы по проекту
- План работ по проекту. Учитываем время, необходимое для:
- разработки прототипа по ключевым страницам версии для ПК и смартфона (планшет можно опустить в большинстве случаев на прототипе)
- формирования обратной связи по прототипу/макетам дизайна
- корректировок и доработок
- возможные паузы между этапами (прототипирование/дизайн/верстка/программирование/тестирование/наполнение и подготовка к публикации/публикация)
- согласовываем технические детали (где размещаем репозитории верстки и программирования, какой язык программирования используем, требования к верстке и т.п.)
- создаем проектную документацию, в которой собираем все договоренности по проекту и ссылки на материалы
- Работаем! Как можно ускорить процессы:
- максимально качественно проработать этап №1 внутри компании. иногда уже на этом этапе нужна помощь на аутсорсе - не стесняйтесь - привлекайте специалистов с рынка
- принимать дизайн по 1 макету (иногда Заказчик просит готовить несколько макетов сразу - это растягивает проект)
- распараллелить этапы (например - начинать верстку после согласования 1-го макета дизайна со всеми адаптивными версиями - обычно это ПК, планшет и смартфон)
- определиться с технической частью проекта на этапе согласования прототипа и начать подготовку серверной архитектуры и необходимых компонентов заранее
- по-возможности делать дизайн и верстку с готовым контентом (чтобы избежать ситуации, когда текста в итоге оказалось меньше и в макете появляются незапланированные "свободные пространства")
- обновляем проектную документацию по завершению каждого этапа
- указать сценарии по работе с контентом и попросить в момент реализации сразу готовить необходимую проектную документацию
- Готово - принимайте
- принимаем работы по этапам - дизайн сверяем по прототипу (все ли учли), верстку - по дизайну (ничего ли не поехало), сборку сайта сверяем с версткой
- обязательно проверяем работу верстки на всех устройствах, уделяя внимание деталям - насколько удобно пользоваться интерактивом на touch-устройствах, насколько плавно отрабатывает анимация или слайдеры и тп
- в момент подключения сайта к админке - проверяем кейсы с разным объемом контента - подгрузку других изображений и редактирование текстов на большие/меньшие по объему
- проверяем работу админки по согласованным сценариям
- когда кажется, что все готово, берем небольшую паузу и просим коллег свежим взглядом посмотреть на проект - собираем обратную связь до запуска (чтобы сроки позволяли - хорошо бы на этот этап закладываться в плане работ по проекту)
- финализируем проектную документацию
- запускаемся и готовимся оперативно вносить корректировки, которые обязательно возникнут после запуска большого и сложного проекта на рабочем окружении
- Исходники прототипа и дизайна (это поможет быстрее и качественнее дорабатывать визуал)
- Исходники верстки (обычно это как минимум sass/pug-файлы и какой-либо сборщик на gulp/webpack - это поможет быстрее/дешевле вносить доработки по дизайну на верстку)
- Сохранить репозиторий верстки и программной части проекта на своих ресурсах (локально или корпоративный Git-сервер)
- Проектную документацию и все исходные материалы
- Пароли, токены и тп важную информацию храним в специализированном месте
Мы привели основные опорные пункты по процессам разработки сайта. Конечно, этот список далеко не полный, но даже по нему можно понять объем работы, который проводит агентство или группа частных специалистов. Сейчас все реже встречаются универсалы, способные спроектировать проект, разработать дизайн, верстку, запрограммировать и задокументировать проект с надлежащим качеством и в разумные сроки. Хотя в далеком 2000м году, большинство специалистов все это делали в одиночку. Но и требования к проектам, конечно, были другие.
