Технічне завдання на мобільний додаток у 2027 році: шаблон

Що таке ТЗ на додаток і чим воно відрізняється від брифу

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

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

Гарна новина: вам не потрібно писати ТЗ як інженер на 80 сторінок. Достатньо 3–6 сторінок простого тексту за шаблоном нижче. Технічні деталі підрядник допише сам, але він не може вигадати за вас, що потрібно вашому бізнесу.

Є й інша користь: ТЗ дає змогу отримати порівнянні пропозиції. Коли пʼять студій оцінюють один документ, ціни можна чесно покласти поруч. Коли кожна оцінює власну версію вашої ідеї, порівнювати нічого.

ТЗ на мобільний додаток: шаблон із 10 розділів

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

1. Мета й вимірюваний результат. Одна фраза: «клієнти записуються самі, і 30 % записів приходять через додаток». Без цифри можна, але тоді напишіть, за чим ви зрозумієте успіх.
2. Користувачі та ролі. Хто користується: клієнт, майстер, адміністратор, курʼєр. У кожної ролі свої екрани й права.
3. Платформи. iOS, Android або обидві; чи потрібен планшет; чи вистачить сайту, який ставиться на телефон як додаток (PWA), чи потрібні магазини додатків. Якщо вагаєтеся, спершу порівняйте додаток, сайт і PWA за вартістю та завданнями.
4. Карта екранів. Список усіх екранів і стрілки між ними: вхід, головний, каталог, картка, кошик, профіль. Можна намалювати від руки й сфотографувати.
5. Сценарії. По кроках, що робить людина: «відкрила, обрала послугу, обрала час, оплатила, отримала нагадування».
6. Функції з пріоритетами. Три колонки: «без цього запускати не можна», «добре б», «потім». Це найважливіший розділ для бюджету.
7. Дані та підключення. Де зберігаються користувачі й замовлення, із чим звʼязуємося: оплата, CRM, облік, карти, пошта, месенджери.
8. Нефункційні вимоги. Швидкість, робота без інтернету, мови, безпека, доступність (докладніше нижче).
9. Публікація й акаунти. На чиє імʼя заводяться акаунти розробника, хто пише опис для магазинів, які країни.
10. Приймання й етапи. Як перевіряємо результат, скільки кіл правок, як ділимо оплату за етапами.

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

Вимоги до мобільного додатка: функційні й нефункційні

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

Приклад ТЗ на мобільний додаток для запису в салон

Роль «клієнт». Реєстрація за номером телефону з кодом із СМС. Каталог послуг із ціною та тривалістю. Вибір майстра й вільного часу. Передоплата карткою. Нагадування за добу та за 2 години. Скасування безкоштовне не пізніше ніж за 24 години. Роль «адміністратор»: розклад майстрів, список записів, повернення коштів, розсилка акцій.

Це функційна частина. До неї додаємо нефункційну:

• Швидкість. Головний екран відкривається без помітної затримки на середньому телефоні п’ятирічної давності.
• Звʼязок. Що бачить клієнт без інтернету: останній запис чи повідомлення про помилку? Повноцінний офлайн-режим коштує окремих грошей.
• Мови й валюти. Скільки мов інтерфейсу, в якій валюті ціни, як виглядають дати.
• Безпека та дані. Які особисті дані зберігаються, хто їх бачить, як людина видаляє свій акаунт. Якщо ви працюєте у вашій країні, уточніть вимоги до персональних даних у юриста: для ЄС це GDPR.
• Доступність. Великий шрифт, контраст, підписи для екранних читалок. Це і зручність, і вимога деяких ринків.
• Пристрої. З якої версії iOS і Android підтримуємо й на яких екранах перевіряємо.

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

Що вписати в ТЗ про App Store і Google Play

Публікація — окремий етап зі своїми правилами, і на неї впливаємо не тільки ми. Тому в ТЗ варто записати кілька пунктів заздалегідь.

• Акаунти розробника. Apple бере $99 на рік, Google Play — $25 одноразово. Ми оформлюємо додаток на ваш акаунт, тому записуйте, хто його заведе і хто зберігає доступи.
• Готова версія для перевірки. За правилами Apple (розділ 2.1, «повнота додатка») на перевірку надсилають завершену збірку: без заглушок і тимчасових сторінок, із робочими посиланнями, а якщо є вхід в акаунт — із демодоступом для перевіряльника, і серверна частина в цей момент має працювати. У ТЗ це перетворюється на пункт приймання: «тестовий акаунт й опис для перевіряльника готові».
• Тестування для Google Play. Для нових особистих акаунтів розробника Google вимагає закрите тестування: щонайменше 12 тестувальників, підключених 14 днів поспіль, і лише потім відкриває випуск для всіх. Закладіть ці два тижні в строк або заводьте акаунт організації; актуальні умови дивіться в довідці Google Play.
• Тексти й картинки для магазинів. Опис, скриншоти, політика конфіденційності, віковий рейтинг. Хто їх пише і якими мовами.
• Платежі. Якщо в додатку продаються цифрові товари чи підписки, у магазинів є свої правила й комісії. Для фізичних товарів і послуг правила інші. Запишіть, що ви продаєте, і підрядник підкаже потрібну схему.

