ТЗ на корпоративный портал: шаблон и чеклист — 2026

Почему 70% порталов проваливаются до первой строки кода

Мы пересмотрели 50+ технических заданий на корпоративные порталы, которые приносили клиенты. Половина — от CMS-вендоров: «установите Битрикс24 и настройте модули». Вторая половина — пустые Google Docs на три страницы, где вместо требований написано «сделайте как в Slack, но для наших». Результат одинаковый: через 4 месяца разработки бюджет удваивается, сроки улетают, а портал не решает ни одной задачи бизнеса.

Проблема не в разработчиках и не в технологиях. Проблема — в ТЗ. Точнее, в его отсутствии. Плохое техническое задание порождает цепочку: неверные оценки, пропущенные интеграции, непонятные роли пользователей, нулевое внимание к безопасности. Потом — переписывание на ходу, конфликты между заказчиком и подрядчиком, итоговая стоимость ×2–3 от первоначальной. Мы собрали шаблон, который закрывает эти дыры. 12 разделов, 80+ конкретных пунктов. Каждый — на основе реальных проектов, где мы строили корпоративные порталы для компаний от 200 до 5 000 сотрудников.

Структура хорошего ТЗ: 12 разделов

Прежде чем нырять в детали — обзор. Вот из чего состоит ТЗ, после которого подрядчик может дать точную оценку, а не «от 3 до 15 млн».

1. Общие сведения о проекте
2. Целевая аудитория и роли пользователей
3. Функциональные требования (модули)
4. Интеграции
5. Нефункциональные требования
6. Дизайн и UX
7. Безопасность
8. Инфраструктура
9. Миграция данных
10. Обучение и документация
11. Приёмочное тестирование
12. Поддержка и SLA после запуска

Если в вашем ТЗ нет хотя бы одного из этих разделов — вы получите «сюрприз» на этапе сдачи. Ниже — полный шаблон с примерами заполнения.

Полный шаблон ТЗ на корпоративный портал

1. Общие сведения о проекте

Этот раздел отвечает на вопрос «зачем вообще портал». Без него разработчик будет угадывать приоритеты.

• Название проекта: «Корпоративный портал [Название компании]» — не «Портал v2», а конкретное название, которое будет в Jira, в договоре, в актах
• Бизнес-цель: сократить время обработки внутренних заявок с 3 дней до 4 часов; снизить нагрузку на HR-отдел на 40% за счёт self-service
• Стейкхолдеры: IT-директор (заказчик), HR-директор (владелец HR-модуля), руководитель АХО (заявки), главный юрист (согласования) — с ФИО и контактами
• Границы проекта: что входит (портал, мобильное PWA, интеграция с 1С) и что НЕ входит (замена корпоративной почты, внешний сайт компании)
• Сроки: дата старта, дата MVP, дата полного запуска. Привязка к бизнес-событиям — «до 1 сентября, начало нового учебного/бизнес-цикла»
• Бюджетная вилка: хотя бы порядок. «3–5 млн» и «15–20 млн» — это разные порталы. Подрядчик без бюджета не может предложить архитектуру
• Критерии успеха: метрики, по которым через 3 месяца после запуска вы определите — портал работает или нет (DAU, среднее время обработки заявки, % сотрудников, использующих портал ежедневно)

2. Целевая аудитория и роли пользователей

Портал для 300 бухгалтеров и портал для 5 000 инженеров на производстве — это разные продукты. Роли определяют всё: от интерфейса до нагрузки.

• Количество пользователей: общее число, пиковая одновременная нагрузка (обычно 15–25% от общего числа)
• Роли: суперадминистратор, администратор подразделения, руководитель, сотрудник, внешний контрагент — с описанием, что каждая роль видит и может делать
• Матрица доступа: таблица «роль × модуль × действие (чтение/создание/редактирование/удаление/согласование)»
• Сценарии использования: 3–5 основных user stories. «Сотрудник подаёт заявку на отпуск → руководитель согласует → HR видит в реестре → 1С получает данные для расчёта»
• Устройства и среда: десктоп (какие браузеры), мобильные (iOS/Android, PWA или нативное приложение), есть ли сотрудники без стационарного рабочего места (производство, склад, выездные бригады)
• Языки и локализация: один язык или мультиязычность (филиалы в СНГ, экспаты)

