Компанія вирішує запустити інтернет-магазин і починає збирати вимоги: потрібен каталог, кошик, оплата, доставка, особистий кабінет. На перший погляд цього достатньо, щоб звернутися до розробників та отримати оцінку.
Але «каталог» для магазину на 100 товарів і каталог на 50 000 позицій із десятками характеристик — це різні задачі. «Доставка» може означати простий вибір способу доставки або складну логіку, залежну від міста, складу, габаритів товару та способу оплати.
Саме тому технічне завдання на інтернет-магазин потрібне не для того, щоб формально описати кожну кнопку. Його основна цінність — домовитися про те, як майбутній магазин повинен працювати.
Хороше ТЗ починається не з переліку сторінок
Одна з типових помилок — описувати майбутній магазин винятково через його інтерфейс: головна сторінка, каталог, картка товару, кошик, checkout.
Це необхідно, але цього недостатньо.
Перед проєктуванням потрібно зрозуміти саму модель продажів. Звідки на сайт потрапляють товари? Хто встановлює ціни? Де зберігаються залишки? Чи є декілька складів? Що відбувається після оформлення замовлення? Де менеджер змінює його статус?
Від відповідей залежить не тільки backend. Вони впливають на структуру каталогу, картку товару, checkout і навіть на те, яку CMS доцільно використовувати.
Каталог потрібно проєктувати на реальних товарах
Каталог часто здається найпростішою частиною магазину. Є категорії, товари та фільтри — що тут проєктувати?
На практиці саме тут можуть з’явитися рішення, які потім складно змінювати.
Уявімо магазин сантехніки. Для змішувачів покупцеві важливі тип монтажу, матеріал, колір та призначення. Для ванн — розмір, форма, матеріал та спосіб встановлення. Для комплектуючих набір характеристик буде зовсім іншим.
Якщо спочатку створити універсальну структуру «товар + декілька характеристик», а вже потім завантажити реальний асортимент, може виявитися, що нормальні фільтри побудувати складно.
Тому ще на етапі ТЗ корисно взяти декілька реальних категорій і пройти весь шлях: категорія → фільтрація → товар → варіант товару → кошик.
Потрібно визначити, звідки сайт отримує дані
Для невеликого магазину товари можна створювати безпосередньо через адміністративну панель. У більшому e-commerce джерелом частини інформації часто стає ERP або облікова система.
Наприклад, компанія вже працює з BAS. Там створюється номенклатура, змінюються ціни та ведеться склад. Якщо після запуску нового магазину контент-менеджер почне окремо змінювати ті самі дані на сайті, бізнес отримає два джерела інформації, які рано чи пізно розійдуться.
Тому в ТЗ важливо визначити не просто наявність інтеграції, а напрямки обміну.
BAS може передавати на сайт артикул, ціну та залишок. CMS — зберігати SEO-тексти й фотографії. Сайт — передавати оформлене замовлення назад в облікову систему. Конкретна схема залежить від процесів компанії.
CODEVISION реалізує інтеграції сайтів із бізнес-системами, зокрема обмін товарами, цінами, залишками та замовленнями.
Checkout краще описувати сценарієм покупця
Формулювання «стандартне оформлення замовлення» небезпечне тим, що кожна сторона може розуміти під ним щось своє.
Покупець додає товар у кошик. Далі він може оформити покупку без реєстрації або увійти в особистий кабінет. Обирає місто, спосіб доставки, відділення або адресу, спосіб оплати. Можливо, вводить промокод. Після успішної оплати отримує повідомлення, а замовлення передається менеджеру або автоматично потрапляє в CRM/ERP.
Коли процес описаний таким сценарієм, набагато легше помітити невизначені місця.
Що робити, якщо оплата не пройшла? Чи можна повторити її з особистого кабінету? Чи резервується товар до оплати? Що відбувається, якщо останню одиницю одночасно замовили двоє покупців?
Ці питання впливають на розробку значно сильніше, ніж колір кнопки «Купити».
Інтеграції потрібно обговорювати до оцінки проєкту
CRM, ERP, платіжна система, служба доставки, email-маркетинг, телефонія, програма лояльності — у реального інтернет-магазину швидко з’являється ціла екосистема сервісів.
Тому одна фраза «потрібна інтеграція з CRM» у ТЗ не працює. Для кожної інтеграції потрібно хоча б на базовому рівні визначити три речі: які дані передаємо, куди передаємо і що має відбутися після передачі.
Наприклад: Покупець оформлює замовлення → сайт створює замовлення → дані передаються в CRM → менеджер отримує нову заявку → зміна статусу синхронізується з магазином.
Це вже бізнес-сценарій, який можна обговорювати, оцінювати та проєктувати.
ТЗ не повинно блокувати розвиток магазину
Є інша крайність — намагатися до початку розробки описати абсолютно все, що бізнес може захотіти через три роки.
Так технічне завдання легко перетворюється на величезний документ із функціями, частина яких ніколи не буде використовуватися.
Раціональніше відділити функціонал, без якого магазин не може запуститися, від можливостей, які можна додати на наступних етапах.
Наприклад, на старті компанії потрібні каталог, фільтрація, оплата, доставка та інтеграція з обліковою системою. Складну бонусну програму, B2B-кабінет або персоналізовані ціни можна передбачити в архітектурі, але реалізовувати пізніше, якщо вони не потрібні для першого запуску.
Це не означає «зробити простіше». Це означає не змішувати критичні вимоги з ідеями на майбутнє.
Що потрібно мати перед стартом розробки
Не обов’язково приходити до веб-агенції зі стосом документації на сотню сторінок. Часто достатньо добре розуміти бізнес-модель, асортимент, основні сценарії покупця та внутрішні процеси.
А вже на етапі аналізу ці вимоги можна перетворити на структуру, прототипи та конкретний функціонал. На сторінці e-commerce CODEVISION саме аналіз і проєктування зазначені серед початкових етапів роботи над інтернет-магазином.
Якщо ви плануєте новий магазин, краще обговорювати з командою не лише те, як він повинен виглядати, а й те, як він буде пов’язаний із продажами, складом, оплатою, доставкою та внутрішніми системами компанії. CODEVISION розробляє e-commerce-проєкти та реалізує необхідні інтеграції — можемо розібрати вимоги до майбутнього магазину й визначити формат реалізації.
