Потребность для HR-направления
Отдел кадров вышеуказанного заказчика выступил с инициативой развития собственного направления.
А именно, итогом данной модернизации должна была стать более прозрачная, удобная и максимально автоматизированная система для взаимодействия с персоналом компании.
Одним из пунктов усовершенствования IT-инфраструктуры являлась подготовка сервиса для работы с организационной структурой компании заказчика.
Что хотел клиент
- Визуально отражать структуру подчиненности подразделений и сотрудников компании;
- Иметь простую, понятную и удобную навигацию;
- Предоставлять основную информацию о руководителе и сотруднике любого отдела (фото, ФИО, должность, телефон, почта);
- Показывать статистические показатели каждого структурного подразделения;
- Осуществлять быстрый поиск сотрудников или отделов, сохраняя после поиска структуру подчиненности от высшего руководства до найденного отдела/сотрудника;
- Обладать фильтрацией по регионам (при этом необходимо отмечать сотрудников, физически находящихся в отфильтрованном регионе и сотрудников, работающих в центральном офисе, но при этом относящихся к региональным подразделениям);
- Загружать данные в систему из внутренних систем заказчика путем автоматизированных выгрузок;
- Ограничить доступ к системе внутренней сетью заказчика;
- Организовать сквозной доступ в систему под логином/паролем от основного компьютера (работа с ADLP-сервером заказчика);
- Разработать, протестировать и привести систему в «боевой» режим в течение полугода.
Этапы решения
Часть 1. Начало
После составления списка первоначальных требований к системе встал вопрос технологической базы. Изначально заказчик предполагал реализовывать систему на базе Битрикс24, но структура компании в данной системе не очень устраивала клиента, поэтому подразумевалась ее модернизация.
Проведя первоначальный анализ, мы предупредили клиента о 2 «подводных камнях»:
- Во-первых. Для отображения сотрудника в организационной структуре Битрикс24 он должен быть зарегистрирован в данной системе. Однако стоимость лицензии на 20 000 человек была слишком высока, и мы видели более экономичные альтернативы.
- Во-вторых. Кастомизация стандартного функционала Битрикс24 возможна, но является трудоемкой. Для решения задач, поставленных заказчиком, гораздо проще и эффективнее было бы разработать систему, «заточенную» под его требования.
После обсуждения данных вопросов с клиентом было решено отказаться от идеи использования стандартного Битрикс24. Мы взялись за разработку системы, максимально адаптированную под конкретные задачи заказчика.
Исходя из предоставленной нам информации, был поэтапно сформирован концепт системы:
- Подготовлены и описаны основные сценарии взаимодействия с пользователем;
- Созданы первые графические прототипы интерфейса;
- Определен технологический стек, а также технические требования;
- Спланирована этапность реализации системы;
- Проведена предварительная оценка стоимости и сроков разработки системы.
Работа, проделанная с нашей стороны, стала хорошим фундаментом для формирования доверия между нами и заказчиком. И сладкой «вишенкой на торте», как закономерный итог, стало заключение договора.
После первоначальной проработки проекта и заключения договора мы приступили к разработке технического задания. В ходе нескольких встреч с клиентом мы подробно разобрали все основные сценарии работы, обсудили форматы и особенности передачи и отображения данных.
После этого проведено полноценное предпроектное исследование, по итогам которого составлено техническое задание, согласованное с заказчиком. А конкретно – было принято решение отказаться от деления проекта на этапы по функциональному признаку и использовать итеративный подход. То есть, тестируя проект на каждом этапе, и по мере необходимости корректируя его.
Часть 2. Подготовка тестового и продуктивного контура:
После детальной проработки проекта мы приступили к реализации. Разумеется, первым шагом стала подготовка тестового и продуктивного контура системы.
Еще на этапе предпроектного исследования мы давали заказчику рекомендации по параметрам серверов. Неудивительно, что к моменту старта второй части заказчик уже подготовил необходимые серверы внутри своей сетевой инфраструктуры.
Получив от сетевых администраторов заказчика все необходимые доступы, мы развернули виртуальное окружение и установили 1С-Битрикс, переведя один из них в тестовый режим.
После установки мы провели тестирование системы и настроили резервное копирование.
Таким образом, в достаточно сжатые сроки мы настроили всю необходимую для работы с проектом среду.
Часть 3. Подготовка прототипа дерева структуры:
Навигацию по дереву организационной структуры мы сделали главной целью первого прототипа.
В качестве реактивного фреймворка нами был выбран Vue. Это решение обуславливалось тем, что он входит в стандартный стек дистрибутива 1С-Битрикс, а значит не вызовет каких-либо проблем с совместимостью и внутренних конфликтов системы.
Само же использование реактивных фреймворков было не просто данью моде. Они были жизненно необходимы, потому что:
- На этапе проектирования мы смогли уместить всю структуру на один экран ноутбука, без необходимости листать длинные «портянки». Соответственно, навигация подразумевала активное взаимодействие пользователя с интерфейсом, а значит система должна была динамически обрабатывать и отдавать большой объем информации;
- Мы шли путем прототипов, а значит, в ходе работы проект мог изменить объем и логику отображения данных, а значит система должна предполагать максимальную гибкость;
- Чтобы навигация была понятна пользователю с точки зрения usability, движение по структуре дерева подчиненности сопровождалось бы анимацией.
Работа с деревом структуры была разбита на несколько логических частей:
- backend-часть;
- frontend-часть;
- информационная шина, отвечающая за их взаимодействие;
- загрузка демо-данных и тестирование.
Кроме этого, часть команды занималась подготовкой шаблонов xml-файлов, передающей в систему информацию из внутренних систем заказчика, загрузкой демо-данных и тестированием системы.
В ходе работы мы устраивали сеансы демонстрации логики системы для проекта и на основе получаемого фидбека корректировали отдельные ее функции.
Учитывая открытый подход к созданию, к финальному тестированию заказчик уже имел четкое представление о системе, ее функционале и возможностях, так что приемка работ прошла без каких-либо затруднений.
Часть 4. Подготовка прототипа системы поиска и фильтрации по регионам
После окончания работ по третьему этапу у заказчика уже было четкое представление о том, как будет выглядеть дерево организационной структуры и о навигации, проходящей по нему.
Однако объем персонала (более 20 000 человек) и сценарии работы пользователей делали простой поиск по всей организационной структуре очень трудоемкой задачей.
Для удобства пользователей в систему были добавлены дополнительные инструменты.
Как и в третьем шаге, работы с поиском и региональной фильтрацией были разбиты на базовые части:
- backend;
- frontend;
- информационная шина данных;
- загрузка демо-данных и тестирование.
Поиск
Для полноценной работы система должна была иметь поиск по:
- ФИО сотрудника;
- Телефону сотрудника;
- Почте сотрудника;
- Названию структурного подразделения сотрудника;
- Имени руководителя структурного подразделения;
- И т.д.
Помимо простого поиска система должна была отображать найденный результат с сохранением структуры дерева подчиненности.
Кроме этого, следовало учесть, что по одному запросу могло быть найдено несколько сотрудников и/или структурных подразделений, и пользователь имел бы возможность быстро посмотреть структуру дерева по каждому из них для получения необходимой информации.
В итоге мы решили сгруппировать результаты поиска в выпадающем окне под поисковой строкой, по сотрудникам и отделам. После клика на определенный результат система отстраивала соответствующее дерево подчиненности. Такой вариант полностью устроил клиента.
Регионы
Учитывая масштаб компании заказчика, неудивительно, что многие сотрудники находились в различных регионах России и подчинялись напрямую региональным отделениям. Однако при этом в регионах могли находиться сотрудники, подчиняющиеся и напрямую центральному офису.
Перед нами стояла задача разработать простую и понятную механику для работы с региональными отделениями.
После ряда экспериментов мы решили вынести выбор региона за рамки модуля поиска, сделав дополнительный фильтр рядом с поисковой строкой.
Всех сотрудников выбранного региона, подчиняющихся напрямую центральному офису, мы вынесли в отдельную ветку, структурно относящуюся к соответствующему блоку дерева. Остальную механику решили оставить прежней.
Это решение также устроило бизнес-заказчика.
Часть 5. Сборка полнофункциональной версии сервиса:
К данному моменту клиент уже не просто понимал все механики работы сервиса, а протестировал и утвердил наиболее удобные для себя варианты на демо-данных.
Фактически, для получения полноценной системы осталось сделать 4 небольших шага:
- Настроить автоматизированные выгрузки данных из внутренних программ заказчика;
- Настроить систему авторизации и интеграцию с AD-сервером;
- Добавить анимацию, визуализирующую процесс перемещения по дереву организации;
- Оптимизировать запросы к базе данных и провести финальные тестирования системы.
Собственно, в таком порядке мы и приступили к работе.
Настройка автоматизированных выгрузок
Основой для обмена информацией был выбран формат .xml. Для удобства и оптимизации обмена данные были разбиты на несколько отдельных файлов выгрузок, с отдельной логикой загрузки и обработчиками.
Проектирование структуры файлов проводилось на самых первых этапах работы с сервисом. Так что к моменту начала настройки автоматизации все работы на стороне технического отдела заказчика были закончены, и мы получили возможность проводить загрузку данных.
На данном этапе мы плотно взаимодействовали с техническими специалистами заказчика для настройки:
- корректной передачи .xml файлов между серверами внутрикорпоративной сети;
- логирования событий и ошибок процесса чтения фидов, а также системы уведомлений системных администраторов о критических сбоях загрузки данных;
- бэкапирования прочитанных файлов выгрузок;
- синхронизации процессов выгрузки, передачи и чтения .xml-файлов.
По итогам данной работы информация стала поступать в систему автоматически, в соответствии с настроенным расписанием.
Авторизация и интеграция с AD-сервером
Учитывая, что данный сервис предназначался для внутреннего использования, делать на нем отдельную систему авторизации было бы неудобно. Сотрудники заказчика использовали для авторизации во всех внутренних системах одну и ту же учетную запись (AD-сервер). В данном проекте было принято решение придерживаться такой же схемы авторизации, так как это заметно упрощало работу сотрудников.
Задача интеграции 1С-Битрикс с AD-сервером достаточно типичная, так что она не заняла много времени.
Также в рамках данного этапа мы провели разграничение функционала по группам:
- Административный доступ;
- Полный доступ к сервису с просмотром статистических данных по каждому отделу;
- Полный доступ к сервису без просмотра статистических данных по каждому отделу;
- Доступ к своей ветке дерева подчиненности (видны только свои и нижестоящие отделы и сотрудники) с просмотром статистических данных;
- Доступ к своей ветке дерева подчиненности (видны только свои и нижестоящие отделы и сотрудники) без просмотра статистических данных.
Дополнительно нами были настроены ограничения регионального фильтра и поиска для групп с минимальными правами для того, чтобы исключить возможность увидеть данные о вышестоящих подразделениях и сотрудниках.
Добавление анимации
Основной нашей задачей было сделать навигацию по дереву оргструктуры простой и наглядной.
Для решения этой задачи в каждый момент времени мы отображаем 3 уровня подчиненности. Переход на выше- или нижестоящие уровни происходит при клике на блок структуры, горизонтальный скролл осуществляется удержанием средней кнопки мышки или наведением на край экрана.
Чтобы пользователь понимал взаимосвязь отделов при кликах, нам необходимо было добавить анимацию, показывающую движение пользователя по дереву.
А для более приятной и наглядной работы системы, мы добавили анимацию к процессу поиска и фильтрации по региону.
Оптимизация запросов к базе данных и финальное тестирование
На данном этапе все основные работы по сервису были закончены, рабочая группа протестировала и дала обратную связь по всем функциональным блокам. Все остались довольны работой новой системы.
При этом, из-за изменений, происходящих в рамках обкатки MVP и полной версии, в системе накопились некоторые устаревшие или неоптимальные куски кода. Безусловно мы не могли делать релиз системы в таком виде.
В конце работы мы провели рефакторинг кода, избавившись от его неактуальных частей и оптимизировав актуальные.
После этого мы смогли спокойно отдать систему в финальное тестирование.
Для итогового тестирования заказчик набрал фокус-группу, состоящую из сотрудников-добровольцев. Такой подход позволил обновить «замыленный» взгляд членов рабочей группы и получить независимое мнение.
Итоговые отзывы фокус-группы очень порадовали как нас, так и заказчика. Учитывая плотное взаимодействие с сотрудниками клиента на всех этапах работы с проектом, результат и механика взаимодействия полностью удовлетворили участников фокус-группы.
По итогам финального тестирования было решено переводить систему в боевой режим.
Часть 6. Запуск продуктивной версии:
Все этапы по разработке сервиса и тестирование до этого проводились в тестовом контуре. После того, как мы убедились, что сервис работает отлично, стартовали работы по переносу сервиса на продуктивный контур.
После переноса мы прогрузили данные и провели ряд тестов для того, чтобы проверить корректность работы системы.
Убедившись в полной работоспособности, мы запустили систему в боевом режиме для всех сотрудников заказчика.
Итог
В течение нескольких месяцев мы полностью спроектировали и реализовали систему для удобной визуализации и работы со структурным деревом компании клиента.
На всех этапах работы мы плотно взаимодействовали с рабочей группой заказчика, что позволило нам создать именно ту систему, которую ожидал клиент.