3. Функциональные требования (модули)

Самый объёмный раздел. Каждый модуль описывается отдельно. Вот типовой набор для корпоративного портала крупной компании:

Авторизация и SSO

• Интеграция с Active Directory / LDAP: автоматическое создание учётной записи при появлении сотрудника в AD
• SSO через SAML 2.0 или OpenID Connect (если есть корпоративный IdP — Keycloak, ADFS, Azure AD)
• Двухфакторная аутентификация для ролей с расширенным доступом (администраторы, HR, бухгалтерия)
• Автоматическая блокировка учётной записи при увольнении (синхронизация с кадровой системой)
• Политика паролей: минимальная длина, сложность, ротация каждые 90 дней (если нет SSO)

Документооборот

• Создание, редактирование, версионирование документов (docx, xlsx, pdf) с историей изменений
• Маршруты согласования: последовательные, параллельные, с условными ветвлениями (сумма договора менее 500 000 ₽ — один согласант, свыше — три)
• Электронная подпись (КЭП/УКЭП) через КриптоПро или VipNet — если требуется юридическая значимость
• Шаблоны документов с автозаполнением реквизитов из справочников
• Полнотекстовый поиск по содержимому документов (Elasticsearch)

Новости и объявления

• Публикация новостей с возможностью таргетирования по подразделениям/филиалам/ролям
• Категории, теги, закреплённые новости
• Подтверждение прочтения: «Я ознакомлен» с фиксацией даты и времени (для приказов, регламентов)
• Комментарии, лайки, возможность отключить комментирование для отдельных публикаций
• Push-уведомления (email + браузер + мобильные)

База знаний

• Иерархическая структура разделов (wiki-формат)
• Markdown или WYSIWYG-редактор с поддержкой вставки изображений, таблиц, кода
• Версионирование статей, сравнение версий (diff)
• Права доступа на уровне раздела: «Политика ИБ» видна всем, «Инструкции для DevOps» — только IT
• Связанные документы: автоматические ссылки между статьями, граф знаний

Заявки и helpdesk

• Типы заявок: IT-поддержка, АХО, HR, юридический отдел — с отдельными формами и маршрутами
• SLA на обработку: приоритет (критический/высокий/средний/низкий) → время реакции → время решения
• Эскалация при нарушении SLA: автоматическое уведомление руководителя исполнителя
• Дашборд для руководителей: количество открытых заявок, среднее время решения, топ-5 категорий
• Оценка качества обслуживания (CSAT) после закрытия заявки

HR-модуль

• Заявки на отпуск/командировку/больничный с визуальным календарём подразделения
• Онбординг нового сотрудника: чеклист задач для HR, IT, руководителя, самого сотрудника
• Справочник льгот и компенсаций (ДМС, фитнес, обучение) с возможностью подать заявку
• Оргструктура компании с визуализацией (дерево подчинённости)
• Интеграция с личным кабинетом сотрудника: расчётные листки, справки 2-НДФЛ, графики отпусков

KPI и отчётность

• Личный дашборд сотрудника: KPI, план/факт, динамика за квартал
• Дашборд руководителя: сводка по подразделению, рейтинг сотрудников, отклонения
• Конструктор отчётов: drag-and-drop, фильтры, группировки, экспорт в Excel/PDF
• Автоматический сбор метрик из подключённых систем (CRM — продажи, helpdesk — время решения)

Корпоративный мессенджер

• Личные сообщения и групповые чаты
• Каналы подразделений (аналог Slack-каналов)
• Отправка файлов, упоминания (@username), поиск по переписке
• Статусы (онлайн, занят, в отпуске — синхронизация с HR-модулем)
• Уведомления из других модулей прямо в чат: «Ваша заявка #1234 закрыта»

Каталог сотрудников

• Поиск по ФИО, должности, подразделению, навыкам, городу
• Карточка сотрудника: фото, контакты, должность, руководитель, проекты
• Иерархия «кто кому подчиняется» с визуализацией
• Интеграция с телефонией: click-to-call из карточки

Поиск

