В нашем Телеграм-канале мы рассказывали про команду Research&Development и предложили помощь с разбором саппортовой или клиентской задачи. Отправили второй отчет и теперь делимся им с вами.
Рассказываем, как Internal Product Management и управление изменениями помогут снизить сопротивление изменениям, и как руководители команд саппортов в Рокетбанке работали с негативом в момент внедрения новой самописной админки.
— Как сохранить лояльность саппортов, если есть технические проблемы с самописной рабочей системой сотрудников чата?
Постановка проблемы
Определяем истинную проблему, исходя из вопроса
Кейс — про управление изменениями и менеджмент внутренних продуктов, то есть отношение к сотрудникам как ко внутренним клиентам.
Исходные данные
Как все устроено сейчас. Ниже будем рассматривать исследования и опыт, наиболее релевантные для этой ситуации
Команда
- 30 специалистов, по 15 в смене.
- 2 руководителя смен и 1 руководитель отдела.
- Средний возраст специалистов — около 22-х лет, много молодых ребят 18–20.
- Сейчас работают удаленно.
Каналы связи
- Чат
- Соцсети
Встречающиеся в админке проблемы
- Долго открываются диалоги.
- Внезапно переключаются онлайн/офлайн.
- Оператор думает, что «встал в офлайн» и уходит на перерыв, но система еще считает, что он онлайн и присылает ему новые обращения.
- Периодически не отправляются сообщения клиенту.
Наука
Рассказываем про два направления в менеджменте: Internal Product Management и управление изменениями, которые концентрируются на работе с сотрудниками для успешных нововведений
Internal Product Management
Что это
В продуктовом менеджменте есть направление, которое называется Internal Product Management (менеджмент внутренних продуктов) — это решение проблем внутренних пользователей, то есть сотрудников компании.
Результат Internal Product Management — это продукты компании, предназначенные не для продажи другим, а для использования внутри компании для поддержки бизнес-задач, куда также входит саппорт.
Зачем это нужно
Главная задача внутреннего продакт-менеджера такая же, как и обычного продакт-менеджера, ориентированного на внешних клиентов — создание продукта, который успешно решает проблему пользователя. Поэтому и в работе они придерживаются общих целей:
- Донесети до руководства компании ценность продукта.
- Оценить, насколько хорошо продукт решает проблему пользователя.
- «Продать» продукт пользователю, то есть донести ценность продукта уже до тех, кто будет его использовать. Для этого используют приемы маркетинга:
- Регулярные почтовые рассылки
- Посты в корпоративном блоге
- Лендинг внутреннего продукта
- Продуктовая инфографика
- И даже рекламные постеры в офисе
- Рассказать, как эффективно пользоваться продуктом:
- Руководство пользователей
- Видеоинструкции
- Техническая документация
Это философский вопрос: готовы ли в компании относиться к сотрудникам как ко внутренним клиентам? Внутренняя админка тоже делается для клиента. Этот клиент — саппорт.
Нужно рассказывать, над какими задачами работают. Делать голосования: какие баги самые важные и больше бесят или с какими чаще всего сталкиваетесь? Давать ощущение, что фидбэк не уходит в никуда.
Это полноценная работа над продуктом.
Управление изменениями
Что это
Непрерывно разрабатывающийся софт — это постоянные перемены. Когда люди привыкли к одному багу, появился второй, только устранили первый и появился третий — это вызывает стресс, в результате которого количество негативно настроенных сотрудников и сопротивление изменениям растет.
Управление изменениями — это структурный подход, который помогает компаниям внедрять изменения, снижая сопротивление сотрудников этому. Он описывает, как подготовиться самому и подготовить сотрудников к преобразованиям, начиная от этапа, когда изменения только планируются, и заканчивая их внедрением и адаптацией.
Ключевые концепции
Так как в компании Ильи софтом уже пользуются, начальными этапами этого подхода можно пренебречь. Мы остановимся на тех ключевых концепциях управления изменениями, которые наиболее релевантны сейчас.
➀ Инициатор и исполнитель
Инициатор — это человек, который планирует и сообщает об изменениях (руководитель). Исполнитель — тот, на кого влияют изменения (сотрудник). Хотим подчеркнуть, что сопротивление изменениям со стороны сотрудников — не исключение, а норма.
Для успешного внедрения изменений с наименьшим сопротивлением сотрудникам важно услышать от первого лица компании мотивы изменений и то, какие негативные последствия будут, если ничего не менять.
Для этого подойдет общее собрание всей компании/команды — пригласить на него фаундера, людей, ответственных за изменения, и самих сотрудников. Рассказать, что случится, где и как можно собрать вопросы, как сотрудники получат ответы на них.
➁ Сопротивление и дискомфорт
Привычка имеет огромную силу, поэтому изменения вызывают беспокойство и неуверенность. К неуверенности добавляется дискомфорт, если сотрудник не может влиять на изменения.
На отношение сотрудника к изменению влияет много личных факторов: ситуация в семье, финансовая защищенность, возраст, здоровье, карьерные ожидания. Сейчас весь мир нестабилен, помимо работы на людей давит пандемия, финансовый кризис. Любое новое нарушение баланса увеличивает сопротивляемость.
Также влияние оказывает история прежних изменений в компании — какие были из-за этого проблемы, и эффективно ли они решались.
➂ Полномочия на изменения
Важно, чтобы руководство активно показывало пользу изменений и свою поддержку:
- Явно и активно участвовать в изменении.
- Напрямую взаимодействовать с сотрудниками, объясняя необходимость изменений и вызванных ими проблем.
Чтобы сотрудник смирился с временными проблемами и полностью поддержал изменение, он должен проникнуться его необходимостью.
Наш опыт
Рассказываем, как в Рокетбанке работали с негативом саппортов при переходе на новую самописную админку. Приводим цитаты капитанов поддержки
Что было
В Рокетбанке всегда была самописная админка, поэтому мы несколько раз сталкивались с похожими проблемами.
У самостоятельно разработанных платформ есть плюсы вроде удобно расположенных нужных кнопок, но есть и минусы: если какой-то функционал устаревал из-за развития бизнеса, то приходилось либо обновлять админку, либо разрабатывать новую.
Несколько раз работали именно по второму варианту. Поэтому MVP был сырым, мешал работе: где-то была неправильная информация, сообщения не подгружались или несколько раз отправлялись, каких-то данных не было — в результате саппорты негативили на разработчиков и не верили, что они активно пытаются исправить баги.
Что с этим делали
➀ Подключали саппорт к решению проблем
Придумали процесс, чтобы каждый раз, когда кто-то сталкивается со сложностью, разработчики быстро о ней узнавали.
Мы выделили специальную группу, которая ходила на скрамы с разработчиками и вместе с ними приоритизировала задачи: смотрели с какими багами чаще сталкиваются, с какими нет.
Мы настроили процесс, и у ребят появилось ощущение, что на это не забили. Они поняли, как устроена разработка изнутри: как идет работа и как на нее повлиять. Они сами стали разбираться, что сейчас критично, а что нет.
➁ Выделяли дни, чтобы пообщаться с саппортами
Проводили 6-часовые тренинги, где обсуждали проблемы.
Постоянно рассказывали, зачем это нужно, почему это делается и для чего это происходит. Писали об этом в письмах и проводили встречи.
Единого рецепта не было: с одним человеком работали одни вещи, с другим — другие. Кому-то нужно было объяснить, что это закончится. А второму нужно было дать понять, что он очень круто делает свою работу — и уже неважно, исправят баги или нет.
Мы очень много про это разговаривали. Негатива было много, но всегда старались переводить его в конструктивное русло: что мы можем с этим сделать, как мы можем это исправить. Было очень важно показать, что нам не все равно.
➂ Вовлекали саппорт в процесс создания админки
Учитывали пожелания по внешнему виду, расположению кнопок и необходимых функций.
Новую админку мы буквально рисовали вместе с основателями: думали куда и какие кнопки поместить. Нужно вовлечь всех, реализовывать их идеи. Показывать, что их слышат. Это банальные вещи, которые всем известны — но они работают.
Когда человек чувствует себя причастным к проекту, то у него меньше pushback возникает. С самого начала ребята принимали участие и, например, прописывали какой функционал и где нужен. Несколько человек выписывали какие-то функции из старой админки, и к ним приходили за советом как к экспертам — это точно повышает лояльность.
Выводы
Что учитывать из Internal Product Management и управлении изменениями, какие выводы можно сделать из нашего опыта в Рокетбанке
Internal Product Management
При разработке продуктов для пользования внутри компании нужно относиться к сотрудникам так же, как к клиентам — такой подход позволит завоевать лояльность коллег:
- «Рекламировать» продукт: рассказывать и показывать, каким крутым он будет, когда завершится разработка.
- Помогать с использованием: писать руководства пользователя, делать видеоинструкции по работе и т.п.
- Убедиться, что саппорты знают, кто сможет помочь, если у них возникла проблема с платформой — создать внутреннюю службу поддержки для сотрудников.
Управление изменениями
Отлично, если первое лицо компании участвует во взаимодействии с сотрудниками и рассказывает лично, почему необходимы изменения и неизбежны вызванные ими проблемы. А еще круче, если сам время от времени будет пользоваться — даже опосредованно, например, просто посидит на линии вместе с саппортом и посмотрит на баги вместе с ним. Это поможет снизить сопротивление изменениям, потому что покажет, что о трудностях известно тем, кто принимает решения, а значит они не остаются без внимания.
При работе с негативом стоит учитывать, что на эмоциональное состояние влияют и личные факторы. Поэтому объяснения, что проблемы с платформой исправят, могут и не сработать.
Также влияние на негатив оказывает история прежних изменений в компании — какие были из-за этого проблемы, и эффективно ли они решались. Если до этого обещали исправить какие-то проблемы, но они так и остались, то доверие к словам будет ниже, а значит, их надо будет с удвоенной силой подкреплять делами.
Наш опыт
Пока ребята из поддержки не начали участвовать в работе над новой админкой, не увидели, как построен процесс разработки и как исправляют ошибки — было много негатива и недоверия. Когда их подключили к решению проблем, они изменили свое отношение к багам: вместо негатива они видели возможность помочь и сделать админку лучше.
Рекомендации
Какие решения для сохранения лояльности мы считаем лучшими
- Уделите время тому, чтобы красочно и наглядно продать/показать, какие преимущества у вашей платформы, почему с ней лучше, чем с другими доступными на рынке.
- Привлеките к работе с саппортами тех, кто принимает решения — это покажет, что их готовы слушать и услышать.
- Учитывайте предложения саппортов при разработке — это будет лучшим доказательством, что к их мнению прислушиваются.
- Подключите саппортов к решению проблем, позвольте им участвовать в собраниях с разработчиками, обсуждайте с ними приоритизацию решения багов — личное участие и наблюдение за процессом разработки поможет решить проблему с недоверием.
Насколько у саппортов реально есть возможность влиять на продукт? В Рокете была. И если бы не было, то команду я бы не удержала. Нам нравилось, что была возможность влиять на все.