Зачем нужно ТЗ, если разработчик всё равно спросит
Без ТЗ оценка стоимости — гадание: одна студия назовёт сумму за «простой каталог», другая — за каталог с личным кабинетом, оплатой и интеграцией с 1С, и сравнить предложения будет невозможно. ТЗ делает оценки сопоставимыми, а при приёмке работ — защищает обе стороны: понятно, что было обещано.
Не нужно писать ТЗ «как программист». Достаточно описать бизнес-задачу и сценарии пользователей — технические детали разработчик предложит сам.
Структура ТЗ: 10 разделов
Этой структуры хватает для большинства приложений для бизнеса. Разделы, которые к вам не относятся, просто пропустите.
| Раздел | Что написать |
|---|---|
| 1. Цель | Зачем приложение бизнесу: больше повторных заказов, меньше звонков, запись без администратора |
| 2. Пользователи и роли | Клиент, курьер, администратор, менеджер — кто что может делать |
| 3. Платформы | iOS, Android, нужна ли веб-версия или админ-панель |
| 4. Сценарии | Пошагово главные действия: «клиент выбирает услугу → время → оплачивает → получает напоминание» |
| 5. Функции первой версии | Что обязательно к запуску, а что — во вторую очередь |
| 6. Интеграции | CRM, 1С, оплата и касса, карты, мессенджеры, ваш сайт |
| 7. Контент и данные | Откуда берутся товары, цены, расписание; кто их обновляет |
| 8. Дизайн | Фирменный стиль, логотип, примеры приложений, которые нравятся |
| 9. Нефункциональные требования | Сколько пользователей, работа без интернета, защита персональных данных |
| 10. Приёмка и поддержка | Как проверяем результат, кто публикует в магазинах, кто выпускает обновления |
Как описывать функции: пример
Самая частая ошибка — описывать функции одним словом: «личный кабинет», «бонусы», «корзина». За каждым словом может скрываться как два экрана, так и двадцать. Описывайте через действия пользователя и правила.
- Плохо: «Бонусная программа».
- Хорошо: «За каждый заказ начисляется 5% бонусами. Бонусами можно оплатить до 30% следующего заказа. Бонусы сгорают через 6 месяцев. Клиент видит баланс и историю начислений в профиле. Начисления хранятся в 1С».
Второй вариант разработчик может точно оценить, а вы — проверить при приёмке.
Делите на версии
Первая версия (MVP) должна закрывать один главный сценарий — например, «заказать и оплатить» или «записаться на время». Всё остальное — во вторую очередь, после того как увидите, как клиенты пользуются приложением. Это экономит бюджет и сокращает срок запуска.
Частые ошибки в ТЗ
- Нет приоритетов: всё «обязательно», и бюджет разрастается вдвое.
- Не указаны интеграции — а потом выясняется, что заказы должны падать в 1С.
- Не описана админ-панель: кто и где будет менять цены, баннеры и расписание.
- Не решено, на кого регистрируются аккаунты разработчика в App Store, Google Play и RuStore.
- Забыта поддержка: кто будет выпускать обновления под новые версии iOS и Android.
- Скопировано чужое ТЗ «как у конкурента» без понимания, зачем это вашим клиентам.
Шаблон, который можно заполнить
Скопируйте и ответьте на вопросы своими словами — этого достаточно, чтобы получить точную оценку.
- Компания и сфера: …
- Цель приложения (одно предложение): …
- Кто пользуется (роли): …
- Главный сценарий клиента по шагам: …
- Функции первой версии: …
- Функции на потом: …
- С чем связать (CRM, 1С, оплата, касса, сайт): …
- Кто и где будет обновлять товары, цены, расписание: …
- Есть ли фирменный стиль и логотип: …
- Приложения, которые нравятся, и чем: …
- Желаемый срок запуска и ориентир бюджета: …
ТЗ можно не писать в одиночку
Если заполнять шаблон некогда, начните с калькулятора на главной: отметьте нужные модули — авторизацию, каталог, корзину, оплату, push-уведомления, интеграции — и вы сразу увидите ориентир стоимости. Базовое приложение для iOS и Android — от 90 000 ₽. Затем мы созвонимся, уточним сценарии и сами соберём ТЗ на основе ваших ответов.