Ни один подрядчик не знает ваш бизнес лучше вас. Поэтому техническое задание – это не формальность и не документ, который можно делегировать и забыть, а важный этап совместной работы и отличная возможность на берегу оценить подрядчика и его подходы.
Если подойти к ТЗ внимательно, разработка становится управляемой и предсказуемой, а вот размытые формулировки, недосказанность и спорные ожидания почти гарантированно приведут к правкам, доработкам и появлению дополнительных этапов, которые легко раздувают бюджет в полтора-два раза.
Почему именно ТЗ так влияет на цену
Стоимость разработки растёт, потому что резко увеличивается:
- количество неопределённостей, которые нужно закрывать встречами и переписками
- число итераций из-за доработок
- риск неправильной архитектуры и интеграций
- объём тестирования и исправлений ближе к релизу
Самый дорогой сценарий всегда один и тот же: требования уточняются уже после того, как решение построено. В этой статье пошагово разберём все нюансы, которые нужно учитывать при составлении ТЗ.
10 ошибок ТЗ, которые чаще всего удваивают стоимость
1. «Сделайте как у них»
Фраза «хочу как у конкурента, только лучше» не является требованием. В ней нет критериев, которые можно проверить.
Как правильно? Разберите «как у них» на конкретику: какие сценарии, какие экраны, какие ограничения, какие показатели важны. И обязательно добавьте, что именно должно стать «лучше», и как это измеряется.
2. Нет бизнес-цели и метрик успеха
Если в ТЗ нет ответа на вопрос «зачем», команда будет оптимизировать «чтобы работало», а не «чтобы приносило результат». Затем начинается бесконечное «давайте ещё добавим…», потому что непонятно, что уже достаточно.
Как правильно? Укажите цели и 3-7 метрик. Подробнее про бизнес-метрики читайте в нашей предыдущей статье Как заказать разработку сайта или цифрового сервиса в 2026 году и получить бизнес-результат
3. Смешаны «базовый минимум» и «роскошный максимум»
Когда в одном списке стоят «личный кабинет» и «тёмная тема», при планировании всё выглядит одинаково важным. Итог: расползание сроков, а бизнес-результат отодвигается.
Как правильно? Разделите на Must, Should, Could. И отдельно сформулируйте MVP: что должно заработать в первой версии, чтобы приносить пользу.
4. Не описаны пользователи и сценарии
В ТЗ часто подробно описываются страницы, но не то, что человек на них должен сделать. Из-за этого получаются красивые экраны, на которых сложно выполнить задачу, которой заказчик сайта ожидает от пользователя.
Как правильно? Добавьте 5-15 ключевых сценариев в формате «кто → что должен сделать → какие шаги → что считаем успехом». Этого уже достаточно, чтобы продуктовые решения были осознанными.
5. Нет границ проекта
Опасная формулировка для подрядчика в ТЗ «Сделайте сайт под ключ». Разработка не отвечает за привлечение к вам на сайт лидов или продвижение в поисковых сервисах. UX/UI-дизайнер не создаёт контент для наполнения страниц, макеты которых он собрал.
Как правильно? Прямо напишите, что должно по вашему мнению входить в список работ. Если нет понимания, кто за что отвечает – напишите все виды задач и попросите подрядчика оценить, что из этого он может закрыть полностью, что, например, получится сделать силами проверенных партнёров. Также оцените свои силы: кто в вашей компании может генерировать контент для сайта, есть ли у вас CRM, в которую будут падать заявки из форм, проводились ли SEO-работы по сайту, собиралась ли семантика или этот процесс нужно будет строить с нуля.
6. Размытые формулировки качества
«Быстро», «удобно», «современно», «безопасно» звучит приятно, но очень субъективно. Быстро для кого, удобно по сравнению с чем, современно – это как, безопасно для чего?
Как правильно? Замените словами с цифрами и правилами. Примеры:
- производительность: LCP, TTFB, вес страниц, целевые значения для мобайла.
- доступность: базовые требования WCAG уровня A/AA, если актуально.
- безопасность: 2FA для админки, роли, журнал действий, требования к паролям.
- надёжность: бэкапы, мониторинг, SLA на поддержку.
7. Не прописаны интеграции и данные
Интеграции могут «съесть» половину бюджета. Особенно если в ТЗ нет списка систем, типов данных и правил синхронизации.
Как правильно? Пропишите для каждой интеграции: что интегрируем, в какую сторону идут данные, какие статусы и ошибки возможны, как выглядит ручной режим, кто владелец доступа и ключей.
8. Игнорирование контента и миграции
«Контент потом» почти всегда означает, что релиз сдвинется. Поэтому его наличие или отсутствие влияет на сайт сильнее, чем кажется. Он определяет структуру, логику экранов, сложность разработки и даже то, насколько сайт потом будет продавать. Когда контента нет, команда вынуждена делать предположения и закладывать запас по часам. Это почти всегда дороже и дольше.
Как правильно? Опишите источники контента, объём, формат, ответственных. Если есть перенос со старого сайта, добавьте план миграции и что будет переноситься автоматом, а что вручную.
Что является контентом для сайта и к чему нужно быть готовым заказчику – расскажем в наших следующих статьях.
9. Нет правил изменения требований
Изменения в разработке – это любые правки к договорённостям после того, как вы их уже зафиксировали и команда начала работу. Даже если фраза звучит безобидно – вроде «Добавим одну кнопку», для команды это часто цепочка действий из дизайн-работ, логики, работы с данными, а иногда их миграции, тестирования и обновления интеграций.
Как правильно? Зафиксируйте процесс change request. Что считается изменением, как оценивается влияние на сроки и бюджет, кто утверждает, как обновляется бэклог и спецификация. Также очень важно прописать в ТЗ всех, кто может инициировать изменения в проект, и в каком виде, в какой итерации.
10. ТЗ пишется «в вакууме», без участия тех, кто будет делать
Иногда ТЗ пишет только заказчик, иногда только подрядчик. И в обоих случаях есть риск перекоса: либо слишком абстрактно, либо слишком технически.
Как правильно? Лучший вариант – совместная работа. Бизнес описывает цели, ограничения, процессы и приоритеты. Команда разработки помогает формализовать, задаёт вопросы, выявляет риски, предлагает план релизов и архитектурные решения.
Из чего обязательно должно состоять ТЗ
Не нужно делать 80 страниц ради объёма. Нужно закрыть ключевые вопросы. Если коротко, хорошее ТЗ обычно включает:
- Контекст проекта – проблема, цель, что меняется после запуска
- Целевая аудитория и роли – кто пользуется, какие роли в системе, что кому доступно
- Пользовательские сценарии – основные действия, пути, критичные кейсы и исключения
- Функциональные требования – список функций по разделам с приоритетами Must/Should/Could
- Структура и интерфейсы – карта страниц, прототипы или описания экранов, логика состояний
- Данные и контент – типы сущностей, поля, источники контента, правила миграции
- Интеграции – системы, обмен данными, ограничения, ответственность за доступы
- Нефункциональные требования – скорость, безопасность, права доступа, масштабирование, совместимость
- Аналитика – какие события и цели считаем, какие отчёты нужны бизнесу, что с воронкой
- Релизы и приёмка – что входит в MVP, что во 2-3 релиз, критерии «готово», формат тестирования
- Процесс изменений и коммуникаций – как принимаются решения, кто финально утверждает, как фиксируются правки.
Если у Вас есть только часть из этого, можно стартовать с предпроектного этапа и вместе с командой разработки довести документ до рабочего.
Кто обычно пишет ТЗ
На практике чаще всего участвуют несколько ролей:
- заказчик и владелец продукта или проекта формулируют цели, приоритеты, процессы, ограничения
- бизнес-аналитик превращает это в чёткие требования и сценарии
- UX/UI-дизайнер помогает с логикой интерфейсов и прототипами
- техлид или архитектор проверяет реализуемость, интеграции и риски
- QA помогает заранее сформулировать критерии приемки
Если Вы небольшая команда без аналитика – не страшно. Важно, чтобы у требований был владелец, и чтобы они были фиксированы в одном месте, а не потерялись в чатах. Если вы понимаете, что хотели бы обсудить ТЗ по вашему проекту – напишите нам, ответим на все ваши вопросы и поможем разобраться со всеми тонкими местами вашего будущего или текущего сервиса.
Как команда разработки работает с ТЗ на всех этапах
До разработки
- уточняет цели и критерии успеха
- проводит разбор сценариев и пограничных случаев
- декомпозирует требования на задачи
- оценивает сроки и бюджет, выявляет риски
- предлагает MVP и план релизов
Во время разработки
- использует ТЗ как источник правды для решений и вопросов
- обновляет спецификацию при согласованных изменениях
- сверяет результат с критериями приёмки по каждому модулю
- параллельно готовит интеграции, контент и аналитику
Перед релизом и после
- тестирование идёт по сценариям из ТЗ, а не «на глаз»
- приемка проходит быстрее, потому что критерии зафиксированы
- для поддержки и развития ТЗ становится основой бэклога что улучшать, что измерять, какие гипотезы проверять.
Как составить ТЗ, которое экономит бюджет ещё на старте
Ниже практичный подход, который можно взять за основу тем, кто не знает, с чего начать при составлении ТЗ на разработку сайта или сервиса.
Шаг 1. Начните с результата, а не с макетов
Запишите 1-2 абзаца: какую бизнес-проблему решаем и что станет лучше через 1-3 месяца после запуска. Добавьте метрики.
Шаг 2. Опишите 5-15 ключевых сценариев
Это самая «денежная» часть. Хороший список сценариев сразу режет пустой функционал и выявляет недостающий.
Пример формата:
- пользователь выбирает услугу – оставляет заявку – получает подтверждение
- менеджер видит заявку в CRM – меняет статус – клиент получает уведомление
- администратор управляет контентом и ценами – права доступа разграничены
Шаг 3. Зафиксируйте MVP и границы разработки по итерациям
Чётко ответьте:
- что обязательно должно заработать в первой версии
- что откладываем во второй релиз
- что можно положить в бэклог и рассмотреть в будущем
Шаг 4. Сделайте список интеграций и данных
Сразу выпишите, какие системы участвуют, и кто даст доступы. Это место, где чаще всего «вдруг» появляется +30 процентов бюджета.
Шаг 5. Добавьте критерии приёмки
Для каждой ключевой функции напишите «готово, когда…». Это экономит кучу времени на финале проекта.
Шаг 6. Уберите требования из переписок и чатов
Один документ или система управления требованиями, одна актуальная версия, все изменения фиксируются только в ней. Это простой организационный шаг, который реально экономит деньги.
С применением такого подхода ваш проект будет реализован прозрачно – и по договоренностям, и по срокам, и по бюджету. Больше полезного про разработку для бизнеса в нашем тг-канале Свои в IT – подписывайтесь, чтобы быть в курсе всего, что нужно знать заказчику!
