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

Но это только половина проблемы. Как всем известно, ресурсами еще нужно уметь грамотно управлять, чтобы не случалось коллизий. Ситуации, когда во время встречи с партнерами, в переговорную врывается руководитель соседнего подразделения со словами “И эта занята!?”, недопустимы.

Второй момент – когда под рукой нет инструмента (к примеру, Outlook или его web-интерфейса), чтобы забронировать переговорную комнату, но очень нужно «успеть» захватить ценный ресурс. Для осуществления задуманного, необходимо идти на свое рабочее место и с него осуществлять бронирование. Теперь представим, что у вас нет на это времени, выходя из переговорной комнаты с очередной встречи.

Можно конечно придумать еще различные варианты «почему». Для нас уже этих двух моментов было достаточно, чтобы начать исследования в направлении поиска решения проблемы.

Как мы дошли до собственного решения

Изначально рассматривались стандартные два варианта:

• Найти что-то готовое;
• Реализовать самостоятельно.

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

Мы выделили несколько решений, которые рассматривали как потенциальные для внедрения:

• SCHEDULLA;
• Evoko Room Manager;
• BookIT Room Scheduling Solution;
• CUE touchONE.

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

Основные задачи, решаемые нашим продуктом

Мы выделили основные задачи, которые должен был первично решать продукт:

• Простота администрирования;
• Индикация статуса переговорной комнаты;
• Возможность быстрого и удобного бронирования переговорной комнаты;
• Просмотр расписания бронирований переговорной комнаты;
• Интеграция с MS Exchange.

Реализация

После проработки задания, макетов интерфейсов и отрисовки необходимой графики, мы приступили к разработке. Нужно оговориться, что для конечного продукта требовалась не только разработка. Необходимо было еще выбрать аппаратную часть. Естественно, мы сразу решили, что конечным устройством у нас будет планшет. Изучив цены и характеристики предлагаемых на рынке планшетов, мы остановили выбор на Lenovo TAB2 A10-30 10.1. По соотношению цена/качество он нас более чем устроил. При этом нужно понимать, что можно на самом деле использовать любое другое устройство, которое устроит по своим техническим, ценовым, имиджевым и другим параметрам. Но и это еще не все. Планшеты нужно еще как-то крепить около переговорных комнат. Мы знали, что для этого используются специализированные кейсы и начали поиск на просторах интернета. Как оказалось, найти подходящий кейс не просто. Не так много предложений есть на рынке, и из имеющихся не так много тех, которые бы могли нам подойти по своему виду. Но как говорится, “вода камень точит”. Кейсы были найдены, планшеты закуплены, разработан продукт, который удовлетворял всем вышеуказанным требованиям.

Что получилось

Немного об архитектуре решения

• Клиентская часть представляет из себя web-приложение, реализованное с использованием AngularJS. Мы не стали реализовывать нативный клиент под устройства, хотя рассматривали такой вариант и, если будет продолжение в серьезном развитии продукта, то есть большая вероятность такой разработки.
• На текущий момент мы используем вспомогательный продукт Kiosk Mode Browser, позволяющий заблокировать переход в любые другие приложения из режима запущенного браузера, а также «залочить» возможность перехода по любым адресам. С функциональностью данного продукта вы можете ознакомиться по ссылке.
• Бэкенд реализован на языке C# с использованием фрэймворка ASP.NET Core. В данном случае мы не привязаны к платформе, на которой можно развернуть бэкенд. На текущий момент у нас он крутится на Windows Server, но ничто не мешает его развернуть на linux/unix – машинах.
• В качестве СУБД мы используем MS SQL. При этом в наших разработках используется ORM Entity Framework, что позволяет безболезненно переключиться практически на любую sql-ориентированную СУБД.
  

  Саму базу данных на текущем этапе мы используем в очень ограниченном формате. В ней мы храним аккаунт администратора и параметры переговорных комнат. Основным источником данных о расписаниях, списке переговорных комнат у нас является MS Exchange Server. В дальнейшем за счет реализации промежуточного слоя между Exchange и бэкендом роль БД будет расширяться.

• MS Exchange Server, с которым посредством его API взаимодействует наш сервер приложения.

Почему мы хотим реализовать промежуточный слой между бэкендом и Exchange? На самом деле основные задачи, которые мы хотим решить таким образом следующие.
Мы считаем, что не всегда и не у всех в ИТ-инфраструктуре присутствует Exchange-сервер. Поэтому необходимо как минимум абстрагироваться от источника информации (переходим на уровень интерфейсов).

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

Интерфейс

Админка

Работа с конечным устройством (планшетом) начинается с привязки к конкретной переговорной комнате. Для этого реализована простая «админка», в которой выводится список с переговорными комнатами, имеющимися в компании.

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

Дополнительной функциональностью является возможность задать параметры переговорной комнаты, такие как:

• Количество человек, которое вмещает переговорная комната для комфортного размещения;
• Наличие оборудования для конференцсвязи;
• Наличие компьютера;
• Наличие канцелярии;
• Наличие доски;
• Наличие телевизора.

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

Основной экран

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

На текущий момент мы определили 3 важных статуса занятости переговорной комнаты:

1. Переговорная комната свободна;
2. Переговорная комната свободна еще <= 15;
3. Переговорная комната занята.

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

Если назначение первого и третьего статусов должно быть интуитивно понятно, то второй требует небольших комментариев. Данный статус мы реализовали для того, чтобы у сотрудника была возможность воспользоваться переговорной комнатой прямо сейчас, но предупредить, что у него в распоряжении не более 15 минут (к примеру нужно совершить важный звонок, что бы вокруг не было “фона”).

Бронирование

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

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

При этом начиная выбирать время начала встречи, у вас будут активироваться или деактивироваться элементы с выбором продолжительности встречи. Логика простая – если промежуток начала и продолжительности не занят, то элемент с заданной продолжительностью становится активным, если какая-либо встреча уже попадает в заданный диапазон, элементы деактивируются.

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

Расписание

На экране расписания бронирований отображены списком диапазоны занятости и свободы «переговорки».

Как видно, при бронировании посредством сервиса, тема встречи задается как “Экспресс-бронирование”. При клике на не занятый диапазон, мы попадаем в режим бронирования, процесс которого описан выше.

О планах

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

• Промежуточный программный “слой”, при помощи которого можно будет абстрагироваться от источника информации о переговорных комнатах, их расписаний и т.п. Это позволит при необходимости быстро, реализовав коннектор с любым внешним сервисом, внедрить решение без привязки к продукту MS Exchange.
• Подбор переговорных комнат по заданным параметрам на заданный промежуток времени.
• Возможность отмены или завершения встречи из переговорной комнаты (бывает, что встречи заканчиваются раньше и есть необходимость об этом просигнализировать для окружающих). Мы не вынесли данную функциональность на внешний интерфейс, чтобы не давать соблазнов сотрудникам “пошутить”.
• Механизм быстрого продления встречи.
• Возможность выбора даты встречи, участников и организатора, а также ввод темы в интерфейсе бронирования.
• Рефакторинг и даже изменение архитектуры кода. Мы знаем об узких местах, которые сейчас заложены в архитектуре кода и стремимся их исправить.

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