Сколько на самом деле занимает разработка e-commerce и что должен делать клиент

Большинство e-commerce проектов, которые выбиваются из сроков, задержали не те люди, что пишут код.

Агентству неудобно это говорить, во многом поэтому об этом и молчат.

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

Так паттерн повторяется, и клиент никогда не узнаёт то единственное, что помогло бы: какими частями графика он реально управляет.

График, это общее обязательство.

Обычно об этом говорят только одной стороне.

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

Куда уходит время

Куда уходит время

E-commerce проект проходит через discovery, UX/UI дизайн, разработку, интеграции, наполнение контентом, тестирование и запуск.

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

Иногда так и есть.

Но многие задержки кучкуются в двух точках, которые на удивление мало связаны с написанием кода:

до начала разработки, пока объём и контент ещё утрясаются, и прямо перед запуском, во время тестирования и согласования.

Обе фазы сильно зависят от клиента.

Это не обвинение.

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

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

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

Она в том, сколько неопределённости содержит график.

Эффект множителя

Эффект множителя

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

Допустим, команда ждёт финальную предметную съёмку.

Фотографии должны были прийти в понедельник.

Они приходят в четверг.

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

Так гладко бывает редко.

Команда разработки не обязательно сидит без дела с понедельника по четверг.

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

Когда недостающий материал наконец приходит, эти люди могут уже работать над чем-то другим.

Исходный контекст приходится восстанавливать.

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

Иногда за это время появилась другая зависимость.

Иногда задержавшийся контент меняет более раннее решение.

Иногда человек, который изначально вёл эту задачу, на той неделе уже недоступен.

Так трёхдневная задержка с отправкой фотографий может превратиться в заметно большее смещение общего календаря.

Именно поэтому клиент и агентство могут помнить один и тот же проект очень по-разному.

Клиент помнит:

«Мы опоздали всего на пару дней».

График проекта помнит:

«Зависимость появилась после того, как команда уже переключилась».

Оба утверждения могут быть правдой.

Контент, это узкое место

Контент, это узкое место

В e-commerce проектах одна из самых частых причин срыва сроков не техническая.

Это данные о товарах.

Названия.

Описания.

Изображения.

Вариации.

Цены.

Категории.

Атрибуты.

Характеристики.

Структуры SKU.

Связи между товарами.

Всё это должно существовать до того, как каталог можно осмысленно построить и протестировать.

Оформление заказа нельзя нормально протестировать на товарах без реальных цен.

Фильтры нельзя проверить на атрибутах, которые ещё придумываются.

Логику вариаций нельзя финализировать, пока клиент ещё решает, какие вариации вообще существуют.

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

Актуальные руководства по e-commerce разработке регулярно называют готовность товарных данных и качество миграции среди факторов, способных сдвинуть проект с графика.

Важно не то, что клиенты должны как-то стать инженерами данных.

Важно, что команда не может строить на информации, которой ещё не существует.

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

Что на самом деле значит «готово»

Данные о товарах обычно называют готовыми задолго до того, как они таковыми становятся.

Практическое определение гораздо однозначнее.

До того как разработка дойдёт до частей проекта, зависящих от каталога:

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

Каталог, отвечающий этим условиям, это то, на чём команда может строить.

Каталог, где три из них ещё обсуждаются, нет.

Это движущаяся спецификация.

А движущаяся спецификация обычно порождает движущуюся разработку.

Связь между структурой каталога и стоимостью разработки подробнее разобрана в статье Что на самом деле делает разработку e-commerce дорогой.

У решений тоже есть цена

У решений тоже есть цена

Контент, это видимое узкое место.

Решения, тихое.

Вопрос уходит клиенту.

Он ждёт.

Команда не может остановиться, поэтому действует по допущению, потому что действовать по допущению, это путь наименьшего сопротивления, а альтернатива, остановить уже оплаченную работу.

Иногда допущение верное.

Когда нет, исправление приходит позже.

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

Это происходит с удивительно мелкими вещами:

Какие товары реально запускаются?

Должно ли это поле быть обязательным?

Получает ли этот тип клиента оптовые цены?

Должна ли эта интеграция синхронизировать ещё и остатки или заказы?

Должна ли эта страница существовать на каждом языке?

Должна ли эта акция распространяться на вариации?

Важен ли этот старый URL для SEO?

Каждый вопрос без ответа технически всё равно решение.

Просто оно становится решением по умолчанию.

Вопрос без ответа не ставит проект на паузу. Он отвечает сам себе.

Это одно из самых дорогих предложений в разработке.

Клиент, часть команды

Клиент, часть команды

Это не значит, что клиент должен управлять разработчиками.

Не должен.

У клиента другая работа.

Клиенту принадлежат решения, которые агентство не может ответственно принять за него.

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

Поэтому у здорового проекта две параллельные дорожки поставки.

Агентство отвечает за

• discovery
• UX/UI
• разработку
• интеграции
• QA
• технические решения в рамках согласованного объёма
• деплой

Клиент отвечает за

• бизнес-решения
• информацию о товарах
• согласования
• доступ к внутренним системам
• согласие стейкхолдеров
• своевременную обратную связь
• финальную приёмку

Когда обе дорожки движутся вместе, движется проект.

Когда одна останавливается, вторая рано или поздно её догоняет.

