Скільки насправді займає розробка e-commerce і що має робити клієнт

Peretz Group

Chapters

How Long Does an E-Commerce Build Actually Take, and What the Client Has to Do

Більшість 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 тижнів».

Це:

«Ось що має статись, хто за яку частину відповідає, що ми припускаємо, і що станеться з графіком, коли одне з цих припущень зміниться».

Це набагато менш приваблива фраза для продажу.

І набагато корисніша.

Якщо ти плануєш e-commerce проєкт і хочеш реалістичну картину строків, перша розмова має бути не про те, як швидко хтось може почати писати код. Вона має встановити, що бізнесу справді потрібно, що належить побудувати, яка інформація вже існує, яким системам потрібно з'єднатись, кому належить кожне рішення і що бізнес реально може забезпечити під час проєкту. Саме це Стратегічна сесія і покликана встановити до того, як обсяг перетвориться на графік.

Забронювати Стратегічну сесію

Ознайомтесь з нашими послугами розробки e-commerce.

Реалістичний графік e-commerce проєкту, це не найкоротший, який може пообіцяти агенція. Це той, який обидві сторони реально зможуть витримати.