ТЗ на разработку: как записать критерии приемки, чтобы не спорить с исполнителем

Содержание

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

Я вижу ТЗ со стороны исполнителя, студии заказной разработки. Для этой колонки я пересмотрел 26 ТЗ за 2022–2026 годы из тендеров и запросов коммерческих предложений на разработку и дизайн приложений, сайтов и корпоративных систем. В этих закупках мы участвовали или думали участвовать.

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

В 17 ТЗ из 26 часть требований откладывали до выбора исполнителя, а твердую цену договора просили сразу. Исполнитель в такой ситуации закладывает запас на неизвестное. Однажды мы подробно разобрали ТЗ и запрос заказчика и нашли работы, под которые в первой оценке не было часов: оценка в часах выросла примерно на 20% при том же сроке.

Размытое ТЗ опасно и тому, кто его написал. Если смысл условия не удается установить иначе, суд толкует его в пользу стороны, которая текст не готовила. Пока не доказано иное, считается, что текст готовил профессионал в этой сфере, в разработке это исполнитель (п. 45 постановления Пленума ВС № 49). По нашей оценке, если ТЗ подготовил заказчик и это видно из документации закупки или переписки, неясность могут истолковать в пользу исполнителя. Если ТЗ за плату написал сам исполнитель, риск на нем. В споре о мобильном приложении суд так и указал: «разработчик несет ответственность за недостатки предложенного технического задания» (решение от 01.12.2023 по делу № А56-106244/2021, ст. 716 ГК).

О чем ТЗ обычно молчит

Споры у нас иногда начинались с того, что заказчику казалось очевидным и потому не попало в ТЗ.

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

Еще посетитель мог выйти из программы терминала на рабочий стол Windows. Заказчик написал: «Конечно же именно этого требования не было в ТЗ, но такое не допускается в терминалах самообслуживания». Слова «терминал самообслуживания» он понимал как все, что бывает в терминалах, а мы как то, что перечислено в ТЗ.

Обязательно проверьте, что в вашем ТЗ описаны:

• сбои: что видит пользователь и что делает система, если пропала связь, не ответил внешний сервис, отказало оборудование;
• крайние случаи (corner cases): пустой список, нулевой баланс, первый вход без данных и пр.;
• изменение и удаление того, что пользователь уже создал;
• роли и права: кто что видит и кто что может менять;
• ограничения внешних сервисов: магазинов приложений, платежных систем, уведомлений.

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

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

Как превратить пожелание в проверяемое требование

В 14 ТЗ из 26 были слова, которые нельзя измерить, например: «современный», «интуитивный», «бесшовный», «мгновенно». Выполнено ли такое требование, каждая сторона решает по-своему, и доказать свою правоту нечем. Требование можно проверить, когда в нем есть число, условия проверки и тот, кто проверяет.

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

Какой документ главный

ТЗ, макеты экранов и смета обычно живут отдельно и часто расходятся: в наших проектах регулярно находятся функции, которые есть в макетах и не описаны в ТЗ, и наоборот. В 13 закупках из 26 противоречия были внутри одного пакета документов. Например, в одном разделе число вложений ограничено 10, в другом не ограничено вовсе.

Запишите в договоре порядок приоритета: при противоречии действует ТЗ, затем макеты, затем смета.

Как принимать работу по ТЗ

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

1. Формат замечания: номер требования из ТЗ, что получилось и как это повторить. По замечанию «не работает корзина» исполнитель не поймет, что сломалось.
2. Классы дефектов: какие ошибки не дают принять работу, какие исправляют в согласованный срок после приемки, какие заказчик принимает с отметкой в акте.
3. Число кругов замечаний. Ни в одном из проектов договоров заказчиков, которые мы видели, оно не было ограничено. Тогда приемка может тянуться сколько угодно: заказчик присылает замечания, исполнитель исправляет, заказчик находит новые. В наших шаблонах договоров повторная приемка проверяет только исправления по списку замечаний.
4. Что именно принимает акт: перечень этапов и требований. В проекте с терминалом в двух актах стояла общая формулировка «разработка программного обеспечения». Об объеме и стоимости заказчик может спорить и после подписанного акта (определение ВС № 305-ЭС23-21003). А на явные недостатки, которые можно было заметить при приемке, после акта без оговорок ссылаться уже нельзя (п. 3 ст. 720 ГК). Поэтому обеим сторонам нужен акт, из которого видно, что принято.
5. Часть работы, которую делает заказчик. Если приложение работает только с сервером или данными заказчика, договоритесь, как принимать без них и что со сроками, пока их нет (не сделана работа на стороне заказчика — например, заказчик сказал, что делает дизайн сам, и не сделал).

Образец раздела ТЗ «Порядок приемки»

Его можно взять за основу и подстроить под проект. В квадратных скобках — то, что стороны выбирают сами.

1. Результат этапа принимают по требованиям раздела [N] ТЗ. У каждого требования есть номер и способ проверки.
2. Исполнитель передает результат: ссылку на тестовую версию, доступы и перечень выполненных требований с номерами.
3. В течение [10] рабочих дней заказчик проверяет результат и подписывает акт или направляет перечень замечаний.
4. В замечании указывают номер требования, что получилось и шаги, чтобы это повторить. Замечание без ссылки на требование ТЗ считается предложением об изменении и оформляется по разделу [«Изменения»].
5. Дефекты делятся на классы:

• критический: требование не выполнено, функцией нельзя пользоваться. Этап с таким дефектом не принимают;
• значительный: требование выполнено с отклонением. Его исправляют в течение [5] рабочих дней после приемки этапа или заказчик принимает его с отметкой в акте;
• незначительный: не мешает пользоваться результатом. Его исправляют в гарантийный срок.

6. При повторной приемке проверяют только исправления по перечню замечаний и то, что могли затронуть эти исправления.
7. Если в срок из пункта 3 заказчик не подписал акт и не направил замечания, этап считается принятым.
8. В акте перечисляют номера принятых требований.

Пункт 2 нужен и для пункта 7: молчание заказчика не делает работу принятой, если исполнитель не докажет, что передал сам результат (определение ВС № 305-ЭС25-5342).

Изменения по ходу проекта

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

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

Проверочный список перед подписанием (пример)

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

Нормы и практика приведены по состоянию на 9 ноября 2026 года.