Сделайте к понедельнику: от чего зависят сроки создания сайтов

Каждый заказчик хочет знать, когда ему ждать результатов. Однако в сфере веб-разработки оценка сроков — это непростой вопрос. 

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

В этой статье разберем:

• Из каких этапов складываются реальные сроки и какую работу можно запараллелить

• Сколько в среднем занимает создание лендинга, корпоративного сайта, интернет-магазина и корпоративного портала

• Из-за чего срываются дедлайны и как обезопаситься от таких ситуаций

• Почему попытки «ускорить любой ценой» почти всегда выходят боком

Ну а для начала обсудим…

Почему разработку сайта нельзя оценивать на глаз

Идея стандартизировать сроки кажется соблазнительной. Некоторые менеджеры, когда готовят коммерческое предложение, нередко стараются дать заказчику четкий ответ на вопрос заказчика: «Ну и сколько все это займет?» Но правда в том, что универсального калькулятора не существует, и вот почему.

Зависимость сроков от типа сайта

Вроде очевидно, что лендинг сделать быстрее, чем интернет-магазин. Но даже в простых кейсах все упирается в нюансы.

Лендинг может быть простым скролл-сайтом из трех блоков и формой обратной связи или полноценным приложением с мультифункциональным калькулятором, анимацией, нестандартной версткой и десятками правок по дизайну. 

Корпоративный сайт может быть визиткой на 5 страниц — или структурным каталогом с фильтрами, личными кабинетами и интеграцией с внутренними системами. 

Мясная фабрика Александров — пример не самой простой визитки с точки зрения исполнения. Хотя личного кабинета и интеграций там нет, повозиться все равно пришлось. Мы сделали свое небольшое исследование китайского рынка веб-дизайна. 

Интернет-магазин бывает подборкой из 20 карточек товаров без логистики или полноценной витриной с интеграцией с «1С», маркетплейсами, CRM и оплатой на сайте. 

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

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

Значение бизнес-целей заказчика

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

Если сайт — это просто визитка и его делает собственник малого бизнеса, все будет идти быстрее. Но если заказчиком выступает крупная компания с ИТ-отделом, брендбуком, несколькими командами, которые надо синхронизировать между собой, то большое время уйдет на согласования, подготовку документации и интеграцию разных систем.

На сроки влияет зрелость внутренней ИТ-структуры и управляемость проекта: от четкого роадмапа и грамотного менеджера в штате до банального наличия тестовой среды. Без этого даже опытная команда буксует.

Одинаковые на первый взгляд проекты могут требовать разного времени

Один интернет-магазин сделали за 6 недель, другой — за 6 месяцев. Оба выглядят примерно одинаково. Почему?

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

Из чего получаются сроки: этапы разработки

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

1. Аналитика и постановка задачи

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

Чтобы не попадать в такие ситуации при создании сайта, разработку нужно начинать с аналитики. На этом этапе выясняются цели бизнеса, фиксируются ограничения (бюджет, сроки, техническая инфраструктура), формируется первичное понимание структуры и функционала.

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

2. Техническое задание и проектирование

Хорошее ТЗ — это половина успеха, а плохое — гарантия будущих конфликтов. Первое отличается от второго степенью проработки.

Чтобы ТЗ на сайт выполняло свою задачу, оно должно включать карты экранов и сценарии взаимодействия с разными целевыми аудиториями, ключевые требования к логике и интеграциям, проработанные пользовательские роли, потоки, jcj,tyysq aeyrwbjyfk.

3. Дизайн

Сюда входят:

• Подготовка референсов

• Разработка дизайн-концепции

• Отрисовка основных экранов

• Создание версии под мобильные устройства

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

4. Фронтенд и бэкенд-разработка

Фронтенд — это внешняя сторона, сюда входят работы по верстке, анимации, созданию адаптивов, выстраиванию интерактивных элементов.

Бэкенд — это подкапотное пространство, где располагаются средства управления контентом (CMS), логика личных кабинетов и форм ввода данных, интеграции с внешними системами.

У сайтов со сложной архитектурой (например, у интернет-магазинов с фильтрами, корзиной, оплатой, доставкой), этап разработки может растянуться на месяцы. Если же речь идет про лендинг с фиксированными блоками, наоборот, все можно сделать за пару дней.

Индивидуальные решения со сложной логикой могут разрабатываться месяцами и годами. Пример — интернет-магазин «Юркас». С ними мы глубоко погрузились в специфику дверного бизнеса, реализовали примерку дверей в интерьер в карточке товара и сделали конфигуратор с возможностью собирать десятки тысяч моделей.

5. Интеграции с внешними системами

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

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

