Техническое задание на сайт: что требует ГОСТ и чего в нём нет

Вам прислали техническое задание на сто страниц. Или наоборот — страницу с общими словами. Оба варианта плохи, и разобраться проще, чем кажется.

Стандартов два, и оба действуют

Первый — ГОСТ 34.602-2020 на автоматизированные системы. Введён с 1 января 2022 года взамен советского предшественника.

Второй — ГОСТ 19.201-78 на программы. Ему почти полвека, и он живой: в карточке Росстандарта статус «Действует», заменяющего документа нет.

Про второй часто пишут, что он отменён «как советский». Это неправда. Больше того, новый стандарт 2020 года сам на него ссылается.

Десять разделов, а не девять

В чужих статьях обычно перечисляют девять разделов. Их десять.

Общие сведения. Цели и назначение. Характеристика объектов автоматизации. Требования к системе. Состав и содержание работ. Порядок разработки. Порядок контроля и приёмки. Требования к подготовке объекта. Требования к документированию. Источники разработки.

Для сайта из этого напрямую работают примерно шесть. Остальные приходится переосмысливать или оставлять пустыми.

Пустой раздел выбросить нельзя

Вот откуда берутся стостраничные документы, которые никто не читает.

Примечание к стандарту не оставляет выбора. Если требований по разделу нет, раздел всё равно сохраняется, и в нём делается запись об отсутствии требований.

Формально это дисциплина. На практике — главы вроде «требования к транспортабельности для подвижных систем» в техзадании на корпоративный сайт.

Там же живут «требования к патентной чистоте» и «статус приёмочной комиссии» с вариантами «государственная, межведомственная, ведомственная».

Чего в ГОСТе нет вовсе

Это не мнение, это замер. Я прогнал поиск по полным текстам обоих стандартов.

Слово «макет» в стандарте 2020 года встречается один раз. И в другом смысле — про изготовление и испытание физического опытного образца.

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

«Нет техзадания — договора нет» — это миф

Утверждение звучит грозно и кочует из статьи в статью. Суды смотрят иначе.

Президиум Высшего арбитражного суда сформулировал прямо: «Отсутствие утверждённой в установленном порядке технической документации не является безусловным основанием для признания договора незаключённым».

Там же объяснено, почему техзадание всё-таки важно. Документация «определяет объём, содержание работ и другие предъявляемые к ним требования, то есть предмет договора». А предмет — существенное условие по статье 432 кодекса.

И ключевой поворот. Верховный суд разъяснил: если работы сданы и приняты, ссылаться на незаключённость уже нельзя. Пока не начали исполнять — да. После приёмки — нет.

Что техзадание делает на самом деле

Оно превращает «сделать сайт» в проверяемый перечень. Это его главная работа.

Без него спор выглядит так. Заказчик говорит, что обещали иначе. Студия говорит, что сделала как договаривались. Доказательств нет ни у кого.

С ним спор выглядит иначе. Открываем документ и сверяем пункт за пунктом.

Второе назначение — деньги. Объём работ определяет цену, а неопределённый объём при твёрдой цене означает бесконечные доделки за счёт студии.

Из чего собрать рабочее задание на сайт

Структуру стандарта можно взять как скелет и дополнить тем, чего в нём нет.

1. Цели и метрики: зачем сайт бизнесу и по чему поймём, что получилось.
2. Аудитория и сценарии: кто приходит и что должен успеть сделать.
3. Структура: перечень страниц и блоков, а не «современный дизайн».
4. Визуальная часть: макеты, ширины экранов, поведение при переполнении.
5. Контент: кто пишет тексты, кто даёт фотографии, к какому сроку.
6. Техническая часть: система управления, интеграции, счётчики, скорость.
7. Доступы: домен, хостинг, почта — у кого и когда оказываются.
8. Права на результат: кому достаются макеты и код после оплаты.
9. Правки: сколько итераций входит в цену и что считается новой задачей.
10. Приёмка: как именно фиксируется готовность.

Первые семь пунктов — это переложение стандарта на язык сайта. Последние три в стандарте отсутствуют, и именно на них разваливаются проекты.

Что происходит, когда проект уже идёт

Половина конфликтов начинается здесь, а не на старте.

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

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

Отсюда и практика этапов. Аналитика и прототип отдельным договором, реализация — следующим, когда объём уже виден. Дороже на бумаге, дешевле по факту.

Как проверить чужое задание за десять минут

Возьмите документ и ответьте на пять вопросов.

Можно ли по нему посчитать объём работ? Если нет — цена будет плавать.

Названы ли сроки и от какого события они считаются? Срок «с момента получения аванса и материалов» закон признаёт согласованным.

Сказано ли, кому достаются права на результат? Молчание здесь работает по-разному в зависимости от типа договора.

Описан ли порядок приёмки? Без него подписание акта превращается в переговоры.

Ограничено ли число правок? Безлимитные правки при твёрдой цене — это работа студии бесплатно и почти всегда конфликт.

Если на все пять ответ «нет», перед вами не задание, а презентация намерений.

Один признак хорошего задания

Он всего один, и проверяется мгновенно.

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

Из этого следует неочевидное. Задание пишется не для подрядчика, а для третьей стороны — суда, нового подрядчика, вашего же сотрудника через год.

Именно поэтому в нём так важны скучные разделы про приёмку и правки.

Идеального задания не бывает

Идеального документа не бывает. Половина проектов меняется по ходу, и это нормально: рынок и данные приходят уже после старта.

Задание нужно не для того, чтобы предусмотреть всё. Оно нужно, чтобы обе стороны одинаково понимали, что именно считается изменением и как оно оплачивается.

Отдельная оговорка: это не юридическая консультация. Формулировки, которые вы берёте в договор, стоит показать юристу.

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

Обязательно ли писать техническое задание по ГОСТу?

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

Действует ли ГОСТ 19.201-78 сегодня?

Да. В карточке Росстандарта у него статус «Действует», заменяющего документа нет. Действует редакция с изменением номер один: именно в ней появился раздел «требования к программной документации».

Сколько разделов обязательно в техзадании по ГОСТ 34.602-2020?

Десять. Причём раздел, по которому требований нет, выбрасывать нельзя: его сохраняют и вписывают туда запись об отсутствии требований.

Можно ли работать без техзадания?

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

Кто должен писать техзадание — заказчик или студия?

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

Нужен ли ГОСТ для техзадания на мобильное приложение?

Формально к программам ближе ГОСТ 19.201-78, а к системе с серверной частью и интеграциями — стандарт 2020 года. На практике для приложения берут ту же логику: цели, сценарии, экраны, состояния, приёмка. Обязателен стандарт только по контракту.

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