В реальном бизнесе команды редко живут «в домике», где ничего не меняется годами. Хочешь ты того или нет, извне постоянно поступают новые вводные. Это непрерывный конвейер: только адаптируешься к последним изменениям, переживешь их, как курс снова меняется. Начинается вынужденный переезд на другие сервисы, запускается масштабирование, глобально перестраивается рабочий процесс и т. п.
Задача руководителя в этих условиях — уменьшить стресс сотрудникам да и самому себе.
Меня зовут Екатерина, я руковожу саппортом в МТС Линк. Специфика поддержки — любые изменения увеличивают количество вопросов от пользователей. То есть нам надо не только самим не сойти с ума, но и снять негатив у клиентов, которые не всегда понимают ситуацию. В этом материале поделюсь своим опытом, как мы готовимся к изменениям и как нам это помогает их преодолевать. Перемены неизбежны, но простые действия и предварительная подготовка позволят чувствовать себя комфортно и сохранить команду.
Жизнь в эпоху перемен
В последние годы наша команда прошла очень интересную череду изменений.
Изначально мы работали под названием Webinar.ru, но с расширением продуктовой линейки старый бренд стал нам «тесен» — потребовалось сменить название и фирменный стиль.
Ребрендинг — это не «просто перекрасить логотип». Меняется миссия, позиционирование, видение будущего. В таких условиях необходимо быстро адаптироваться, параллельно преодолев неприятие изменений, которое встречается и в команде, и среди клиентов.
Одновременно с российского рынка массово уходили иностранные вендоры. Пошла волна перехода на отечественные инструменты — появились запросы от новых клиентов.
Казалось бы, бери и радуйся такому бурному росту. Но саппорту в тот момент пришлось тяжко. Крупным клиентам в условиях экстренной миграции, конечно же, хотелось усиленную поддержку. У многих из них были настроенные в иностранных продуктах интеграции через API — все это требовалось быстро реализовать в рамках МТС Линк. Для нас это был настоящий вызов.
Почти сразу после такого экстремального роста мы сами начали менять рабочие инструменты:
Переехали на собственный мессенджер.
Поменяли главный рабочий инструмент — хелпдеск.
Перешли на новую базу знаний, что потянуло за собой изменение логики поиска. При этом саму базу, накопленную за долгие годы, нужно было сохранить в полном объеме.
С новыми инструментами, естественно, появились новые регламенты работы, т. е. у большинства инженеров серьезно изменилась их ежедневная рутина.
Каждое из этих изменений само по себе — стресс для коллектива, а вместе это просто <censored>. Но мы с ними справились, выработав некий общий подход к любым преобразованиям, о котором и расскажу ниже.
Как подготовиться к изменениям
Не пытайтесь все провернуть в одиночку — соберите команду
С самого начала не надо пытаться справиться с ситуацией в одиночку. Привлеките к решению проблемы продвинутых сотрудников, чьи сферы интересов также затрагивают эти изменения. На время преобразований все вы станете единой командой, которая справится с изменениями.
Важно понимать, какие функции рабочих инструментов востребованы больше всего, какие принципиальные моменты есть в текущем процессе. В бизнесе всегда вокруг есть люди — они подскажут, что делать.
При смене хелпдеска (программы приема обращений, публикации базы знаний и рассылки триггерных сообщений и подсказок) для переезда нам удалось собрать команду из:
руководителей групп специалистов поддержки (настройка ИИ-бота, перенос сотрудников, инструкции, обучение, контроль правил распределения заявок, настройка welcome-бота);
специалистов из нового хелпдеска (перенос существующих диалогов и базы знаний пользователей);
разработчиков МТС Линк (настройка переноса данных, виджета в личном кабинете, проверки совместимости, выполнение интеграции для заявок, передающихся по API);
СТО и СРО (контроль плана переезда, трудозатрат, оценка масштабирования нового хелпдеска);
маркетинга (обучение и настройка триггерных сообщений для обучения и освоения навыков, распространения информации о дайджестах и т. д.).
Проведите анализ доступных решений
Реагируя на изменения, не хватайтесь за первое попавшееся решение. Проанализируйте разные варианты. Если речь идет о замене инструмента, посмотрите рынок.
По итогам анализа я составляю обычную табличку с плюсами и минусами, поддержкой нужных мне сценариев работы, функций, а также ценой. Так проще выбрать оптимальный вариант.
При смене инструментов я рекомендую присматриваться к тому, есть ли на стороне вендора команда, которая поможет на этапе переезда. На мой взгляд, в рамках адаптации к новым инструментам не стоит запираться внутри компании, рассчитывая только на свои силы — нужно пользоваться всей помощью, которая есть вокруг.
Примерно по этой схеме мы и действовали при смене хелпдеска:
посмотрели имеющиеся решения;
составили сравнительную таблицу;
выделили наиболее важные аспекты для переезда;
совместно с руководством выбрали решения на тест силами нескольких сотрудников.
Ключевыми факторами при выборе стали:
наличие success-команды для внедрения решения;
затраты на доработки и переезд.
Не застревайте на этапе анализа!
Мы наступали на эти грабли: когда к нам пришло много новых клиентов для тестирования продукта, мы слишком долго анализировали, чего же им не хватает. По статистике мы заметили, что в рамках пробного периода клиенты до нас не доходят. Они пробуют продукт, сталкиваются с техническими проблемами и отваливаются. Им можно было бы помочь, но на этом этапе у клиентов еще нет закрепленного менеджера, который бы отследил их проблемы.
Мы подумали, что будет логично сделать выделенную линию поддержки для тех, кто только нас тестирует. Но мы очень долго присматривались к этой идее, так как это создавало дополнительную нагрузку на команду. В итоге мы все-таки выделили сотрудников и раскрутили этот процесс, но упустили довольно много времени (и потенциальных клиентов).
Подготовьте план изменений
Резко вынуть старое и вставить взамен новое не получится — обязательно что-то сломается. Поэтому вне зависимости от того, что меняется — инструмент или процесс — нужно составлять план с оценкой основных этапов. Я в нем еще расписываю шаги в рамках каждого этапа, указывая, в том числе, дедлайны и ответственные стороны.
В плане важно отметить основные пункты, которые должны быть реализованы в новом процессе или инструменте. Приходится мириться с тем, что нововведения редко перекрывают всю старую функциональность. Но всегда есть ключевые элементы, которые надо сохранить. Например, поддержка должна продолжать принимать заявки от клиентов. А детали настройки интерфейса сотрудника, возможно, на этапе внедрения не так и важны.
Перед реализацией план нужно обязательно показать рабочей группе. Также надо понимать, что вы будете делать дальше, после завершения текущего плана. Основные функции вы внедрением закроете, но может, нужны будут новые интеграции?
Проработка плана часто показывает, что придется затронуть «соседние» рабочие процессы. У нас так случилось при замене хелпдеска. В старом инструменте была интеграция для автоматической передачи запросов на новую функциональность в продуктовую команду. В новом хелпдеске подходящего плагина не было, поэтому мы закрыли задачу другим способом и включили его в план.
Заранее готовьте коллег
Проводите встречи, предупреждайте о грядущих изменениях. Напоминайте, что все пройдет хорошо. Что переход — штука сложная, но команда справится. Если коллеги будут морально и физически подготовлены, все пройдет по плану.
Лучше, если подобные встречи проходят в доверительной обстановке. Так коллеги будут знать, куда пойти и кому сообщить, если они не смогут решить какие-то проблемы при переходе самостоятельно.
Если проявляется сильный негатив, можно проводить встречи один на один, выслушивать обратную связь и, если она конструктивна, обсуждать ее с продуктовой командой. Так сотрудники будут чувствовать свою причастность к настройке работы — видеть свое влияние на ситуацию.
В ходе переезда на новый хелпдеск мы собирали информацию о сложностях в работе через формы обратной связи для сотрудников. Озвученные запросы отрабатывали напрямую с выделенной командой. Благодаря этому, например, нам всего за несколько недель реализовали критичную доработку, позволяющую контролировать присутствие сотрудников на рабочем месте и автоматически переводить диалоги на дежурных смены в случае отсутствия. Насколько это важно, стало понятно именно по обратной связи от сотрудников.
Подобная подготовка помогает сконцентрироваться на плане переезда и необходимых шагах, а не на сопротивлении. В нашем случае мы смогли удержать качество обработки обращений клиентов в процессе изменений. При смене хелпдеска мы заранее провели встречи и обучение, подготовили инструкции, морально поддерживали ребят, чтобы они понимали происходящее. К моменту окончательного перехода многие из них уже успели попробовать новый интерфейс (мы раздавали тестовые доступы).
Протестируйте решение на небольших группах
Подробный план внедрения изменений важен, но нужно помнить, что он не является панацеей. Надо настроиться на то, что он покрывает какую-то часть процесса, но что-то обязательно останется вне зоны видимости. Эта серая зона может ухудшить процесс перехода или даже стать блокирующим фактором.
Чтобы проверить, как изменения будут внедряться, действительно ли переход пройдет плавно, стоит протестировать разработанный план на части бизнеса — небольшой группе сотрудников или отдельных процессах. Так при переезде на собственный мессенджер мы проверили его заранее — к моменту внедрения сотрудники уже хорошо знали интерфейс. Поэтому переход произошел достаточно быстро.
Если возможности для тестов нет, нужно принять, что в процессе реализации плана придется что-то придумывать на ходу. У нас так было при замене хелпдеска. Нам нужно было провести миграцию максимально быстро и бесшовно для клиентов — нельзя просто отключить прием заявок на час или два. Увы, но в процессе перехода выяснилось, что на бэкенде есть баг, который блокирует прием определенных категорий заявок. Пришлось срочно откатывать внедрение. Спасибо команде разработки, ошибку нашли быстро (до этого на тестовых стендах она просто не проявлялась). На следующий день мы переехали уже окончательно — клиенты практически ничего не заметили.
На всех этапах собирайте обратную связь от коллег и правильно на нее реагируйте
Я много про это говорила выше, но хочу обратить внимание еще раз. Изменение методов работы — процесс сложный. Его часто сопровождает негатив. Он может быть вызван естественным консерватизмом, но бывают и резонные замечания. Упускать из виду не стоит ни тот, ни другой.
Субъективный негатив надо обсудить и поддержать коллег, чтобы им было проще с ним справиться. А конструктивные комментарии к новому процессу или инструменту вполне могут улучшить пользовательский опыт всего коллектива. При этом я рекомендую давать фидбэк о дальнейшей судьбе высказанных замечаний.
Во многих ситуациях обратную связь стоит собирать и с клиентов. Иногда даже надо поставить отдельных людей, которые будут обрабатывать и реагировать на их фидбэк. Так можно успеть что-то исправить (то, что больше всего «болит» после переезда).
Подготовьте план на случай ЧП
При организации бесперебойной работы чего-либо всегда очень важно прорабатывать план на случай ЧП. В новостях иногда мелькают примеры того, как развиваются события, когда плана на случай ЧП нет. На примере таких ситуаций мы проработали переключения основных каналов, заранее договорились с резервными сервисами, продумали информирование, подготовили релизы оповещений на основных сайтах.
Договоритесь с коллегами, что сделать, если придется что-то куда-то переключать, экстренно оповещать пользователей и т. п. Это сильно упростит вам жизнь. Понятно, что все предусмотреть невозможно. Но выделить основные точки, от сбоя которых будет хуже всего, вполне по силам. Найдите, чем их заменить. Проинструктируйте команду, к кому в этом случае обращаться.
Что, если времени на все это нет?
Все изложенные выше советы отлично работают, если мы говорим о каких-то плановых изменениях — о том же ребрендинге или смене хелпдеска. Как правило, в этих случаях остается время на обсуждения важных моментов. Возможно, у вас не будет двух месяцев на предварительное тестирование и придется запускать решение в работу сразу на всех сотрудников. Но даже если вы сталкиваетесь с подобной историей впервые в жизни, рядом будут коллеги, которые подскажут (по крайней мере со своего ракурса).
Но часто возникают и более спонтанные изменения, когда план приходится выдумывать на ходу. Этапы смешиваются, прогнозирование ломается. В таких ситуациях я рекомендую поговорить со всеми причастными и попытаться для себя и команды выделить несколько основных моментов (функций, задач, процессов), на которых необходимо сконцентрироваться в первую очередь. Это нужно для того, чтобы не зависнуть в эдакой стрессовой ситуации надолго, а максимально быстро перейти в плюс-минус стабильный режим функционирования.
Самый важный этап — это адаптация к новым условиям
Практика показывает, что после любых изменений следует длительный период адаптации. В моменте ты закрываешь основную задачу, но дальше долго выстраиваешь всю работу по-новому.
Для себя я придумала аналогию с трансплантацией органа. Переезд — это хирургическая операция. Но затем орган начинает приживаться, и это очень важный этап. Так же с ИТ-решениями и процессами: после переезда важно нужно не упустить, прорабатывая шаг за шагом все, что не было сделано во время «операции».
По своему опыту могу сказать, что впечатления от переезда у коллег формируются именно на последнем этапе. Когда первый стресс отступает, они видят, что нечто идет не так, как было раньше, чего-то не хватает. Нужно снова собирать обратную связь. Анализировать ее и прорабатывать это в дальнейших шагах.
При внедрении нового хелпдеска у нас был в мессенджере новостной канал, где обсуждали все, чего не хватает. Мы собирали пожелания и составляли бэклог с учетом приоритетности. При этом разработчики решения выделили команду, которая реализовывала под нас подобные запросы.
В качестве критерия успеха в адаптации к изменениям обязательно должен фигурировать показатель стабильности команды. Если коллектив сохранился, то изменения прошли успешно.