Складання технічного завдання на мобільну розробку
ТЗ без технічних деталей — це документ для юриста, не для розробника. «Додаток має працювати швидко і бути зручним» — не вимога. «Список замовлень має завантажуватися не більше 2 секунд на 4G при 100 одночасних користувачах» — вимога, на яку можна спиратися при проектуванні.
Що відрізняє хороше ТЗ для мобільної розробки
Хороше ТЗ вирішує три проблеми одночасно: оцінку трудозатрат розробником, вхідний контроль при прийманні та базу для тест-плану QA. Якщо документ не дозволяє зробити хоча б одне з трьох — він неповний.
Функціональні вимоги у мобільному контексті — це не «користувач може зайти в систему». Це:
- Авторизація через email + пароль, Google Sign-In (
google_sign_in/ GoogleSignIn SDK), Apple Sign-In (обов'язково для iOS якщо є інші соцмережі — App Store Guideline 4.8) - Зберігання сесії: JWT у
flutter_secure_storage/ iOS Keychain / Android Keystore, час життя access token — 15 хвилин, refresh token — 30 днів - Поведінка при істеченні токена: тихе оновлення через interceptor, не видаляти користувача на екран входу при кожному запуску
Такий рівень деталізації знімає десятки запитань «а як має працювати» в процесі розробки.
Нефункціональні вимоги (NFR) — часто упускають
NFR для мобільного додатка:
| Параметр | Приклад вимоги |
|---|---|
| Продуктивність | Запуск додатка (cold start) — не більше 3 секунд на iPhone XR і Pixel 5 |
| Сітьовий таймаут | HTTP-запити: connect timeout 10s, receive timeout 30s |
| Офлайн | Останні 50 записів доступні без інтернету |
| Розмір додатка | IPA не більше 50 МБ до завантаження ресурсів (App Thinning) |
| Підтримані версії | iOS 15+, Android 8.0+ (API 26+) |
| Локалізація | ru, en — обов'язково; de, fr — в наступній версії |
| Доступність | Підтримка Dynamic Type (iOS) та font scale (Android) |
Без NFR розробник зробить «як зручно», а не «як потрібно».
Екрани та User Stories
Структура ТЗ по екранах: кожен екран описується через User Story (Як [роль], я хочу [дія], щоб [мета]) + wireframe або посилання на Figma + деталізація поведінки. Не «екран профіля», а:
Екран «Редагування профіля»: користувач може змінити ім'я (обов'язково, 2–50 символів), аватар (вибір з галереї або камери, кропінг 1:1, максимум 5 МБ), номер телефону (валідація через SMS OTP). Зміни зберігаються по натисненню «Зберегти». При відсутності змін кнопка неактивна. При помилці мережі — toast з текстом помилки, зміни не втрачаються.
API-контракти та залежності
ТЗ має фіксувати зовнішні залежності:
- Перелік сторонніх API і SDK (Firebase, Stripe, Google Maps, тощо) з конкретними версіями або мінімальними вимогами
- Формат обміну даними з бекендом: REST / GraphQL / WebSocket, схема авторизації (Bearer JWT, API Key, OAuth 2.0)
- Якщо бекенд розробляється паралельно — мінімальний OpenAPI 3.0 контракт, на який орієнтується мобільна команда
Що не потрібно писати в ТЗ
Спосіб реалізації — це зона відповідальності розробника, не замовника. ТЗ описує що має працювати, не як. «Використовувати Flutter» — допустимо. «Використовувати BLoC для управління станом» — це вже не ТЗ, а технічні рішення, які обговорюються окремо.
Процес та строки
Робота над ТЗ:
- Інтерв'ю з замовником — збираємо бізнес-вимоги, ролі користувачів, пріоритети функціональності
- Аналіз конкурентів — якщо продукт у існуючій ніші, вивчаємо UX-паттерни лідерів
- Написання документа — функціональні вимоги, NFR, екрани, API-залежності
- Узгодження — ітерації з замовником, уточнення крайових випадків
Готове ТЗ: 2–3 дні для додатка до 20 екранів. Для складних продуктів (маркетплейс, фінтех) — 4–6 днів. Вартість розраховується індивідуально.