Як замовити сайт і правильно підготувати технічне завдання

Технічне завдання починається не з технологій

Замовнику не обов’язково заздалегідь вирішувати, який framework, CMS або тип бази даних використовувати. Спочатку важливо описати проблему: що зараз не працює, кому потрібен сайт, яку інформацію людина шукає й що має відбутися після її дії.

Хороше ТЗ зменшує неоднозначність. Воно не має передбачати кожен піксель, але повинно фіксувати сторінки, ключові сценарії, джерела даних, інтеграції, контент, обмеження та критерії готовності.

1. Опишіть бізнес і пропозицію

Достатньо кількох абзаців: що продає компанія, для кого, у яких регіонах працює та як зараз отримує звернення. Якщо пропозицій кілька, потрібно розділити основні й допоміжні. Це допомагає визначити, чи вистачить Landing Page, чи потрібен багатосторінковий сайт послуг.

2. Визначте аудиторії та їхні запитання

Різні аудиторії можуть потребувати різних аргументів і маршрутів. Власник малого бізнесу, закупівельник компанії та кінцевий покупець оцінюють пропозицію по-різному. Варто записати, що людина має зрозуміти до звернення, які має заперечення та які докази реально доступні.

3. Складіть попередній список сторінок

Типовий перелік може містити головну, загальну сторінку розробки або категорії, окремі послуги, портфоліо, кейси, блог, контакти й юридичні документи. Не потрібно створювати сторінки лише тому, що певна фраза є ключовим словом. Кожен URL повинен мати окремий намір і достатній зміст.

Якщо формат ще не зрозумілий, використайте порівняння типів сайтів для бізнесу.

4. Перелічіть ключові сценарії

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

5. Опишіть форми та дані

Потрібно знати, які поля збираються, що є обов’язковим, куди надходить заявка, які повідомлення бачить користувач і чи залучений сторонній сервіс. Не варто збирати дані, які не потрібні для першого контакту. Паролі, приватні токени й секретні API-ключі не можна розміщувати у frontend або передавати через URL.

6. Зафіксуйте інтеграції

Назвіть CRM, платіжний сервіс, доставку, аналітику, email або API, якщо вони вже обрані. Для кожної інтеграції потрібні документація, доступ до тестового середовища, відповідальна сторона та розуміння обмежень. Не можна оцінити «інтеграцію з усім» без конкретного сервісу й сценарію.

7. Підготуйте контент

Визначте, хто надає назви, описи, фото, ціни, контакти, політики, кейси й юридичні дані. Не варто заповнювати прогалини вигаданими відгуками, статистикою чи адресами. Якщо контент ще не готовий, у плані мають бути чіткі placeholders і відповідальні.

8. Сформулюйте SEO-вимоги

Для публічного сайту варто одразу передбачити окремі URL для важливих намірів, унікальні title й descriptions, один H1, self-canonical, HTML-посилання, sitemap, robots, breadcrumbs і structured data, що відповідають видимому контенту.

Якщо існує старий сайт, додайте список чинних URL та дані про те, що має зберегтися. Зміна маршруту потребує 301 redirect, а редизайн не повинен знищувати сторінки, які вже отримують трафік.

9. Визначте критерії готовності

Наприклад: усі погоджені URL відкриваються зі статусом 200; одна сторінка має один H1; форми валідовуються й показують результат; mobile не має горизонтального скролу; навігація працює з клавіатури; canonical і sitemap містять production URL; у консолі немає критичних помилок.

10. Розділіть перший запуск і майбутній розвиток

Не обов’язково реалізовувати все одразу. Корисно виділити must-have для першої версії, наступний етап і гіпотези, які потрібно перевірити на реальних даних. Так бюджет спрямовується на ключову цінність, а архітектура не блокує розширення.