Сколько человек нужно, чтобы вкрутить лампочку организовать поездку на конференцию?

Я сейчас в поиске ответа на этот вопрос на своём опыте оформления командировки. И список точек касания (людей, запросов в джире, задач на мне) всё растёт…

Речь про участие в конференции за границей. В моём идеальном мире процесс согласования поездки выглядит так: шаг 1 — согласование с руководителем на словах; шаг 2 — оформление задачи; (дальше некая магия…); шаг 3 — подача документов на визу; шаг 4 — сама поездка; шаг 5 — презентация инсайтов с конференции коллегам. Но вот на втором шаге реальность разъехалась с ожиданием драматично. Под командировку своя задача, под покупку билетов на конференцию — вторая, под визы — третья. Поскольку на старте для меня это было не очевидным, пришлось предварительно поискать ответственных за каждый стрим в HR и уточнить. Типа “вот для командировки оформляй такую-то задачу, а для визы не ко мне, спроси у…”

В итоге я пытаюсь синхронизировать HR-бизнес-процессы, чтобы в сумме они привели меня к шагам 3-4-5. Ощущается это как если бы в маркетплейсе нашёл вещь, а потом договаривался с продавцом о цене, с банком — о переводе денег, с логистами — о доставке вместо того, чтобы просто нажать кнопки “в корзину”-”оформить”-”оплатить”. Хороший сервис забирает рутину с клиента, плохой — добавляет. Хотел бы я, чтобы все HR-процессы были как отличный сервис!

О важности UX-райтинга и понимание языка аудитории (часть 1)

Недавно решил очередной платёж по кредиту погасить в чуть большем размере, чтобы сократить размер последующих платежей. Зашёл в любимую Альфу и пошёл по пути “погасить досрочно”, где встретил вот такой экран. Ответом на вопрос “сколько хотите внести?” очевидным для меня образом стала сумма “платёж” + “вот та моя добавочка”. Я внёс деньги и был сильно удивлён, когда в день по графику банк снова попросил заплатить. Оказалось, что на тот вопрос надо было отвечать лишь цифрой, которую готов отдать сверх платежа. Не поняв этого, я отдал банку ежемесячный платёж в двойном размере. “Спасибо” теперь уже не любимой Альфе за попытку лёгким, но ничего не поясняющим языком общаться со мной в интерфейсе.

Как думаете, почему так произошло? Где в HR-интерфейсах встречаются такие же ловушки?

О важности UX-райтинга и понимание языка аудитории

Продолжение прошлого поста про обманчивый интерфейс приложения от Альфа. Спасибо, за ваши комменты и идеи. Мы выделим три проблемы:

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

В HR, например, мы часто просим что-то согласовать руководителя и не поясняем, что будет дальше. Это вызывает вопросы: “обучение сотруднику уже согласован или нужно ещё получить “ок” от команды обучения?”

2. Двусмысленность вординга. То, что мы пишем в интерфейсах, должно быть однозначно понято пользователем. Сомневаетесь?  Покажите интерфейс и текстовки в нём десяти случайным людям из офиса. Не сомневаетесь? Всё равно покажите. То, что понятно написано для вас, может оказаться вообще неясным для других. Часто мы как профессионалы HR имеем своё представление, что значат слова “менеджер”, “курс” и пр. 


3. Отсутствие связи между поддержкой пользователей и командой продукта. В тот эпизод с выплатой кредита закончился тем, что я обратился в поддержку, которая развела руками и попросила-таки внести ежемесячный платёж второй раз. Мы не знаем, как устроено в Альфе, но хотим верить, что такие сигналы от разгневанного пользователя доходят до команды продукта. И команда продукта, в свою очередь, обладает доступом к статистике обращений.

В HR-роль поддержки часто выполняют HRBP, которым некогда нести все запросы в центр экспертизы. Кроме того, часто такие запросы приходят в личных беседах с сотрудниками и нигде не регистрируются. Тут поможет автоматизация HR-поддержки, сделайте одну точку входа для всех запросов в HR, например, чат или тикеты в Jira. Первым шагом, могут быть регулярные синки центра экспертизы и HRBP после запуска нового продукта.

Мы тоже удивляемся: “за такой маленькой частью интерфейса, стоит так много работы!”

Создаёт ли ваш сервис культуру самоорганизованности и ответственности?

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

При выходе нового сотрудника в мою команду обнаружил у себя очень милое приглашение в календаре, что-то вроде: “У твоего новичка сегодня оформление и велком день. Они закончатся к этому часу, встреть его в офисе через дорогу.”

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

Таким образом, говоря о сервисной модели HR-процессов, мы должны учитывать не только опыт сотрудника, но и какую культуру он создаёт, чтобы потом к нам не бегали с вопросами про парковку и пропуска)

