Зачем нужно техническое задание
Техническое задание - это договор о том, что именно будет сделано, между заказчиком и командой разработки. Без него каждый понимает задачу по-своему: заказчик ждёт одно, разработчики делают другое, и на приёмке начинаются споры. Хорошее ТЗ фиксирует функциональность, ограничения и критерии готовности, поэтому напрямую влияет на смету и сроки: чем точнее описаны требования, тем меньше переделок и тем ближе оценка к реальности. Именно поэтому вопрос «как написать техническое задание» стоит решить до того, как обсуждать цену и дедлайны, а не после.
Структура технического задания: из чего оно состоит
Структура технического задания почти всегда одинаковая, меняется только глубина деталей. Базовый набор разделов такой: цель и бизнес-контекст продукта; роли и сценарии пользователей; функциональные требования (что система делает); нефункциональные требования (нагрузка, безопасность, скорость, поддерживаемые устройства); интеграции с внешними сервисами; описание данных и их хранения; дизайн и требования к интерфейсу; этапы и критерии приёмки. Не обязательно писать все разделы одинаково подробно - важно, чтобы под каждый пункт можно было проверить результат: сделано или нет.
Плохая и хорошая формулировка требования
Главная ошибка в ТЗ - размытые формулировки, которые нельзя проверить. Плохо: «приложение должно быстро работать». Хорошо: «экран каталога открывается не дольше 2 секунд при 3G и списке из 500 товаров». Плохо: «удобная авторизация». Хорошо: «вход по номеру телефона с СМС-кодом, повторная отправка кода через 60 секунд, блокировка после 5 неверных попыток». Разница в том, что вторые формулировки измеримы: по ним однозначно понятно, выполнено требование или нет, и не остаётся места для спора на приёмке.
Шаблон ТЗ: скопируйте структуру под свой проект
Готовый каркас, который можно взять за основу и заполнить под свою задачу. 1. Цель проекта - какую проблему решаем и для кого. 2. Пользователи и роли - кто и что делает в системе. 3. Пользовательские сценарии - пошагово, от входа до целевого действия. 4. Функциональные требования - список функций, каждая измерима. 5. Нефункциональные требования - нагрузка, скорость, безопасность, платформы. 6. Интеграции - платежи, уведомления, карты, аналитика, внешние API. 7. Данные - что храним, где, сроки и требования 152-ФЗ. 8. Интерфейс - макеты или ссылки на дизайн, тон, брендинг. 9. Этапы и приёмка - как разбиваем работу и по каким критериям принимаем. Даже краткое заполнение этого шаблона снимает большую часть будущих вопросов к команде.
Частые ошибки в ТЗ
Первая ошибка - писать «как надо сделать» вместо «что должно получиться»: заказчик не обязан выбирать технологии, его дело - результат и ограничения. Вторая - смешивать обязательное и желательное: пометьте, что нужно к запуску, а что может подождать до второй версии. Третья - забыть про нефункциональные требования: без указания нагрузки и требований к данным команда заложит минимум, а потом переделка выйдет дороже. Четвёртая - не описать граничные случаи: что происходит при ошибке оплаты, потере сети, пустом списке. Именно необработанные сценарии чаще всего всплывают на приёмке.
Что делать, если ТЗ нет и непонятно, с чего начать
Если у вас есть идея, но нет ни ТЗ, ни чёткого понимания объёма - это нормально, и писать сразу детальный документ не нужно. В такой ситуации задачу решает предпроектная аналитика (discovery): команда вместе с вами превращает идею в прототип, бэклог требований и обоснованную оценку. По сути discovery и есть процесс, на выходе которого рождается ТЗ - но уже проверенное на реалистичность, а не написанное вслепую. Если вы только выбираете подрядчика, обратите внимание, готов ли он начать именно с аналитики, а не сразу называть цену за «разработку приложения» без документа.