Технічне завдання на сайт: як скласти, щоб кошторис збігся

Чому розпливчасте ТЗ зʼїдає бюджет і терміни

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

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

• Форма заявки — це лист на пошту чи заявка потрапляє в CRM, створює угоду й надсилає клієнтові автовідповідь?
• Десять сторінок — це десять унікальних екранів з окремою версткою чи один шаблон, який наповнюють текстом десять разів?
• Контент — ви віддаєте готові тексти й світлини чи їх ще хтось має написати та зняти?
• Мови — одна чи три, і хто відповідає за переклад?

Різниця між «дешевим» і «дорогим» прочитанням цього абзацу — кратна, а не в межах похибки — і обидва прочитання чесні: просто відповіді в тексті не було.

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

Бриф, ТЗ і межа робіт: чим різняться та хто їх пише

Бриф — вхідна анкета на одну-дві сторінки, яку заповнює замовник: хто ви, що продаєте, кому, навіщо потрібен сайт, що подобається й що дратує в конкурентів, бюджет і термін. Він описує не рішення, а задачу. За брифом не можна порахувати точний кошторис — можна зрозуміти, чи варта розмова заходу і в якому порядку цифр перебуває проєкт.

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

Хто має писати ТЗ

Коротка відповідь: бриф пише замовник, ТЗ пише студія. Ви експерт у своєму бізнесі — маржинальність, сезонність, заперечення клієнтів, вузькі місця продажів. Студія експерт в іншому: які рішення існують, що скільки коштує і що зламається на третій місяць. Коли замовник пише ТЗ сам, він вигадує рішення там, де не має досвіду, — і документ або описує те, що так не працює, або про всяк випадок вимагає все одразу.

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

Початок ТЗ: бізнес-ціль, аудиторія, конкуренти

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

Бізнес-ціль

Ціль формулюють у термінах бізнесу, а не сайту. «Гарний сучасний сайт» — це оцінне судження. Ціль звучить радше так: «отримувати заявки на монтаж від приватних замовників, зараз усе йде телефоном і половина губиться» або «перевести оптових клієнтів на самообслуговування». З першого випливає, що головне — форма, довіра і швидкість; з другого — особистий кабінет і повторне замовлення в один клік. Той самий бюджет іде в геть різні речі.

Аудиторія

Аудиторію описують поведінкою, а не демографією. «Чоловіки 25–45» не дає розробникові нічого. А ось це дає:

• Хто ухвалює рішення і хто платить — часто це різні люди.
• Як людина потрапляє на сайт: гуглить проблему, іде за рекомендацією, клікає рекламу.
• Що вона перевіряє, перш ніж погодиться: ціну, терміни, ліцензію, відгуки, географію.
• З якого пристрою дивиться. Телефон на обʼєкті з поганим звʼязком змінює вимоги до ваги сторінок.

Конкуренти

Дайте три-пʼять посилань і до кожного одне речення: що тут зроблено добре, а що погано. Не «подобається дизайн», а «у них ціна видно одразу, без запиту — хочу так само». Така звичка економить тижні листування, бо перетворює смак на вимоги. І напишіть чесно, чим ви відрізняєтесь від цих конкурентів: якщо відмінностей немає — це не проблема сайту, і жодна верстка її не розвʼяже.

Перелік сторінок і структура: головний розділ ТЗ

Це розділ, з якого береться більша частина кошторису. Правило просте: рахують не сторінки, а унікальні шаблони. Каталог із тисячі товарів — це один шаблон картки. Сайт із восьми сторінок, де кожна намальована по-своєму, дорожчий за сайт із тридцяти сторінок на трьох шаблонах. Тому перелік пишуть у два проходи: спершу називаємо всі сторінки, потім позначаємо, які типові, а які унікальні.

Як описувати структуру сторінки

Для кожної унікальної сторінки — перелік блоків згори вниз і призначення кожного. Наприклад, для сторінки послуги:

