Перейти к содержимому
DevUzDevUz Studio

// сайт государственной организации по тендеру

Техническое задание на сайт госоргана: разбор типового ТЗ

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

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

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

Что обычно упускают в ТЗ

Роли в админке и ответственность за наполнение не описаны

Чем оборачивается. В ТЗ есть перечень разделов, но не сказано, кто и как их заполняет. Подрядчик закладывает одну учётную запись администратора и демонстрационные материалы, а у заказчика новости ведёт пресс-служба, документы выкладывает юрист, обращения граждан смотрит отдельный сотрудник. На приёмке выясняется, что разграничения прав нет, и каждый правит всё. Отдельный спор — кто переводит и публикует контент на трёх языках: подрядчик считает это работой заказчика, заказчик — частью сдачи сайта.

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

Нет требований к хостингу, резервному копированию и нагрузке

Чем оборачивается. ТЗ описывает сайт как продукт, но не как работающую услугу. Не сказано, на чьих мощностях он размещается, кто оплачивает хостинг и домен после сдачи, как часто снимаются резервные копии и сколько они хранятся. Результат: сайт принят, а через несколько месяцев после сбоя восстанавливать нечего. Отдельно всплывает нагрузка — публикация важного документа даёт наплыв посетителей, и сайт, рассчитанный на обычный день, ложится.

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

Перенос старых материалов не упомянут вообще

Чем оборачивается. У действующего сайта госоргана накоплен архив: новости за годы работы, постановления, отчёты, формы. В ТЗ про них нет ни слова — как будто сайт создаётся с нуля. Подрядчик считает цену без переноса, заказчик уверен, что архив переедет сам собой. На финальной стадии либо архив теряется вместе со ссылками, по которым на материалы ссылались извне, либо переносится авралом за счёт качества остальных работ.

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

Приёмка описана «по внешнему виду»

Чем оборачивается. Формулировка вида «сайт должен соответствовать утверждённому дизайну и работать корректно» не позволяет ни принять, ни отклонить работу. Комиссия открывает главную страницу, смотрит на неё и высказывает пожелания по цветам и расположению блоков — на этапе, когда менять их поздно. А функции, которые действительно критичны, никто не проверяет: дошло ли обращение гражданина до ответственного сотрудника, сохранилась ли форматирование документа при загрузке.

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

Доступность и скорость на телефоне не заданы измеримо

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

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

Не сказано, кому передаются исходники и доступы

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

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

Требования написаны так, что сравнить заявки невозможно

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

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

Что даёт хорошее ТЗ

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

Подрядчик считает цену по понятным границам работ и не закладывает запас на неизвестность — заявки становятся сопоставимыми.

Архив старого сайта, доступы и исходники не теряются между подрядчиками: следующая доработка начинается с передачи материалов, а не с переговоров.

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

Сколько стоит и сколько занимает

Техническое задание — от $400, 1–4 недели: цена зависит от сложности системы, архитектуры, стека и интеграций. Разработка на субподряде — по объёму контракта, оценка до подачи заявки.

ТЗ для тендера или субподряд — подробнее →

Заказчиков и закупки не называем: разбираем типовое ТЗ, а не чей-то тендер.

Готовите закупку или уже выиграли тендер?

Обсудить тендер