Технічне завдання на розробку сайту: що має бути в ТЗ і як його скласти

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

Насправді хороше технічне завдання не повинно починатися з технологій.

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

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

Головне не обсяг документа, а те, наскільки однаково замовник і команда розробки розуміють майбутній проєкт.

Для чого потрібне технічне завдання на розробку сайту

Уявімо просту ситуацію.

Клієнт говорить:

Потрібен сучасний корпоративний сайт приблизно на 10 сторінок.

Для бізнесу цього опису може бути достатньо, щоб пояснити загальну ідею. Для оцінки розробки — ні.

Не зрозуміло, чи потрібен індивідуальний дизайн, скільки буде унікальних шаблонів сторінок, хто готує тексти, чи потрібна мультимовність, які форми повинні працювати, чи буде CRM, блог, пошук, фільтри, аналітика або подальше SEO-просування.

Саме ці деталі поступово перетворюють загальне побажання на конкретний проєкт.

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

Клієнт, своєю чергою, отримує зрозуміле уявлення про те, що саме буде створено.

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

Чи повинен клієнт сам писати ТЗ

Ні.

І це одна з найважливіших речей, яку варто розуміти перед зверненням до розробника.

Клієнт добре знає свій бізнес, продукти, послуги, клієнтів і внутрішні процеси. Але він не зобов’язаний знати, як правильно побудувати структуру WordPress, який тип інтеграції використати або яким способом реалізувати каталог.

Більше того, надто детальне технічне рішення від замовника іноді навіть заважає.

Наприклад, клієнт може написати:

Потрібен сайт на WordPress із 12 плагінами, таким-то фільтром і конкретним модулем CRM.

А після аналізу може виявитися, що частина цих інструментів взагалі не потрібна або ту саму задачу можна вирішити простіше.

Тому нормальний процес виглядає інакше.

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

У theDC.studio ми саме тому перед оцінкою складніших проєктів спочатку уточнюємо задачу, структуру та функціонал, а не очікуємо від клієнта готового технічного документа.

З чого починається хороше ТЗ

Перша частина технічного завдання взагалі може не містити нічого технічного.

Спочатку потрібно описати сам бізнес і роль майбутнього сайту.

Наприклад:

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

Або:

Приватна клініка планує створити сайт з окремими сторінками напрямів, лікарів, послуг і можливістю запису на консультацію.

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

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

Для одного проєкту головною дією буде заявка.

Для іншого — дзвінок.

Для інтернет-магазину — оформлення замовлення.

Для освітнього сайту — вибір програми та реєстрація.

І вже від цього повинна будуватися структура.

Структура сайту — одна з головних частин ТЗ

Наступний етап — визначити, з яких сторінок складатиметься сайт.

Наприклад, для корпоративного сайту базова структура може включати головну сторінку, інформацію про компанію, сторінки послуг, кейси, блог, контакти та окремі посадкові сторінки.

Але просто написати «10 сторінок» недостатньо.

Важливо розуміти, які з них будуть унікальними, а які використовуватимуть один шаблон.

Наприклад, у медичної клініки може бути 30 сторінок лікарів. Це не означає, що дизайнер повинен створювати 30 різних макетів. Зазвичай створюється один шаблон сторінки лікаря, а вже контент у ньому змінюється.

Те саме стосується:

• товарів;
• послуг;
• кейсів;
• викладачів;
• міст;
• категорій;
• об’єктів каталогу.

Ця різниця дуже важлива під час оцінки проєкту.

Саме тому в хорошому ТЗ описують не тільки кількість сторінок, а й логіку їхньої побудови.

Що потрібно описати для кожної важливої сторінки

Необов’язково писати детальну інструкцію для кожного блоку.

Але для ключових сторінок бажано зафіксувати їхню функцію.

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

Для сторінки послуги — описувати конкретний напрям, відповідати на основні запитання клієнта та давати можливість звернутися до компанії.

Для картки товару — містити фото, ціну, характеристики, варіації, статус наявності та кнопку покупки.

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

Функціонал потрібно описувати через сценарії

Це особливо важливо для складніших сайтів.

Фраза:

Потрібен особистий кабінет.

майже нічого не говорить розробнику.

Набагато корисніше написати:

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

Або замість:

Потрібна інтеграція з CRM.

краще:

Після відправлення форми на сайті контакт користувача і вибрана послуга повинні автоматично передаватися в CRM та створювати новий лід.

Це називається користувацьким сценарієм.

Саме такі сценарії допомагають зрозуміти реальний обсяг програмування.

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

Дизайн: що потрібно зафіксувати в ТЗ

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

Але загальний напрям бажано зафіксувати.

Якщо у компанії вже є фірмовий стиль, потрібно передати логотип, кольори, шрифти та брендбук.

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

Наприклад:

Подобається велика типографіка і мінімалістична подача.

або:

Подобається структура сторінки, але не кольори.

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

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

Хто готує контент

Цей пункт часто забувають зафіксувати на початку.

У результаті дизайн уже готовий, розробка завершена, а сайт неможливо запустити, тому що немає текстів, фотографій або описів товарів.

Тому ще в ТЗ бажано визначити, хто відповідає за контент.

Це може бути клієнт, вебстудія або обидві сторони.

Наприклад, клієнт передає технічну інформацію про продукт, а студія адаптує її для сайту.

Або бізнес повністю готує тексти та фотографії самостійно, а команда розробки лише розміщує матеріали.

