Привет. Меня зовут Саша, я UI/UX-дизайнер. В этой статье расскажу о том, как мы пытались наладить процесс планирования времени в компании, какие пути решения использовали и что придумали в итоге.
Если хотите читать сразу исследование - вам в середину статьи) Там где возможно прикладываю ссылки на артефакты.
Предпосылки
Как дизайнер я работал в разных компаниях клиентской разработки, которые в целом можно разделить на несколько типов:
- «Полтора землекопа» – маленькая компания, в которой множество мелких шабашек и 2 директора на 2 специалиста. Приходилось переключаться каждый час, лишь бы что-то успеть. Ни о каком внятном планировании речи и не шло.
- Единственная команда на кучу проектов – тут народу побольше. Были попытки планировать время, но больше «на словах». Когда прилетает заказчик с негативом, вся команда переключается, а другой заказчик в этот момент копит новую порцию негатива. И в итоге у тебя ежедневные пожары и срочности.
- Полноценная команда на небольшом проекте – здесь история обратная: людей набрали, а делать им нечего. Т.е. планов не хватает, чтобы всех загрузить задачами. Поэтому команда чилит и на расслабоне.
Сейчас я работаю в компании с полным циклом разработки: СА, БА, фронт, бэк, тестировщики, техподдержка, технические писатели, дизайнеры, проджекты… У нас много проектов, которыми нужно рулить и 250+ человек в штате, которых нужно грамотно планировать.
Как было «До»
Процесс планирования времени в компании был довольно стандартный:
- За неделю формировался пул спринтов.
- Сотрудники давали свои оценки по каждой задаче в часах.
- Планирование времени происходило с учетом потребностей на проектах
Сама система планирования менялась в зависимости от роста компании и за 3 года прошла несколько этапов развития:
- Пока было мало людей: просто на словах договаривались, какой специалист чем будет заниматься на следующей неделе.
- Потом была табличка с указанием специалиста, проекта или задачи, на которую его планируют. Таблицу все заполняли, но была каша.
- Какое-то время была еженедельная встреча проджектов и руководителей отдела. Обсуждали потребности проектов, какой нужен специалист для их решения и сколько на это уйдет часов. Все это сводили и решали, как лучше распределить.
Всё это в какой-то мере работало, но через костыли. Были конфликты интересов, когда один специалист дает предварительную оценку на множество задач, т.к. работает на нескольких проектах, и его планируют на 80 часов в неделю.
Идея сервиса
Система планирования развивалась и требовала актуального решения в виде готового сервиса. Посмотрели на рынок. Что-то попробовали. Не прижилось.
Параллельно, один из разработчиков в команде решил сделать так, «как он видит», и мы внедрили его идею на временное использование (но нет ничего более постоянного, чем временное)
Не найдя на рынке подходящего продукта под наши потребности, мы решили создать что-то свое. Нам нужно было сформировать коммуникации между множеством ролей, поэтому решили исследовать вопрос: «Что происходит сейчас и кто чего хочет?»
Перед началом исследования была проведена короткая очная встреча с администратором и руководителем проекта. Получив основную информацию, мы смогли сегментировать пользователей и выставить им приоритет для исследования.
Какие были выделены роли:
- Руководитель проекта (высокий приоритет) – у них есть потребность в специалисте на проекте. Сервис нужен для планирования сроков проекта и спринтов.
- Руководитель направления (высокий приоритет) – у них потребность безболезненно распределить специалистов по проектам, чтобы они не прыгали от одного к другому, и были достаточно погружены для качественной реализации. Им нужно смотреть динамику загрузки и планировать выходы новых специалистов.
- Руководитель департамента (средний приоритет) – они смотрят «сверху» на направления в рамках департамента.
- Руководитель проектного офиса (низкий приоритет) – расставляет приоритеты проектов. Сервис нужен для решения конфликтов интересов. Много функций совпадает с руководителями проекта.
- Сотрудник (низкий приоритет) – сервис нужен для того, чтобы узнать планы/команду на следующую неделю.
Базовый паттерн был достаточно простой:
Проджект формирует запрос на сотрудника в часах -» руководитель отдела его валидирует и подтверждает.
С этого и начали. Взяли ранее собранную рабочую систему, с которой помог вышеупомянутый разработчик, и начали «плясать» от неё.
Анализ существующего сервиса
С точки зрения своей экспертизы подсветили и расписали моменты, которые кажутся странными, нелогичными, неудобными и всё вокруг этого. Это помогло сформировать основные гипотезы (часть из которых, кстати, была не подтверждена).
На этом этапе стало понятно, как все работает сейчас. Также поняли, по каким сценариям будем запускать респондентов на юзабилити-тестировании.
Назначили встречи с респондентами: для каждой роли по 5-7 человек.
Генерация гипотез
Исходя из вышеописанного и опираясь на свой опыт, сформировали гипотезы:
Затем провели очные встречи с каждым специалистом, чтобы выявить их потребности.
Интервью и тестирование
Для интервью продумали требования:
- Интервью состоит из двух частей: открытые вопросы и часть, где сотрудники сами рассказывают о работе с сервисом, подчеркивая сложности.
- В конце обязательно слушаем личные предложения каждого респондента. В дальнейшем совпадения в ответах помогли продумать новые, важные фичи.
Результаты интервью и тестов занесли в таблицу для дальнейшей обработки. (детали по ссылке)
Валидация
Прошлись по всем проведенным интервью и наблюдениям. Все данные внесли в таблицу (как всегда по ссылке):
Отметили частоту совпадения данных. Это позволило расставить приоритеты во всей полученной информации:
Проведенные интервью подсветили моменты, которые совпали не только между респондентами в одной группе (например, руководители проектов), но и между двумя разными ролями (РП и РО). На основании совпадений по инсайтам мы сформировали список улучшений сервиса, которые взяли в работу.
Некоторые выводы после исследований:
- РО и РП в основном используют одни и те же разделы сервиса. Большее количество совпадений пришлось на страницу «Заявки». Решили данную страницу сделать стартовой.
- Все респонденты отмечали неудобство в работе с календарем для планирования. Планируем переработать его логику.
- Все респонденты отмечали одинаковые разделы сервиса, которыми никогда не пользуются. Скроем неактуальные разделы.
- Все респонденты отметили, что через сервис неудобно высчитывать остаток часов у сотрудников, и приходится делать это вручную. Рассмотрим вариант автоматического просчета времени в сервисе.
- У каждой роли разные сценарии действий в рамках сервиса. Например, РО отмечали, что им не нужно отображение планирования и заявок других отделов, т.к. они работают в рамках одного отдела. РП такая функциональность нужна: у них, как правило, несколько проектов. Разный контекст работы формирует разный взгляд на процессы: РП важно видеть команду, статус заявок и список проектов. РО важна только нагрузка отдела/сотрудника в часах.
- Будем делать разграничение доступа к редактированию и реализуем ролевую модель.
Джобсы и флоу
Перешли к последнему этапу перед тем, как приступим к макетам и начнем уже что-то собирать.
Дальше – проще
Запилили макеты и прототипы, провалидировали их с несколькими специалистами как описывали выше. Было несколько итераций, постоянно выявлялись новые штуки, но это к лучшему – протестируем.
Передали в разработку.
Как стало «После»
Мы получили сервис, который назвали «Планировщик» — он полностью регулирует взаимоотношения между руководителями проектов, руководителями отделов и сотрудниками-исполнителями. Сотрудники всегда знают свою загруженность, РП видят, кто запланирован на проектах, РО понимают нагрузку отдела на будущую неделю.
К сервису имеют доступ все сотрудники компании, но у каждой роли свой интерфейс. Его мы разрабатывали в зависимости от потребностей ролей, о которых мы узнали в результате исследований.
Теперь в сервисе можно легко и структурно планировать рабочее время человека на неделю, не вызывая конфликта интересов.
Руководители проектов:
- Формируют спринты и оформляют заявку в «Планировщик» на сотрудника.
- В заявке они описывают потребность, прикладывают кликабельную ссылку на задачу в Jira, в которой есть постановка и оценка. Оценку задачи в часах сотрудник по-прежнему дает заранее.
- Благодаря сервису, РП могут более точно прогнозировать спринты и контролировать скорость работ.
Руководитель отдела:
- Смотрит все заявки по своему подразделению, утверждает их или корректирует в зависимости от загруженности конкретного сотрудника.
- Минимизируется возникновение ситуаций, когда на сотрудника запланировали более, чем на 40 часов в неделю.
- Сервис помогает РО регулировать многозадачность и нагрузку в отделе.
Интересные моменты, которые были в процессе работы
- Некоторые роли сами не знали чего хотят, поэтому мы копали и предлагали варианты решения.
- Нашли некоторые баги в самих процессах компании и выдвинули варианты решения.
- Поработали с прекрасным UI-Kit Taiga UI.
- Сами начали внедрять исследования и очень рады этому.
Что имеем сейчас
- Сервис запущен и находится в режиме пилотирования.
- Мы внедрили обратную связь для всех и постоянно принимаем предложения по улучшению.
- Конфликтных моментов стало сильно меньше (цифры пока не могу привести, но в ближайшем будущем постараюсь это сделать).
- Появились еще идеи по развитию, которые касаются оптимизации процессов в компании.
Сервис продолжает активно развиваться и масштабироваться: мы прорабатываем реализацию новых ролей и исследуем гипотезы об их целесообразности. Обратная связь от коллег очень помогает улучшать интерфейс и делать «Планировщик» удобным и прозрачным инструментом для планирования времени.
