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

Техническое задание (ТЗ) может написать заказчик, исполнитель или третья сторона, которую наняли только для этого. Работа по договору подряда делается по заданию заказчика (статья 702 ГК), поэтому ТЗ - его документ: кто бы ни писал текст, утверждает и передаёт его разработчику заказчик.

Заказать ТЗ отдельно и строить своей командой стало выгоднее с тех пор, как код начали писать с ИИ-инструментами. Код дешевеет, а понимание задачи - нет. Этот путь подходит, если у вас есть кому строить (свой программист, команда или уже выбранный подрядчик) и кому принимать работу по списку. Если задача укладывается в пару недель работы программиста, отдельное ТЗ может стоить дороже самой разработки.

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

Кто пишет ТЗ: заказчик, исполнитель или третья сторона?

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

Обычный совет - писать ТЗ вместе с исполнителем. Это правда для случая, когда исполнитель уже выбран. Если вы только собираетесь выбирать или строить своими силами, ТЗ от исполнителя делает вас зависимым от него раньше, чем вы его выбрали.

Почему купить ТЗ отдельно стало выгоднее

Коротко: код с ИИ пишется быстрее, и большие компании выпускают инструменты, в которых разработка с ИИ идёт от спецификации. Узким местом стало понимание, что строить. С хорошим ТЗ своя небольшая команда работает с ИИ-помощниками и не переделывает сделанное.

С 2025 года крупные разработчики инструментов строят работу с ИИ от описания задачи. GitHub в сентябре 2025 года выпустил набор инструментов, в котором спецификация названа источником правды: при работе с ИИ именно она определяет, что будет построено. Среда разработки Kiro от Amazon из запроса сначала делает требования с критериями приёмки, потом проект и только потом список задач для ИИ.

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

Цена плохих требований известна давно. В опросе PMI 2014 года руководители проектов и бизнес-аналитики назвали плохую работу с требованиями главной причиной в 47% неуспешных проектов (это опрос мнений 2 066 практиков, замеров в нём нет). Барри Боэм и Виктор Базили в 2001 году писали, что 40-50% усилий в проектах уходит на переделку, которой можно было избежать.

Популярную цифру «ошибка в эксплуатации в 100 раз дороже, чем в требованиях, по данным IBM» лучше не повторять: опубликованного исследования IBM за ней нет. Сами Боэм и Базили писали, что разница бывает стократной у крупных систем, а для небольших некритичных - скорее 5 к 1. Но и пятикратная разница в цене исправления - повод ловить ошибки ещё в ТЗ.

Когда путь «ТЗ отдельно, разработка своими» подходит, а когда нет

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

Три вопроса, после которых понятно, нужен ли отдельный проектировщик.

Путь подходит, если:

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

Путь не подходит, если:

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

Что должно быть в ТЗ, по которому строят и принимают работу

Коротко: у каждого требования - критерий приёмки, противоречия сняты до разработки, между спорными вариантами выбрали, зная цену каждого, решения записаны с причинами. Объём страниц значения не имеет.

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

Критерий приёмки у каждого требования. В сервисе бронирования корпоративной парковки мы записали 157 требований, у каждого - источник в исходном документе и критерий, по которому работу принимают. Без критерия требование «система уведомляет о брони» можно сдать десятком способов, и все будут формально верными.

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

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

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

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

Решения с причинами и свобода исполнителю там, где она нужна. В проекте wellness-приложения мы оставили исполнителю технические детали (как части системы обмениваются данными и как устроена база), чтобы не навязывать их до выбора команды. А решения архитектора записаны вместе с причинами: исполнитель видит не только что решено, но и почему, поэтому не станет переделывать решение вслепую.

Список открытых вопросов. Честное ТЗ помечает, чего пока никто не знает, и что из-за этого нельзя начинать. Уверенный текст, в котором пробелы закрыты догадками, разработчик прочтёт как решение и построит по нему.

Государственный стандарт на ТЗ (ГОСТ 34.602-2020 для автоматизированных систем) можно использовать как список разделов, чтобы ничего не забыть. В коммерческом проекте он не обязателен: стандарты применяются добровольно. Если сослаться на него в договоре, его требования, как правило, становятся обязательными для сторон.

Как проверить ТЗ до того, как платить за разработку

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