• Единый поиск по всем модулям: новости, документы, база знаний, заявки, сотрудники
• Фасетные фильтры: по типу контента, дате, автору, подразделению
• Автодополнение, исправление опечаток, поиск по морфологии (русский язык)
• Результаты ранжируются по релевантности и дате, с учётом прав доступа (пользователь видит только то, к чему у него есть доступ)

4. Интеграции

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

• 1С (Бухгалтерия / ERP / ЗУП): синхронизация оргструктуры, кадровых данных, расчётных листков. Направление: двустороннее (заявки → 1С, статусы ← 1С). Протокол: REST API или COM-объект. Периодичность: реалтайм для заявок, раз в сутки для справочников
• Active Directory / LDAP: автоматическое создание/блокировка учётных записей, синхронизация групп и атрибутов. Направление: AD → портал (мастер-данные в AD)
• CRM-система: передача данных о клиентах и сделках для модулей, связанных с продажами. Интеграция с корпоративной CRM через REST API
• Корпоративная почта (Exchange / Postfix): отправка уведомлений, подписка на дайджесты. SMTP/IMAP
• Телефония (Asterisk / Cisco UCM): click-to-call из каталога сотрудников, запись и привязка звонков к заявкам
• BI-система (Superset / Power BI / Metabase): встраивание дашбордов в портал через iframe или API, SSO pass-through
• СКУД и системы безопасности: данные о присутствии сотрудника на рабочем месте для модуля учёта рабочего времени
• Файловое хранилище (S3 / MinIO / NextCloud): единое хранилище документов с версионированием, квотами на пользователя

5. Нефункциональные требования

Этот раздел чаще всего отсутствует в ТЗ. А потом портал «падает» в понедельник утром, когда 800 человек заходят одновременно.

• Нагрузка: количество одновременных пользователей (например, 500 concurrent sessions), количество запросов в секунду (RPS) в пиковые часы
• Время отклика: страница загружается за 1–2 секунды на канале 10 Мбит/с. API отвечает за 200 мс (95-й перцентиль)
• Доступность: 99,5% uptime (не больше 44 часов простоя в год) или 99,9% (не больше 8,7 часов)
• RPO/RTO: допустимая потеря данных (Recovery Point Objective) — например, не больше 1 часа. Время восстановления после сбоя (Recovery Time Objective) — не больше 2 часов
• Производительность поиска: полнотекстовый поиск по базе из 500 000 документов — результат за 1 секунду
• Масштабируемость: портал должен выдерживать рост числа пользователей на 30% в год без перепроектирования архитектуры

6. Дизайн и UX

• Брендбук: соответствие корпоративному стилю (цвета, шрифты, логотип). Приложить брендбук или ссылку на него
• Адаптивность: desktop (1280–1920px), планшет (768–1024px), мобильный (320–428px). Указать приоритетные breakpoints
• Accessibility (ГОСТ Р 52872-2019): если среди сотрудников есть люди с ограничениями — контрастность, навигация с клавиатуры, поддержка screen readers
• Прототипы: до начала разработки — wireframes основных экранов (Figma / Axure). Утверждение прототипов — отдельный этап с актом
• Дизайн-система: UI-kit с типовыми компонентами (кнопки, формы, таблицы, карточки) — для единообразия и ускорения разработки. Указать, есть ли существующая дизайн-система или нужно создать с нуля
• Навигация: максимум 3 клика до любой функции. Боковое меню, хлебные крошки, быстрый доступ к избранному
• Мобильное приложение: PWA (браузер с «установить на главный экран») или нативное (React Native / Flutter / Kotlin Multiplatform). PWA дешевле в 2–3 раза

7. Безопасность

Корпоративный портал содержит персональные данные сотрудников (ФИО, паспорт, ИНН, зарплата), внутренние документы, коммерческую тайну. Безопасность — не «потом допилим».

