ukБільшість перевитрат бюджету в розробці трапляються не через «поганих програмістів», а через те, що замовник і студія по-різному зрозуміли задачу. Технічне завдання — єдиний інструмент, який захищає від цього обидві сторони. Розповімо, як написати ТЗ, яке дасть точну оцінку й не перетвориться на фоліант на сто сторінок.
Навіщо потрібне ТЗ, якщо «і так усе зрозуміло»
Фраза «зробіть як Uber, тільки для перукарень» здається вичерпною, доки не починаєш рахувати: скільки ролей, яка логіка запису, що робити при скасуванні, як приймати оплату, чи потрібен чат. Кожне з цих питань — дні роботи. Без ТЗ студія або закладе ризики в ціну (ви переплатите), або оцінить оптимістично (ви переплатите пізніше, на доопрацюваннях).
Добре ТЗ розв'язує три задачі: фіксує обсяг, слугує основою для кошторису та стає критерієм приймання — «готово» означає «відповідає ТЗ».
Структура ТЗ на мобільний застосунок
1. Цілі та контекст
Два-три абзаци: який бізнес, яку проблему розв'язує застосунок, хто користувачі, як вимірюватимете успіх. Наприклад: «Застосунок для мережі з 12 салонів краси. Мета — перевести 60 % записів із телефону в онлайн за пів року та знизити кількість неявок за допомогою нагадувань».
Це не формальність. Розуміючи мету, команда пропонує рішення, про які ви не подумали, і відмовляє від функцій, які меті не служать.
2. Ролі користувачів
Перелічіть усіх, хто користуватиметься застосунком, і що кожен може робити. Клієнт, майстер, адміністратор салону, власник мережі — чотири ролі, чотири набори екранів і прав. Саме кількість ролей найчастіше подвоює бюджет, тому краще побачити це до старту.
3. Користувацькі сценарії
Найважливіша частина. Опишіть, як кожна роль розв'язує свої задачі, крок за кроком:
Клієнт відкриває застосунок → обирає салон на карті або зі списку → обирає послугу → бачить вільних майстрів і час → підтверджує запис → отримує push за 2 години до візиту → після візиту може оцінити майстра.
Не забувайте «нещасливі» шляхи: що відбувається при скасуванні за годину до візиту, якщо майстер захворів, якщо оплата не пройшла. Саме вони ховають половину складності.
4. Список екранів і функцій
На основі сценаріїв складіть перелік екранів із коротким описом елементів на кожному. Не потрібно малювати — достатньо тексту: «Екран запису: календар на 30 днів, слоти по 30 хвилин, зайняті слоти сірі, кнопка "Записатися" активна лише після вибору часу».
Корисно розділити функції на три групи: обов'язкові для запуску, бажані та «колись». Це дозволить студії запропонувати варіант MVP у межах бюджету.
5. Інтеграції
Перелічіть усі зовнішні системи: платіжний шлюз (який саме), CRM, SMS-провайдер, карти, соцмережі для входу, бухгалтерія, аналітика. Щодо кожної — чи є доступ до API та документація. Інтеграція із системою без нормального API може коштувати дорожче за половину застосунку.
6. Адмін-панель
Про неї часто забувають, а це окремий продукт. Хто і що налаштовуватиме: послуги та ціни, розклад майстрів, контент, push-розсилки, звіти. Що докладніше — то точніша оцінка.
7. Нефункціональні вимоги
- Платформи: iOS та Android? З якої мінімальної версії?
- Мови: одна чи кілька.
- Навантаження: скільки користувачів очікуєте в перший рік.
- Офлайн-режим: чи потрібен.
- Безпека та дані: чи зберігаються персональні, медичні або платіжні дані; вимоги GDPR і місцевого законодавства.
- Дизайн: чи є брендбук, референси застосунків, які подобаються.
8. Обмеження та очікування
Бюджетна вилка, бажаний термін запуску, хто з боку замовника ухвалює рішення і як швидко. Вказати бюджет не означає «переплатити»: це дозволяє студії одразу запропонувати обсяг, який у нього вкладається, замість оцінки «всього й одразу».
Типові помилки
- ТЗ з одного рядка. «Потрібен застосунок для доставки їжі» — це не ТЗ, а тема розмови.
- ТЗ на 150 сторінок до першої консультації. Половина застаріє після розмови з командою. Краще 5–10 сторінок за структурою вище, а деталі — разом з аналітиком.
- Опис рішень замість задач. «Зробити кнопку синьою і ліворуч» замість «користувач має за один дотик потрапити в кошик». Дайте команді вирішувати, як; ваша зона — що і навіщо.
- Забуті «нудні» частини: авторизація, відновлення пароля, сповіщення, обробка помилок, адмін-панель. Це до 30 % роботи.
- Немає пріоритетів. Коли все «обов'язково», бюджет зростає, а запуск відкладається.
Що робити, якщо писати ТЗ самому ніколи
Це нормально: ТЗ — робота аналітика, а не замовника. Достатньо підготувати пункти 1, 2 і 8 зі структури вище та список референсів. Решту — сценарії, екрани, інтеграції — ми робимо разом на етапі аналітики: це перша сходинка будь-якого проєкту в нашій студії, і її результат стає основою кошторису та договору.
Хочете, щоб ми допомогли сформулювати задачу? Залиште заявку — на безкоштовній консультації розберемо ідею та скажемо, що потрібно уточнити до старту.