Больше разделов не означает больше пользы

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

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

Почему новости редко подходят на роль основы

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

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

На старте полезно прямо назвать то, что останется в прежних системах. Если кадровые документы уже обрабатываются в отдельном сервисе, портал может объяснять порядок и давать переход, не создавая второе место хранения тех же документов.

База знаний: когда сотруднику нужен ответ

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

Поиск экономит переходы. В документации Яндекс Вики действие «Поиск» относится к страницам, доступным пользователю. Это наглядный пример для задания независимому порталу: поиск следует границам доступа, а закрытое содержание не появляется в подсказках для постороннего сотрудника. Названия пунктов готового сервиса приводятся как пример устройства, а не как обязательные названия будущего сайта.

Что считать рабочим содержанием

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

Удобство начинается с привычных слов. Сотрудник ищет замену пропуска, а не название подразделения, которое исторически отвечает за эту процедуру, поэтому названия тем лучше привязывать к потребности.

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

Наглядный разбор

Три разных результата посещения

  1. База знаний

    Получить ответ без обращения к коллеге

  2. Заявка

    Передать вопрос назначенному исполнителю

  3. Навигатор

    Открыть действующий рабочий сервис

Подход выбирают по завершению задачи сотрудника.

Портал заявок: когда требуется ответное действие

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

Карточка заявки вместо бесконечной переписки

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

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

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

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

Навигатор сервисов: меньше разработки, больше порядка

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

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

Повторное посещение без поиска с начала

Для возвращения к нужным материалам существуют разные приёмы. Например, в навигации Яндекс Вики предусмотрено «Избранное». Там же «Подписки» собирают страницы, за изменениями которых следит пользователь. Отдельный пункт «История изменений» ведёт к созданным или отредактированным им страницам. Для собственного портала выбирают только те приёмы, которые помогают повторному действию, и объясняют их сотрудникам привычными словами.

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

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

Права и критерии для первого выпуска

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

Читатель и редактор решают разные задачи. В описании ролей Яндекс Вики «Читатель» просматривает страницу, а «Редактор» изменяет её содержание. Роль соавтора включает управление доступом, и это полезное разделение ответственности для задания: право исправить текст не обязано автоматически давать право раскрыть его всему коллективу или удалить чужой материал.

Групповой доступ проще поддерживать при кадровых изменениях. Но исключения придётся описать: в настройках Вики различаются типы «Всем сотрудникам» и «Некоторым сотрудникам». Для собственного портала это пример выбора круга читателей. Исполнитель объясняет, что произойдёт с прямой ссылкой и вложением, когда человека уберут из нужной группы.

Запись в заданииСодержимое
ДействиеНайти инструкцию по доступу к рабочему сервису
ПолучательГруппа сотрудников, которым доступна инструкция
ОтветственныйВладелец текста и сотрудник на замену
ЗавершениеОтвет найден или создано обращение с номером
ОтказНет прав, нет результата поиска, сервис недоступен
ПриёмкаДемонстрация каждого исхода под нужной ролью

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

Наглядный разбор

Доступ сопровождает весь путь

  1. Учётная запись

    Определяет сотрудника

  2. Группа

    Задаёт круг материалов

  3. Страница и файл

    Применяют те же права

  4. Отключение

    Закрывает дальнейший доступ

Закрытый материал остаётся закрытым в поиске и по прямой ссылке.

Первый выпуск измеряется завершёнными действиями

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

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

Что компания принимает в итоге

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

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

Источники и полезные ссылки

  1. Яндекс Вики: роли ↗
  2. Яндекс Вики: навигация ↗
  3. Яндекс Вики: персональные права ↗

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

Игорь Крещенко

Руководитель ШТАБ ИТ. Занимается управлением проектами, веб-разработкой, рекламой и PR. Подробнее об авторе →