Техническое задание на разработку ПО: как написать, пример и шаблон
Техническое задание на разработку нужно и перед заказом мобильного приложения, и перед разработкой сайта, и для тендера. Разбираем, из каких разделов состоит сильное ТЗ, как описывать требования так, чтобы по ним давали точную смету, и приводим рабочий шаблон с примерами из проектов FITTIN.
Что такое техническое задание на разработку
Техническое задание на разработку требуется в самых разных ситуациях: компания заказывает мобильное приложение, предприятие обновляет сайт, стартап готовит описание продукта для инвестора, закупочный отдел собирает тендер.
Техническое задание (ТЗ) — документ, в котором заказчик и разработчик фиксируют, какой продукт должен получиться: цели, пользователей, функции, связи с другими системами, требования к скорости и безопасности, критерии приёмки результата. По ТЗ подрядчик считает смету и сроки, стороны подписывают договор, а в конце проекта — принимают работу.
Для бизнеса документ решает четыре задачи:
- Сопоставимая смета. С ТЗ на руках несколько студий оценивают один и тот же объём, и их предложения можно сравнивать напрямую. По отзывам на странице услуги разработки ТЗ, разброс оценок одного проекта у разных студий до спецификации доходил с 2 до 8 млн ₽, а после подготовки документа расхождение сократилось до 15%.
- Основание для договора. Объём работ, сроки и порядок приёмки становятся частью договора, а не договорённостью из переписки.
- Приёмка без споров. Каждый пункт ТЗ проверяется: либо функция работает по описанию, либо нет.
- Передача проекта. По готовому документу продукт сможет развивать другая команда — требования уже собраны и записаны.
Чем крупнее продукт и чем больше в нём связей с другими системами, тем дороже обходится работа без документа: уточнение требований переносится на этап разработки, где изменение затрагивает уже макеты и код. Как устроен полный цикл от идеи до поддержки — в статье об этапах разработки ПО.
Чем техническое задание отличается от брифа
Бриф и ТЗ часто путают, потому что оба документа появляются до старта разработки. Разница в том, что бриф собирает вводные, а техническое задание фиксирует решения. Бриф заполняет заказчик в начале знакомства, ТЗ готовит аналитик после интервью и исследования.
| Параметр | Бриф | Техническое задание |
|---|---|---|
| Назначение | Познакомить подрядчика с задачей и пожеланиями | Зафиксировать объём работ, требования и критерии приёмки |
| Кто пишет | Заказчик, часто по анкете студии | Аналитик вместе с заказчиком, после интервью и исследования |
| Глубина | 2–5 страниц: цели, аудитория, общие пожелания | Десятки страниц: сценарии по ролям, интеграции, нефункциональные требования |
| Юридический статус | Не приложение к договору | Приложение к договору, основа приёмки работ |
| Точность оценки | Предварительный диапазон цен | Рабочая смета по функциям и интеграциям |
На практике бриф превращается в ТЗ по ходу предпроектной работы: интервью, анализ конкурентов, приоритизация функций. Как проходит это исследование и что остаётся у заказчика на выходе, разобрано в статье про предпроектную фазу, методы сбора данных о нише — в материале об анализе рынка и конкурентов.
Из чего состоит техническое задание: восемь разделов
Единого обязательного формата ТЗ нет: в госзакупках ориентируются на ГОСТ 34.602, в коммерческих проектах студии работают по своим шаблонам. Состав разделов при этом совпадает почти везде — без любого из восьми ниже документ не выполняет свою задачу.
| Раздел | Что описываем | Пример формулировки |
|---|---|---|
| 1. Цели и метрики | Задача бизнеса и показатели, по которым оценят результат | «20% онлайн-заказов через приложение через год после запуска» |
| 2. Аудитория и роли | Кто пользуется продуктом и какие права есть у каждой роли | «Покупатель, менеджер магазина, администратор сети» |
| 3. Функциональные требования | Сценарии: что делает пользователь и что отвечает система | «Пользователь выбирает оттенок краски, система рассчитывает цену колеровки» |
| 4. Интеграции | Внешние системы, данные, направление и частота обмена | «Каталог из учётной системы, обновление остатков каждые 15 минут» |
| 5. Нефункциональные требования | Скорость, нагрузка, платформы, безопасность, сторы | «Экран каталога открывается до 2 секунд; публикация в App Store, Google Play, RuStore и других сторах по запросу» |
| 6. Критерии приёмки | Проверяемые условия, по которым принимают работу | «Заказ на юрлицо оформляется без участия менеджера, счёт приходит на почту» |
| 7. Этапы и сроки | Разбивка на итерации с датами и точками согласования | «Прототип — к 15 марта, первая версия — к 30 мая» |
| 8. Ограничения и допущения | Что не входит в проект и на чьей стороне какие зоны ответственности | «Методы интеграции со стороны учётной системы предоставляет заказчик» |
Четыре раздела — функциональные требования, интеграции, нефункциональные требования и критерии приёмки — определяют смету сильнее всего, поэтому разберём их подробнее.
Функциональные требования: от «сделайте каталог» к сценарию
Функциональный раздел описывает, что делает продукт, через роли и пользовательские истории. Рабочий формат формулировки — «действие → данные → результат»: пользователь что-то делает, система что-то проверяет и что-то возвращает. Такую формулировку можно оценить в часах и проверить при приёмке.
Разница между пожеланием и требованием:
- Пожелание: «Сделайте удобный поиск». Требование: «Поиск по названию и артикулу, подсказки после третьего символа, выдача до 20 позиций с фото и ценой, фильтры по наличию в выбранном городе».
- Пожелание: «Нужна программа лояльности». Требование: «Бонусы начисляются за заказ, списываются до 100% стоимости, виртуальная карта добавляется в Apple Wallet и Google Pay».
- Пожелание: «Оформление заказа в пару кликов». Требование: «Корзина сохраняет адрес и получателя, способ доставки и оплаты выбирается на одном экране, повторный заказ — из истории».
Пример сложного функционального раздела — приложение сети строительных гипермаркетов «Сатурн». Для строительного ритейла в требованиях пришлось описать сценарии, которых нет в обычном интернет-магазине:
- Колеровка краски — выбор оттенка из палитры и расчёт цены услуги;
- Распил материалов — указание параметров реза при оформлении заказа;
- Доставка крупногабарита — транспорт с манипулятором, ограничения по высоте проезда, заказ грузчиков с этажом и габаритами лифта;
- Заказ на юридическое лицо — свои документы и способ оплаты;
- Региональные склады — наличие и цены привязаны к городу и учётной системе 1С.
Каждый такой пункт меняет экраны, серверную часть и смету. Если бы колеровка всплыла на этапе разработки, команда пересматривала бы карточку товара, корзину и обмен с учётной системой уже по ходу проекта. Поэтому в функциональном разделе важны не общие слова про «каталог и корзину», а специфика ниши.
Интеграции: что зафиксировать до старта
Интеграционный раздел — самый недооценённый в самодельных ТЗ. Фраза «интеграция с 1С» для сметы бесполезна: непонятно, какие данные ходят, в какую сторону, с какой частотой и кто отвечает за методы на стороне учётной системы.
Для каждой внешней системы в документе фиксируют:
- Данные — какие сущности передаются: товары, цены, остатки, заказы, клиенты, бонусы;
- Направление обмена — система отдаёт, принимает или обмен меняется двусторонним;
- Частота — в реальном времени, по расписанию, по событию;
- Ответственный за API — готовые методы интеграции (API, webhooks) есть у поставщика системы или их нужно разрабатывать;
- Поведение при сбое — что видит пользователь, если система не отвечает.
Как это выглядит в заполненном документе — на примере One Price Coffee, федеральной сети кофеен с более чем 350 точками, которые работают по франшизе. Интеграционный раздел проекта включал кассовую систему iiko (номенклатура, стоп-листы, приём заказов, часовые пояса и состояние смен), систему лояльности, эквайринг и сервис отправки SMS. По данным страницы кейса, каталог синхронизируется инкрементально — приложение забирает только изменившиеся позиции, — а стоп-листы обновляются отдельным расписанием каждые 15 минут по всем организациям сети, чтобы гость не заказал недоступный напиток. У франшизы свои реквизиты, налогообложение и доступы у каждой кофейни — и это тоже требование, которое нужно было записать до разработки.
Типовой набор интеграций для торгового приложения: учётная система (1С и аналоги), CRM и маркетинговые рассылки (Mindbox и другие), эквайринг и СБП, службы доставки (СДЭК, Boxberry, Почта России), для ресторанов — кассовые системы вроде iiko (подробнее — на странице интеграции приложения с iiko), для продаж через маркетплейсы — обмен с Wildberries, Ozon, Яндекс Маркетом. Общий подход к обмену с учётной системой описан на странице ERP-интеграции для интернет-магазина.
Нефункциональные требования
Нефункциональные требования описывают не то, что продукт делает, а то, насколько хорошо он это делает. Их заказчики забывают чаще всего, потому что эти свойства «не видно на экране». Минимальный набор для ТЗ:
- Производительность — время открытия ключевых экранов и реакции на действие;
- Нагрузка — пиковое число одновременных пользователей, например в день распродажи;
- Платформы и сторы — версии iOS и Android, перечень сторов публикации;
- Безопасность — работа с персональными данными по Федеральному закону № 152-ФЗ, роли и доступы;
- Офлайн-сценарии — что доступно без интернета;
- Доступность сервиса — допустимое время простоя и порядок мониторинга.
Два примера из проектов FITTIN. У «Сатурна» нефункциональным требованием была публикация сразу в четырёх сторах — App Store, Google Play, RuStore и AppGallery: для федеральной сети важно присутствие бренда на всех площадках, и это влияет на сборку и релизный цикл. У One Price Coffee офлайн-требованием стал QR программы лояльности: код формируется локально и показывается на кассе даже без интернета.
Роли и зоны ответственности в ТЗ
В разделе об ограничениях и ролях записывают, кто за что отвечает: кто предоставляет доступы и методы интеграции, кто готовит контент, кто согласует макеты, кто заводит учётные записи разработчика в сторах. Этот раздел экономит недели, потому что снимает ожидания «мы думали, это делаете вы».
Рабочий пример — проект Lassie, приложение для финского бренда детской одежды. Работа была разделена так: команда клиента готовила API и вебхуки — методы интеграции для передачи товаров, заказов, программы лояльности и доставки, — а команда FITTIN параллельно делала интерфейсы и приложение на Flutter. Когда методы были готовы, осталось подключить данные, и простоев не возникло. По данным страницы кейса, приложение вышло к предновогоднему сезону и собрало 3 576 установок за первые 6 недель, в пиковые дни декабря — до 376 установок в день. Такой параллельный график возможен только когда зоны ответственности и сроки по данным зафиксированы в документе заранее.
Кто вообще участвует в проекте и за что отвечает каждая роль — в статье о команде разработки.
Критерии приёмки: как зафиксировать результат
Критерий приёмки — проверяемое условие, по которому стороны понимают, что работа сделана. Общая фраза «приложение работает корректно» не критерий: её каждая сторона трактует по-своему. Критерии пишут на языке проверки: выполнил действие → получил предсказуемый результат.
| Требование | Критерий приёмки |
|---|---|
| Синхронизация стоп-листов с кассовой системой | Позиция, снятая с продажи, недоступна в приложении не позднее чем через 15 минут |
| Программа лояльности с QR на кассе | Код открывается и сканируется при выключенном интернете |
| Заказ на юридическое лицо | Покупатель указывает реквизиты, оплачивает по счёту, документы приходят на почту без участия менеджера |
| Публикация в сторах | Приложение проходит модерацию и доступно для установки во всех сторах, перечисленных в ТЗ |
По таким формулировкам тестировщики готовят проверки, а заказчик принимает работу без дискуссий. Кроме сценарных критериев в ТЗ включают общие: набор устройств для проверки, нагрузочное тестирование перед пиковым сезоном (отдельная услуга — нагрузочное тестирование), порядок приёмки по этапам.
Как написать техническое задание: шесть шагов
Порядок работы над документом одинаков для приложения, сайта и внутренней системы — различается только глубина проработки.
Шаг 1. Сформулировать цель и метрики
Что происходит: Отвечаем на вопрос, какую задачу бизнеса решает продукт и как поймём, что он удался. Метрика формулируется с цифрой и сроком: не «рост продаж», а «20% онлайн-заказов через приложение через год после запуска». Какие показатели отслеживать и чем их собирать — в статье об аналитике мобильного приложения.
Шаг 2. Собрать вводные и ограничения
Что происходит: Проводим интервью с участниками, которых затрагивает продукт: продажи, маркетинг, логистика, поддержка, ИТ-служба. Фиксируем бюджет, желаемую дату запуска, обязательные системы и требования к защите данных.
Шаг 3. Описать роли и сценарии
Что происходит: Выписываем роли и для каждой — сценарии в формате «действие → данные → результат». Сценарии раскладываем по приоритетам, обычно по методу MoSCoW (от англ. Must, Should, Could, Won't — обязательно, желательно, возможно, не в этой версии), чтобы очертить объём первой версии.
Шаг 4. Зафиксировать интеграции и нефункциональные требования
Что происходит: Для каждой внешней системы записываем данные, направление и частоту обмена, ответственного за API и поведение при сбое. Отдельно — производительность, нагрузка, версии ОС, перечень сторов, требования по персональным данным.
Шаг 5. Определить критерии приёмки
Что происходит: Превращаем ключевые требования в проверки: действие и ожидаемый результат. Договариваемся о порядке приёмки — по этапам или целиком, кто и в какой срок подписывает.
Шаг 6. Согласовать и приложить к договору
Что происходит: Документ проходит согласование у владельца продукта и всех отделов-участников, после чего становится приложением к договору. С этого момента изменения проходят через дополнительное соглашение с пересмотром сметы и сроков.
Восемь частых ошибок в техническом задании
По нашему опыту разработки приложений и сайтов, споры и перерасход бюджета чаще всего растут из восьми мест в документе:
- Расплывчатые формулировки. «Удобный», «быстрый», «современный» не проверить и не оценить — каждое свойство переводим в цифру или сценарий.
- Функции без критериев приёмки. Требование есть, а способа проверить его нет — на приёмке начинается спор о трактовке.
- Интеграции «как-нибудь». Не записано, кто отвечает за методы со стороны учётной системы, — и обмен сдвигается на неопределённый срок.
- Забытые нефункциональные требования. Производительность, нагрузка, сторы и офлайн-сценарии вспоминают после релиза, когда доработка дорожает.
- ТЗ без участия заказчика. Подрядчик написал документ в одиночку — и склад с поддержкой узнают о продукте на тестировании.
- Нет приоритетов первой версии. Все функции «обязательные» — смета раздувается, а запуск откладывается. Приоритеты по MoSCoW решают это до подписания.
- Изменения без процедуры. Новые пожелания добавляются устно, смета и сроки не пересматриваются — конфликт гарантирован.
- Копия чужого ТЗ. Документ от другого проекта тащит чужие роли, системы и ограничения — собственная специфика остаётся незаписанной.
Ещё один пласт промахов лежит на стороне заказчика за пределами самого документа — они собраны в статье об ошибках заказчика при разработке приложения.
Шаблон технического задания на разработку
Рабочий каркас, с которого начинаем документы в проектах FITTIN, — двенадцать пунктов:
- Общие сведения — название продукта, стороны, назначение документа;
- Цели и метрики — задача бизнеса и показатели успеха;
- Термины и сокращения — словарь, чтобы все читали документ одинаково;
- Аудитория и роли — пользователи и их права;
- Функциональные требования — пользовательские истории с приоритетами;
- Интеграции — системы, данные, направление, частота, ответственные;
- Нефункциональные требования — скорость, нагрузка, платформы, безопасность;
- Интерфейсы — ссылка на макеты и правила их согласования;
- Критерии приёмки — проверки по сценариям и общие условия;
- Этапы и сроки — итерации с датами и точками согласования;
- Ограничения и зоны ответственности — что не входит и кто что предоставляет;
- Порядок изменений — как новые требования попадают в документ и смету.
По такому каркасу любая студия даст сопоставимую оценку — это и есть проверка полноты шаблона. Глубина проработки зависит от продукта: для мобильного приложения критичны сторы, версии ОС и push-уведомления, для сайта — структура разделов, формы, скорость загрузки и требования поисковиков, для B2B-системы — роли, доступы и обмен с учётной системой.
Сколько стоит разработка ТЗ и кто его пишет
Три рабочих варианта авторства: документ пишет сам заказчик (подходит, когда в компании есть опытный аналитик), пишет аналитик подрядчика (самый частый сценарий — интервью и формализация требований на его стороне) или стороны делают это вместе. Во всех трёх вариантах заказчик отвечает за вводные, участие отделов и согласование.
Цены на разработку технического задания в FITTIN опубликованы на странице услуги:
| Формат | Объём документа | Стоимость и срок |
|---|---|---|
| Мини-ТЗ | Описание MVP до 20 экранов, пользовательские истории, макеты ключевых экранов | от 80 000 ₽, 2–3 недели |
| Стандартное ТЗ | Полная спецификация до 50 экранов, интерактивные прототипы, архитектура и план реализации | от 200 000 ₽, 3–4 недели |
| Комплексное ТЗ | Мультиплатформенный продукт (iOS, Android, веб-версия и административная панель), детальные контракты API, UX-исследование | от 400 000 ₽, 4–6 недель |
Срок зависит от объёма продукта и скорости согласований на стороне заказчика. Если документ готовит аналитик подрядчика по часовой оплате (Time & Materials), работа считается по ставкам ролей со страницы тарифов — со сметой и оценкой по часам перед стартом задачи.
Кейсы: как требования из ТЗ работают в реальных проектах
Три проекта FITTIN, где результат определило качество требований, зафиксированных до разработки. Цифры приведены со страниц кейсов.
«Сатурн» — 7 594 установки за первый месяц, конверсия 12,4%
Федеральная сеть строительных гипермаркетов, более 20 городов и свыше 30 000 товаров в каталоге. Колеровка красок, распил материалов, доставка с манипулятором и грузчиками, оформление на юридическое лицо, привязка к региональным складам в 1С — каждое требование описано до старта, поэтому приложение вышло одновременно для iOS и Android и опубликовано в четырёх сторах: App Store, Google Play, RuStore и AppGallery.
Lassie — 3 576 установок за 6 недель, выпуск к новогоднему сезону
Приложение финского бренда детской одежды как продолжение интернет-магазина. Команда клиента готовила API и вебхуки, команда FITTIN параллельно делала интерфейсы и приложение — к готовности методов интеграции оставалось подключить данные. Приложение вышло без простоев к предновогоднему сезону: в пиковые дни декабря — до 376 установок в день, основным драйвером стал смартбаннер на сайте.
One Price Coffee — 350+ точек на франшизе, стоп-листы каждые 15 минут
Приложение сети кофеен с предзаказом, конструктором напитка и лояльностью с QR без интернета. Интеграционный раздел включал iiko, систему лояльности, эквайринг и SMS: каталог синхронизируется инкрементально, стоп-листы обновляются каждые 15 минут по всем организациям сети, реквизиты и доступы хранятся по каждой кофейне отдельно — иначе точки франшизы не смогли бы работать в одном приложении.
Остальные проекты — в разделе кейсов.
Итог: как получить работающее техническое задание
Техническое задание окупается, когда в нём восемь разделов — цели и метрики, роли, функциональные требования, интеграции, нефункциональные требования, критерии приёмки, этапы, ограничения — написаны проверяемым языком, а не пожеланиями. Такой документ даёт сопоставимые сметы от разных студий, становится приложением к договору и убирает споры на приёмке. Для нового продукта разработка ТЗ — оптимальная первая покупка: она дешевле любой переделки на этапе кода.
Что делать дальше:
- Нужен готовый документ для оценки и договора — закажите разработку технического задания, при сложной предметной области к работе подключается бизнес-аналитик.
- Хотите сначала прикинуть бюджет разработки — посчитайте на калькуляторе, ставки и пакеты — на странице тарифов.
- ТЗ уже есть — отправьте его через форму внизу страницы, вернёмся с оценкой сроков и бюджета.
Вопросы и ответы
Что должно входить в техническое задание на разработку?
Восемь обязательных разделов: цели и метрики, аудитория и роли, функциональные требования в виде пользовательских историй, интеграции с внешними системами, нефункциональные требования (скорость, нагрузка, платформы, безопасность), критерии приёмки, этапы и сроки, ограничения и зоны ответственности. Без любого из них документ не даёт ни точной сметы, ни основы для приёмки.
Кто должен писать техническое задание — заказчик или разработчик?
Чаще всего документ готовит аналитик подрядчика: он проводит интервью, формализует требования и приводит их к проверяемому виду. Заказчик в этой работе отвечает за вводные, участие своих отделов и согласование. Если в компании есть свой опытный аналитик, ТЗ можно написать своими силами — подрядчик проверит его на полноту перед оценкой.
Чем техническое задание отличается от брифа?
Бриф собирает вводные — цели, аудиторию, пожелания — и его заполняет заказчик при знакомстве со студией. Техническое задание фиксирует решения: сценарии по ролям, интеграции, нефункциональные требования и критерии приёмки. ТЗ становится приложением к договору, бриф — нет. По брифу подрядчик даёт предварительный диапазон цен, по ТЗ — рабочую смету.
Сколько страниц должно быть в техническом задании?
Объём следует за числом сценариев и интеграций, а не за нормой страниц. Описание MVP до 20 экранов обычно укладывается в 15–30 страниц, спецификация продукта до 50 экранов — в 40–80, мультиплатформенный проект с контрактами API занимает больше сотни. Признак достаточности — по документу незнакомая с проектом студия даёт оценку без уточняющих вопросов по существу.
Сколько стоит разработка технического задания?
В FITTIN мини-ТЗ (описание MVP до 20 экранов) стоит от 80 000 ₽ и занимает 2–3 недели, стандартное (спецификация до 50 экранов с прототипами и архитектурой) — от 200 000 ₽ и 3–4 недели, комплексное (мультиплатформенный продукт с контрактами API и UX-исследованием) — от 400 000 ₽ и 4–6 недель. Актуальные составы форматов опубликованы на странице услуги разработки ТЗ.
Как написать техническое задание на разработку сайта?
Каркас тот же, что для приложения, но акценты другие: структура разделов и навигация, формы и их обработчики, требования к скорости загрузки и адаптивной вёрстке, интеграции с учётной системой и сервисами аналитики, требования поисковых систем к индексации. Для сайта с большим объёмом структурированного контента — каталога, медиа, портала — отдельным разделом описывают модель контента и права редакторов.
Можно ли начать разработку без технического задания?
Можно, если объём мал и понятен — например, доработка работающего продукта по часовой оплате. Для нового продукта без документа уточнение требований переносится на этап разработки, где изменения затрагивают макеты и код. Оптимальный путь при ограниченном бюджете — мини-ТЗ или разработка MVP с узким набором сценариев.
Что делать, если требования изменились после подписания ТЗ?
Изменения оформляют дополнительным соглашением: новое требование оценивается по часам и срокам, смета и график пересматриваются, стороны подписывают обновлённую версию раздела. Такая процедура записывается в самом ТЗ — пункт «порядок изменений» как раз и существует для этого случая.
Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации.
