Переработка структуры отпуска
во внутренней программе
Роль: Product дизайнер. Работала в команде с 2 дизайнерами, product owner
Сроки: 3 месяца
О продукте
WH — внутренняя программа учета рабочего времени (аналог Jira) для компании
из 90 сотрудников. За годы существования продукт разросся: планирование проектов, документооборот, карточки задач, производственный календарь.
Находится под NDA, по запросу возможна иллюстрация решений.
Задача
Проджект-менеджер пришел с запросом переработать существующий раздел отпусков и разработать новый функционал планирования, так как процесс очевидно не работал:
наблюдались постоянные вопросы к кадровику (сколько дней осталось, могу ли перенести отпуск, могу ли взять отгул, что с моим заявлением),
сотрудники брали больше/меньше положенного или нарушали интервалы между отпусками,
не всем сотрудникам до конца понятна процедура планирования и утверждения отпусков,
взаимозаменяемые коллеги уходили одновременно (проектная деятельность).
Ограничения
несколько уровней согласования отпусков, поэтому нужна была возможность менять даты уже в процессе согласования, а не только на старте.
расчет баланса должен был учитывать северные коэффициенты и дни отгулов,
а не только стандартную норму отпуска.деятельность в компании в основном проектная, поэтому конфликты нужно было проверять не только по отделам, но и по занятости сотрудника на конкретных проектах: если на выбранные даты у него назначены работы по проекту, отпуск
в эти даты система должна была отмечать как рискованный.нельзя было сильно перешивать логику всего продукта, решение встраивалось
в существующую систему.
Исследование

Решения
Было: планирование без контекста.
Стало: умные подсказки при выборе дат (пересечения с коллегами, минимальные интервалы, остаток дней). Обосновано тем, что 80% выбирали даты вслепую, а 17 из 20 в тесте ожидали именно такого поведения системы.
Было: ручной поиск конфликтов.
Стало: автоматическая подсветка пересечений с коллегами. Обосновано тем, что 5 из 7 руководителей узнавали о конфликте уже после отправки заявления, то есть слишком поздно, чтобы что то поменять без переделок.
Было: неизвестно, сколько дней осталось.
Стало: баланс отпусков виден сразу в интерфейсе. Обосновано тем, что это один из вопросов, который кадровик слышал каждый день.
Было: непонятно, что происходит с заявлением.
Стало: история заявлений со статусами согласования. Обосновано тем, что 85% в юзабилити тесте не видели проблему с заявлением, пока оно не уходило на согласование, то есть статус был непрозрачен на всем пути.
Было: кадровик отвечал на повторяющиеся вопросы.
Стало: вся нужная информация доступна в интерфейсе. Прямое следствие интервью с кадровиком.



