ТЗ на корпоративный портал: роли, поиск и жизненный цикл знаний

Начните с повседневных задач

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

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

Постройте модель ролей и ресурсов

Матрица доступа должна связывать роль с конкретным ресурсом и действием: чтение, изменение, публикация, согласование и скачивание. «Сотрудник видит портал» слишком широкая формулировка. Внутри могут находиться общие инструкции, документы подразделения и материалы ограниченного доступа.

Документация Microsoft о разрешениях SharePoint показывает, что доступ зависит от модели групп и совместного использования. Это пример платформенного подхода, а не готовая схема для любой компании. В выбранной системе подтвердите, какие права наследуются, где создаются исключения и кто вправе ими управлять.

OWASP рекомендует проверять авторизацию для запрашиваемого ресурса. Поэтому в приёмке нужны прямые адреса, вложения и поисковая выдача. Скрытие ссылки в меню не должно оставлять документ доступным по сохранённому URL.

Назначьте владельцев знаний

Для каждого типа материала определите автора, владельца содержания, утверждающего и срок повторной проверки. Технический администратор отвечает за работу системы, но не обязательно знает, какой производственный регламент актуален. Без владельца новый портал быстро повторяет проблемы старой сетевой папки.

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

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

Проверьте поиск на реальных вопросах

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

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

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

Опишите заявки и взаимодействие систем

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

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

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

Учтите кадровые изменения

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

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

Примите портал от имени каждой роли

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

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

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

Соберите бриф и правила сопровождения

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

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