Як скласти ТЗ на розробку застосунку: шаблон і поради

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

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

Навіщо ТЗ ще до розмови з розробниками

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

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

ТЗ на цьому етапі — не договір і не фінальна специфікація. У ньому можуть бути відкриті питання. Позначка «поки не знаємо» біля пункту набагато корисніша, ніж його відсутність: вона одразу показує команді, на чому зосередитися під час discovery.

Що включити в ТЗ на розробку застосунку

Згрупуйте зміст у чотири блоки. Не обов'язково ідеально заповнювати кожен рядок — ясність важливіша за повноту.

1. Бізнес-контекст

• Мета. Яку проблему розв'язує продукт і що має змінитися для бізнесу після запуску? «Клієнти записуються без дзвінка адміністратору» — корисніше формулювання, ніж «зробити застосунок для запису».
• Аудиторія. Хто користувачі, якого віку, з яких пристроїв заходять, у яких країнах і якими мовами користуються? Застосунок для людей похилого віку і застосунок для кур'єрів потребують зовсім різних інтерфейсів.
• Метрики успіху. Як ви зрозумієте, що продукт працює, через три місяці після запуску: кількість записів, платних підписок, замовлень на день, зекономлених годин персоналу?

2. Обсяг продукту

• Ролі користувачів. Перелічіть усі типи користувачів: гість, зареєстрований клієнт, співробітник, партнер, адміністратор. Кожна роль зазвичай означає окремі екрани й права доступу.
• Ключові сценарії. Опишіть крок за кроком 3–7 найважливіших шляхів користувача, наприклад: «клієнт знаходить сервіс на мапі → обирає час → оплачує → отримує нагадування».
• Обов'язкове і бажане. Розділіть функції на ті, без яких перший реліз не має сенсу, і ті, що можуть зачекати. Це найефективніший спосіб контролювати бюджет і основа, на якій будується розробка MVP.
• Платформи. iOS, Android, веб чи комбінація? Лише смартфони чи й планшети? Чи потрібен окремий сайт, крім застосунку?

3. Технічний контекст

• Інтеграції. Платежі, CRM чи ERP, мапи, служби доставки, месенджери, аналітика, наявні бази даних. Назвіть конкретні сервіси, якщо знаєте, і вкажіть, чи мають вони API — від цього часто залежить обсяг робіт із розробки API.
• Адмінпанель. Хто керуватиме контентом, користувачами, замовленнями й налаштуваннями і які звіти потрібні? Адмінпанель часто недооцінюють, хоча вона може забрати помітну частину бюджету.
• Контент. Хто пише тексти, надає фото, відео й переклади і скільки мов потрібно? Відсутній контент — одна з частих причин зсуву запуску.

4. Дизайн і обмеження

• Референси. Посилання на 2–5 застосунків або сайтів, які вам подобаються, з одним реченням про те, що саме подобається: навігація, тон, кольори, онбординг. Якщо є брендбук — згадайте його.
• Обмеження. Вимоги до даних і законодавства (персональні чи медичні дані, GDPR, вікові обмеження), обов'язкові технології, побажання щодо хостингу, наявний код, який треба зберегти.
• Діапазон бюджету. Навіть широкий діапазон дозволяє команді запропонувати обсяг, що в нього вкладається, а не ідеальний продукт, який вам не по кишені.
• Дедлайн. Бажана дата і причина — демо для інвестора, сезон, виставка. Жорсткий і гнучкий дедлайни ведуть до різних планів.

Шаблон ТЗ на розробку застосунку (скопіюйте і заповніть)

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

1. Назва проєкту й опис одним реченням.
2. Мета: яку проблему ви розв'язуєте і якого бізнес-результату очікуєте.
3. Цільова аудиторія: хто користувачі, де вони живуть, якими мовами й пристроями користуються.
4. Ролі користувачів і що може робити кожна роль.
5. Ключові сценарії (3–7), описані крок за кроком.
6. Обов'язкові функції для першого релізу.
7. Бажані функції для наступних версій.
8. Платформи: iOS, Android, вебзастосунок, адмінпанель, сайт.
9. Інтеграції: платежі, мапи, CRM, сповіщення, аналітика, наявні системи.
10. Адмінпанель: чим керує ваша команда і які звіти потрібні.
11. Контент: хто надає тексти, медіа й переклади.
12. Референси дизайну і матеріали бренду.
13. Обмеження: вимоги до даних і законодавства, обов'язкові технології, наявний код.
14. Діапазон бюджету і дедлайн із поясненням дати.
15. Метрики успіху на перші 3–6 місяців і людина, яка ухвалює рішення з вашого боку.

Як описати функції, щоб розробники зрозуміли

Більшість ТЗ перелічують екрани: «вхід, профіль, каталог, кошик». Це мало що говорить про реальний обсяг роботи. Натомість описуйте, чого досягає користувач і що система має робити «під капотом».

Порівняйте два описи. «Екран сповіщень» може бути задачею на один день. «Нагадати користувачу про запис за 24 години і за годину, дати змогу перенести запис прямо з нагадування і повідомити про це заклад» — це планувальник на сервері, push-сповіщення, deep links і повідомлення для іншої ролі. Таку функцію команда вже може оцінити коректно.

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

Типові помилки в ТЗ

• Опис рішення замість проблеми. «Нам потрібен чат» може приховувати справжню потребу — швидко відповідати на запитання клієнтів, — яку розв'язала б простіша функція.
• Усе в пріоритеті. Якщо всі 40 функцій обов'язкові, команда не зможе запропонувати менший і дешевший перший реліз.
• Забута адмінчастина. Хтось має керувати користувачами, контентом, замовленнями й поверненнями коштів. Без адмінпанелі в ТЗ оцінка буде неповною.
• Жодного слова про бюджет. Тоді команди вгадують, і ви отримуєте пропозиції або надто скромні, або набагато дорожчі, ніж планували.
• «Як відомий застосунок, тільки для X». За відомими продуктами стоять роки роботи. Назвіть дві-три функції, які вам справді потрібні з цього прикладу.
• Приховані невизначеності. Невідомі інтеграції чи незрозумілі юридичні вимоги не зникають, якщо про них змовчати, — вони повертаються пізніше як сюрпризи в бюджеті.

Як команда перетворює ТЗ на оцінку

ТЗ — це вхідні дані, оцінка — результат. Між ними короткий етап discovery. Зазвичай він виглядає так:

1. Аналіз і запитання. Команда читає ТЗ і надсилає запитання щодо незрозумілих сценаріїв, інтеграцій і пріоритетів.
2. Дзвінок з тим, хто ухвалює рішення. Зазвичай 30–60 хвилин, щоб узгодити цілі, користувачів і те, що має довести перший реліз.
3. Декомпозиція. Функції розбивають на менші задачі з дизайну, мобільної чи веброзробки, бекенду й тестування — кожна з діапазоном часу.
4. Ризики і припущення. Невідомі — сторонній API без документації, правила магазинів щодо платежів, вимоги до даних — фіксують разом із їхнім впливом на терміни й вартість.
5. Оцінка і дорожня карта. Ви отримуєте рекомендований обсяг першого релізу, орієнтовні терміни, склад команди й діапазон бюджету, а також перелік того, що можна перенести в наступні версії.

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

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