Три студії дали вам $1 800, $3 400 і $9 000 за «сайт компанії». Порівняти ці цифри неможливо, бо кожна рахувала свій уявний проєкт. Технічне завдання — це документ, який робить пропозиції зіставними, а суперечки про обсяг робіт — неможливими. Нижче структура ТЗ по розділах, формулювання, які прибирають різночитання, критерії приймання й помилки, через які документ на 40 сторінок все одно нічого не захищає.

Що насправді захищає ТЗ

Поширена думка: ТЗ потрібне розробнику. Насправді воно потрібне замовнику, і ось чому. Без нього кожне розходження в розумінні вирішується на користь того, у кого сильніша переговорна позиція, — а на середині проєкту це завжди підрядник, бо в нього ваші файли й ваша передоплата.

• Робить кошториси порівнюваними. З однаковим ТЗ різниця між пропозиціями перестає бути лотереєю: видно, хто заклав тестування, а хто ні.
• Фіксує межу «це вже інша робота». Найдорожчі конфлікти виникають не через якість, а через фразу «ми думали, це входить».
• Задає момент оплати. Приймання прив’язується до перевіряємих критеріїв, а не до відчуття «начебто готово».
• Залишає вам проєкт після розриву. Якщо доведеться міняти підрядника, ТЗ — єдиний документ, за яким новий виконавець зрозуміє, що мало бути зроблено.

Структура, за якою можна писати з нуля

Порядок розділів має значення: кожен наступний спирається на попередній. Якщо почати з переліку сторінок, ви отримаєте сайт, який ніхто не проєктував під задачу.

1. 1Мета й вимірюваний результат. Не «покращити імідж», а «отримувати 30 заявок на місяць з органічного пошуку через 6 місяців». Це визначає половину технічних рішень.
2. 2Аудиторія та сценарії. Два-три типові відвідувачі й шлях кожного до цільової дії. Саме звідси береться структура меню.
3. 3Карта сторінок із типами шаблонів. Ключовий розділ для бюджету: платять за шаблони, а не за сторінки. Вкажіть, що каталог із 300 позицій — це один шаблон.
4. 4Функціональні вимоги поблоково. Форми, фільтри, кабінет, калькулятор, пошук. Для кожного — що вводить користувач, що бачить у відповідь, куди йдуть дані.
5. 5Інтеграції з зовнішніми системами. Назва системи, напрям обміну, частота. «Інтеграція з CRM» — не вимога; «створення угоди у CRM при відправці форми, поля: імʼя, телефон, джерело» — вимога.
6. 6Контент: хто і коли надає. Найчастіша причина зриву строків. Пропишіть обсяг, мову, дедлайн і що робити, якщо тексти не готові вчасно.
7. 7Дизайн і межі правок. Кількість раундів правок на макет, формат передачі, чиї брендові матеріали використовуються.
8. 8Технічні вимоги. Стек або обмеження щодо нього, підтримувані браузери, цільові показники швидкості, мультимовність, вимоги до адмінки.
9. 9SEO та аналітика мінімум. Метатеги, ЧПУ, sitemap, розмітка, лічильники, цілі. Без цього пункту вони «не входили».
10. 10Приймання, права й підтримка. Критерії здачі, передача доступів і вихідного коду, гарантійний період, умови підтримки після нього.

Розділи 1–3 роблять до вибору підрядника, решту часто пишуть разом із ним — це нормально й навіть корисно. Як це лягає на календар проєкту, показано в розборі етапів розробки сайту.

Формулювання, які прибирають різночитання

Правило одне: вимогу можна перевірити «так» або «ні». Якщо для оцінки потрібна дискусія про смак — це не вимога, а побажання, і воно не має юридичної ваги.

Приймання й порівняння пропозицій

1. 1

   Розбийте оплату на 3–4 етапи

   Типово: 30% на старт, 30% після затвердження дизайну, 30% після демонстрації на тестовому сервері, 10% після приймання. Останній платіж — ваш єдиний важіль на фінальних правках.

2. 2

   Опишіть, що таке «готово», для кожного етапу

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

3. 3

   Надішліть однакове ТЗ усім підрядникам

   І попросіть кошторис із розбивкою по ваших же розділах. Пропозиція одним числом без розбивки — привід поставити додаткові питання.

4. 4

   Порівнюйте не суму, а склад

   Дешевша пропозиція зазвичай не містить аналітики, тестування або технічної SEO-бази. Що саме перевіряти в підрядника, розібрано в матеріалі про вибір веб-студії.

5. 5

   Зафіксуйте передачу доступів письмово

   Домен, хостинг, репозиторій, адмінка, аналітика — усе оформлене на вас, а не на підрядника. Це пункт, який згадують надто пізно.

П’ять помилок, які знецінюють документ

І окремо про бюджет: не ховайте його. Названий діапазон економить обом сторонам два тижні — підрядник одразу скаже, що з вашого списку в нього поміститься. Орієнтири по ринку зібрані в розборі вартості сайту.

Часті питання про технічне завдання

Коротко

• ТЗ потрібне передусім замовнику: воно робить кошториси порівнюваними й фіксує межу обсягу робіт.
• Кошторис рахують за типами шаблонів та інтеграціями, тому саме ці розділи мають бути найдетальнішими.
• Вимога, яку не можна перевірити відповіддю «так» або «ні», у суперечці нічого не варта.
• Розбийте оплату на етапи з описом «готово» для кожного і залиште 10% на фінальне приймання.
• Обовʼязково пропишіть доступи, права на код, гарантійний період і хто відповідає за контент.