Что такое ТЗ и почему проект без него проваливается

Почему разработка начинается не с кода

Когда клиент приходит с запросом «сделайте нам приложение», первый инстинкт команды — открыть редактор и начать писать код. Это ошибка, которая стоит денег.

Разработка без технического задания — это строительство дома без чертежа. Можно начать, но в какой-то момент окажется, что стены стоят не там, окна смотрят не в ту сторону, а заказчик хотел три этажа, а не два.

По данным исследований в области управления проектами, более 60% IT-проектов выходят за рамки бюджета или срываются по срокам. Главная причина в большинстве случаев одна: на старте не было зафиксировано, что именно нужно сделать.

ТЗ решает именно эту проблему. Не useless документ ради документа — а инструмент, который переводит «хочу удобное приложение» в конкретные экраны, логику, роли пользователей и критерии приёмки.

Что такое ТЗ простыми словами

Техническое задание (ТЗ) — это документ, в котором зафиксировано, что должна делать система, для кого, при каких условиях и как это будет проверяться.

Это не инструкция для программиста. Это договорённость между заказчиком и исполнителем о том, что считается готовым результатом.

Хорошее ТЗ отвечает на пять вопросов:

• Что — какие функции должна выполнять система
• Для кого — роли пользователей и их сценарии использования
• Как — логика работы, бизнес-правила, ограничения
• Где — платформы, интеграции, окружение
• Когда готово — критерии приёмки, по которым работа считается выполненной

Важно понимать: ТЗ — живой документ. Он не высечен в камне. Но изменения в нём фиксируются формально — и это защищает обе стороны.

Что происходит когда ТЗ нет

Отсутствие ТЗ — это не просто неудобство. Это системный риск, который проявляется на каждом этапе проекта.

На этапе разработки команда интерпретирует задачу самостоятельно. Разные разработчики принимают разные решения. В итоге система работает, но не так, как ожидал заказчик.

На этапе сдачи начинается «а мы думали, что будет по-другому». Это самый дорогой момент — переделки на финальной стадии стоят в 5–10 раз дороже, чем правки на этапе проектирования.

На этапе споров ни у кого нет документа, к которому можно апеллировать. Нет ТЗ — нет защиты ни для заказчика, ни для исполнителя.

Мы в DevSymfony не беремся за проекты без предпроектного анализа. Не потому что это «корпоративная бюрократия». А потому что видели слишком много проектов, где экономия на ТЗ обернулась переделкой всего продукта.

Из чего состоит хорошее ТЗ

Хорошее ТЗ — не значит длинное. Значит полное и конкретное. Вот структура, которая работает на практике:

1. Введение и цели Что за продукт, для какого бизнеса, какую проблему решает. Одна страница — не больше.

2. Целевая аудитория и роли пользователей Кто будет использовать систему. Администратор, менеджер, клиент — у каждой роли свои права и сценарии.

3. Функциональные требования Что должна делать система. Описываются через пользовательские истории: «Как [роль] я хочу [действие], чтобы [результат]».

4. Нефункциональные требования Производительность, безопасность, масштабируемость. Например: «Система должна выдерживать 1 000 одновременных пользователей».

5. Интеграции Какие внешние системы подключаются: платёжные шлюзы, CRM, карты, SMS-сервисы.

6. Ограничения и допущения Что намеренно выносится за рамки первой версии. Это защищает от scope creep — бесконечного расширения задачи.

7. Критерии приёмки По каким условиям работа считается выполненной. Конкретно, измеримо, без «мне должно нравиться».

Типичные ошибки при составлении ТЗ

Плохое ТЗ иногда хуже, чем его отсутствие — оно создаёт иллюзию договорённости там, где её нет.

Ошибка 1: расплывчатые формулировки «Удобный интерфейс», «быстрая работа», «современный дизайн» — это не требования. Это пожелания. В ТЗ должны быть цифры и критерии: «время загрузки страницы — не более 2 секунд».

Ошибка 2: отсутствие пользовательских сценариев Описать функцию недостаточно. Нужно показать, как именно пользователь с ней взаимодействует — шаг за шагом. Без этого разработчик додумывает сам.

Ошибка 3: игнорирование edge cases Что происходит, если пользователь вводит неверный пароль три раза? Что если платёж не прошёл? Что если интернет пропал в середине оформления заказа? Краевые случаи — источник большинства багов.

Ошибка 4: ТЗ написано только для разработчиков Хорошее ТЗ должен понять заказчик, дизайнер, тестировщик и разработчик. Если документ читаем только с техническим бэкграундом — он неполный.

Ошибка 5: ТЗ заморожено Рынок меняется, приоритеты меняются. ТЗ должно обновляться — но каждое изменение должно быть согласовано и задокументировано.

Кто пишет ТЗ и сколько это стоит

В профессиональных командах ТЗ составляет бизнес-аналитик или системный аналитик совместно с заказчиком. Это не односторонний процесс — хорошее ТЗ рождается из серии интервью, воркшопов и итераций.

Типичные форматы предпроектной аналитики:

Важный момент: стоимость ТЗ засчитывается в бюджет разработки при заключении договора на проект. То есть это не дополнительные расходы — это аванс на понимание.

Если подрядчик предлагает начать разработку без аналитики и ТЗ — это красный флаг. Либо опыта нет, либо деньги важнее результата.

Как выглядит ТЗ на практике: краткий пример

Возьмём конкретный кейс: клиент хочет Telegram Mini App для записи клиентов в салон красоты.

Без ТЗ задача звучит так: «Сделайте запись через Telegram».

С ТЗ это выглядит так:

Роли пользователей:

• Клиент — просматривает услуги, выбирает мастера, записывается, получает подтверждение
• Мастер — видит своё расписание, может закрыть слоты
• Администратор — управляет всеми записями, мастерами, услугами и ценами

Ключевые сценарии:

• Клиент выбирает услугу → выбирает мастера → выбирает время → подтверждает → получает уведомление в Telegram
• За 2 часа до записи клиент получает напоминание
• При отмене за менее чем 1 час — клиент видит предупреждение

Интеграции: Payme для предоплаты, Telegram Bot API для уведомлений

Вне скоупа первой версии: программа лояльности, отзывы, аналитика для владельца

Критерий приёмки: запись проходит полный цикл от выбора услуги до подтверждения менее чем за 3 минуты

Разница между «сделайте запись» и этим описанием — это разница между проектом за $2 000 и проектом за $8 000. И между продуктом, который работает, и продуктом, который переделывают три раза.

Итог

ТЗ — это не бюрократия и не формальность. Это единственный способ убедиться, что заказчик и исполнитель говорят об одном и том же продукте.

Проекты без ТЗ не проваливаются потому что разработчики плохие. Они проваливаются потому что у каждого участника в голове своя версия продукта — и никто об этом не знает до момента сдачи.

Хорошее ТЗ:

• Сокращает стоимость разработки за счёт точной оценки
• Защищает обе стороны при спорах
• Исключает «а мы думали по-другому» на финальном этапе
• Даёт команде чёткий ориентир без лишних совещаний

Правило простое: чем дороже проект — тем дороже обходится отсутствие ТЗ. Сэкономить $500 на аналитике и потерять $15 000 на переделках — классический сценарий, который мы видим регулярно.

Начинайте с ТЗ. Всегда.