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

Проект близький до завершення, але замовник каже: «Це не те, що я хотів». Ситуація знайома кожному розробнику. Причина — погане технічне завдання. Складання технічного завдання на розробку сайту — наша спеціалізація. Ми, інженери з десятирічним досвідом, підготували понад 50 ТЗ для інтернет-магазинів, сервісів і порталів. Наш підхід: детальна аналітика, формалізація вимог і версіонування в Git. Хороше ТЗ — інструмент комунікації між замовником, розробниками та тестувальниками. Воно фіксує, що буде розроблено, як виглядає і як перевіряється. Без ТЗ проект перетворюється на хаос. Зв'яжіться з нами для аудиту вашого проекту — ми допоможемо перетворити хаотичні побажання на чітку документацію.

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

Основна помилка в ТЗ — описувати інтерфейс замість поведінки. «Кнопка синього кольору в правому куті» — не ТЗ. А ось «При натисканні на кнопку "Оформити замовлення" система створює замовлення зі статусом draft, резервує товар, надсилає email підтвердження та перенаправляє на сторінку /orders/{id}» — це ТЗ.

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

Як виглядає якісне ТЗ?

Хороше ТЗ містить:

• вимірювані критерії (LCP < 2,5 с, конверсія > 3%),
• однозначні формулювання — будь-який розробник зрозуміє однаково,
• опис поведінки, а не інтерфейсу,
• облік в Git з версіонуванням та обговоренням через Pull Request.

Погане ТЗ — набір скріншотів і фраз «зробіть красиво». Воно гарантує переробки, які обходяться в 3–5 разів дорожче.

Чому ТЗ краще зберігати в Git?

Markdown + Git дають переваги перед Word:

ТЗ в Git в 10 разів зручніше для керування версіями. Ми використовуємо саме такий підхід.

З чого складається ТЗ для інтернет-магазину?

Призначення та цілі системи — складання технічного завдання

Описує контекст: для кого створюється, яку бізнес-задачу вирішує, критерії успіху (конверсія не менше 3%, час завантаження до 2 секунд).

Користувацькі ролі та права

Приклад матриці доступу:

Функціональні вимоги

Кожна вимога у форматі: ідентифікатор, опис, передумови, результат, винятки.

FR-001: Реєстрація користувача

• Передумови: користувач не аутентифікований, email не зареєстрований.
• Сценарій: введення email, пароля, імені; валідація; створення облікового запису зі статусом «не підтверджено»; надсилання листа з посиланням (TTL 24 години).
• Винятки: email вже використовується → помилка; невалідний email → помилка; помилка надсилання → повторна черга.
• Результат: запис у таблиці users, запис у черзі email.

Нефункціональні вимоги

• Продуктивність: 95-й перцентиль API < 300 мс при 100 rps; FCP < 1,5 с, LCP < 2,5 с; JS-бандл < 150 КБ gzip.
• Надійність: uptime 99,5%, відновлення < 15 хвилин, резервне копіювання щоденно зі зберіганням 30 днів.
• Безпека: JWT (TTL 1 година + refresh 30 днів), bcrypt (cost 12), rate limiting, HTTPS, HSTS, параметризовані запити, CSP.

Інтеграції

• Оплата: ЮKassa (API v3: карта, СБП, ЮMoney), webhook з HMAC-SHA256.
• Доставка: СДЕК (розрахунок, створення накладної, трекінг).
• Email: SendGrid (транзакційні листи: підтвердження, відновлення, статуси).
• Аналітика: Яндекс.Метрика + GA4 з електронною торгівлею.

Схема даних

users (1) ─── (N) orders
orders (1) ─── (N) order_items
order_items (N) ─── (1) products
products (N) ─── (1) categories
products (1) ─── (N) product_images
users (1) ─── (1) carts
carts (1) ─── (N) cart_items

Середовища та деплой

• development: Docker Compose локально
• staging: https://staging.example.com — тестування перед релізом
• production: https://example.com
• CI/CD: develop → автодеплой на staging, main → ручний деплой на production з обов'язковим прогоном тестів
• Моніторинг: UptimeRobot (щохвилини), Sentry (помилки), Grafana + Prometheus (метрики)

Приймальні критерії

• Пагінація (20 товарів на сторінку)
• Фільтрація за категорією, ціною, наявністю
• Сортування за ціною, новизною, популярністю
• Повнотекстовий пошук від 3 символів
• Картка товару: фото, опис, ціна, кнопка «В кошик»
• Breadcrumbs з мікророзміткою BreadcrumbList
• LCP < 2,5 с на мобільному (Lighthouse)
• Додавання неіснуючого товару повертає 404

Скільки часу займає підготовка ТЗ?

Для інтернет-магазину середнього розміру (50–100 екранів) складання ТЗ займає 2–3 тижні. Включає аналітичні інтерв'ю, прописування сценаріїв, узгодження нефункціональних вимог і рев'ю з технічною командою. Вартість розраховується індивідуально — залежить від складності та кількості інтеграцій.

Типові помилки при складанні ТЗ

• Описувати інтерфейс, а не поведінку
• Пропускати нефункціональні вимоги
• Використовувати загальні фрази без цифр
• Не фіксувати винятки та граничні випадки
• Зберігати ТЗ в Word без версіонування

Що входить у роботу

1. Повний аудит поточного стану (якщо є прототип або попередня документація)
2. Інтерв'ю з ключовими співробітниками замовника (до 5 осіб)
3. Формування функціональних і нефункціональних вимог
4. Опис інтеграцій і схеми даних
5. Створення матриці ролей і прав
6. Узгодження та фіксація приймальних критеріїв
7. Версіонування в Git з історією змін
8. Фінальне рев'ю з командою розробки

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

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.