// портал онлайн-услуг для граждан и компаний

Техническое задание на портал онлайн-услуг: что обычно упускают заказчики

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

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

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

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

Услуги перечислены названиями, без маршрута заявления

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

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

Не описан вход в личный кабинет

Чем оборачивается. Если способ входа не зафиксирован, подрядчик закладывает один вариант (например, простую регистрацию по телефону), а на приёмке выясняется, что требовался вход через OneID или с ЭЦП. Это не доработка интерфейса, а другая архитектура аутентификации и другие сроки.

Как написать правильно. В разделе входа явно указать: какие способы авторизации обязательны (OneID, ЭЦП, номер телефона с подтверждением), для каких категорий пользователей — граждан, компаний, какие данные система получает при входе и откуда.

Интеграции названы, но не описаны

Чем оборачивается. Фраза «интеграция с системой ведомства X» ничего не говорит о формате обмена данными, протоколе, частоте запросов и о том, кто должен открыть доступ к тестовой среде. Подрядчик узнаёт это в процессе разработки, когда сроки уже согласованы, и ждёт ответа от третьей стороны, на которую не влияет.

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

Нет требований к хранению персональных данных

Чем оборачивается. Портал работает с заявлениями, в которых — паспортные данные, адреса, часто сведения о компаниях. Без требований к хранению и защите этих данных подрядчик выбирает архитектуру сам, а на приёмке или при проверке регулятором выясняется, что она не соответствует ожиданиям заказчика.

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

Нагрузка в пиковые дни не оценена

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

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

Нет описания, что считается готовой и принятой системой

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

Как написать правильно. Прописать конкретные критерии приёмки по каждой услуге и интеграции, а также сценарии тестирования, которые должны быть пройдены до подписания акта.

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

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

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

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

Разработка такого ТЗ — отдельный этап перед закупкой, и его стоит делать до объявления тендера, а не параллельно с ним.

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

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

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

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

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

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