Меня зовут Рустам Нурдавлятов, я являюсь руководителем одного из центров разработки в Nexign. Последний год моя команда создавала HRM-систему, которая будет отвечать всем требованиям бизнеса. Что позволило в краткие сроки разработать основные модули продукта и объединить внутренние потребности и запросы рынка? Ответ простой — продуктовый подход к разработке.
В этой статье опишем кейс создания HRM-системы, расскажем о схеме совместной работы команд HR и разработки, а также на собственном примере разберем продуктовый подход к созданию HR-систем.
Надеемся, что материал будет полезен как заказчикам со стороны бизнеса, так и тем, кто только приступает к разработке больших систем для нужд компании.
В чем проблема?
Nexign — это IT-компания, для которой важно повышать эффективность работы. Также нам просто необходимо использовать лучшие инструменты привлечения и удержания специалистов, чтобы оставаться конкурентоспособными на рынке труда.
До 2020 года у нас было четыре IT-системы для реализации разных HR-задач:
Mirapolis — для опросов методом 360 градусов и целеполагания;
SharePoint — как Service desk и хранилище документов;
«Инфополе» — самописный интранет (справочник подразделений, карта офиса, новости);
Skillber — самописная система (сообщества, профили, маркет брендированных товаров, расширенный соцпакет «Кафетерий»).
Такой набор систем путал коллег и вызывал множество вопросов, требовал больших усилий для их сопровождения и просто был неудобен. Мы поняли, что компании необходима единая система с удобным пользовательским интерфейсом, и пошли смотреть рыночные предложения.
Готовые решения нам не подошли. Причин было много:
Устаревший UI: интерфейс не позволяет быстро ориентироваться на портале;
Нет централизованного доступа: системы не обеспечивают единый доступ к необходимой информации и поддержку всех этапов жизненного пути сотрудника;
Legacy-код: любые изменения внедрять сложно и долго;
Высокая стоимость владения: каждая доработка решения на стороне поставщика требует дополнительных затрат.
В итоге мы решили разработать собственный корпоративный портал Neon — интегрированную платформу для формирования современной, открытой корпоративной экосистемы.
Портал объединил в себе множество функциональных блоков: Новости, Сообщества и Афиша, Профиль, Личный кабинет сотрудника, Карта офиса и FreeDesk.
Шло время, решение развивалось и наш корпоративный портал заинтересовал другие компании — так было принято решение о выводе продукта на рынок. И на текущий момент более 50 000 пользователей из различных компаний используют решение Nexign. Например, в компании «МегаФон» Neon заменил SAP Success Factors в части процессов, которые нужно было перестроить в срочном порядке. Также за разработку портала компания выиграла Премию HR-бренд от hh.ru в категории «Федерация».
Но нам хотелось большего…
В конце 2022 года было принято ещё одно решение: объединить HR и разработчиков в общую команду и создать полноценную HRM, используя имеющиеся наработки. Основные требования к системе: гибкая конфигурация, легкая адаптируемость и масштабируемость, быстрый процесс внедрения.
В январе 2023 мы стартовали работы и за основу взяли существующий корпоративный портал. Делать старались так, чтобы удовлетворить внутренние HR-потребности и запрос рынка — решение должно быть актуальным и для большинства других компаний.
На подготовительном этапе определились с базовыми характеристиками нашей HRM:
low-code / no-code подход для создания готового конструктора форм и процессов — чтобы клиент мог редактировать модули без участия программистов;
микросервисная архитектура без legacy-кода — нужна, чтобы поэтапно разрабатывать и комбинировать различные наборы модулей;
современный UI — делает систему понятной и приятной в использовании.
В стандартном продуктовом подходе в основу решения ложится Customer Journey Map. В нашем случае использовали Employee Journey Map с описанием всех этапов жизненного пути сотрудника — от первого контакта до офбординга.
Все эти этапы можно представить как HR-продукты: у каждого есть свой владелец и продуктовое видение, с помощью которого следует развивать разработку.
Подходы к разработке
Как разработка HR-функциональности во внутренних системах шла раньше? Приходил HR-клиент и выгружал целый набор требований. Dev-команда уходила в долгий процесс аналитики, разработки и внедрения. В итоге только через 6-9 месяцев новый функционал выезжал на пром.
Как разработка происходит сейчас? Команда поняла, что надо менять подход и пошла по продуктовому пути. Сначала определяем, что решаем, и выбираем через какие метрики оценивать результат, строим гипотезы о путях достижения, проводим фокус-группы, получаем MVP (Minimal Viable Product), переводим жизнеспособную версию продукта в эксплуатацию и развиваем решение дальше, поэтапно добавляя функциональность.
Продуктовый подход позволяет:
уходить от больших систем к модулям и микросервисам;
учитывать запрос рынка и внутренних пользователей;
принимать решения на основе данных;
взаимодействовать и синхронизироваться на каждом этапе;
получать результат существенно быстрее.
Разберём пример
В теории любой подход может звучать хорошо, давайте разберёмся, как процесс был устроен на практике.
Цель — разработать модуль «Опрос 360 градусов» для максимально удобного и прозрачного процесса получения обратной связи.
Задачи модуля:
развитие навыков на основе обратной связи от коллег и руководителей;
выявление недостающих компетенций и формирование эффективной кадровой политики;
определение сильных сторон и потенциала для развития команды.
Шаг 1. Определяем, что решаем
На старте в процедуре оценки участвовало 87% сотрудников → стремимся сделать показатель близким к 100%.
Около 15 минут уходило на заполнение опросника → стремимся оптимизировать процесс и сократить время прохождения опроса на 30%.
Результат хранился в почте или в папках на ПК → интегрируем результаты опроса в другие системы, связанные с развитием.
Решение от внешнего подрядчика, требующее регистрации и передачи персональных данных сотрудников → создаем модуль в рамках единого корпоративного портала.
Шаг 2. Формулируем гипотезу
Есть внутренний запрос на решение недостатков текущей системы:
нужна своя внутренняя платформа, так как при использовании решений от подрядчиков сотруднику приходится переходить на другой ресурс и передавать свои данные, а это неудобно;
сложный процесс: опрос занимает много времени у участников;
любые доработки реализуются долго и дорого.
Есть внешний запрос рынка:
дружелюбный UI-интерфейс;
интеграция с профилем сотрудника, модулем «Обучение» и др;
быстрая кастомизация.
На выходе получаем внушительный набор требований:
Шаг 3. Бизнес-анализ
На этом этапе соотносим требования внешнего и внутреннего клиентов. Определяем наиболее востребованные из них, расставляем приоритеты. Этот шаг курируют бизнес-аналитики, которые собирают полный список и подробные описания функциональностей.
Шаг 4. Груминг требований
На данном этапе встречаются все участники процесса: владелец функции (в нашем кейсе — HR), владелец продукта и разработка.
Главная задача — разделить требования по трем направлениям:
MVP — функции, без которых модуль не имеет смысла (1 очередь);
Release — функции, без которых модуль существовать может, но они важны и нужны (2 очередь);
Future — функции с характеристикой «Хотелось бы» или «Хорошо бы» (бэклог).
Каждый участник процесса делится своей оценкой по большому списку первоначальных требований. Иногда получается принять решение единогласно, сложные случаи требуют конструктивной дискуссии и чёткой аргументации.
Шаг 5. Системный анализ
Переводим бизнес-требования на технический язык. Для этого анализируем потребности заказчика, возможности платформы, собираем варианты разрешения системных проблем с учетом ограничений, рисков. На основе комплексных данных даем обоснованные рекомендации по оптимальному плану разработки.
Если говорить кратко, то для каждого этапа соотносим возможности платформы и бизнес-требования. Например, сможем ли мы поддержать работу платформы на 30 000 пользователей? И в соответствии с этим планируем доработки.
Шаг 6. Демонстрация макетов
Для промежуточной синхронизации готовим примеры визуализации запланированных модулей и обсуждаем их с заказчиком. Этот этап позволяет ещё раз свериться по ожиданиям и своевременно внести правки — до момента полной готовности продукта.
Возвращаясь к нашему примеру, покажем макет одного из модулей:
Шаг 7. Проектирование архитектуры модулей
Наша задача, кроме подготовки модуля — спроектировать схему данных, информационные потоки. Встроить этот «кусочек пазла» в существующую платформу и организовать «общение» одного модуля с другими — в нашем примере с «Обучением».
И здесь играет большую роль микросервисная архитектура, которая:
дает возможность разрабатывать и использовать технологии и инструменты наиболее подходящие для каждого сервиса;
обеспечивает легкое внедрение нового функционала за счёт разработки отдельного микросервиса;
позволяет проводить независимую развертку сервисов и быстрое обновление.
Шаг 8. Разработка MVP
Приближаемся к самому интересному: разрабатываем и запускаем MVP продукта в соответствии с приоритетами. Если вы качественно провели все подготовительные этапы, то разработка пройдёт максимально гладко и эффективно. Конечно, не забываем про тестирование с привлечением экспертов-заказчиков. Осталось только презентовать выпущенные жизнеспособные модули.
Резюмируем итоги
После завершения работ мы протестировали новый модуль «Опрос 360 градусов» на сотрудниках Nexign.
Так выглядят результаты…
Среднее заполнение анкеты: было 15 минут, стало 10 минут.
Количество сотрудников HR, обслуживающих систему сократилось с двух до одного.
Количество негативных отзывов уменьшилось с 17% до 0%.
Количество сотрудников, прошедших опрос, увеличилось с 87% до 99%.
Вспомним, что в начале проекта мы хотели учесть и потребности рынка. Одним из важных внешних запросов была возможность кастомизации.
Какие функции реализовали для выполнения данного блока требований?
Конструктор страниц и виджетов — для настройки внешнего вида и содержания профиля сотрудника, главной страницы, личного кабинета, новостей и новых страниц портала с помощью добавления виджетов и настройки их отображения.
Конструктор форм — для создания форм и новых HR- и ИТ-заявок без использования кода и с привязкой к соответствующему бизнес-процессу обработки.
Конструктор бизнес-процессов — для управления бизнес-процессами и согласованиями.
Если говорить о сроках, то на запуск одного модуля «Опрос 360 градусов» у нас ушло 3 месяца. Параллельно с этим занимались разработкой и развитием других модулей: «Портал», «Целеполагание», ИПР, «Обучение».
Применяя продуктовый подход в работе команд, менее чем за год мы смогли создать основные модули HRM-системы: узнать больше о характеристиках и заказать демо можно на отдельной странице Neon HRM.
А если вы хотите узнать больше о разработке продуктов HRM и BAP, то загляните в специальный раздел карьерного сайта Nexign.
Возвращаясь к теме статьи
В использовании продуктового подхода мы заметили целый ряд преимуществ. Заказчики не только обладают необходимой экспертизой, но и применяют её на пользу продукту. Открытый обмен мнениями и обсуждение запросов позволяет понять, что происходит на рынке и создать лучшее решение как для своих коллег, так и для внешнего пользования. Вовлечение всех участников в процесс разработки помогает видеть задачу комплексно, быстро принимать решения и вносить изменения в режиме лайв.
Такой подход может пригодиться, если нужно:
поэтапно реализовывать продукт;
учитывать потребности как внутреннего, так и внешнего заказчика;
создавать продукт, который можно быстро конфигурировать без больших усилий или дополнительной доработки.
Так что продуктовый подход — это не просто тренд, но ещё и эффективный процесс, который помогает решать бизнес-задачи так, чтобы для всех участников проекта «ожидания» совпали с «реальностью».