Особливо важливо визначити це для великих каталогів та інтернет-магазинів, де наповнення може займати не менше часу, ніж сама розробка.

SEO у технічному завданні

Необов’язково проводити повне SEO-дослідження ще до початку кожного проєкту.

Але якщо бізнес планує отримувати трафік із Google, це потрібно врахувати в ТЗ.

Наприклад, ще на етапі структури варто зрозуміти, чи потрібні окремі сторінки для різних послуг, міст, категорій або напрямів.

Також бажано передбачити коректну структуру URL, можливість редагувати метадані, заголовки, тексти, ALT зображень і створювати внутрішню перелінковку.

Чому ці речі бажано закладати ще під час розробки, ми детально розберемо в окремому матеріалі про SEO-підготовку сайту.

Інтеграції потрібно визначити до оцінки

CRM, служби доставки, платіжні системи, телефонія, email-маркетинг, ERP або зовнішні API можуть суттєво впливати на обсяг розробки.

Тому бажано назвати їх ще до формування остаточного кошторису.

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

Якщо конкретна система вже використовується, потрібно одразу повідомити її назву.

Якщо бізнес лише знає, що хоче автоматизувати певний процес, технічний спосіб реалізації можна вибрати разом із розробником.

Не забудьте про аналітику

Ще до запуску бажано визначити, які дії користувачів потрібно відстежувати.

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

Зазвичай на сайт підключають Google Analytics 4, Google Search Console та, за потреби, рекламні системи чи інші аналітичні сервіси.

Це невелика частина ТЗ, але вона дозволяє після запуску оцінювати сайт не лише візуально, а за реальними діями користувачів.

Як визначити, що сайт готовий

Ще один важливий пункт технічного завдання — критерії завершення роботи.

Формулювання «сайт повинен працювати нормально» занадто нечітке.

Краще зафіксувати, що перед запуском перевіряється адаптивність основних сторінок, робота форм, посилань, функціоналу, основних браузерів та інтеграцій.

Для інтернет-магазину додатково перевіряється процес від додавання товару в кошик до створення замовлення та оплати.

Для складнішого сервісу тестуються користувацькі сценарії, описані в ТЗ.

Так у клієнта і розробника є зрозуміла точка, коли проєкт переходить із розробки в запуск.

Що робити, якщо під час розробки з’явилися нові ідеї

Це абсолютно нормальна ситуація.

Під час роботи над дизайном або вже готовими сторінками часто стає зрозуміло, що потрібно додати ще один блок, інтеграцію або функцію.

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

Тому важливо розділяти уточнення початкового завдання та новий функціонал.

Якщо в ТЗ була форма заявки, але потрібно змінити назву одного поля — це звичайне уточнення.

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

Хороший процес передбачає, що такі зміни фіксуються та оцінюються до початку додаткової роботи.

Технічне завдання, бриф і прототип — це не одне й те саме

Ці поняття часто плутають.

Бриф допомагає зібрати початкову інформацію про бізнес, цілі, аудиторію та побажання.

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

Прототип показує майбутню структуру сторінок уже візуально: де буде заголовок, форма, каталог, переваги, кейси або інші блоки.

У невеликому проєкті ці етапи можуть частково об’єднуватися.

Для складного сайту їх краще розділяти.

Який вигляд може мати коротке ТЗ на сайт

Для невеликого бізнес-сайту не обов’язково створювати документ на 50 сторінок.

Базовий варіант може містити такі розділи:

• інформація про компанію та задача сайту;
• цільова аудиторія;
• структура сторінок;
• функціональні вимоги;
• вимоги до дизайну;
• контент і відповідальні сторони;
• інтеграції;
• базові SEO-вимоги;
• аналітика;
• порядок погодження та тестування;
• умови запуску.

Цього вже достатньо, щоб перейти до детального опрацювання проєкту.

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

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

Найчастіша помилка — намагатися описати технології замість задач.

Клієнту значно корисніше написати:

Менеджер повинен отримувати заявку з сайту в CRM.

ніж самостійно визначати API, формат передачі даних і необхідний плагін.

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

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

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

Чи можна замовити розробку сайту без готового ТЗ

Так.

Для більшості бізнес-проєктів це абсолютно нормальна ситуація.

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

На основі цієї інформації вже можна сформувати структуру майбутнього сайту, визначити технічні вимоги та підготувати оцінку.

Саме так ми працюємо в theDC.studio: не очікуємо від клієнта готової технічної документації, якщо він не має її на старті. Спочатку розбираємо задачу, а потім переводимо її мовою структури, дизайну та розробки.

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

Якщо потрібен проєкт саме на WordPress, окремо описали цей напрям на сторінці розробки сайтів на WordPress.

Що в результаті дає хороше технічне завдання

ТЗ потрібне не для того, щоб зробити розробку складнішою.

Навпаки, воно повинно спростити її для обох сторін.

Команда розуміє, що потрібно реалізувати. Бізнес розуміє, що отримає в результаті. Стає легше оцінити строки, бюджет, додаткові роботи та момент завершення проєкту.

І хороше технічне завдання не обов’язково має бути великим.

Для простого сайту достатньо короткого структурованого документа. Для складної системи знадобиться детальна специфікація.

Головне, щоб після прочитання ТЗ у замовника та розробника не було двох різних уявлень про один і той самий сайт.

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

Плануєте розробку сайту?

Якщо у вас уже є готове технічне завдання — можемо проаналізувати його та оцінити розробку.

Якщо ТЗ немає, це теж не проблема.

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