Зачем ТЗ, если есть прототип
Прототип показывает, как приложение выглядит, но не объясняет, как оно ведёт себя в нестандартных ситуациях. Что будет, если у клиента закончился интернет в момент оплаты? Кто получает уведомление, если мастер отменил заказ? Можно ли редактировать заказ после подтверждения? Ответы на такие вопросы должны быть записаны, иначе их придумает разработчик, и необязательно так, как вам нужно.
Поэтому ТЗ — это договор о понимании. Оно же служит основой приёмки: вы проверяете готовое приложение по списку, а не по ощущениям.
Из каких разделов состоит ТЗ
Цель и результат
Какую проблему решает приложение и по какому показателю вы поймёте, что получилось: число заказов, время обработки, возвраты.
Пользователи и роли
Кто пользуется: клиент, курьер, мастер, менеджер, администратор. Что каждая роль может и не может делать.
Экраны и сценарии
Перечень экранов и путей между ними: регистрация, каталог, корзина, оплата, история, профиль.
Данные и интеграции
Какие данные хранятся, откуда загружаются каталог и остатки, куда уходят заказы: 1С, CRM, Kaspi, касса.
Платформы и устройства
iPhone, Android, минимальные версии, планшеты. Нужна ли веб-версия или админка.
Нефункциональные требования
Скорость, работа без интернета, языки, доступность, безопасность, нагрузка в первый месяц.
Критерии приёмки
По каким проверкам вы признаёте приложение готовым, и сколько времени есть на правки.
Вопросы, которые стоит проговорить заранее
- Кто и как регистрируется: номер телефона, почта, через Apple или Google
- Какие языки интерфейса: русский, казахский, английский
- Как отменяется заказ и кто и когда получает деньги назад
- Что видит клиент, если товара нет в наличии
- Как администратор меняет цены, акции и описания без программиста
- Какие тексты и фото предоставляете вы, а какие пишем мы
Не нужно делать всё самому
Можно прийти с презентацией, таблицей или голосовым сообщением. На брифе мы задаём вопросы и сами собираем ТЗ с экранами и сценариями, а вы проверяете, что мы поняли вас верно.