Строки перевірки магазинів від нас не залежать, тому ми ніколи не обіцяємо точну дату появи в магазині. Докладніше про самі кроки публікації — у статті як створити мобільний додаток: від ідеї до App Store.

Пʼять помилок у ТЗ, через які ростуть строки та ціна

1. Немає пріоритетів. Коли все «дуже потрібно», оцінка включає все, а першу версію ви запускаєте через пів року замість двох місяців. Поділіть функції на «обовʼязково», «добре б» і «потім».
2. Немає критеріїв приймання. «Гарно й зручно» перевірити не можна. «Запис створюється не більше ніж за чотири дотики» — можна.
3. Забуто адмінку та ролі. Додаток для клієнта — половина продукту. Друга половина — інструмент вашої команди.
4. Розмиті інтеграції. «Звʼязати з CRM» означає різні обсяги роботи для різних систем. Назвіть систему й опишіть, які дані куди йдуть.
5. Немає відповідальної особи. Якщо рішення з вашого боку ухвалюють троє людей, проєкт гальмує на погодженнях. Призначте одного, хто каже «так» або «ні».

Ще одна поширена пастка — писати ТЗ на готовий «ідеальний продукт». Краще описати першу версію, яка перевіряє ідею на реальних людях, а окремим списком — усе, що ви додасте, якщо вона спрацює. Як виглядає така перша версія і скільки вона коштує, пояснює стаття MVP: що це і скільки коштує запустити.

Перевірте, чи готове ТЗ до оцінки

Пройдіть короткий чек-лист нижче. Він показує, чи можна надсилати документ підрядникам, чи спершу варто закрити прогалини. Якщо на більшість пунктів ви відповідаєте «ні», нічого страшного: частину питань можна розібрати разом із підрядником, і ми до цього готові.

Хто має писати ТЗ: ви, підрядник чи разом

Є три робочі сценарії, і вибір залежить від того, наскільки зрозуміла ваша ідея.

• Ви пишете самі за шаблоном. Підходить, якщо ідея проста, а ви знаєте свою аудиторію. Отримаєте кілька оцінок і порівняєте їх.
• Підрядник пише за вашим брифом. Зручно, але памʼятайте: що докладніший документ, то точніший кошторис. Безкоштовне ТЗ нерідко перетворюється на «ТЗ під нашу ціну», тому запитайте, кому воно належить, якщо ви оберете іншу команду.
• Платна передпроєктна робота. Для складних продуктів (ролі, оплати, кілька систем) ми робимо це окремим етапом: архітектурна сесія за €3 500. На виході карта продукту, кошторис і план першої версії. Ця сума зараховується в проєкт, а сама карта лишається у вас за будь-яких обставин, навіть якщо ви потім оберете іншу команду.

Якщо потрібні екрани, а не лише текст, додайте дизайн і прототип, від €1 990: клікабельний прототип на телефоні пояснює ідею краще за десять сторінок опису. У готових пакетах додатка дизайн уже входить.

Як вибрати, кому довірити документ і сам проєкт, розбирає стаття як обрати веб-студію і не помилитися: ті самі запитання підходять і для розробників додатків. А скільки коштує сам додаток, дивіться в статті скільки коштує розробка додатка.

Що обрати у вашій ситуації

• Ідея проста: один сценарій, одна роль. Заповніть шаблон самі, надішліть двом-трьом командам і порівняйте відповіді. Додаток на iOS і Android у нас від €10 900, точна сума рахується в кошторисі після ТЗ.
• Є кілька ролей, оплата, інтеграції. Не пишіть усе наосліп: почніть з архітектурної сесії й отримайте ТЗ у вигляді карти продукту та кошторису.
• Немає впевненості, що додаток узагалі потрібен. Можливо, вистачить сайту на телефоні або Telegram-додатка. Порівняйте варіанти й вартість до того, як писати документ.
• Уже є ТЗ від іншої студії. Покажіть його нам та іншим підрядникам: один документ, кілька пропозицій. Як чесно порівняти відповіді, розбирає стаття як порівняти підрядників і комерційні пропозиції.
• Потрібно запуститися якнайшвидше. Опишіть лише обовʼязкові функції та віддайте решту в другу версію.

Не знаєте, з чого почати? Напишіть нам, і ми разом визначимо формат старту у вашому місті або віддалено: від простого прототипу до архітектурної сесії.