Как заказчику составить ТЗ на разработку ПО и информационной системы: пошаговая инструкция

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

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

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

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

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

Хорошее техническое задание решает сразу три задачи: фиксирует пожелания заказчика, позволяет точно оценить бюджет и сроки, и служит аргументом в спорах между клиентом и исполнителем.

ТЗ как часть договора: юридическая сила и защита от споров

Часто ТЗ становится приложением к договору между заказчиком и подрядчиком. Это превращает документ из «пожеланий» в обязательство: в нём чётко зафиксированы объём и стоимость работ. Если по ходу проекта появляются новые пожелания — например, добавить пару функций, — эта работа отдельно оценивается и оформляется как дополнительное приложение к договору. Именно поэтому грамотно составленное ТЗ защищает обе стороны: заказчик получает гарантию результата, исполнитель — защиту от бесконечных бесплатных правок.

Кто должен разрабатывать ТЗ — заказчик или исполнитель

Три модели: пишет заказчик, пишет исполнитель, пишут вместе

На практике существуют три подхода к тому, кто занимается разработкой ТЗ.

Первый — ТЗ пишет заказчик сам. Подходит, когда внутри компании есть аналитик или технически грамотный менеджер. Плюс: вы точно передаёте своё видение. Минус: без опыта легко упустить технические нюансы, которые всплывут уже в разработке.

Второй — ТЗ пишет исполнитель. Это чаще всего оптимальный вариант: компания-разработчик учитывает и требования заказчика, и собственную экспертизу. Тогда разработка идёт быстрее, а документ получается технически корректным. Но и здесь заказчик не выпадает из процесса — он источник требований.

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

Зона ответственности заказчика: что знаете только вы

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

Роль аналитика, проджект-менеджера и архитектора

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

Таблица: Кто и за что отвечает при разработке ТЗ

Структура технического задания: из каких разделов состоит ТЗ

Универсальная структура ТЗ на разработку ПО

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

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

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

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

Это ядро любого ТЗ, и заказчику важно различать два типа. Функциональные требования отвечают на вопрос «что система делает»: например, «пользователь может записаться к мастеру по клику на свободное время в календаре». Нефункциональные описывают, «как хорошо она это делает»: скорость загрузки, надёжность, безопасность, нагрузка. Хорошее требование всегда проверяется тестом; плохое — расплывчато («удобно», «быстро») и верификации не поддаётся.

Как описать разработку дополнительного функционала в ТЗ

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

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

Шаг 1. Бриф и сбор требований заказчика

Всё начинается с брифа — короткого документа, где заказчик в общих чертах описывает, чего хочет. Затем следует серия встреч, на которых аналитик подробно расспрашивает о целях, процессах и ограничениях. На этом этапе задача заказчика — не молчать: чем полнее вы опишете контекст, тем меньше сюрпризов на приёмке.

Шаг 2. Анализ и классификация требований

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

Шаг 3. Оформление и структурирование документа

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

Шаг 4. Согласование, правки и подписание

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

Методика постановки задач программисту по ТЗ

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

Стандарты и ГОСТ на разработку ТЗ

ГОСТ 34.602-2020 для автоматизированных систем

С 1 января 2022 года действует обновлённый ГОСТ 34.602-2020 «Техническое задание на создание автоматизированной системы», пришедший на смену версии 1989 года. Он устанавливает состав, содержание и правила оформления ТЗ на создание, развитие или модернизацию автоматизированных систем и применяется прежде всего при внедрении серийных решений.

ГОСТ 19.201-78 для программных изделий

Второй стандарт — ГОСТ 19.201-78 из Единой системы программной документации. Он устанавливает порядок построения и оформления ТЗ на разработку программы или программного изделия. Серию 19 применяют, когда пишут новый программный код.

Чем ГОСТ 34 отличается от серии 19

ГОСТ 34 — про системы и их внедрение, серия 19 — про программы и код. По ГОСТ ТЗ может иметь иерархическую структуру: сначала формируется общее техническое задание на систему в целом, а затем — частные ТЗ на подсистемы, модули и комплексы задач. Итоговый документ становится своего рода «сборником»: общие требования плюс частные ТЗ на отдельные части.

Когда заказчику обязателен ГОСТ, а когда нет

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

Три формата ТЗ: ГОСТ, универсальный шаблон и визуальное Lite-ТЗ

Строгое ТЗ по ГОСТ для госзаказа и крупных ИС

Оформляется в точном соответствии с ГОСТ 34.602-2020 и ГОСТ 19.201-78. Обязательно для государственных проектов и крупных информационных систем.
Плюс — юридическая надёжность и предсказуемость; минус — трудоёмкость и объём в десятки, а то и сотни страниц.

Универсальное ТЗ для бизнес-проектов

Гибкий документ на основе внутреннего шаблона команды, который соответствует и здравому смыслу, и духу ГОСТ, но не сковывает формой. Подходит для большинства коммерческих задач: интернет-магазинов, порталов, CRM, корпоративных сервисов.