1. Перший екран: заголовок, короткий опис, кнопка запиту розрахунку.
2. Що входить у послугу — маркований перелік, 5–8 пунктів.
3. Як відбувається робота — етапи, від 3 до 6 кроків.
4. Ціни: таблиця тарифів або рядок «від», вирішуємо на дискавері.
5. Приклади робіт — три картки, підтягуються автоматично з портфоліо за тегом послуги.
6. Часті питання — редагуються з адмінки. Форма запиту.

Зверніть увагу на дві фрази, які тут роблять усю роботу: «підтягуються автоматично за тегом» і «редагуються з адмінки». Це не оздоблення, це години: блок, який редактор наповнює руками, і блок, що збирається сам із даних, — різна задача й різна ціна.

Навігація та звʼязки

Опишіть головне меню та підвал повністю. Окремо — як сторінки повʼязані: з послуги ведемо в кейси, з кейса — у послугу й у форму, зі статті — у послугу. Корисна вправа: пройдіть майбутнім сайтом як чужа людина. Хтось шукав проблему й потрапив на статтю — що він бачить далі й куди йде? Якщо відповіді немає, сторінку треба добудувати. Як це виглядає на живих проєктах, видно в наших роботах. І не пишіть «сайт має бути адаптивним» — це норма; пишіть місця, де мобільна версія поводиться інакше: таблиця цін перетворюється на картки, фільтр відкривається на весь екран. Саме вони зʼїдають час, коли спливають несподівано.

Як описувати функціональність без двозначностей

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

Робоча альтернатива — сценарії: хто, що робить і що отримує. Порівняйте. Погано: «Особистий кабінет з історією замовлень». Добре:

• Клієнт входить за email і паролем, є відновлення пароля за посиланням із листа.
• Клієнт бачить перелік замовлень: номер, дата, сума, статус, кнопка «повторити».
• Статусів пʼять: нове, у роботі, відвантажено, доставлено, скасовано. Змінює їх менеджер в адмінці.
• Кнопка «повторити» кладе товари в кошик; чого немає в наявності, те пропускається з повідомленням.
• Клієнт завантажує рахунок у PDF, але не може змінити назву юридичної особи — це робить лише менеджер.

Другий варіант оцінюється в годинах без жодного дзвінка; перший — тільки навгад, повз.

Описуйте крайні випадки

Дорого коштує не основний сценарій, а все довкола нього — тут ховається половина бюджету:

• Що відбувається, коли даних немає: порожній кошик, пошук без результатів, категорія без товарів.
• Що відбувається при помилці: платіж не пройшов, файл завеликий, email уже зареєстровано.
• Що бачить користувач, якщо звʼязок обірветься посеред оплати, і хто що може робити — у редактора й адміністратора різні права.

І позначте кожен пункт: обовʼязково до запуску, бажано або другий етап. Це найкращий інструмент керування бюджетом: коли кошторис виявиться вищим за очікування, ви різатимете свідомо, а не викидатимете перше, що трапилось.

Контент, інтеграції та мови: хто, що і коли дає

Тут ламається більше проєктів, ніж на будь-якому коді. Сайт готовий, а запуску немає — бо немає текстів. Або тексти є, а світлини зняті на телефон у темному цеху.

Контент

У ТЗ має бути прямо написано, хто відповідає за кожен тип контенту і до якого терміну він зʼявляється:

• Тексти сторінок. Пише замовник, копірайтер студії, чи пишете ви, а редагуємо ми? Три ціни.
• Світлини. Ваш архів, зйомка чи сток? Якщо зйомка — хто організовує й оплачує.
• Каталог. Хто заповнює картки, звідки описи, у якому форматі приходить вивантаження.
• Юридичні документи. Політика, оферта, реквізити — зона замовника, але нагадати має студія.

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

Інтеграції

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

Мови

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

Дизайн-референси та пастка «хочу як у X»

Референси потрібні: без них дизайнер змушений вгадувати смак, а вгадати смак у листуванні неможливо. Але подавати їх треба правильно.

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

Звідси правило: референс без коментаря марний. Кожне посилання супроводжується реченням, що саме ви звідти берете:

• «Подобається, як подано ціну: одразу, без форми запиту».
• «Подобається відчуття простору: багато повітря, мало тексту на екрані».
• «Подобається структура картки товару, а не кольори».
• «Категорично не подобається карусель на першому екрані».