1. Оценка двумя исполнителями. Отправьте ТЗ двум командам и попросите цену и срок. Если обе называют их после нескольких вопросов, ТЗ рабочее. Если обе возвращаются с длинным списком «а что если», эти вопросы и есть недоработки ТЗ.
2. Чтение глазами клиента. Пройдите по ТЗ как ваш клиент: заказал, передумал, отменил, заплатил дважды, вернулся через месяц. Для каждого шага должно быть написано, что делает система.
3. Проверка критериев. Возьмите пять случайных требований и спросите себя: как я проверю, что это сделано? Ответ «посмотрю, нормально ли» значит, что критерия нет.
4. Вопросы разработчика письменно. Попросите своего программиста или подрядчика в первую неделю прочитать ТЗ и прислать список вопросов. Этот список - бесплатная проверка качества ТЗ, а ответы на него нужно внести в документ.

Что записать в договорах на ТЗ и на разработку

Коротко: в договоре на ТЗ - права на документ, приёмку самого ТЗ и обязанность автора отвечать на вопросы разработчиков. В договоре на разработку - что исполнитель проверяет ТЗ в начале работы и что приёмка идёт по критериям из ТЗ.

Автор ТЗ отвечает перед заказчиком, разработчик - тоже перед заказчиком. Вопросы идут через заказчика.

Формулировки пунктов ниже стоит согласовать с юристом: многое зависит от того, как оформлен договор.

В договоре на ТЗ:

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

В договоре на разработку:

• Проверка ТЗ в начале. Закон обязывает подрядчика немедленно предупредить заказчика и приостановить работу, если он обнаружит, что переданная ему техническая документация непригодна. Если он этого не сделал, потом ссылаться на плохое ТЗ он не вправе (статья 716 ГК). Если договор оформлен как оказание услуг, эта обязанность может не действовать, поэтому запишите в договоре прямо: срок на разбор ТЗ и формат списка вопросов.
• Приёмка по критериям. Работа принимается по критериям из ТЗ. Проверяйте результат до подписания акта: кто принял работу без проверки, теряет право ссылаться на недостатки, которые можно было увидеть сразу (статья 720 ГК).
• Права на код. С фрилансером-физлицом передачу прав на код тоже нужно записать прямо, по умолчанию она не происходит.

Если строит ваша штатная команда, договора подряда нет и статья 716 не применяется. Тогда порядок «прочитали, задали вопросы письменно, получили ответы» нужно ввести самим.

Как устроена фиксированная цена и почему ей нужен понятный объём работ, мы разбирали в статье про фиксированную цену и почасовую оплату. Что записать в задании именно на CRM, есть в разборе разработки CRM на заказ.

Сколько стоит ТЗ отдельно

Коротко: отдельное ТЗ по заявленным ценам российских студий на их сайтах стоит от нескольких десятков тысяч рублей за типовой сайт до нескольких сотен тысяч за программу с архитектурой. Срок - от двух недель до двух-трёх месяцев.

Мы посмотрели заявленные цены четырёх российских студий на их сайтах на 30 сентября 2026 года:

Это цены «от», и в них по-разному входят встречи, прототипы экранов и архитектура. Сравнивайте то, что вы получите за эти деньги: будут ли критерии приёмки, список противоречий и ответы на вопросы разработчиков после сдачи.

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

Источники

• ГК РФ, статья 702: договор подряда
• Статья 716 ГК РФ: о чём подрядчик обязан предупредить заказчика
• Приёмка работ: статья 720 ГК РФ
• Права на произведения, созданные по заказу: статья 1296 ГК РФ
• Закон о стандартизации, статья 26: добровольное применение стандартов
• GitHub: разработка от спецификации с ИИ, сентябрь 2025
• Kiro: анонс среды разработки от спецификации, июль 2025
• Бригитта Бёкелер на сайте Мартина Фаулера: разбор разработки от спецификации, октябрь 2025
• PMI Pulse of the Profession: управление требованиями, 2014 (PDF)
• Боэм и Базили: Software Defect Reduction Top 10 List, 2001 (PDF)
• The Register: исследование IBM про «в 100 раз дороже» не существует, 2021

Если строить будет своя команда и нужно ТЗ, по которому её работу можно принять, напишите нам через заявку. В ответ пришлём состав работ и смету за 24 часа.