Эту часть работы часто недооценивают, а зря. Если у клиента нет документации по работе бухгалтерской системы, а ИТ-служба выдает разработчикам доступы с задержкой, процесс начинает сильно тормозить. 

Поэтому нужно заранее подумать, с какими источниками данных должен взаимодействовать сайт:

• CRM-службами

• Складскими и бухгалтерскими системами 

• Платежными шлюзами и маркетплейсами

• Сторонние API

6. Наполнение контентом

Еще одна задача, про которую постоянно забывают: работающий сайт нужно поддерживать и развивать. Это значить готовить тексты, фото и видео, форматировать контент под требования верстки, загружать его на ресурс, добавлять карточки товаров, шаблоны новостей и статей.

Иногда это делает агентство, иногда — заказчик. Во втором случае сроки часто зависят от того, как быстро клиент собирает нужный контент. 

7. Тестирование

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

Что если пользователь не переключит раскладку? Не сломает ли это сайт? Может ли злоумышленник внедрить в поле логина вредоносную команду и взломать веб-сервер? На какую страницу возвращать клиента, если банк отказывается оплачивать покупку из-за недостатка средств?

Тестировщики помогают определить неочевидные сценарии работы с сайтом, найти все технические шероховатости, доработать «защиту от дурака». Они проверяют отображение контента на разных устройствах, функционирование всех форм, фильтров и кнопок, валидность HTML/CSS-элементов и скорость загрузки страниц в разных условиях.

Если не заложить время на исправление ошибок, выход сайта в боевую среду наверняка не состоится в запланированную дату. А в худшем случае компании предстоит столкнуться с недовольными клиентами, а то и утечками данных.

8. Подготовка к запуску

Когда сайт вроде бы готов, нужно заложить еще несколько дней на подготовительные работы. Сюда входят перенос на боевой сервер, настройка домена, SSL-сертификата, почты, установка аналитики и метрик, итоговая проверка по чек-листу.

Иногда это делается за день, но любая мелочь вроде неработающего SMTP или отсутствующего доменного доступа может затянуть финал.

Над чем можно работать параллельно

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

Но: аналитику, создание ТЗ и проектирование всегда нужно завершить до того, как к работе подключатся дизайнеры и веб-разработчики. Иначе это приведет к авральным переделкам и срывом сроков.

Любое дополнительное пожелание, даже «просто поправить кнопку», — это плюс часы или даже дни работы. У команды есть контекст, пайплайн, сроки, так что каждая дополнительная задача так или иначе влияет на конвейер. Особенно критично, если правки приходят на финальных этапах.

Основные типы проектов

Сразу повторим главный тезис: каждый проект особенный и развивается по индивидуальному сценарию. Сроки создания сайта сокращаются, если есть проработанное ТЗ и контент, если клиент постоянно на связи и быстро согласовывает материалы, а также если сложность позволяет использовать шаблонные решения (например, CMS с готовыми модулями).

С другой стороны, проекты непредсказуемо разрастаются, когда утверждение макетов проходит по множеству уровней, когда брифы оказываются неполными, когда приходится интегрироваться с плохо документированными системами.

Не верьте, если вам обещают сайт за 17 дней и ни минутой больше (если только подрядчик не готов вписать это обещание в договор, а настоящий профессионал вряд ли так сделает).

Сроки можно назвать только зная ваши вводные. 

Читайте: 

Какой сайт вам нужен: когда пойдет шаблон за 50 тысяч, а когда интернет-магазин за 20 миллионов рублей  

Лендинг

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

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

Но если клиент еще не до конца понимает, что продает, и хочет «бренд-концепцию», работа может растянуться и на месяц, и на два. Большая часть времени при этом уйдет на то, чтобы ответить на вопросы, с которыми нужно определиться заранее.

Корпоративный сайт-визитка

Такой сайт можно назвать лендингом на максималках. У него небольшой объем (5-10 страниц) и нет сложной логики. В идеале у заказчика уже должны быть хорошие тексты и фото. Тогда команда разработки сможет сосредоточиться на дизайне, верстке и быстрой загрузке контента.

Пример: «Мясокомбинат Светлый» 

Обычно на корпоративном сайте есть блоки «О компании», «Услуги», «Контакты», «Кейсы», а также форма обратной связи. Иногда еще добавляется блог, и в этом случае, как мы говорили, нужно помнить, что его нужно будет регулярно обновлять.

Корпоративный сайт

Это уже по-настоящему серьезный проект: к базовым разделам из предыдущего пункта добавляется список товаров и услуг с возможностью оформления заказа. Базовые функции удобного каталога — это фильтрация, сортировка, работа с карточками с разными типами контента. 