Визуальное Lite-ТЗ для MVP и мобильных приложений

Для проектов, где важна скорость, применяют визуальное ТЗ: карта экранов и связей между ними, прототипы всех экранов и user story* — описание того, что даёт пользователю каждая функция. Исполнителю понятнее, когда требования показаны «экранами» с короткими комментариями, а заказчик сразу видит, на какой результат может рассчитывать.

Таблица: как выбрать формат под свой проект

Примеры технического задания

Разбор структуры ТЗ на примере

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

Пример приложения к ТЗ по ГОСТ

В ТЗ по ГОСТ схемы, диаграммы и таблицы выносят в приложения — например, приложение с описанием пользовательских сценариев в виде диаграммы или приложение с перечнем интеграций.

Важно: любая схема сопровождается текстом, иначе читатель толкует её по-своему.

Как описать ТЗ на разработку формы или отдельного модуля

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

Инструменты и ПО для составления ТЗ

В качестве ПО для составления ТЗ подходят текстовые редакторы и вики-системы (для самого документа), инструменты прототипирования (для экранов), а также трекеры задач, куда требования превращаются в задачи для команды. Для визуального Lite-ТЗ незаменимы редакторы прототипов и онлайн-доски.

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

Типичные ошибки заказчика при разработке ТЗ

Размытые формулировки «удобно», «быстро», «красиво»

Самая частая ошибка. «Сайт должен быть удобным» — это не требование, а пожелание. Замените на измеримое: «страница каталога загружается не дольше 2 секунд при 1000 товаров».

Отсутствие критериев приёмки

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

Как заказчику проверить и принять готовое ТЗ (чек-лист)

• Понятны ли цели и назначение продукта без пояснений автора?
• Разделены ли требования на обязательные и желательные?
• Все ли функции проверяемы (есть критерий готовности)?
• Учтены ли интеграции, безопасность и нагрузка?
• Описан ли порядок контроля и приёмки?
• Зафиксированы ли сроки, этапы и порядок внесения изменений?
• Приложено ли ТЗ к договору и подписано ли обеими сторонами?

FAQ — частые вопросы о разработке ТЗ

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

Сколько стоит разработка ТЗ и от чего зависит цена?
Стоимость входит в общую смету проекта и зависит от масштаба, формата (ГОСТ дороже универсального) и глубины проработки. Для госпроектов иногда отдельно нанимают специалиста, который приводит документ к стандарту.

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

ТЗ пишут на систему в целом или на её части?
Возможны оба варианта. По ГОСТ допускается иерархия: общее ТЗ на систему плюс частные ТЗ на подсистемы и модули. Выбор зависит от масштаба проекта.

Чем ТЗ отличается от бизнес-требований и функциональных требований?
Бизнес-требования отвечают на вопрос «зачем» (цели бизнеса), функциональные — «что делает система», а ТЗ объединяет всё это в единый документ с техническими деталями, этапами и порядком приёмки.

Мнение эксперта

Дмитрий Коноваленко — совладелец и операционный директор digital-агентства MWI (входит в ТОП-10 Рейтинга Рунета). Отвечает за операционное управление компанией, бизнес-процессы, контроль качества реализации проектов и работу с ключевыми клиентами. Автор Telegram-канала «Предпринимательство и digital». Эксперт в области веб-разработки, технической архитектуры интернет-проектов и автоматизации бизнес-процессов. Практик с 15+ годами опыта в digital и e-commerce.

Техническое задание нужно составлять всегда и фиксировать в нём даже малейшие изменения от заказчика. Но перед тем как вносить новую функцию, обязательно советуйтесь с командой — насколько это реально и целесообразно. Иногда безобидная на первый взгляд правка тянет за собой серьёзную переделку архитектуры и увеличивает сроки в разы. И ещё: успех проекта на 80% определяется не тем, кто набрал документ, а тем, насколько честно и полно заказчик передал свой контекст. Аналитик задаёт правильные вопросы — но ответы есть только у заказчика.

Заключение

Хорошее ТЗ — это не бюрократия, а страховка вашего бюджета и нервов. Оно превращает «сделайте что-нибудь хорошее» в измеримый план, по которому команда работает, а вы принимаете результат без сюрпризов. Начните с малого: заполните бриф, отделите обязательные требования от желательных, пропишите критерии приёмки и сверьтесь с чек-листом из этой статьи. Если проект сложный или предстоит госзаказ — доверьте разработку ТЗ аналитику, который переведёт ваши цели на язык требований по ГОСТ.

Термины и сноски

* Бриф — короткий опросник, с которого начинается сбор требований заказчика.
* Стейкхолдер — заинтересованная сторона, чьё мнение влияет на проект и приёмку.
* User story — краткое описание функции с точки зрения пользователя.
* MVP — минимально жизнеспособная версия продукта.
* Прототип — схематичный макет экранов будущего продукта.

Категория вопроса

Что мы можем предложить?