Как написать ТЗ на разработку, чтобы подрядчик сэкономил ваши деньги.
О чем статья?
Вы изначально договорились на созвоне на 400 тысяч, а через неделю получили смету в 2 раза больше. Подрядчик объясняет: «Всплыли дополнительные требования». Вы же уверены, что требования были изначально. И оба правы — потому что вы говорили на разных языках.
Главная причина, по которой стоимость разработки сайта вырастает ещё до старта — не жадность исполнителя, а расплывчатые требования. Чем больше неизвестных в проекте, тем выше коэффициент страховки в смете. Хорошее техническое задание убирает эту неопределённость и экономит деньги ещё до начала работ.
В этой статье разберём, что должно быть в ТЗ, какие ошибки увеличивают бюджет, и дадим чек-лист для самопроверки.
Почему смета растёт ещё до начала работ
Как выглядит типичная цепочка переплаты
Подрядчик не завышает специально. Он просто не знает, что именно вы имеете в виду — и закладывает резерв на всякий случай. Это нормальная логика самозащиты.Вот как это работает на практике:
- Вы пишете «удобный интерфейс» → подрядчик закладывает 20 экранов вместо 8, потому что не знает, что «удобно» именно для вас.
- Вы пишете «интеграция с CRM» → разработчик оценивает 40 часов вместо 10, потому что не знает, какая CRM, насколько глубокая интеграция и нужен ли двусторонний обмен данными.
- Вы пишете «что-то вроде маркетплейса» → получаете смету с расчетом на три квартала.
Как выглядит хорошее ТЗ?
ТЗ — это ключевой инструмент для минимизации рисков, контроля бюджета и сроков, а также гарантии достижения ожидаемых бизнес-результатов.
Хорошее техническое задание отвечает на три вопроса:
- Зачем создаётся продукт — какую бизнес-задачу решает
- Кто и как им пользуется — что делает пользователь, какой путь проходит?
- По каким критериям мы примем работу — что считается готовым результатом?
Без ответа на эти вопросы каждый участник проекта держит в голове свою версию продукта. Это дорого.
Обязательные разделы ТЗ
Бизнес-цели и KPI
Начните не с функций, а с цели. Не «нам нужен сайт», а «нам нужен сайт, который генерирует 50 заявок в месяц из органического трафика» или «снижает нагрузку на менеджеров на 30% за счёт онлайн-записи».Зачем это нужно подрядчику: понимая цель, он не будет добавлять функционал, который «может быть полезным», но не приближает к результату. Каждая лишняя функция — это время и деньги.
Целевая аудитория и сценарии использования
Опишите, кто ваш пользователь и что он делает на сайте — шаг за шагом. В разработке это называют User Story (пользовательский сценарий).Пример:
«Пользователь заходит на сайт → видит каталог → фильтрует по параметрам → добавляет товар в корзину → вводит данные доставки → оплачивает картой → получает подтверждение на почту».
Без сценариев разработчик додумывает интерфейс самостоятельно. Чужая фантазия стоит денег.
Функционал и его границы
Запишите, что входит в проект. А потом — и это важнее — явно запишите, чего не будет в первом релизе.Без списка исключений подрядчик может включить в оценку «очевидные» вещи, которые вам не нужны: личный кабинет, программу лояльности, чат поддержки — потому что «на нормальных сайтах это обычно есть».
MVP — минимально жизнеспособный продукт
MVP (Минимально Жизнеспособный Продукт) — это первая версия продукта с ключевым функционалом, которая уже работает и приносит результат.Фиксируйте MVP в ТЗ явно:
Меньше объём на старте → меньше бюджет → быстрее запуск → раньше начинаете зарабатывать.
- Входит в MVP: регистрация, каталог, корзина, оплата картой.
- Вторая версия: личный кабинет, отзывы, программа лояльности, мобильное приложение.
Интеграции и внешние зависимости
Перечислите все системы, с которыми должен работать сайт: CRM, 1С, платёжные шлюзы, карты, аналитика, мессенджеры. Для каждой укажите, насколько глубокая интеграция нужна.Почему это критично: интеграция с «обычной CRM» и интеграция с кастомной 1С на устаревшей конфигурации — это разные задачи с разницей в цене в несколько раз. Если не указать — всплывёт как «доработка» в середине проекта с отдельным счётом.
Нефункциональные требования
Это требования к тому, как работает сайт, а не что он делает:Без этих требований подрядчик реализует минимально работающую версию — а потом оказывается, что под нагрузкой сайт падает или что мобильная версия не протестирована.
- Производительность: скорость загрузки до 2 секунд, одновременно до 500 пользователей.
- Безопасность: защита персональных данных, шифрование, резервные копии.
- Адаптивность: корректная работа на мобильных устройствах, перечень браузеров.
Технический стек и платформа
CMS (система управления контентом), фреймворк, хостинг — зафиксируйте или обсудите с подрядчиком и запишите в ТЗ.Важный момент: выбор технологий влияет не только на стоимость разработки, но и на стоимость поддержки. Сайт на редком стеке может обходиться дешевле сейчас, но дорого — потом, когда нужно будет найти другого разработчика или обновить систему.
Этапы, сроки и критерии приёмки
Разбейте проект на этапы с конкретными результатами и дедлайнами. Для каждого этапа пропишите критерии приёмки — как вы поймёте, что работа выполнена.Без критериев приёмки «готово» у заказчика и подрядчика означает разное. Это открытые ворота для бесконечных правок и споров, что входило в оговорённую стоимость.
Скрытые расходы
Что такое TCO — и почему дешёвый проект может стоить дорого
TCO (Total Cost of Ownership) — совокупная стоимость владения: сумма всех расходов на продукт за 3–5 лет, не только первоначальная разработка.
Что входит в TCO:
- хостинг и серверы,
- лицензии CMS и плагинов,
- техническая поддержка,
- обновления и доработки,
- обучение сотрудников.
Реальный пример: сайт на редкой CMS может обходиться значительно дороже в поддержке — не из-за качества, а потому что специалистов меньше и рынок уже. Это стоит считать заранее.
Три вопроса до договора
Ошибки, которые повышают цену
Не знаете, что писать в ТЗ
Начните с брифа, а не с документа
Не умеете писать ТЗ — и не надо уметь. Начните с ответов на 5–7 вопросов:
- Зачем вам сайт или приложение?
- Кто ваш клиент и что он должен делать на сайте?
- Что уже есть (сайт, CRM, 1С, каналы продаж)?
- Каков бюджет и желаемый срок?
- Что вам нравится у конкурентов или в других продуктах?
Хороший подрядчик помогает превратить бриф в ТЗ — это стандартная практика. Если вам предлагают написать ТЗ полностью самостоятельно и без помощи команды, задумайтесь.
Работайте с неопределённостью честно
«Не знаю» — нормальный ответ. Лучше зафиксировать «этот блок пока неясен, уточним после анализа» и поставить резерв, чем придумать несуществующие требования.Часто запуск MVP сам по себе помогает прояснить требования: вы видите, как работает продукт в реальности, и понимаете, что нужно в следующей версии — без дорогостоящей фантазии на старте.
Чек-лист перед отправкой ТЗ
Сохраните и пробегитесь по нему, прежде чем отправить ТЗ подрядчику:
- Прописаны бизнес-цели и измеримые KPI
- Описана целевая аудитория и сценарии использования (пошагово)
- Есть список функционала и явный список того, чего не будет в первом релизе
- Определён MVP с описанием, что войдёт в следующие версии
- Перечислены все интеграции с внешними системами — с детализацией
- Указаны нефункциональные требования: скорость, безопасность, адаптивность
- Зафиксирован технический стек или согласован с подрядчиком
- Проект разбит на этапы с дедлайнами и критериями приёмки
- Запрошена совокупная стоимость владения на 3 года (TCO)
- Все формулировки конкретные и проверяемые — нет «удобно», «быстро», «современно» без цифр
Если на большинство пунктов можете ответить «да» — ТЗ рабочее. Если нет — именно здесь сидят деньги, которые потом уйдут в «непредвиденные расходы».
FAQ
1. Обязательно ли писать ТЗ для небольшого сайта?
Для лендинга на 3–5 страниц — достаточно детального брифа. Для интернет-магазина, приложения или проекта с интеграциями — ТЗ обязательно. Экономия на документе всегда выходит боком на этапе правок.
2. Кто должен писать ТЗ — заказчик или подрядчик?
Оптимально — совместно: заказчик отвечает на вопросы о бизнесе, подрядчик переводит их в технические требования. Если подрядчик отказывается участвовать в формировании ТЗ — это тревожный сигнал.
3. Можно ли обойтись без ТЗ, если доверяю подрядчику?
Доверие — это хорошо, зафиксированные ожидания — лучше. Даже с проверенным партнёром ТЗ защищает обе стороны: заказчика от неожиданных счётов, подрядчика — от бесконечных бесплатных правок.
Если вы дочитали до этого места, значит, понимаете: хорошее ТЗ — это не бюрократия, а инструмент защиты вашего бюджета.
Мы помогаем заказчикам формулировать требования правильно — от первичного брифа до готового технического задания с детализированной сметой.
Напишите нам - разберём ваш проект и покажем, где можно сэкономить без потери качества.
Все статьи автора
