Как делегировать зону ответственности, если под неё нет отдельной роли в команде
Пошаговый алгоритм на примере зоны ответственности с широким набором функций
Кейсы из опыта консультанта Алеси Малковой
#кейсы #управление
Хочу рассказать историю о том, как мне удалось делегировать большую зону ответственности, связанной с техподдержкой в онлайн-школе. Я расскажу:
Меня зовут Алеся Малкова, я консультант по управлению и карьерному развитию руководителей. Работаю на курсе «Управление командой» в Яндекс.Практикум и развиваю свой телеграм-канал «Человек и бизнес».
- как выявить «скрытые» операционные нагрузки;
- как с помощью документации сделать делегирование устойчивым;
- какой эффект даёт даже частичное перераспределение обязанностей.
Меня зовут Алеся Малкова, я консультант по управлению и карьерному развитию руководителей. Работаю на курсе «Управление командой» в Яндекс.Практикум и развиваю свой телеграм-канал «Человек и бизнес».
Исходная ситуация
В чём была сложность с точки зрения передачи кому-то этой задачи.
Первая сложность была следствием того, что в начале проекта техподдержка была в слепой зоне – ни я, ни собственник не воспринимали это как полноценную функцию и не планировали сотрудника для этой задачи. И на старте это было обоснованно – на почту приходила парочка вопросов, на которые я отвечала за пять минут, и на этом всё. Но когда мы начали активно размещать рекламу и привлекать учеников, я в какой-то момент осознала, что на вопросы техподдержки я стабильно трачу пару часов в день.
Частая история для руководителя «так исторически сложилось, что это моя зона ответственности, хотя это вообще не мой уровень задач». Отсюда мой любимый пример про разноуровневые задачи: утром руководитель отвечает на вопросы техподдержки, а вечером годовую стратегию бизнеса защищает. Это я говорю про себя :)
В чём была сложность с точки зрения передачи кому-то этой задачи.
Первая сложность была следствием того, что в начале проекта техподдержка была в слепой зоне – ни я, ни собственник не воспринимали это как полноценную функцию и не планировали сотрудника для этой задачи. И на старте это было обоснованно – на почту приходила парочка вопросов, на которые я отвечала за пять минут, и на этом всё. Но когда мы начали активно размещать рекламу и привлекать учеников, я в какой-то момент осознала, что на вопросы техподдержки я стабильно трачу пару часов в день.
Частая история для руководителя «так исторически сложилось, что это моя зона ответственности, хотя это вообще не мой уровень задач». Отсюда мой любимый пример про разноуровневые задачи: утром руководитель отвечает на вопросы техподдержки, а вечером годовую стратегию бизнеса защищает. Это я говорю про себя :)
В начале проекта техподдержка как функция была в слепой зоне.
Вторая сложность делегирования техподдержки заключалась в том, что в онлайн-школе вопросы пользователей затрагивают широкий набор зон:
- контент уроков («почему в passe' compose' использовали j'ai descendu? когда должно быть je suis descendu»);
- email-рассылки («у вас ссылка в письме не открывается»);
- техническую работу сайта («у вас кнопка купить не работает»);
- техническую работу личного кабинета («у меня урок в кабинете не включается»);
- техническую работу сторонних сервисов («у меня оплата не проходит»)
и многое другое.
И в разрезе делегирования я получаю такой парадокс: с одной стороны, в проекте нет человека, кому можно передать такой широкий набор задач. С другой стороны, для отдельной роли и найма нового человека мало работы. Студенты-ассистенты на два часа в день тоже идут мимо всё также из-за широкого набора задач и необходимости погружаться в специфику.
- контент уроков («почему в passe' compose' использовали j'ai descendu? когда должно быть je suis descendu»);
- email-рассылки («у вас ссылка в письме не открывается»);
- техническую работу сайта («у вас кнопка купить не работает»);
- техническую работу личного кабинета («у меня урок в кабинете не включается»);
- техническую работу сторонних сервисов («у меня оплата не проходит»)
и многое другое.
И в разрезе делегирования я получаю такой парадокс: с одной стороны, в проекте нет человека, кому можно передать такой широкий набор задач. С другой стороны, для отдельной роли и найма нового человека мало работы. Студенты-ассистенты на два часа в день тоже идут мимо всё также из-за широкого набора задач и необходимости погружаться в специфику.
Парадокс: с одной стороны, в проекте нет человека, кому можно передать такой широкий набор задач. С другой стороны, для отдельной роли и найма нового человека мало работы.
Третья сложность заключалась в том, что часть вопросов техподдержки на тот момент входили непосредственно в зону моей ответственности: например, email-рассылки и взаимодействие с разработчиками. Но одно дело отвечать за эту зону, а другое – дополнительно два часа в день отвечать на связанные с этим вопросы. Это как если бы менеджеры по продажам постоянно приглашали на свои встречи с клиентами опытного айтишника – он же лучше всех расскажет о технических особенностях продукта. Да, но – это доп.нагрузка, которой никому не хочется.
Что было сделано
Первое правило, которое мне помогло в этой ситуации запустить процесс делегирования: не можешь передать зону ответственности полностью – передай часть. И первой стороной, которая получила свою часть работы, стали сами пользователи :) Я подготовила страницу с FAQ, который мы разместили на странице с формой обратной связи. Для убедительности написали, что запросы обрабатываются в течение 1-2 рабочих дней, чтобы мотивировать людей искать ответы на свои вопросы в разделе FAQ.
Через какое-то время я договорилась с копирайтером, что она будет обрабатывать вопросы, которые не затрагивают техническую сторону проекта. Для неё я подготовила более расширенную версию FAQ и первые инструкции для внутренних задач, связанных с вопросами пользователя.
Очень важный момент, который стал для меня доступен благодаря подключению копирайтера: она начала фильтровать типы запросов и я подключалась к техподдержке, только если там появлялись вопросы по моей части. Допустим, сотрудник мог ответить на 20% обращений, но поскольку я захожу и вижу только вопросы для меня, я начала тратить на техподдержку в среднем не более 1 часа. Т.е. моя нагрузка сократилась на 50% – очень классный пример того, что при делегировании задач освобождение времени нелинейно, и даже передача маленького кусочка задач может освободить существенное количество времени. Я получила +5 свободных часов в неделю! Считай рабочий день.
Постепенно я делегировала всё направление email-маркетинг, ещё позже – взаимодействие с разработчиками. Вместе с этим сотрудники забрали на себя и соответствующие блоки техподдержки.
Первое правило, которое мне помогло в этой ситуации запустить процесс делегирования: не можешь передать зону ответственности полностью – передай часть. И первой стороной, которая получила свою часть работы, стали сами пользователи :) Я подготовила страницу с FAQ, который мы разместили на странице с формой обратной связи. Для убедительности написали, что запросы обрабатываются в течение 1-2 рабочих дней, чтобы мотивировать людей искать ответы на свои вопросы в разделе FAQ.
Через какое-то время я договорилась с копирайтером, что она будет обрабатывать вопросы, которые не затрагивают техническую сторону проекта. Для неё я подготовила более расширенную версию FAQ и первые инструкции для внутренних задач, связанных с вопросами пользователя.
Очень важный момент, который стал для меня доступен благодаря подключению копирайтера: она начала фильтровать типы запросов и я подключалась к техподдержке, только если там появлялись вопросы по моей части. Допустим, сотрудник мог ответить на 20% обращений, но поскольку я захожу и вижу только вопросы для меня, я начала тратить на техподдержку в среднем не более 1 часа. Т.е. моя нагрузка сократилась на 50% – очень классный пример того, что при делегировании задач освобождение времени нелинейно, и даже передача маленького кусочка задач может освободить существенное количество времени. Я получила +5 свободных часов в неделю! Считай рабочий день.
Постепенно я делегировала всё направление email-маркетинг, ещё позже – взаимодействие с разработчиками. Вместе с этим сотрудники забрали на себя и соответствующие блоки техподдержки.
Не можешь передать зону ответственности полностью – передай часть.
Ключевые выводы
Эта ситуация показала мне несколько важных принципов делегирования, которыми хочется поделиться:
Эта ситуация показала мне несколько важных принципов делегирования, которыми хочется поделиться:
- Делегирование может быть поэтапным. Это особенно актуально, когда зона ответственности большая, имеет разнородную структуру, при этом в компании нет возможности передать направление полностью одному человеку.
- Документация — основа устойчивости. Инструкции позволяют формировать базу знаний, к которой сотрудник может обращаться в случае вопросов.
- Элементы «самообслуживания» снижают нагрузку. Раздел «Вопросы и ответы» для пользователей сокращает поток рутинных вопросов.
- Гибкость важнее «должностной инструкции». Можно распределить обязанности между существующими сотрудниками – это только вопрос ваших договорённостей.