ruБольшинство перерасходов бюджета в разработке случаются не из-за «плохих программистов», а из-за того, что заказчик и студия по-разному поняли задачу. Техническое задание — единственный инструмент, который защищает от этого обе стороны. Расскажем, как написать ТЗ, которое даст точную оценку и не превратится в талмуд на сто страниц.
Зачем нужно ТЗ, если «и так всё понятно»
Фраза «сделайте как у 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 из структуры выше и список референсов. Остальное — сценарии, экраны, интеграции — мы делаем вместе на этапе аналитики: это первая ступень любого проекта в нашей студии, и её результат становится основой сметы и договора.
Хотите, чтобы мы помогли сформулировать задачу? Оставьте заявку — на бесплатной консультации разберём идею и скажем, что нужно уточнить до старта.