Техническое задание на разработку программного обеспечения описывает, что должна делать система, для кого, с какими ограничениями и как вы примете результат. В хорошем ТЗ есть цели проекта, роли пользователей, сценарии работы, требования к интеграциям, данным и безопасности, а также критерии приёмки. Если исполнитель может по документу оценить работу, а вы можете по нему проверить готовый продукт, ТЗ выполняет свою задачу.
Зачем нужно ТЗ, если есть договорённости на словах
Устные договорённости расходятся уже через месяц: каждый помнит свою версию. ТЗ фиксирует общую картину и защищает обе стороны.
Что включить в техническое задание
Состав зависит от проекта, но для большинства заказных систем подходит такой набор разделов.
ГОСТ или свободная форма
В России для ТЗ есть два известных стандарта. ГОСТ 34.602-2020 описывает техническое задание на создание автоматизированной системы, ГОСТ 19.201-78 относится к ТЗ на программу. Государственные заказчики и крупные компании часто требуют оформление по ГОСТ 34.
Для коммерческого проекта строгий ГОСТ обычно не обязателен. Разделы стандарта полезны как чек-лист, чтобы ничего не забыть, но толстый документ с общими формулировками хуже короткого ТЗ с конкретными сценариями. Выбирайте форму под проект: для небольшого сервиса хватит короткого документа, для системы с десятком интеграций он будет заметно больше.
Кто пишет ТЗ и как это организовать
Есть три рабочих варианта.
Если вы только начинаете проект, удобно сначала договориться о небольшом этапе аналитики. По его итогам у вас будет ТЗ, оценка и понимание, стоит ли продолжать с этим подрядчиком.
Типичные ошибки в ТЗ
Как проверить готовое ТЗ
Перед подписанием прочитайте документ глазами трёх людей. Пользователь должен узнать в сценариях свою работу. Разработчик должен понять, что делать, без устных пояснений. Тот, кто будет принимать проект, должен по каждому требованию сказать, как проверит его выполнение. Если хотя бы на один из этих вопросов ответ «не уверен», раздел стоит доработать. Полезно также попросить подрядчика оценить ТЗ по разделам: вопросы и допущения в оценке сразу покажут, где описание неполное.
Как ТЗ меняется в гибкой разработке
При работе спринтами подробное ТЗ на весь проект заранее не пишут. Вместо него ведут бэклог: список требований и пользовательских историй с приоритетами. При этом базовая часть остаётся обязательной: цели, роли, ключевые сценарии, интеграции, нефункциональные требования и правила приёмки каждого спринта. Без этого гибкий процесс быстро теряет направление.
Если вы проверяете идею и хотите быстрее выйти на рынок, начните с описания первой версии продукта. Об этом подходе мы писали в статье о том, что действительно нужно первой версии.
Частые вопросы
Сколько времени занимает подготовка ТЗ?
Зависит от размера системы и от того, насколько вы уже описали свои процессы. Для небольшого сервиса хватает нескольких встреч и короткого этапа аналитики, для крупной системы с интеграциями работа идёт дольше. Точнее подрядчик скажет после первого интервью.
Можно ли начать разработку без ТЗ?
Можно, если вы работаете спринтами и готовы регулярно участвовать в проекте: формулировать задачи, смотреть результаты, принимать решения. Но цели, роли и ключевые сценарии всё равно стоит записать до старта, иначе оценка и сроки будут условными.
Чем ТЗ отличается от технического проекта?
ТЗ отвечает на вопрос «что должна делать система». Технический проект описывает, как именно её построить: архитектуру, структуру базы данных, протоколы обмена. Обычно технический проект готовит исполнитель после согласования ТЗ.
Кому принадлежит ТЗ, если его написал подрядчик?
Это определяет договор. Если аналитика оформлена отдельным этапом и вы его оплатили, разумно закрепить права на документ за собой. Тогда вы сможете продолжить проект с любой командой.
Нужно ли прикладывать ТЗ к договору?
Да. Обычно ТЗ оформляют приложением к договору, и на него ссылаются при приёмке работ. Изменения требований в ходе проекта согласуют дополнительными соглашениями или в порядке, который описан в договоре.
Что ещё почитать
Мы занимаемся заказной разработкой и программными интеграциями и начинаем проекты с анализа задачи: помогаем сформулировать требования, готовим ТЗ и оценку. Если вы планируете систему и хотите обсудить задачу, напишите нам.