Именно поэтому график проекта никогда не должен показывать только задачи агентства.

Разговор, которого избегают

Разговор, которого избегают

Есть структурная причина, почему эта информация редко доходит до клиентов.

Сказать клиенту, что ограничение, это он, коммерчески неудобно.

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

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

Но данные обычно есть.

У каждого заданного и отвеченного вопроса есть отметка времени.

У каждого согласования есть отметка времени.

У каждой поставки контента есть отметка времени.

У каждого запроса на изменение есть отметка времени.

Система управления проектом часто может восстановить, что именно происходило.

Просто это не тот тип доказательств, который кто-то хочет предъявлять на ретроспективе, потому что разговор внезапно становится личным.

Мы предпочитаем поднять вопрос зависимостей в начале, когда это полезно, а не в конце, когда это превращается в спор.

Цель не в том, чтобы доказать, что задержку вызвал клиент.

Цель в том, чтобы клиент понимал, какими частями графика он может управлять.

Тестирование, не редизайн

Тестирование, не редизайн

Финальная фаза перед запуском, это место, где графики часто рассыпаются.

Приёмочное тестирование принадлежит клиенту.

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

Это не момент, чтобы пересматривать весь дизайн.

Это две совершенно разные активности.

У полезного процесса приёмки есть:

• определённое окно тестирования
• ясный список областей для проверки
• одно структурированное место для обратной связи
• различие между дефектами и новыми запросами
• человек, отвечающий за сведение обратной связи

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

Различие между дефектом и новой идеей особенно важно.

«Кнопка оформления заказа не работает», это дефект.

«Нам надо переделать оформление заказа перед запуском», это новое проектное решение.

Новые идеи не враг.

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

Бессрочный период тестирования обычно превращается одновременно во второй этап дизайна, сессию запросов на фичи и бесконечную задержку.

Сколько это занимает

Сколько это занимает

Осмысленного универсального числа не существует.

Диапазон зависит от того, что строится.

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

Кастомная витрина с индивидуальным UX/UI, реальным каталогом, интеграциями и работой по миграции обычно занимает несколько месяцев.

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

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

Мультиязычные проекты добавляют ещё один слой.

И это добавление не сводится к простому:

Один язык равен X недель, значит три языка равны 3X недель.

Контент нужно локализовать, проверять и поддерживать.

Некоторые макеты должны вмещать другие системы письма.

SEO нужны локализованные структуры.

А бизнесу нужно реально поддерживать эти версии после запуска.

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

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

Обычно это допущение с наибольшей вероятностью не сбывается.

Что подготовить заранее

Что подготовить заранее

Самый эффективный способ сжать сроки e-commerce проекта на удивление мало связан с командой разработки.

До начала разработки клиент может решить несколько вещей, которые иначе становятся зависимостями позже.

Решить, у кого есть право утверждать

Одному человеку не обязательно принимать каждое решение.

Но все должны знать, за кем финальное слово.

Назначить владельца товарных данных

Кто-то внутри бизнеса должен владеть каталогом.

Не обязательно готовить каждую таблицу лично.

Но кто-то должен отвечать за то, готовы ли данные на самом деле.

Определить интеграции заранее

Каким системам нужно общаться?

Кто ими администрирует?

Кто может дать доступы?

Какие данные должны двигаться в каждом направлении?

Решить, что будет с существующими URL

Если ты переделываешь или переносишь существующий магазин, SEO не может стать разговором на неделе запуска.

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

Отделить решения от возможностей

Не каждую идею нужно решать немедленно.

Но команде нужно знать, что уже решено, а что действительно открыто.

Быть честным насчёт скорости ответа

Это, пожалуй, самая недооценённая зависимость из всех.

Если клиент говорит:

«Мы обычно отвечаем в течение двух дней».

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

График, построенный на оптимистичной скорости ответа, это не амбициозный график. Это выдуманный.

Как читать график

Как читать график

График в предложении, это утверждение.

Одни утверждения проверяемы лучше других.

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

Что график предполагает о товарных данных?

Что он предполагает о контенте?

Что он предполагает о согласованиях?

Что он предполагает об интеграциях?

Что произойдёт, если один из этих входов опоздает?

Где отмечены зависимости от клиента?

Ограничено ли тестирование по времени?

Каков механизм обратной связи?

Каковы точки согласования?

Сколько времени отведено на каждую?

Что явно исключено из графика?

И, пожалуй, самый показательный вопрос:

Что превратит этот восьминедельный график в двенадцатинедельный?

Хорошее агентство должно ответить на это без запинки.

График, описывающий только работу агентства, это не проектный график.

Это оценка собственной работы агентства, поданная как дата поставки.

Разница становится очевидной где-то к шестой неделе.

График, это общее обязательство

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

Обычно это те, где обе стороны понимали, ещё до первой строчки кода, на что и к какому сроку они подписались.

Агентство не может управлять тем, как быстро клиент утвердит каталог.

Клиент не может управлять тем, сколько занимает правильно спроектированная интеграция.

Ни одной стороне не выгодно притворяться иначе.

Поэтому полезный график, это не «мы построим тебе магазин за X недель».

Это:

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

Это гораздо менее привлекательная фраза для продажи.

И гораздо более полезная.