Что такое техническое задание на разработку ПО
Основы3 минРедакция Innovialabs
Коротко
Техническое задание — это документ, который фиксирует, что именно нужно разработать, как это должно работать и по каким критериям работа считается принятой; он защищает обе стороны от споров и лишних затрат.
Что такое ТЗ и зачем оно нужно
Техническое задание (ТЗ) — документ, в котором описано, что должна делать будущая система, для кого и как проверить, что она сделана правильно.
ТЗ превращает идею из головы заказчика в общий текст, который одинаково понимают все участники: владелец бизнеса, менеджер, дизайнер, разработчики и тестировщики.
Без ТЗ каждый держит в голове свою версию продукта. Расхождения всплывают поздно — когда уже написан код и переделка стоит дорого.
Почему ТЗ защищает обе стороны
Заказчика ТЗ защищает от ситуации «сделали не то». Если функция описана, исполнитель обязан её реализовать так, как записано.
Исполнителя ТЗ защищает от бесконечных доработок. Всё, что не входит в документ, — это новая задача, которую оценивают отдельно.
Кроме того, ТЗ позволяет:
- сравнить предложения разных подрядчиков на одной основе;
- точнее оценить сроки и бюджет;
- принять работу по понятным критериям, а не «нравится — не нравится»;
- передать проект другой команде без потери знаний.
Кто пишет техническое задание
Вариантов несколько, и каждый рабочий:
| Кто пишет | Плюсы | Минусы |
|---|---|---|
| Сам заказчик | Лучше всех знает бизнес | Часто упускает технические детали |
| Бизнес- или системный аналитик подрядчика | Знает, что нужно разработчикам | Нужно время на погружение в бизнес |
| Совместно на этапе discovery | Учитываются обе стороны | Отдельный этап работы |
На практике лучший результат даёт совместная работа: заказчик формулирует цели и процессы, аналитик переводит их в требования.
Из каких разделов состоит ТЗ
Жёсткого стандарта для коммерческих проектов нет, но хорошее ТЗ обычно включает:
- Цели проекта. Какую бизнес-задачу решаем и как поймём, что решили.
- Пользователи и роли. Кто работает с системой: клиент, менеджер, администратор — и что каждому доступно.
- Функциональные требования. Что система делает. Удобно описывать через пользовательские сценарии: «Клиент выбирает товар, добавляет в корзину, оплачивает онлайн».
- Нефункциональные требования. Скорость работы, нагрузка, безопасность, поддерживаемые браузеры и устройства, языки интерфейса.
- Интеграции. С какими системами нужен обмен данными: платёжные сервисы, CRM, 1С, службы доставки.
- Дизайн. Ссылка на макеты или требования к интерфейсу и фирменному стилю.
- Ограничения. Технологии, хостинг, требования законодательства к хранению данных.
- Критерии приёмки. Как проверяется, что каждая функция работает.
- Что не входит в проект. Этот раздел часто забывают, хотя он снимает много споров.
Как написать ТЗ, которое работает
- Пишите конкретно. Вместо «быстрый сайт» — «страница каталога открывается быстро на мобильном интернете» с понятным способом измерения.
- Избегайте двусмысленных слов: «удобный», «современный», «и т. д.». Их невозможно проверить.
- Описывайте сценарии, а не только экраны. Важно, что пользователь делает и что видит в ответ, включая ошибки.
- Нумеруйте требования. На них проще ссылаться в переписке и при приёмке.
- Добавляйте схемы и макеты. Одна схема процесса часто заменяет страницу текста.
- Считайте ТЗ живым документом. Изменения возможны, но их фиксируют и согласуют письменно.
Частые ошибки
- ТЗ на одну страницу для сложной системы — это пожелания, а не задание.
- ТЗ на сотню страниц для MVP — команда тратит месяцы на документ вместо проверки идеи.
- Описание решения вместо задачи. «Сделайте кнопку справа» хуже, чем «пользователь должен быстро повторить прошлый заказ».
- Нет критериев приёмки, поэтому сдача проекта превращается в спор.