Как составить техническое задание на разработку: пошаговая инструкция

Без ТЗ проект живёт по принципу «договорились на словах»: разработчик делает то, что понял, заказчик принимает не то, что ожидал — и начинаются переделки. Корректное техническое задание на разработку предотвращает такие ситуации и защищает обе стороны: заказчика от недоделок, исполнителя от расползания задачи. Для государственных заказов составление ТЗ регулирует ГОСТ 34.602-2020.

Из этой статьи вы узнаете, кто участвует в создании документа, из каких разделов он состоит и каких ошибок стоит избегать.

Что такое ТЗ на разработку и зачем оно нужно

Техническое задание — одновременно рабочий инструмент и юридический документ. Как рабочий инструмент оно даёт команде понимание объёма задач, бюджета и сроков. Как юридический — становится приложением к договору и фиксирует обязательства сторон.

ТЗ выполняет три ключевые функции: переводит пожелания заказчика в конкретные требования; помогает оценить бюджет и сроки до старта работ; служит арбитром при разногласиях на этапе приёмки.

Отсутствие документа запускает цепочку: расплывчатые договорённости → разное понимание результата → переделки → срыв сроков → финансовые потери. Даже небольшой проект требует хотя бы минимального ТЗ.

Кто составляет техническое задание на разработку

Главный автор и координатор — проджект-менеджер (PM) уровня мидл и выше. Он организует процесс сбора требований, пишет финальный документ и отвечает перед заказчиком за итоговый результат.

Заказчик формулирует бизнес-цели в свободной форме — в брифе, исполнитель переводит их в технический язык. Утверждает документ всегда заказчик или стейкхолдер: именно он оплачивает работу и несёт ответственность за постановку задачи.

Команда создания ТЗ: роли и задачи каждого участника

В разработке полноценного технического задания участвуют шесть ролей:

• Проджект-менеджер. Собирает требования, пишет финальный документ, координирует всех участников.
• Системный архитектор. Проектирует структуру решения, выбирает технический стек, выявляет технические риски.
• Бизнес-аналитик. Переводит бизнес-цели заказчика в функциональные требования, понятные разработчику.
• Разработчик. Оценивает реализуемость каждого требования, уточняет детали на уровне кода.
• Тестировщик. Формирует критерии приёмки и сценарии тестирования ещё на этапе документа.
• Стейкхолдер. Согласовывает и подписывает итоговый документ, несёт ответственность за постановку задачи.

Пропуск любой роли приводит к пробелам в документе: архитектор не описал техстек — смета окажется заниженной; тестировщик не добавил критерии — приёмка превратится в спор.

Структура технического задания: из чего состоит документ

Техническое задание строится как иерархический документ с 7–9 разделами. ГОСТ 34.602-2020 закрепляет девять блоков для государственных заказчиков; коммерческие проекты используют адаптированные шаблоны с аналогичной логикой.

Два раздела, которые чаще всего пропускают: критерии приёмки (бинарный чеклист «выполнено / не выполнено») и «Что НЕ входит» (явный список исключений из scope). Их отсутствие — главная причина конфликтов при сдаче проекта.

Стандартный состав технического задания: общие сведения о проекте, назначение системы, группы пользователей, функциональные требования, технический стек, ограничения и допущения, критерии приёмки, список исключений, глоссарий.

Функциональные требования и пользовательские сценарии

Функциональные требования — ядро любого ТЗ. Они описывают, что система делает: авторизация, каталог товаров, фильтры, корзина, онлайн-оплата, личный кабинет. Каждое требование формулируется конкретно и проверяемо.

Параллельно прописываются нефункциональные требования: производительность (время отклика менее двух секунд при 1000 одновременных пользователях), безопасность (шифрование, роли доступа), доступность системы по уровню SLA.

Пользовательский сценарий — это маршрут: кто → что делает → в каком порядке → какова реакция системы. Пример: «Покупатель добавляет товар в корзину → система обновляет счётчик → при переходе к оформлению показывает итоговую сумму».

В разделе «Что НЕ входит» явно фиксируются исключения: наполнение контентом, разработка SEO-стратегии, дизайн маркетинговых материалов — всё это отдельные бюджеты и договоры.

Интеграции с внешними программными интерфейсами (API) оформляются чеклистом: CRM (Bitrix24 или AmoCRM), платёжные системы, Яндекс Карты, сторонние сервисы. Каждая интеграция — отдельный пункт с описанием логики обмена данными.

Пошаговый процесс создания ТЗ: от брифа до подписания

Шаг 1 — Бриф. Заказчик описывает задачу в свободной форме: цели, аудитория, конкуренты, пожелания по интерфейсу.

