Корпоративный портал: 12 требований до старта разработки

Практический чек‑лист, который экономит бюджет и нервы: что зафиксировать ДО того, как дизайнер нарисует первый экран, а разработчик откроет репозиторий.

Корпоративный портал почти всегда стартует как «сделаем удобнее», а ломается на мелочах: не договорились о ролях, не описали процессы, интеграции вспомнили на 70% готовности, безопасность «прикрутили» после, а поддержка оказалась вне бюджета. Ниже — 12 требований, которые нужно закрыть до старта, если вы хотите предсказуемый проект, а не бесконечный «переделать ещё чуть‑чуть».

Что считаю «требованием» (и что именно надо фиксировать)

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

Минимальный набор артефактов (если их нет — риск перерасхода почти гарантирован)

Дальше — 12 требований, из которых эти артефакты обычно и собираются.

12 требований до старта разработки

1. Цель портала и границы продукта (что НЕ делаем)

• Сформулировать 2–3 бизнес-цели в измеримых терминах: сократить время согласований, снизить число ручных запросов в почту/мессенджеры, ускорить онбординг.
• Определить «границы»: какие процессы остаются в почте/1С/CRM, а какие переезжают в портал.
• Зафиксировать KPI на 3–6 месяцев после запуска: например, доля заявок, проходящих через корпоративный портал; среднее время обработки; процент задач без возврата на доработку.

2. Владелец продукта и матрица стейкхолдеров (кто принимает решения)

• Назначить одного product owner с правом финального решения по приоритетам и спорным вопросам.
• Список стейкхолдеров: HR, бухгалтерия, юристы, ИТ, продажи, филиалы — и что каждому нужно от портала.
• Правило изменений: кто и как добавляет требования в бэклог, кто утверждает, как фиксируются компромиссы.

3. Портреты пользователей и роли (RBAC), включая филиалы и подрядчиков

• Составить перечень ролей: сотрудник, руководитель, HR, бухгалтерия, админ, внешний подрядчик и т.д.
• Для каждой роли: какие разделы видит, какие действия может делать, какие данные недоступны.
• Отдельно: увольнение/перевод/отпуск — как меняются права автоматически, и кто отвечает за актуальность оргструктуры.

4. Инвентаризация процессов и выбор MVP (первые 6–10 сценариев)

• Собрать список процессов, которые реально «болят»: заявки (отпуск/командировка/доступы), согласования документов, onboarding, обучение, сервис-деск, закупки.
• Отобрать MVP: 6–10 сценариев, которые дадут эффект в первый релиз; остальное — в бэклог.
• Для каждого сценария: входные данные, участники, шаги, SLA, условия отказа, уведомления, результат.

5. Данные и интеграции: источники истины, частота обмена, ответственность

• Нарисовать схему систем: 1С, CRM, AD/LDAP, кадровая система, телефония, BI, файловые хранилища.
• Определить master data: где «истина» по сотрудникам, контрагентам, договорам, товарам, заявкам.
• Указать режимы: realtime/по расписанию/ручной импорт, форматы (API, вебхуки, файлы), требования к журналированию ошибок.

6. Выбор платформы и стратегия кастомизации (Bitrix24 vs заказная разработка)

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

7. Контент-модель и поиск: документы, база знаний, версии и права

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

8. UX и «сервисный дизайн»: сценарии, мобильность, уведомления, доступность

• Топ-10 пользовательских путей (user journeys): «создать заявку», «найти регламент», «пройти курс», «согласовать документ».
• Мобильность: обязательные функции на телефоне, push/почта/мессенджер, офлайн-режим (если нужен).
• Порог входа: сколько кликов до ключевого действия, единый стиль форм, понятные статусы.

9. Нефункциональные требования: нагрузка, доступность, RPO/RTO, мониторинг

• Профиль нагрузки: число пользователей, пиковые периоды, тяжёлые отчёты, объём файлов.
• Доступность: целевой аптайм, окна обслуживания, что считается критическим инцидентом.
• Резервирование и восстановление: RPO/RTO для портала и интеграций; обязательный мониторинг и алерты.

10. Информационная безопасность и персональные данные: «по умолчанию закрыто»

• SSO (AD/LDAP/SAML/OAuth) и MFA, политика паролей, управление сессиями.
• Логи и аудит действий: кто что просмотрел/изменил, хранение логов, доступ к логам.
• Персональные данные и документы: категории данных, маскирование, разграничение по подразделениям, DLP при необходимости.

11. Критерии приёмки: тест‑кейсы, качество данных, миграция, обучение

• Definition of Done: что должно быть готово, чтобы функция считалась выполненной (включая документацию и тесты).
• План миграции: какие данные переносим, из каких источников, кто чистит и сверяет, как откатываемся.
• Обучение: инструкции, короткие видео/гайд, сценарии для первой линии поддержки.

12. Эксплуатация и развитие: SLA, линия поддержки, релизы, управление изменениями

• Кто принимает заявки от пользователей, где очередь задач, какие уровни критичности и сроки реакции.
• Релизный цикл: частота, этапы (dev → test → stage → prod), ответственность, контроль качества.
• Бюджет и правила развития: что входит в абонентскую поддержку, что оценивается отдельно, как приоритезируем бэклог.

Быстрая самопроверка: 7 красных флагов перед стартом

• В проекте нет одного владельца продукта: решения принимаются «коллективно», а ответственность размазана.
• «Сначала сделаем дизайн», хотя роли, процессы и интеграции ещё не описаны.
• Никто не может назвать 6–10 сценариев MVP — вместо этого звучит «давайте всё, как в нормальных порталах».
• Интеграции планируют «потом, когда запустимся». Это почти всегда означает двойную работу.
• Безопасность и персональные данные обсуждают на уровне «у нас всё закрыто» без конкретики по ролям, SSO и логам.
• Нет договорённостей про поддержку: кто отвечает за инциденты, обновления и обучение пользователей.
• Приёмка предполагается «по ощущениям», без тест‑кейсов, событий аналитики и чек‑листов.

Если нужно закрыть эти пункты быстро: как мы это делаем в Cetera Labs

Обычно разумная последовательность такая: короткий сбор требований и аудит текущих процессов → конкретное ТЗ/спецификация на портал → разработка или внедрение платформы → поддержка и развитие по SLA.

Финальная мысль

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