• Аутентификация: SSO + MFA для административных ролей. Блокировка после 5 неудачных попыток входа
• Авторизация: ролевая модель (RBAC) с наследованием. Каждый API-эндпоинт проверяет права доступа на уровне бэкенда, а не только на фронте
• Шифрование: TLS 1.3 для передачи данных. Шифрование чувствительных полей в базе (AES-256). Хеширование паролей (bcrypt / Argon2)
• 152-ФЗ «О персональных данных»: определить категорию ИСПДн, подготовить модель угроз, получить согласия на обработку ПД. Хранение данных — на территории РФ
• Журналирование (audit log): фиксация всех действий с чувствительными данными — кто, когда, что просмотрел/изменил/удалил. Хранение логов минимум 1 год
• Защита от OWASP Top 10: SQL-инъекции, XSS, CSRF, IDOR — подрядчик обязан провести SAST/DAST перед сдачей
• Сетевая безопасность: WAF перед порталом, сегментация сети (DMZ для фронтенда, закрытая сеть для бэкенда и БД)

8. Инфраструктура

• Хостинг: on-premise (серверы заказчика) или облако (Yandex Cloud, VK Cloud, Selectel). Указать ограничения: «данные не могут покидать контур компании» → только on-premise
• Контейнеризация: Docker + Kubernetes (или Docker Compose для MVP). Описать требования к оркестрации
• CI/CD: pipeline для автоматической сборки, тестирования и деплоя (GitLab CI / Jenkins / GitHub Actions). Окружения: dev → staging → production
• Мониторинг: Prometheus + Grafana (метрики), ELK / Loki (логи), Sentry (ошибки). Алерты в Telegram / PagerDuty
• Бэкапы: ежедневное резервное копирование БД, еженедельное — файлового хранилища. Проверка восстановления из бэкапа — раз в квартал
• Отказоустойчивость: описать требования к кластеризации. Минимум — два экземпляра приложения за балансировщиком (Nginx / HAProxy)

9. Миграция данных

Если портал заменяет существующую систему (старый интранет, SharePoint, общие папки на файл-сервере) — без этого раздела будет хаос.

• Источники: перечислить все системы, из которых нужно перенести данные (SharePoint, файловый сервер, старый портал, Excel-таблицы)
• Объём: количество документов, записей, пользователей. Оценить объём в гигабайтах
• Маппинг полей: таблица соответствия «поле в старой системе → поле в новой». Особое внимание — к полям, которых в новой системе нет
• Очистка данных: кто отвечает за чистку дублей, удаление устаревших записей, нормализацию справочников. Обычно это задача заказчика, а не подрядчика
• Тестовая миграция: обязательный прогон на staging-среде до боевой миграции. Проверка целостности и полноты данных
• Параллельная работа: период, когда старая и новая системы работают одновременно (обычно 2–4 недели)

10. Обучение и документация

• Администраторская документация: инструкции по настройке ролей, модулей, интеграций. Как добавить новый тип заявки, как настроить маршрут согласования
• Пользовательская документация: пошаговые инструкции с скриншотами для каждой роли
• Видео-инструкции: 5–10 коротких роликов (2–3 минуты) по основным сценариям
• Обучение ключевых пользователей: 2–3 очных/онлайн-сессии по 2 часа. Ключевые пользователи потом обучают остальных (train-the-trainer)
• FAQ и чат-бот: раздел частых вопросов + бот, который подсказывает «как подать заявку на отпуск»

11. Приёмочное тестирование

• Критерии приёмки: перечень функциональных требований, каждое из которых проверяется тест-кейсом. Требование считается выполненным, если тест-кейс проходит
• Нагрузочное тестирование: результаты теста при пиковой нагрузке (например, 500 одновременных пользователей). Инструмент: JMeter / Gatling / k6
• Тестирование безопасности: отчёт SAST/DAST, подтверждение устранения критических и высоких уязвимостей
• UAT (User Acceptance Testing): группа из 10–15 реальных пользователей тестирует портал 1–2 недели. Все замечания фиксируются в трекере
• Критерии блокирующих дефектов: определить, какие баги блокируют приёмку (например, «невозможно войти через SSO»), а какие могут быть исправлены после запуска
• Акт приёмки: формальный документ с подписями сторон. Без акта — проект не считается завершённым

12. Поддержка и SLA после запуска

• Гарантийный период: обычно 3–6 месяцев после подписания акта. Исправление дефектов — бесплатно
• SLA на техподдержку: время реакции и время решения по приоритетам. Критический (портал недоступен): реакция 15 минут, решение 2 часа. Высокий (модуль не работает): реакция 1 час, решение 8 часов
• Каналы поддержки: email, Telegram-бот, телефон, система тикетов
• Обновления: плановые обновления (раз в месяц), экстренные патчи безопасности (в течение 24 часов)
• Мониторинг: подрядчик следит за работоспособностью или заказчик берёт это на себя. Кто получает алерты, кто реагирует ночью
• Развитие: отдельный бюджет на доработки после запуска (time & material или фиксированные спринты)

