Каждый из нас если не сталкивался, то хотя бы видел, как в современном офисе разбираются с мелкими, но важными вопросами вроде восстановления доступа или замены сломанной мышки. Обычно такие задачи требуют времени, объяснений и терпения, и важно, чтобы всё не превратилось в лишний стресс и непродуктивные простои. Мы в Яндексе поставили перед собой очень простую цель: сделать так, чтобы каждый сотрудник мог быстро и легко решить свой вопрос, не отвлекаясь от работы и не тратя силы на бюрократию или ожидания в очередях.
В Яндексе этот путь начался с ряда самостоятельных решений для автоматизации внутренних сервисов — киосков самообслуживания, умных локеров и хелпоматов. Со временем мы объединили всё это в одну платформу — Я.Терминалы. С её помощью можно гибко и удобно настраивать и запускать цифровые сервисы для офисных сотрудников. Это значит, что любые задачи — от получения документов до заказа нового оборудования — теперь решаются быстро и самостоятельно, без лишних ожиданий, то есть меньше отвлекают от работы.
Всем привет! Меня зовут Дмитрий Сидоров, я работаю в Яндексе, в Corp IT, а именно развиваю офисные сервисы. В этой статье расскажу, как мы пришли к идее единой платформы, почему отказались от готового решения и сколько времени удалось высвободить как для сотрудников ресепшена, так и для коллег, которые пришли со своим вопросом. И самое главное — при чём же здесь котики.
Чем вы вообще тут занимаетесь?
Думаю, что после того, как я отвечу на этот вопрос, станет понятно, почему мы вообще решили делать эти продукты. Так как наше подразделение относится к внутреннему ИТ, а задачи внутреннего ИТ включают в себя и поддержку пользователей, то пользователь должен иметь возможность куда-то обратиться с проблемой. Поэтому во многих офисах Яндекса есть физические стойки обслуживания (их мы называем welcome-зоны), куда яндексоиды могут прийти с любой проблемой, которая касается железа, софта, доступов и прочего. Об этом мы несколько лет назад рассказывали на Хабре.
Когда пользователь приходит на стойку, то в зависимости от темы обращения сотруднику поддержки нужно создать тикет в Яндекс Трекере. Думаю, вы уже поняли из описания, что это классический кейс для инструмента электронной очереди: пользователь подходит к стойке → «пикается» бейджем и выбирает категорию обращения → инструмент создаёт тикет с нужной разметкой → сотрудник уже знает, кто и зачем к нему пришёл, → PROFIT! Таким образом, на каждом обращении пользователя на стойку мы стали экономить примерно минуту-полторы времени как сотрудника поддержки, так и коллеги, который к нам пришёл.
Кстати, одни из первых версий устройств выглядели вот так:
Именно поэтому у наших киосков самообслуживания есть неформальное название — «котики», а фраза «пикнуться в котика» стала устойчивым выражением среди яндексоидов.
Конечно, в Яндексе свои стойки обслуживания есть не только у ИТ: аналогичные места работы с сотрудниками создали, например, HR-сервисы и секретариат. Поэтому постепенно запросы на сервис начали поступать и от других подразделений. Так «котики» стали размножаться 😊
И вот тут возникли первые вызовы, которые трансформировались в продуктовые задачи. Дело в том, что на рынке мы не нашли готовых решений, которые выступали бы именно как конструктор киоска для разных видов ресепшенов. Всё, что есть, в основном делится на три категории:
инструменты электронной очереди;
инфокиоски для БЦ или ТЦ;
решения digital signage, через которые возможно выводить контент в виде html-странички, но без встроенного конструктора.
Кроме того, в Яндексе не самый стандартный стек в части внутренних систем. Многие вещи самописные, и интеграция внешних решений, даже on-premises, потребовала бы много усилий либо со стороны разработчиков готового продукта, либо с нашей стороны. Тут же всё хранится внутри, и никто внешний не может случайно (или не случайно) получить доступ к потенциально сенситивной информации.
Инструмент становится продуктом
Киоски создавались как внутренний инструмент для ИТ, и в самом начале мы использовали ряд готовых составляющих. Так, в качестве основы для бэкенда системы мы взяли опенсорс-фреймворк, чтобы уже на его основе создать веб-приложение, которое как раз и поддерживает функциональность электронной очереди.
Кстати, такой подход позволил нам реализовать мультиплатформенность. «Котика» можно развернуть на любом устройстве с браузерным окном — от iPad до киоска-столба под управлением Windows или Linux.
Так как на первом этапе это был такой инструмент «для своих», мы не инвестировали много времени в UX/UI «слоя управления» (проще говоря, админки сервиса), а пользовались стандартным Django Admin. Да и работали с ним достаточно редко, с точки зрения настройки.
Когда «котики» стали распространяться на другие подразделения, мы столкнулись с тем, что коллегам работа с Django Admin не всегда понятна/удобна (нужное подчеркнуть). Плюс был запрос на возможность кастомизации интерфейса киосков, логики их работы и многое другое.
В общем, пользователи инструмента просили ясный/понятный GUI админки, который бы обеспечивал «низкий порог входа» в части объёма знаний/умений, чтобы этим инструментом управлять.
Это был первый звоночек (нам, кстати, хватило одного), когда мы поняли, что купец есть, а вот товар надо бы серьёзно потюнить, чтобы купцы не разбежались со временем. С учётом всей обратной связи, которую мы получили от заказчиков, мы определили для себя список того, чему «котики» должны научиться:
быстрая настройка и установка;
интуитивно понятная настройка бизнес-логики (что «котик» должен уметь);
возможность работать по расписанию, учитывать перерывы и прочее;
кастомизация интерфейса (цветовая схема, картинки, шрифты и вот это всё);
возможность отображения «стороннего контента»;
групповое управление;
тюнинг и универсализация UI на «котике».
«Котики» дрессировке поддавались отлично, поэтому всему без проблем научились.
Быстрая настройка и установка
Как я писал выше, пользовательский интерфейс «котика» — это по факту веб-приложение. Оно располагается во внутренней сети, и, когда устройство обращается на URL, где оно находится, бэкенд смотрит, «знакомое» это устройство или нет. Любому терминалу, который обращается на бэк, автоматически назначается постоянный ID устройства, и если устройство новое, то оно попадает в своеобразную «песочницу».
Дальше устройство из этой «песочницы» уже можно взять и накатить на него пресет (своеобразный набор настроек), который и определяет логику работы устройства.
Итого: чтобы «котик» ожил, нужно заказать для него устройство с заранее установленными сетевыми сертификатами и клиентским MDM-приложением. Оно обеспечивает в том числе открытие URL, где располагается веб-приложение в режиме киоска. Устройство включается → заказчик берёт ID, назначенный устройству, → инициализирует его в админке и применяет к нему пресет.
«Котик» оживает. Таким образом, непосредственно инициализация устройства занимает пару минут.
К слову, то, что мы не стали использовать готовое решение, сыграло нам на руку. Тут бы пришлось превращать его во что-то компромиссное, отсекая или переделывая какие-то вещи. А мы сразу стали создавать именно то, что нужно внутренним пользователям и заказчикам. Ещё один плюс: можно спокойно управлять бэклогом и приоритизировать то, что нужно, не ожидая ресурса на твой фич-запрос поставщику решения.
Настройка, кастомизация, отображение стороннего контента
Выше я писал, что интерфейс наших киосков представляет собой веб-приложение. Мы вдохновились концепцией, которую можно обозначить как «конструктор для котиков», — её мы и реализовали в пресетах.
Пресет — это набор страниц, которыми пользователь может управлять в конструкторе пресета:
Добавлять или удалять страницы пресета, определять, какая страница будет заглавной/начальной.
Редактировать заголовок страницы и подстрочник.
Вставлять контент, которым могут быть как картинка, так и сторонняя веб-страница или форма, вставленная через iFrame, управлять размером этого контента на странице.
Добавлять плитки, которые выступают в качестве кнопок, на те или иные страницы пресета.
Управлять внешним видом плиток, их размерностью, оформлением и расположением на странице (тут пользователь может всё делать через drag’n’drop).
Добавлять действие «Создание тикета» на страницу и определять, с какими параметрами и в какой очереди в Трекере этот самый тикет создаётся.
Управлять отображением статус-бара сверху и кнопок «Домой» и «Назад» в футере.
В итоге у нас получился своеобразный конструктор интерфейсов, который позволяет реализовывать определённую базовую логику для электронных очередей через создание тикетов. Если у заказчика есть какие-либо свои формы или веб-приложения, взаимодействие с которыми он хочет поместить на экран «котика», то он может их встроить через iFrame (не самый элегантный вариант технически, но рабочий для большинства сценариев, которые у нас используют бизнес-заказчики).
Также каждый пресет обеспечивает взаимодействие «один ко многим», то есть один и тот же пресет может использоваться на нескольких устройствах. Таким образом, если, например, у условных HR-сервисов появляется новый сервис или новая категория обращения, которую они хотят поместить в «котика», то достаточно отредактировать пресет: логика автоматом применится ко всем киоскам, которые привязаны к нему.
Тюнинг и универсализация UI на «котике»
Тут мы решили не изобретать велосипед и сделали плиточный UI, который в целом удобен для тач-интерфейсов и позволяет реализовывать комбо в виде «виджет/кнопка». С учётом того что название действия бывает довольно длинным, места хватает: какие-то, наиболее частотные, можно делать крупнее, добавлять иконки и вот это вот всё. Ну и вообще выглядит аккуратно, при этом предоставляет достаточно возможностей для кастомизации внешнего вида.
Немного про админку
Все указанные выше возможности реализуются через зонтичную админку «Я.Терминалы». Вообще через неё можно управлять не только «котиками», но ещё и другими устройствами, которые являются частью системы: умными локерами и вендоматами с компьютерными аксессуарами. Логически админка поделена на корневые разделы по типам устройств: «Котики», «Локеры» и «Вендоматы». Внутри каждого корневого раздела, в подразделах, уже происходит управление настройками конкретных устройств или сущностями, относящимися к этим устройствам.
Список устройств по умолчанию представлен в табличном виде, но можно переключаться на плитки, есть сквозной поиск, фильтры — в общем, всё, чтобы быстро найти нужное для настройки.
Нажимая на конкретное устройство, мы проваливаемся в его карточку, где уже можно управлять его настройками. Для разных типов устройств набор настроек будет различаться: у них ведь разные задачи и логика работы.
В админке реализована ролевая модель — для разграничения доступа и возможностей для настроек. Выдача той или иной роли происходит через внутреннюю систему выдачи прав — IDM.
Что в итоге?
Опыт внедрения и развития Я.Терминалов показал, насколько востребованы подобные цифровые продукты в корпоративной среде. Автоматизация повседневных задач, удобство настройки под потребности каждого подразделения и простота масштабирования становятся ключевыми преимуществами для всех сервисных команд компании.
Сейчас в офисах Яндекса живёт не менее 60 «котиков». В месяц через них создаётся около 15 000 тикетов, что даёт существенную экономию. До внедрения «котиков» в среднем на заведение и разметку у сотрудника уходило 90–120 секунд, а сейчас всё происходит мгновенно. Сотрудник ресепшена сразу приступает к обслуживанию коллеги. Итого в месяц мы экономим порядка 460 человеко-часов (причём как для сотрудников ресепшена, так и для коллег, пришедших решить свой вопрос).
На этом развитие продукта не заканчивается: мы продолжаем собирать обратную связь, тестировать новые сценарии использования и искать направления дальнейшего улучшения. Пока мы планируем посмотреть в сторону наращивания количества разных навыков «котиков». И соответственно, думаем, где ещё будет полезно применить информационно-навигационные киоски в наших офисах с разного рода релевантной информацией для сотрудников.
Если у вас есть идеи или вопросы — с радостью обсудим в комментариях!