Чем крупнее бизнес, чем шире ассортимент товаров и услуг, тем больше растут сроки. 

Со стороны исполнителя: потому что нужно спроектировать, разработать и проверить всю сложную логику. 

Со стороны заказчика: потому что становится больше решений, больше утверждений и правок. Техзадание на такой сайт нередко превращается в документ на 50 страниц.

Пример: ТРЦ Galleria Minsk

Интернет-магазин

Такой ресурс потребует не просто страницы с каталогом, но и сложной сопутствующей архитектуры. У интернет-магазина должна быть корзина, страница для оформления заказа, личные кабинеты пользователей, поддержка разных способов оплаты и доставки.

Пример: Digital-инфраструктура магазина мобильного оператора

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

Корпоративный портал

Такой сайт можно сравнить с внутренним интернет-магазином компании, только вместо заказа товаров здесь будет оформление командировок и отпусков, работа с электронными документами, просмотр базы знаний и т. д.

На корпоративном портале должен быть личный кабинет, поиск по сотрудникам, лента новостей. Иногда заказчики просят развернуть целый интранет с комментариями, архивом публикаций, таск-трекерами и даже авторизацией через VK. Поэтому такие проекты в большинстве своем требуют индивидуальной архитектуры и сильно завязаны на внутренней инфраструктуре компании. Также нужно подумать о требованиях к безопасности, отказоустойчивости и масштабируемости, чтобы злоумышленник не мог через портал проникнуть во внутреннюю сеть, а открытие нового офиса не требовало перестраивать всю логику ресурса.

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

Как планировать с учетом рисков

На практике любой проект сталкивается с отклонениями. Чтобы сроки разработки не стали вечностью, важно предусмотреть буферы и уметь работать с неопределенностью.

Заложите запас времени на каждом этапе

Правило простое: все, что может пойти не по плану, наверняка пойдет не по плану. Дизайнер заболеет, менеджер уволится, иллюстрации не подойдут к новой версии CMS. Поэтому если этап занимает 2 недели, ставьте в график минимум 3-4. 

Уточняйте зоны неопределенности

Если что-то звучит как «разберемся позже», это тревожный звоночек. Каждый туманный пункт нужно прояснить до старта разработки. Иначе проект застрянет на середине, когда не будет ни бюджета на доработки, ни времени на исследования.

Работайте итерациями

Не всегда можно заранее предсказать все сценарии. В таком случае поможет подход MVP — минимально жизнеспособного продукта. Сделайте базовую версию, проверьте свои гипотезу и масштабируйтесь. Это снижает риск глобальных переделок.

Пропишите политику правок

Правки неизбежны, но можно договориться, что считается простым изменением, а что требует нового ТЗ. Например, установите, что по мелким UI-изменениям у вас есть два раунда правок, а дальше — по допсоглашению. 

Планируйте зависимые работы

Как мы уже говорили, сайт не существует в вакууме. Нужно завести CRM, подключить склад, интегрировать маркетплейс. Все это требует внешних доступов, людей, согласований. Такие задачи нужно планировать вместе с разработкой.

Почему попытки ускорить могут привести к срыву

Однако нужно четко понимать: проект можно разогнать только до определенной степени. 

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

Как следствие предыдущего пункта, спешка повышает нагрузку на людей, вызывает выгорание и повышает хаос в проекте. Одна за другой начинают сыпаться мелочи: здесь забыли про адаптив для мобильных, там не проверили интеграцию, а потом вообще в Chrome сломалась верстка. Все это требует отката и тратит время.

Когда ради скорости из продукта выбрасывают «необязательные» детали (авторизацию, фильтры, поиск), они возвращаются позже в виде допработ. На каждом следующем этапе приходится все больше чинить то, что накостылили на старте.

Когда проект уже опаздывает, часто хочется поскорее запуститься. Тестирование упрощается, регрессия не проводится, критичные ошибки попадают в боевую среду. Так запуск превращается в новый этап разработки.

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

Заключение

Сроки разработки сайта отражают зрелость компании, уровень проработки задачи и слаженность команды. Универсального шаблона нет: два проекта с одинаковым ТЗ могут идти по разным траекториям в зависимости от деталей, коммуникации и уровня доверия между сторонами.

Важно не только изначально честно оценить объем работ, но и грамотно управлять процессом. Правки, интеграции, согласования, задержки с контентом — это часть работы, которую нужно предусмотреть. Если правильно подойти к планированию, можно избежать 90% проблем. 

Главное, помните: чтобы сделать продукт, который привлечет пользователей и принесет прибыль, нужны четкий рабочий ритм, прозрачность и сотрудничество.