Антиреференси працюють не гірше: «ось так не треба, надто казенно» звужує пошук швидше, ніж пʼять прикладів того, що подобається.

Що ще варто зафіксувати

Чи є брендбук і наскільки він обовʼязковий; тон — стриманий чи розмовний; і головне — хто затверджує дизайн. Проєкти застрягають на погодженнях частіше, ніж на технологіях, коли макет іде на коло до третього заступника й повертається з правками, що суперечать правкам першого. Запишіть у ТЗ імʼя людини, чиє «так» остаточне, і число ітерацій. Дві-три — нормально. Нескінченність — це вже не проєкт.

Технічні обмеження, SEO та життя в адмінці

Розділ, який замовники проминають зі словами «вам видніше». Студії справді видніше щодо рішень, але вихідні обмеження знаєте тільки ви.

Технічні обмеження

• Хостинг і домен. Де живе зараз, у кого доступи, чи є вимоги до розміщення даних.
• Наявна система. Якщо сайт уже є — що переносимо, що викидаємо, що лишається паралельно.
• Внутрішні правила. Служба безпеки, вимоги до паролів, обмеження на зовнішні сервіси.
• Права на код і персональні дані. Кому належить результат, які дані збираєте і як видаляєте на запит.

SEO

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

• Керовані title, description і заголовки на кожному типі сторінок — з адмінки, без програміста.
• Читабельні адреси, зрозуміла схема URL і налаштування перенаправлень під час переїзду.
• Розмітка даних, мапа сайту, канонічні адреси, а за кількох мов — мовні атрибути.
• Вимоги до швидкості: не «швидко», а конкретні метрики і на якому пристрої міряємо.

Адмінка й редагування

Найбільш недооцінений пункт ТЗ. Дайте відповідь на одне питання: що ви змінюватимете самі й як часто? Відповідь визначає архітектуру. Якщо раз на рік змінюється телефон — адмінка майже не потрібна. Якщо контент-менеджер щотижня збирає посадкові під акції, потрібен конструктор блоків — інша система й інший бюджет. Опишіть ролі і що відбувається, коли редактор помилився: чернетки, попередній перегляд, відкат. І чесно оцініть рівень людей, які працюватимуть: інтерфейс для розробника у звичайного редактора викликає параліч.

Критерії приймання, терміни та бюджетна рамка

Ці три речі завершують ТЗ і перетворюють його з опису мрії на робочий документ.

Критерії приймання

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

• Усі сторінки з переліку відкриваються, посилання не ведуть у помилку.
• Форма заявки надсилається, лист приходить на адресу, заявка зʼявляється в CRM.
• Сайт коректно відображається в актуальних браузерах і на телефоні.
• Метрики швидкості на головній і на картці товару вкладаються в погоджений поріг.
• Оплата тестовою карткою проходить, замовлення створюється, лист клієнтові йде.

Такий перелік захищає обидві сторони: замовник знає, що дивитись, а студія знає, де фініш, і не опиняється в прийманні, яке триває вічно, бо замовникові «щось не те».

Терміни

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

Бюджетна рамка

Замовники приховують бюджет, побоюючись, що кошторис підженуть під цифру. Результат зворотний. Бюджет — це не ціна, а обмеження задачі: не назвавши його, ви отримаєте або пропозицію не по кишені, або усічену до невпізнанності. Досить діапазону: «орієнтуємось на такий порядок, готові обговорювати за обґрунтування». Далі починається інженерна розмова: що вміщується в рамку, що переносимо на другий етап. З чого складається ціна і чому однакові на вигляд сайти коштують по-різному, розібрано в матеріалі про те, скільки коштує сайт у 2026 році.

Чого не варто писати в ТЗ

Погане ТЗ буває не лише коротким. Товстий документ на вісімдесят сторінок — теж симптом, просто іншої хвороби. Ось що сміливо викидайте.

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

Готові технічні рішення, якщо ви не технічний фахівець. Рядок «зробити на такій-то технології» без пояснення чому звʼязує руки й здорожчує проєкт. Правильніше описати обмеження: «наш адміністратор обслуговує лише такий стек» або «має жити на нашому сервері». Причину студія врахує, а спосіб добере сама.

