Найпоширеніша причина зірваних дедлайнів у веброзробці — не лінощі підрядника і не форс-мажор. Це розмите технічне завдання. Коли в документі написано «зробити зручний каталог», кожна сторона розуміє під цим своє, і на етапі здачі починається болісне з’ясування, хто що мав на увазі. Проєкт на два місяці розтягується на пів року.
Хороше ТЗ не робить процес бюрократичним. Воно робить його передбачуваним.
Що має бути в документі
Цілі та обмеження. Навіщо магазин, скільки товарів у каталозі зараз і скільки буде через рік, які регіони обслуговуєте, хто ваш покупець. Це рамка, у якій приймаються всі подальші рішення. Перш ніж замовити інтернет магазин, варто витратити тиждень саме на цей розділ — він економить місяці згодом. Наприклад, у веб студії TeraGroup не беруть проєкт у роботу, поки цей блок не заповнений: без нього неможливо назвати ані терміни, ані чесну ціну.
Структура сайту. Перелік усіх сторінок і типів шаблонів: головна, категорія, картка товару, кошик, оформлення замовлення, особистий кабінет, статичні сторінки. Просто список — але він одразу показує реальний обсяг робіт.
Функціонал по пунктах. Не «фільтри», а конкретно: фільтр за ціною повзунком, за брендом чекбоксами, за наявністю. Не «кошик», а: чи можна змінювати кількість, чи зберігається вміст після закриття вкладки, чи працює промокод.
Інтеграції. Найнедооціненіший розділ і водночас головне джерело затримок. Перелічіть усе: Нова пошта, Укрпошта, платіжна система, 1С або BAS, CRM, вивантаження на маркетплейси, аналітика. Для кожної інтеграції — хто надає доступи та API-ключі й у які терміни.
Контент. Хто пише тексти, звідки беруться фото, у якому форматі передається база товарів. Класична пастка: сайт готовий, а замовник ще два місяці збирає описи товарів — і винним у зриві термінів чомусь виявляється розробник.
Приймання і підтримка. За якими критеріями робота вважається виконаною, скільки триває гарантійний період, що входить у безкоштовні правки, а що оплачується окремо.
Три поради з практики
Не описуйте рішення — описуйте задачу. Замість «зробити кнопку в правому верхньому куті» пишіть «покупець має бачити кількість товарів у кошику з будь-якої сторінки». Як саме це реалізувати, краще знає розробник.
Фіксуйте, чого в проєкті немає. Це рятує від суперечок сильніше, ніж список того, що є.
І закладайте окремим пунктом порядок внесення змін. Вони будуть — питання лише в тому, чи будуть вони керованими.