Чеклист «Готово ли ваше ТЗ?»

20 вопросов. Если на 15+ ответ «да» — ТЗ готово к отправке подрядчику. Если меньше 10 — вернитесь к шаблону выше.

1. Бизнес-цель портала сформулирована в одном предложении?
2. Определены конкретные метрики успеха (DAU, время обработки заявок, % adoption)?
3. Перечислены все роли пользователей с матрицей доступа?
4. Описаны 3–5 основных user stories от начала до конца?
5. Указано количество пользователей и пиковая одновременная нагрузка?
6. Каждый модуль описан отдельно с перечнем функций?
7. Маршруты согласования документов задокументированы (кто, в каком порядке, условия)?
8. Перечислены все внешние системы для интеграции с протоколами и направлениями обмена?
9. Указаны требования к времени отклика и доступности (SLA)?
10. Есть требования к нагрузочному тестированию с конкретными числами?
11. Описаны требования 152-ФЗ и определена категория ИСПДн?
12. Указано, где будет размещён портал (облако / on-premise)?
13. Описаны требования к CI/CD и окружениям (dev/staging/prod)?
14. Есть план миграции данных из существующих систем?
15. Определены критерии приёмочного тестирования?
16. Указаны требования к адаптивности (какие устройства, breakpoints)?
17. Приложен брендбук или ссылка на него?
18. Описаны требования к мобильному доступу (PWA / нативное)?
19. Определён гарантийный период и SLA на поддержку?
20. Есть бюджетная вилка (хотя бы порядок)?

5 ошибок в ТЗ, которые удорожают проект в 2–3 раза

1. «Интеграции — потом»

Типичная фраза в ТЗ: «Интеграция с 1С будет реализована на втором этапе». На практике: портал запускается без связи с кадровой системой, сотрудники вводят данные вручную, через месяц никто порталом не пользуется. Второй этап начинается с переделки архитектуры, потому что интеграционный слой не был заложен. Стоимость: +40–60% к бюджету.

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

2. Роли пользователей описаны через «admin и user»

Две роли — это признак того, что ТЗ писал человек, который не разговаривал с бизнесом. В реальном портале — 5–8 ролей минимум. Без детальной матрицы доступа разработчик реализует «плоскую» модель, а потом её переделывают на ходу, когда юристы спрашивают: «Почему стажёр видит зарплаты отдела?»

3. Нет нефункциональных требований

«Портал должен быть быстрым» — это не требование. «Страница загружается за 1,5 секунды при 300 одновременных пользователях на канале 10 Мбит/с» — это требование. Без цифр подрядчик оптимизирует ровно столько, сколько считает нужным. А это обычно ноль.

4. Безопасность на уровне «SSL-сертификат»

ТЗ упоминает HTTPS — и на этом раздел безопасности заканчивается. Нет ни слова про модель угроз, 152-ФЗ, RBAC, audit log, шифрование чувствительных полей. Потом — аудит ИБ, список замечаний на 40 пунктов, 2 месяца доработок.

5. «Дизайн — на усмотрение подрядчика»

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

Что дальше

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

Мы в Новаком используем этот шаблон как основу для discovery-фазы при разработке корпоративных порталов. Обычно после заполнения шаблона клиент получает оценку с точностью ±15%, а не ±300%.

Если у вас уже есть ТЗ — присылайте. Если нет — поможем составить. На основе шаблона выше мы проведём бесплатную экспресс-оценку: стоимость, сроки, архитектура, стек. Результат — за 1 рабочий день.

Отправить ТЗ на оценку →

Или напишите нам — обсудим задачу. Строим порталы на Java/Kotlin + Spring Boot + PostgreSQL, которые выдерживают 1 000+ пользователей и интегрируются с любыми корпоративными системами. Подробнее о нашем подходе — на странице разработки корпоративных порталов. Если портал должен стать частью заказного ПО вашей компании — у нас есть опыт и с такими проектами.