Поделитесь своим опытом, где с одной стороны вы делали многие вещи сами как клиент, но при этом было ощущение заботы и понятности? Мы вспомнили миниму две компании с таким сервисом, поделимся чуть позже в комментах

Бесит, когда тебя  просят подстроиться под робота!

Жутко злит, когда звонит какой-то непрошенный продавец услуги, ты берёшь трубку с мыслью: “А вдруг что-то полезное, наконец?!” — А там музыка или робот говорит: “Подождите минуту, вам ответит оператор”. — “Что?! Реально!?”

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

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

HR для себя может сделать вывод, что при автоматизации сервисов, надо очень точно найти баланс между человеческим общением и роботом. Бот может напомнить человеку про обучение, но не должен быть единственным способом вести диалог о развитии.

Друзья, мы хотим делать для вас лучший контент! Расскажите о себе
 
Мы очень рады, что нас тут уже так много. Видимо, развитие HR-продуктов и наши размышления на эту тему позволили собраться достаточно большому сообществу.
 
Звучит, как отличный повод “пересчитаться”! Вы получите понимание рынка специалистов, мы познакомимся с вами получше. Вместе будем делать сервис HR не хуже, чем в B2C-продуктах!

“Угловой случай” в вашем продукте: корнер кейс

Сегодня пост — из серии “в клиентских продуктах есть, а в HR пока не очень”(теперь помечаем такие хештегом #старший_брат). Речь про понятие “корнер-кейс” (в оригинале — corner case, как легко догадаться). Термином обозначают редкие и нестандартные примеры использования сервиса, которые создают большие сложности.

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

Чтобы ваш продукт попадал в высшую лигу, собирайтесь с командой и продумывайте такие “несчастные случаи”. Например, что случиться с формой, где сотрудник написал коллеге развернутый фидбек, если он случайно закроет браузер? Данные сохраняется при открытии страницы? А если да, то как пользователю найти эту страницу?

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


#понятие #старший_брат

Корнер кейс: сбор обратной связи на уникальных разработчиков

Мы уже писали о ценности сбора обратной связи от пользователей своего продукта и про понятие “корнер-кейс”. Поделюсь, как мне удалось, общаясь с пользователями, найти такой кейс при запуске платформы для непрерывной обратной связи (continuous feedback).

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

В разговоре с одним из руководителей разработки я услышал такую фразу об одном из его инженеров: “Во всём СНГ такого уровня специалистов 5 человек, один из них работает у нас. Что мы будем делать, если кто-то из коллег оставит отрицательную обратную связь, а ему это не понравится?”. Хорошего ответа у меня не нашлось, но этот пример натолкнул на мысль, что руководителям (и не только тем, кто боится “дышать” на команду), действительно, будет полезно иметь возможность скрывать или открывать обратную связь самостоятельно.

Таким образом, единичный, но яркий случай использования продукта подсветил точки роста, полезные многим, и лишний раз напомнил о том, что любой запуск нужно замыкать сбором фидбека, который даёт старт новому витку улучшений.

Knowledge journey map — почему бы и нет?
   
Мы уже не раз разбирали примеры проектирования опыта учащегося с помощью продуктовых практик. Например, смотрели на взаимодействие с ботом для нотификаций из LMS. В этом посте решили пойти чуть дальше и посмотреть с нового ракурса (или отдельная строка на карте), который мы предлагаем добавить — это объём преподаваемого контента.
 
При создании курсов мы чаще склонны отвечать себе на вопрос: “что я хотел бы рассказать?”, чем “что слушатели уже знают и готовы воспринять сверх?” В этом кроется риск нагрузить аудиторию контентом, к которому она не готова, хоть он и качественен, подробен и объёмен.
 
Представьте, что вы готовите вебинар для начинающих руководителей, которые впервые будут проводить оценку работы своей команды. Первый соблазн — рассказать вообще всё: про итоги оценки (повышение, понижение, премии), систему оценок, встречи один на один с сотрудниками и многое другое. Голова новичка лопнет уже на втором пункте.
 
Второй соблазн — выстроить всё по порядку: от постановки целей до встреч один на один о результатах. Новичок рискует не получить необходимых здесь и сейчас знаний (например, про то, что ревью — это что-то, что может привести к повышению грейда) до конца курса.
 
Для борьбы с этими соблазнами есть хороший проверочный вопрос, который предложила Анастасия Мизитова, когда мы однажды готовили вебинар для VK по оценке: "А вашей аудитории точно нужны такие подробности?".
 
Нужный объём деталей и тем давайте нанесём на нашу employee knowledge journey map. От блока к блоку внутри урока. От урока к уроку внутри курса. От курса курсу. Как по лесенке будут взбираться наши слушатели от той базы, которой обладают к тому объёму, который мы хотим им дать.