Шаг 2 — Сбор требований. PM проводит встречи с заказчиком, консультируется с архитектором, аналитиком и разработчиком. На этом этапе выявляются скрытые ожидания и технические ограничения.

Шаг 3 — Составление ТЗ. PM пишет документ — самостоятельно, по шаблону или с помощью нейросети для быстрого черновика. Черновик требует обязательной адаптации под специфику проекта.

Шаг 4 — Согласование. PM презентует документ стейкхолдеру. Вносятся правки, уточняются формулировки. Может занять несколько итераций.

Шаг 5 — Подписание. ТЗ становится приложением к договору и приобретает юридическую силу. Любые изменения scope — через дополнительное соглашение.

Шаг 6 — Смета и старт разработки. На основе подписанного документа рассчитывается стоимость работ и формируется план спринтов или дорожная карта.

Типы ТЗ на разработку: ПО, сайт и информационная система

Три основных типа IT-технических заданий различаются по объёму, применяемым стандартам, составу команды и числу интеграций. Ниже — сравнение ключевых параметров.

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

Техническое задание на разработку программного обеспечения — самый объёмный из трёх типов. Специфика: описание архитектуры (клиент-сервер, микросервисы, монолит), выбор базы данных (СУБД), список внешних программных интерфейсов (API), требования к нагрузочному тестированию и условия лицензирования.

Технический стек прописывается как обязательный раздел: языки программирования, фреймворки, хостинг, СУБД. Это напрямую влияет на смету и возможность расширения команды.

Пример: ТЗ на CRM-систему включает архитектуру микросервисов, интеграцию по REST API, разграничение прав доступа по ролям (администратор, менеджер, клиент) и требования к производительности.

Для государственных заказчиков ГОСТ 34.602-2020 обязателен: стандарт задаёт девять разделов и требует документирования каждого этапа разработки. Коммерческие компании используют его как ориентир, адаптируя структуру под собственные нужды.

ТЗ на разработку сайта

Требования, специфичные для сайтов: выбор системы управления контентом (CMS) или разработка без неё, адаптивная вёрстка по принципу mobile-first, совместимость с актуальными браузерами (кроссбраузерность), скорость загрузки и базовые SEO-требования.

Состав документа: количество и типы страниц, дизайн-система (шрифты, цвета, сетка), требования к хостингу и SSL. Интеграции прописываются отдельно: CRM, платёжные системы, Яндекс Карты, системы аналитики.

Пример: ТЗ на интернет-магазин включает каталог на 200 позиций с фильтрами по категориям и цене, корзину, оплату картой через эквайринг, интеграцию с 1С для синхронизации остатков и адаптивный интерфейс для смартфонов.

ТЗ на разработку информационной системы

Техническое задание на информационную систему (ИС) работает на корпоративном или государственном уровне. Обязательные элементы: разграничение ролей пользователей, уровни доступа, параметры доступности по SLA и время восстановления после сбоев.

Требования к безопасности: шифрование данных в хранилище и при передаче, поддержка протоколов LDAP или SSO для корпоративной аутентификации, стратегия резервного копирования и план аварийного восстановления.

ГОСТ 34.602-2020 обязателен для корпоративных и государственных ИС. Объём документа — от 50 страниц; к работе подключаются системный архитектор и бизнес-аналитик.

Шаблон технического задания: образец для немедленного использования

Базовый шаблон технического задания на разработку включает семь разделов:

1. Общие сведения — название проекта, заказчик, исполнитель, версия документа, дата.
2. Назначение — бизнес-цель и проблема, которую решает система.
3. Пользовательские группы — кто работает с системой и какие задачи решает каждый тип пользователя.
4. Функциональные требования — полный перечень функций с приоритетами: обязательно / желательно / в следующей версии.
5. Технический стек — языки, фреймворки, СУБД, хостинг, внешние сервисы.
6. Ограничения и допущения — бюджетные рамки, сроки, технические ограничения.
7. Критерии приёмки и исключения — чеклист «выполнено / не выполнено» + явный список того, что НЕ входит в scope.

Пример критерия приёмки: «Форма обратной связи принята, если данные передаются в CRM за менее двух секунд и пользователь получает подтверждение на почту». Такая формулировка исключает двусмысленность при сдаче.

Шаблон адаптируется под тип продукта: для сайта добавляется раздел с CMS и дизайн-системой, для ПО — архитектурная схема, для информационной системы — требования к безопасности и SLA.

Если хотите профессионально составлять технические задания — программы «Системный аналитик: с нуля до проектирования систем» и «Специалист по информационным системам: от организации до сопровождения ИТ-проектов» дают именно эти компетенции.

Частые ошибки при составлении технического задания

