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

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

Для замовника ТЗ також є інструментом контролю обсягу. Коли нова ідея з’являється посеред роботи, можна порівняти її з погодженим документом: це вже врахована вимога, уточнення наявного сценарію чи окрема зміна, що впливає на бюджет і пріоритети.

Для чого замовнику ТЗ на додаток

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

ТЗ дає відповідь на п’ять управлінських запитань:

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

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

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

Структура документа: що обов’язково описати

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

Контекст, ціль і межі першої версії

Опишіть продукт у трьох-п’яти реченнях: хто ним користується, яку дію він має спростити та який процес залишається поза межами запуску. Наприклад, «клієнт самостійно повторює замовлення з каталогу, а менеджер підтверджує його у наявній CRM». Це одразу створює межу: додаток не обов’язково має замінити CRM або автоматизувати бухгалтерію.

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

Користувачі, ролі та сценарії

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

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

Окремо перелічіть платформи: iOS, Android або обидві; потребу в планшетах, мовах інтерфейсу та доступності. Це не формальність: платформа, тип пристрою та способи входу впливають на обсяг дизайну, тестування й підтримки. Якщо вам потрібна розробка мобільних додатків, саме ці рішення дадуть виконавцю достатній контекст для предметної розмови про формат реалізації.

Заповнений шаблон ТЗ: навчальний приклад

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

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

Як відрізнити побажання від перевірюваної вимоги

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

• Побажання: «Авторизація має бути простою». Вимога: «Чинний клієнт входить за номером телефону й одноразовим кодом; пароль не використовується».
• Побажання: «Потрібні повідомлення». Вимога: «Після зміни статусу замовлення на “Доставляється” користувач отримує push-сповіщення; натискання відкриває деталі цього замовлення».
• Побажання: «Хочемо інтеграцію з CRM». Вимога: «З CRM надходять ім’я, адреси та історія замовлень; із застосунку передаються склад нового замовлення, адреса й контактний номер».
• Побажання: «Застосунок має бути безпечним». Вимога: «Після виходу з акаунта профіль і історія не доступні до нового входу; користувач не бачить дані інших клієнтів».

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

Дані, інтеграції та відповідальність замовника

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

Для кожної інтеграції опишіть бізнесовою мовою:

1. систему або сервіс, з яким потрібен обмін;
2. які дані застосунок отримує і які передає;
3. у який момент відбувається обмін: одразу, за розкладом чи після ручної дії;
4. що бачить користувач, якщо відповідь не надійшла або дані не збігаються;
5. хто з боку замовника підтверджує правила, надає доступи та тестові дані.

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

Критерії приймання: як уникнути суперечок наприкінці

Критерії приймання не дорівнюють загальному враженню від застосунку. Це погоджений список перевірок для важливих функцій. Вони мають бути пов’язані зі сценаріями з ТЗ, а не з’являтися лише під час фінальної демонстрації.

Проста формула критерію

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

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

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

Що в ТЗ впливає на обсяг і бюджет

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

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

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

Фінальна перевірка ТЗ перед погодженням

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

• Є одна конкретна бізнес-мета та межі першої версії.
• Для кожної ролі визначено доступні дії й дані.
• Ключові сценарії описано від старту до результату, включно з важливими винятками.
• Платформи, мови, пристрої та спосіб входу погоджено.
• Для даних та інтеграцій зрозумілі джерело, напрям обміну й відповідальна сторона.
• Кожна критична функція має критерій приймання, який можна продемонструвати.
• Ідеї на майбутнє відділено від обов’язкових функцій запуску.

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