ТЗ розробнику — як уникнути кота в мішку

Уявіть ситуацію: ви запустили проект з розробки сайту, погодили бюджет, підписали контракт: і от через три місяці замість функціонуючого інтернет-магазину отримуєте половину обіцяного функціоналу, непередбачені витрати та розчарування. Це класичний “кіт у мішку” в IT-індустрії, коли очікування стикається з реальністю розробки так болісно, що компанії втрачають від 30 до 50% додаткового бюджету на доопрацювання й переробки.

Що таке технічне завдання і навіщо воно потрібно

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

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

Різниця між ТЗ і ФЗ у розробці

Часто підприємці плутають технічне завдання з функціональним. Це різні документи, і кожен вирішує своє завдання.

Типові помилки в ТЗ на сайт

Я бачив сотні ТЗ, і в більшості з них є одні й ті самі помилки. Ось найбільш небезпечні:

1. Розмиті вимоги до дизайну. Замість «гарний сайт» напишіть: «Сайт повинен відповідати гайдлайну бренду (кольори: #1a1a1a, #ffffff), використовувати шрифт Inter, мати адаптивний дизайн для мобільних пристроїв з точкою розриву 768px». Бриф на дизайн без конкретики — це запрошення до переробок.
2. Відсутність опису інтеграцій. Якщо сайт має інтегруватися з crm, платіжною системою або сервісом доставки, це має бути описано з вказанням API-документації, необхідних ендпоінтів і формату даних.
3. Не визначені терміни та мілстоуни. «Зробити за місяць» — це не план. Проміжний контроль починається з чітких дат: «Макети до 15 січня, фронтенд до 1 лютого, інтеграція до 15 лютого».
4. Відсутність вимог до тестування. Які unit-тести обов’язкові? Який відсоток покриття коду? Чи потрібні integration-тести? Без цього розробник може пропустити критичні баги.
5. Неясні вимоги до продуктивності. «Швидкий сайт» — це не метрика. Напишіть: «Час завантаження головної сторінки не більше 2 секунд на 4G, Core Web Vitals у зеленій зоні».
6. Відсутність опису обробки помилок. Що відбувається, якщо API недоступний? Як система обробляє некоректні дані?
7. Не визначеність із підтримкою та масштабуванням. Скільки одночасних користувачів має витримувати сайт? Які хмарні рішення використовувати?

Чек-лист для перевірки ТЗ перед відправленням розробнику:

• Всі вимоги описані конкретно, без слів «красиво», «зручно», «добре»
• Вказані всі інтеграції з зовнішніми сервісами та їхні API-ендпоінти
• Визначені терміни та проміжні мілстоуни
• Описані вимоги до тестування (unit-тести, integration-тести)
• Вказані метрики продуктивності та масштабованості
• Визначені процеси обробки помилок та виключень
• Описані вимоги до безпеки та захисту даних

Як скласти ТЗ для розробника сайту

Коли я говорю про те, як скласти ТЗ, щоб уникнути «кота в мішку», я маю на увазі структурований процес. Ось покроковий алгоритм, який ми використовуємо в BUSINESS SITE.

Ключові розділи ТЗ, щоб уникнути «кота в мішку»

1. Цілі та контекст проєкту

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

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

   Опишіть кожну функцію окремо. Використовуйте формат «Користувач повинен мати можливість…»:

   • Користувач повинен мати можливість зареєструватися через email або соціальні мережі
   • Користувач повинен мати можливість додати товар у кошик і оформити замовлення за 3 кліки
   • Адміністратор повинен мати можливість керувати каталогом товарів, завантажувати зображення та встановлювати ціни
3. Технічні вимоги

   Тут описуються технічні умови реалізації:

   • Стек технологій (наприклад, React для фронтенду, Node.js для бекенду, PostgreSQL як база даних для зберігання даних)
   • Архітектура (мікросервіси, моноліт, serverless)
   • REST API ендпоінти з описом методів (GET, POST, PUT, DELETE) і формату даних
   • Вимоги до безпеки (https, захист від CSRF, валідація вхідних даних)
   • Вимоги до продуктивності (час відгуку API не більше 200ms)
4. Вимоги до дизайну та UX

   Додайте макети або посилання на Figma. Опишіть:

   • Кольорову палітру та типографіку
   • Адаптивність (мобільні, планшети, десктопи)
   • Інтерактивні елементи (кнопки, форми, модальні вікна)
   • Мікровзаємодії (анімації, зворотний зв’язок при кліку)
5. Інтеграції

   Якщо сайт має інтегруватися із зовнішніми сервісами, опишіть кожну:

   • Платіжна система (Stripe, 2Checkout тощо): які методи оплати, яка обробка помилок
   • CRM (для зберігання даних клієнтів): які дані синхронізувати
   • email-маркетинг (Mailchimp, ActiveCampaign): які події ініціюють відправлення листів
   • Хмарне сховище (S3): для яких файлів, які обмеження за розміром

   Для кожної інтеграції вкажіть документацію API.

6. Вимоги до тестування

   Опишіть піраміду тестування:

   • Unit тести: мінімум 70% покриття критичного коду
   • Integration тести: всі API ендпоінти мають бути протестовані
   • E2E тести: основні користувацькі сценарії (реєстрація, покупка, повернення)

   Вкажіть, які інструменти використовувати (Jest для unit тестів, Cypress для E2E).

7. Терміни та віхи

   Розбийте проєкт на етапи з чіткими дедлайнами:

   • Тиждень 1-2: Дизайн та архітектура (затвердження макетів і ТЗ)
   • Тиждень 3-4: Фронтенд основних сторінок
   • Тиждень 5-6: Бекенд та інтеграції
   • Тиждень 7: Тестування та доопрацювання
   • Тиждень 8: Деплой і запуск

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

Піраміда тестування та автотести в ТЗ

Основа (Unit тести): це тести окремих функцій та компонентів. Вони швидкі, дешеві і повинні складати 70% усіх тестів. Приклад: тест функції розрахунку знижки, який перевіряє, що знижка 10% на суму 1000 гривень дає результат 900 гривень.

Agile та Scrum у розробці застосунку

Якщо ви працюєте з аутстафінгом розробників або аутсорсингом IT-проєкту, ймовірно, вони запропонують працювати за методологією Agile. Це добре, але ТЗ все одно потрібне.

Критерії приймання (acceptance criteria):

• Фільтр повинен відображати список показань
• Користувач має обрати одне або кілька показань
• Результати мають оновлюватися в реальному часі
• Фільтр має працювати на мобільних пристроях

Проміжний контроль у Scrum відбувається в кінці кожного спринту на зустрічах review і retrospective. Це дозволяє вам бачити прогрес, давати зворотний зв’язок і коригувати вимоги, якщо потрібно.

Тривожні сигнали підрядника: як обрати аутстафінг розробників

Навіть якщо ви напишете ідеальне ТЗ, неправильний вибір підрядника може все зіпсувати. Red flags в аутстафінгу — це ознаки того, що розробник або компанія ненадійні. Ось топ-10 red flags, на які варто звернути увагу.

1. Нечіткі відповіді на запитання. Якщо ви запитали, як розробник буде вирішувати конкретне технічне завдання, а в відповідь отримали розмитий текст, це поганий знак. Хороший розробник пояснить свій підхід, обговорить альтернативи та обґрунтує вибір.
2. Відсутність портфоліо або прикладів робіт. «Усе в резюме»: це не аргумент. Попросіть посилання на проєкти, які розробник робив. Якщо він не може показати прикладів, це червоний прапор.
3. Обіцянки, що звучать занадто добре. «Зробимо за тиждень», «Гарантуємо результат», «Це дуже просто» — усе це ознаки того, що розробник не розуміє складності проєкту або намагається вас обдурити.
4. Відсутність питань до вас. Якщо розробник не ставить питань про ваш проєкт, цілі, бюджет і терміни, це означає, що він не зацікавлений у розумінні ваших потреб. Хороший підрядник ставить багато питань.
5. Не готовий обговорювати ТЗ. «Давайте почнемо розробку, а ТЗ напишемо в процесі» — це шлях до хаосу. Якщо розробник не хоче витратити час на погодження вимог, це поганий знак.
6. Відсутність процесу контролю якості. Як розробник перевіряє якість коду? Чи використовує він code review, автоматичні тести, статичний аналіз? Якщо відповіді немає, якість буде низькою.
7. Не готовий підписувати контракт з чіткими умовами. Якщо розробник ухиляється від обговорення термінів, вартості, умов оплати та відповідальності, це дуже поганий знак.
8. Відсутність комунікації. Розробник не відповідає на повідомлення, пропускає зустрічі, не надає оновлень про прогрес. Це ознака ненадійності.
9. Занадто низька ціна. Якщо ціна вдвічі нижча, ніж у інших розробників, це не везіння, це червоний прапор. Або розробник недооцінив проєкт, або він працює низької якості.
10. Відсутність досвіду у вашій сфері. Розробник, який ніколи не робив сайти для e-commerce, може не розуміти специфіку вашого проєкту. Досвід у схожих проєктах важливий.

Скринінг розробників: тест і резюме

Якщо ви знайшли потенційного розробника, не поспішайте наймати його. Проведіть системний скринінг.

Крок 1: Перевірка резюме розробника

Зверніть увагу на:

• Досвід у схожих проєктах (якщо вам потрібен e‑commerce, шукайте досвід у розробці інтернет-магазинів)
• Технологічний стек (чи збігається з вашими вимогами?)
• Тривалість роботи на кожній посаді (часті зміни роботи: це червоний прапор)
• Рекомендації та відгуки від попередніх роботодавців

Крок 2: Технічне інтерв’ю

Задайте питання, що перевіряють глибину знань:

• «Розкажіть про найскладніший проєкт, який ви робили. Які були виклики і як ви їх вирішили?»
• «Як ви підходите до оптимізації продуктивності? Які інструменти використовуєте?»
• «Розкажіть про ваш досвід роботи з REST API. Як ви проектуєте ендпоінти?»
• «Як ви пишете unit-тести? Який відсоток покриття коду ви вважаєте прийнятним?»

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

Оцініть:

• Якість коду (читабельність, структура, дотримання найкращих практик)
• Наявність тестів та їхня якість
• Документація (чи є README, коментарі в коді)
• Час виконання (встиг чи в термін)

Крок 4: Перевірка soft skills

М’які навички часто важливіші за технічні. Перевірте:

• Комунікація: чи може розробник чітко пояснити свої рішення?
• Відповідальність: чи виконав він тестове завдання вчасно та в повному обсязі?
• Готовність до співпраці: чи ставить питання, якщо щось незрозуміло?
• Проактивність: чи пропонує покращення або просто виконує вимоги?

М’які навички програміста та відповідальність

Я часто бачу, як компанії наймають розробника з ідеальним резюме, але з жахливими soft skills. Результат: розробник не може працювати в команді, не слухає фідбек, не комунікує з клієнтом.

Комунікація: Розробник повинен уміти пояснити складні технічні речі простою мовою. Якщо ви не розумієте, що він каже, це проблема.

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

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

Як перевірити soft skills на тестовому завданні:

• Попросіть розробника пояснити свій код. Чи може він зробити це чітко?
• Дайте фідбек на його рішення. Як він реагує? Захищається чи слухає?
• Задайте питання. Чи ставить він зустрічні питання, якщо щось незрозуміло?
• Перевірте комунікацію. Чи відповідає на повідомлення вчасно? Чи надає оновлення про прогрес?

Контроль ТЗ і ризики в ІТ-аутстафінгу

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

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

Паспорт якості: Це документ, який описує критерії якості для кожного компонента проєкту. Приклад: “Фронтенд має мати 80% покриття unit-тестами, усі компоненти повинні бути задокументовані в Storybook, час завантаження головної сторінки не більше 2 секунд”.

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

Автоматичні тести та CI/CD: Кожен коміт у репозиторій має запускати автоматичні тести. Якщо тести не пройдені, код не повинен потрапляти в production. Це запобігає потраплянню багів у бойову систему.

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