Расплывчатые формулировки запускают цепочку: двусмысленность → разное понимание результата → конфликт при приёмке. Пример: «Сделайте красиво» → превращается в «Логотип в векторном формате, три цветовых варианта, стиль — минимализм».

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

Agile или Waterfall: как методология влияет на ТЗ

Методология определяет тип, объём и ритм обновления документа. В Waterfall техническое задание пишется один раз и становится контрактным обязательством. В Agile документ живёт — обновляется вместе с продуктом и отражает актуальный scope каждого спринта.

Нейросеть для составления ТЗ: как ускорить подготовку документа

Нейросеть помогает сформировать черновик технического задания за несколько минут. Рабочий процесс: заказчик или PM описывает задачу → нейросеть генерирует структурированный черновик → PM адаптирует под специфику бизнеса → документ уходит на согласование.

Преимущества: скорость и готовая структура. Особенно полезно для малого бизнеса без штатного аналитика.

Ограничения: нейросеть не знает специфики проекта, не несёт юридической ответственности и не заменяет экспертизу PM. Черновик — отправная точка, не финальный документ.

Рабочий промпт: «Составь техническое задание для [тип продукта] по структуре ГОСТ 34.602-2020, включая функциональные требования, технический стек и критерии приёмки».

Программа «Системный аналитик: с нуля до проектирования систем» за 72 часа даёт компетенции в сборе требований, проектировании систем и составлении технической документации. Программа «Специалист по информационным системам: от организации до сопровождения ИТ-проектов» за 144 часа охватывает полный цикл — от ТЗ до сопровождения готового продукта. Смотрите каталог доступных программ.

Часто задаваемые вопросы

Как правильно написать техническое задание для программиста?

Укажите цель проекта, функциональные требования (авторизация, каталог, фильтры, API), выбранный технический стек, критерии тестирования и сроки поэтапной сдачи. Формулируйте каждую функцию бинарным критерием — «работает / не работает». Избегайте фраз «нужен современный интерфейс»: они не проверяемы и гарантируют конфликт при приёмке.

Кто должен писать ТЗ — заказчик или исполнитель?

Составляют совместно: заказчик формулирует бизнес-цели, PM переводит их в технические требования, системный архитектор добавляет детали реализации. Утверждает всегда заказчик — он оплачивает работу и несёт ответственность за постановку задачи.

Нужно ли ТЗ для небольшого сайта?

Для проектов до 20 часов разработки достаточно таблицы требований. Для более сложных — полное ТЗ обязательно. Даже минимальный согласованный документ защищает обе стороны: заказчика от недоделок, разработчика от бесконечных правок без оплаты.

Как составить ТЗ по ГОСТ 34.602-2020?

Стандарт требует девяти разделов: введение, основания для разработки, назначение, требования к программному обеспечению, требования к документации, технико-экономические показатели, этапы разработки, процесс контроля и приёмки, приложения. Обязателен для государственных заказчиков; коммерческим рекомендован как ориентир.

Что такое частное техническое задание?

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

Чем ТЗ на сайт отличается от ТЗ на программное обеспечение?

ТЗ на сайт включает требования к CMS, адаптивности, кроссбраузерности и скорости загрузки. ТЗ на ПО акцентирует архитектуру, СУБД, API и нагрузочное тестирование. Для государственных заказчиков в обоих случаях применяется ГОСТ 34.602-2020.

Что входит в критерии приёмки?

Бинарный чеклист: каждый пункт либо выполнен, либо нет. Пример: «Форма передаёт данные в CRM за менее двух секунд» или «При пустом поле email выводится сообщение об ошибке». Критерии согласовываются до старта работ и фиксируются в ТЗ.

Как составить ТЗ для дизайнера на дизайн-проект?

Укажите бизнес-информацию (целевая аудитория, стилистика компании), технические требования (форматы AI/PNG/PDF, цветовые модели CMYK и RGB), референсы — что нравится и что нет, площадки применения (сайт, полиграфия, социальные сети). Пример: «Фирменный стиль, минимализм, три цветовых варианта, веб и печать».

Что указывают в ТЗ на разработку логотипа?

Формат (векторный AI/SVG), цветовые варианты (монохром, цветной, обратный), охранная зона, цветовые схемы (CMYK для печати, RGB для экрана), стилистика (строгий, минималистичный, игровой) и площадки применения (визитки, вывеска, социальные сети).

Как проверить ТЗ перед передачей разработчику?

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

Хотите профессионально управлять IT-проектами и составлять технические задания на разработку? В рамках федерального проекта «Активные меры содействия занятости» нацпроекта «Кадры» можно освоить востребованные IT-профессии — без оплаты и без отрыва от работы.