Усе одразу про всяк випадок. «Також бажано передбачити можливість подальшого розширення функціоналу» не означає нічого, але студія закладе в кошторис запас на невідомість. Ви платите за туман.

Копіпаст із чужого ТЗ. Помітно, коли в завданні на сайт клініки раптом зʼявляється кошик і способи доставки: незрозуміло, які пункти справжні. Дизайн словами і юридичні конструкції — теж зайве: одне вирішується макетом, інше договором.

І те, чого майже завжди бракує

Зворотний бік: є речі, які пропускають у девʼяти ТЗ із десяти і які не мають важливого вигляду, поки не вистрелять.

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

Як ТЗ перетворюється на кошторис і що робити з правками

Кошторис — це не число з досвіду, а арифметика за документом.

Механіка оцінювання

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

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

Правки після підписання

Зміни будуть — бізнес не стоїть на місці, а на демо видно те, чого не було видно в тексті. Питання не в тому, як їх уникнути, а в тому, як проводити:

1. Зміну формулюють письмово — у вигляді пункту, а не голосом на дзвінку.
2. Студія оцінює: скільки годин, що зсунеться в термінах, що зачепить.
3. Замовник вирішує: робимо зараз, другим етапом чи відмовляємось, і рішення фіксують додатком.

Корисне правило: виправлення — це коли зроблено не так, як у ТЗ; зміна — це коли в ТЗ було не те, що потрібно. Перше студія лагодить безкоштовно, друге оцінюється. Межу проводить документ, а не настрій. І якщо додаємо функцію, то щось із обовʼязкового переїжджає на другий етап або в кошторис додається сума. Третього не буває.

Чек-лист: ТЗ готове, якщо в ньому є

Пройдіться переліком. Якщо понад три пункти лишились без відповіді, документ ще не готовий до оцінювання — і будь-який кошторис за ним буде фантазією.

1. Бізнес-ціль у термінах бізнесу, а не сайту.
2. Аудиторія через поведінку: хто вирішує, звідки приходить, що перевіряє, з якого пристрою.
3. Конкуренти: 3–5 посилань із коментарем, що взяти й чого уникати.
4. Перелік сторінок із поділом на унікальні та типові шаблони.
5. Структура кожної унікальної сторінки: блоки згори вниз і призначення кожного.
6. Функції сценаріями: хто, що робить, що отримує. Плюс крайні випадки й помилки.
7. Пріоритети: обовʼязково до запуску / бажано / другий етап.
8. Контент: хто пише тексти, хто дає світлини, до якого терміну, що при затримці.
9. Інтеграції поіменно: що, куди, коли, що при помилці, у кого доступи.
10. Мови: скільки на запуск, хто перекладає, що за відсутності перекладу.
11. Дизайн: референси з коментарями, брендбук, хто затверджує, скільки ітерацій.
12. Технічні обмеження: хостинг, доступи, права на код, персональні дані.
13. SEO: керовані метатеги, схема адрес, перенаправлення при переїзді, поріг швидкості.
14. Адмінка: що змінюєте самі й як часто, ролі, чернетки, відкат, навчання.
15. Критерії приймання: перевірюваний перелік, а не «працює коректно».
16. Терміни етапами із залежностями і бюджетна рамка діапазоном.
17. Після запуску: підтримка, резервні копії, передача доступів, межа гарантії.

Якщо ви читаєте це перед стартом — не намагайтесь заповнити весь перелік самотужки за вечір. Заповніть те, що знаєте напевно: ціль, аудиторію, конкурентів, обмеження, бюджетну рамку. Це ваша зона. Решта — сторінки, функції, інтеграції, приймання — нормально збирається на дискавері разом зі студією.

Хороше ТЗ схоже на креслення: нудний документ, без якого будинок будують на око. Година, витрачена на формулювання до старту, економить день переробок посеред проєкту. Якщо хочете, щоб ТЗ зібрали разом із вами й чесно оцінили за ним — напишіть нам: почнемо з брифу й розмови, а документ зʼявиться сам.

Часті запитання