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

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

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

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

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

1. Мета і контекст. Пояснює, навіщо потрібен результат і яку бізнес-задачу він має розв'язати. Це не формальність: виконавець, який розуміє кінцеву мету, частіше пропонує ефективніше рішення, ніж той, хто лише виконує перелік вимог. 
2. Обсяг робіт. Визначає, що входить до завдання, а що — ні. Саме нечіткі межі відповідальності часто стають причиною непорозумінь між сторонами. 
3. Вимоги до результату. Описують функціональні, технічні, візуальні та інші характеристики, яким має відповідати готовий результат. 
4. Обмеження. Фіксують технологічні, бюджетні й часові рамки, а також вимоги до сумісності з наявними системами, продуктами чи процесами.
5. Критерії приймання робіт. Визначають чіткі й вимірювані ознаки, за якими оцінюють результат. Без них приймання легко перетворюється на суб'єктивну дискусію про те, «подобається чи ні».
6. Строки та етапи. Містять кінцевий термін виконання або поділ проєкту на етапи з проміжними результатами й контрольними точками.
7. Порядок внесення змін. Визначає, хто може змінювати вимоги, як погоджуються такі зміни та як вони впливають на строки, бюджет і обсяг робіт.

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

Порівняйте:

• розмито: сайт має швидко завантажуватися;
• коректно: показник Largest Contentful Paint не перевищує 2,5 секунди на мобільному з'єднанні 4G.

Або:

• розмито: зручна форма замовлення;
• коректно: оформлення замовлення відбувається не більш ніж за три кроки, без обов'язкової реєстрації.

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

Для вебпроєктів базову структуру технічного завдання зазвичай доповнюють кількома важливими розділами:

• Структура сайту. Перелік усіх сторінок, шаблонів і їхніх взаємозв'язків, а не лише навігаційного меню.
• Сценарії користувача (User Flow). Описують шлях користувача від першого відвідування сайту до виконання цільової дії.
• Адаптивність. Визначають цільові пристрої та вимоги до відображення інтерфейсу на різних екранах.
• Інтеграції. Перелік зовнішніх сервісів, із якими взаємодіє сайт (CRM, платіжні системи, аналітика, служби доставки тощо), а також вимоги до інтеграції, зокрема версії API, якщо це критично.
• Права доступу. Ролі користувачів і рівні доступу до адміністративної панелі та інших компонентів системи.
• Передача проєкту. Порядок передання доступів, вихідного коду, технічної документації, інструкцій, а також умови гарантійної підтримки.

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

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

Мінімальне ТЗ для копірайтера має містити:

• тему та мету тексту;
• цільову аудиторію;
• формат і обсяг (у словах або знаках);
• ключові слова та вимоги до їх використання;
• бажану структуру або перелік обов'язкових розділів;
• тон комунікації та стиль;
• джерела інформації, які потрібно використати або, навпаки, яких варто уникати.

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

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

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

Водночас варто розвіяти поширений міф. Багато шаблонів технічних завдань, які й досі можна знайти в українському інтернеті, побудовані на основі ГОСТ 34.602-89 — радянського стандарту 1989 року, що визначав структуру технічного завдання для автоматизованих систем. В Україні цей стандарт остаточно втратив чинність 12 січня 2025 року.

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

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

Водночас варто розвіяти поширений міф. Багато шаблонів технічних завдань, які й досі можна знайти в українському інтернеті, побудовані на основі ГОСТ 34.602-89 — радянського стандарту 1989 року, що визначав структуру технічного завдання для автоматизованих систем. В Україні цей стандарт остаточно втратив чинність 12 січня 2025 року.

Ось кілька рекомендацій:

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