Техническое задание на разработку ПО: что писать

Заказчик пишет техническое задание, чтобы получить то, что задумал. Разработчик читает то же самое ТЗ, чтобы понять, за сколько часов он это сделает и где его подстерегает неизвестность. Это два разных чтения одного документа, и расхождение между ними оплачивается из бюджета проекта.

По запросу про техническое задание на разработку программы девять из десяти материалов в топе объясняют структуру и предлагают скачать шаблон по заявке. Замер выдачи Яндекса, регион Москва, 2 сентября 2026 года. Ни один не показывает, что происходит с вашим документом после отправки подрядчику: в каком порядке его читают, какие абзацы пропускают целиком и в каком месте текста рождается цифра в коммерческом предложении.

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

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

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

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

Главное в этой механике вот что. Там, где ТЗ отвечает на вопрос однозначно, вилка узкая: 6-8 часов. Там, где формулировка допускает два прочтения, разработчик обязан заложить худшее: 6-20 часов. Он не жадничает, он защищается от разговора «мы имели в виду другое» на приемке. Каждая двусмысленная фраза в вашем тексте превращается в запас, и запас оплачиваете вы.

Вторая функция ТЗ появляется позже, в момент спора. Через два месяца работы прилетает просьба «добавить фильтр по менеджеру в отчет». Ответ на вопрос, входит это в договор или оценивается отдельно, дает не память сторон, а текст задания. Без документа побеждает тот, кто настойчивее, и обе стороны выходят из проекта недовольными.

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

Что реально читают в вашем ТЗ

Документ на 40 страниц не читают подряд. Его сканируют в поисках ответов на три вопроса, и порядок поиска почти всегда одинаковый.

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

Второй вопрос: что происходит с данными. Откуда они приходят, где хранятся, куда уходят. Здесь читают раздел про интеграции, и читают придирчиво. Фраза «интеграция с 1С» ответа не содержит: непонятно, какая конфигурация, какой обмен, кто инициатор, есть ли доступ к тестовой базе. Дальше внимание переходит на объемы: 500 записей и 5 миллионов записей это разные архитектуры, разная стоимость сервера и разный срок.

Третий вопрос: как понять, что задача сделана. Раздел с критериями приемки читают в последнюю очередь и с наибольшим интересом. Если критериев нет, приемка превратится в обсуждение вкусов, а это самый дорогой способ закрыть проект.

Теперь про то, что пролистывают. История компании, миссия, описание рынка, абзац про важность цифровизации, пожелание сделать «современно и удобно» и «как у конкурента, только лучше». Эти части занимают в среднем треть объема присланных нам заданий и не влияют на оценку ни на час.

Правило, которое экономит вам время при написании: пишите то, за чем стоит таблица в базе, экран в интерфейсе или запрос к чужому API. Все остальное можно проговорить голосом на созвоне, документ от этого станет короче и полезнее.

Обязательные разделы ТЗ для веб-проекта

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

Каждый раздел стоит писать в проверяемых формулировках. «Быстрая загрузка» проверить нельзя, «главная отдается за 1,5 секунды на 4G» проверить можно. Разница между двумя фразами это разница между спором и замером.

Если проект собирается на фреймворке и требует собственной серверной части, часть решений из разделов про данные и инфраструктуру принимается вместе с подрядчиком. Как устроен такой цикл, разобрано в материале про разработку на Laravel под ключ.

Три формата ТЗ: когда какой

Единственно правильного формата не существует, есть три сложившихся, и выбор между ними определяется не размером проекта, а тем, кто будет принимать работу.

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

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

Lite-ТЗ и user stories. Короткий документ на несколько страниц: цель, роли, список историй в формате «как менеджер, я хочу видеть заказы за период, чтобы свести отчет». Годится, когда объем работ заранее не зафиксирован и стороны договорились об оплате по часам, а не за результат целиком. При фиксированной цене этот формат опасен для обеих сторон: границы объема в нем нет.

Практический выбор выглядит так. Идете в тендер, берете ГОСТ, других вариантов нет. Заказываете систему за фиксированную цену, берите коммерческий шаблон. Проверяете идею и готовы платить за часы, хватит Lite. Диапазоны цен по рынку взяты с march-code.ru, проверено 2 сентября 2026 года.

Типичные ошибки, которые срывают оценку

Ошибки ниже собраны по заданиям, которые приходят к нам на оценку. Каждая из них либо расширяет вилку в часах, либо возвращает документ на доработку и добавляет к старту проекта неделю.

«И так далее», «по аналогии», «и тому подобное». Три самые дорогие конструкции в русском языке применительно к ТЗ. «Отчеты по продажам, по менеджерам и так далее» это неизвестное количество работы. Разработчик посчитает три отчета, вы имели в виду восемь. Разговор об этом произойдет на приемке, в худшей для обеих сторон точке.

«Как на сайте конкурента». Ссылка на чужой продукт описывает внешний вид и молчит о логике внутри. Что происходит при отмене заказа, как считается скидка, что видит менеджер и чего не видит клиент, по чужому сайту не восстанавливается. Ссылка полезна как иллюстрация к описанному, но не вместо описания.

Интеграция без доступа. Написано «обмен с CRM», не написано, есть ли у вас тестовый контур, кто выдает ключи и работает ли API вашей версии. Пока доступа нет, работа стоит, а часы аналитика на переписку с чужой поддержкой тратятся. Приложите к разделу про интеграции ссылку на документацию и имя человека, который выдает доступы.

Адаптив без макетов. «Адаптивный дизайн» в одну строку означает, что макеты либо есть, либо их придется рисовать. Это разница в десятки часов и в том, кто отвечает за внешний вид результата. Напишите прямо: макеты будут в Figma к такому-то числу, либо дизайн на стороне подрядчика.

Отсутствие объемов. Раздел про данные написан, цифр в нем нет. Каталог на 300 позиций и каталог на 300 тысяч позиций требуют разных решений по поиску, выгрузке и серверу. Без цифры разработчик закладывает средний вариант, и он может оказаться неверным в обе стороны. Требования к нагрузке и архитектуре подробнее разобраны в материале про разработку веб-сервиса и SaaS.

Смешение обязательного и желательного. В одном списке лежат вещи, без которых система не запустится, и вещи из категории «хорошо бы когда-нибудь». Оценивается весь список, цена выходит за бюджет, проект откладывается. Помечайте приоритет у каждого пункта, тогда подрядчик сможет предложить первый этап в пределах денег.

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

Сколько стоит разработать ТЗ

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

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

Заказываете ТЗ отдельно. Рыночная вилка для веб-проекта: 30 000-80 000 ₽ для простых, 80 000-200 000 ₽ для средних, до 500 000 ₽ для сложных систем (march-code.ru, проверено 2 сентября 2026 года). Плюс формата в том, что с готовым заданием можно идти к нескольким подрядчикам и сравнивать оценки на одинаковом входе. Минус в том, что аналитик, который не будет делать проект, иногда описывает то, что потом неудобно реализовывать.

ТЗ как первый этап разработки. Наш вариант работы: 2500 ₽/ч, оплата по факту, без аванса. Для типового проекта малого бизнеса это 20-60 часов аналитики, дальше начинается разработка по этому же документу. Автор задания и исполнитель совпадают, поэтому расхождение между написанным и сделанным минимально.

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

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

Частые вопросы