It takes everybody: делегируем команде

Меня зовут Катя, я руковожу операционным отделом ITSM 365 в Naumen.

Несколько лет назад у меня была одна команда из трех аналитиков. Сейчас — три команды, три тимлида, два техлида и пятнадцать аналитиков. Вместе с ростом команды, разумеется, росло и количество процессов, в которые я была вовлечена.

И вроде бы все было хорошо: задачи закрывались, заказчики были довольны, команда справлялась с нагрузкой. Но со временем я начала замечать, что значительная часть процессов постепенно замыкается на мне. Тогда задала себе простой вопрос: что будет, если я на время выпаду из работы?

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

Что происходит, когда процессы держатся на одном человеке

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

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

Однако с ростом команды система начинает давать сбои:

• решения принимаются дольше;

• снижается самостоятельность команды;

• растет нагрузка на руководителя;

• появляется риск остановки процессов.

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

А еще оказалось, что проблему нельзя решить простым делегированием отдельных задач. Если процесс изначально построен вокруг одного человека, передача ответственности другому сотруднику создает новую точку зависимости.

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

Почему передавать процессы оказалось сложно

Когда я решила что‑то менять, оказалось, что основное ограничение находится не в команде, а в моей голове.

Вот три страха, которые мешали мне передать ответственность.

Страх №1. «А что буду делать я? Меня же уволят»

Наверное, это самый иррациональный, но при этом очень распространенный страх у руководителей.

Когда долго держишь на себе большое количество процессов, начинает казаться, что именно это и делает тебя ценным. Если команда сможет справляться самостоятельно, то что тогда останется руководителю?

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

Именно тогда появляется возможность заниматься теми задачами, которые действительно невозможно делегировать: развитием команды, изменениями в процессах, стратегическими решениями.

Страх №2. «Команда и так загружена, а тут еще я им добавлю задач»

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

Кроме того, у команды появляется ощущение собственного влияния на процессы. Для многих это оказалось важным. Люди перестают быть просто исполнителями и начинают чувствовать себя полноценной частью системы.

Страх №3. «Команда сделает что-то не так»

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

Но со временем я поняла важную вещь: «по-другому» не всегда означает «хуже». Да, команда иногда принимает решения иначе, чем это сделала бы я. Но это просто другой способ решения. Теперь для меня существует правило: если процесс работает только при моем участии — это слабое место, а не моя ценность. 

Даже после того, как я разобралась в своих страхах и честно их признала, справиться с ними моментально не получилось: какие-то опасения со временем стали слабее, на какие-то просто пришлось закрыть глаза.

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

Как мы перестроили систему консультаций

Как было

Мы работаем с клиентами и консультируем их по использованию нашего продукта. Он непростой и функциональный: многие задачи можно решить несколькими способами, и выбор часто зависит от контекста, ограничений и множества мелких деталей.

Из‑за этого консультации занимают важную часть работы команды. Нужно не просто ответить на вопрос, а разобраться в ситуации, предложить подходящее решение и объяснить, почему оно будет работать именно в этом случае.

Раньше схема выглядела очень просто: если возникает сложный вопрос — все идут ко мне. Причем речь шла не только о нестандартных кейсах, но и о повседневных рабочих ситуациях. 

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

Что мы изменили

Мы решили сначала разобраться, какие вообще бывают консультации. В итоге выделили три основные группы:

Дальше посмотрели на реальную экспертизу внутри команды и распределили роли:

• Появилась вторая линия — более опытные аналитики, которые помогают коллегам разбираться в вопросах. 

• Для ежедневных технических консультаций появился скриптолог дня. 

• Сложные технические кейсы начали закрывать техлиды. 

• Третья линия стала финальной инстанцией.

После этого исчез обязательный шаг «спросить у Кати».

При этом я старалась не просто объявить новые правила. Для меня было важно объяснить команде, зачем вообще все это делается.

Мы обсуждали:

• почему скорость решений важна;

• зачем прокачивать экспертизу;

• почему команде полезно уметь консультировать друг друга;

• как это помогает лучше понимать продукт.

И отдельно проговорили, что любые изменения можно пересматривать, если они не работают. Людям важно понимать смысл процесса, а не просто механически следовать новым правилам.

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

Как мы перестали тратить часы на планирование дежурств

Как было

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

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

Что мы изменили

Я оставила за собой только рамки процесса:

• сколько слотов нужно закрыть

• какие роли должны быть задействованы

Все остальное передала команде. Мы сделали общую таблицу, в которой сотрудники сами выбирают удобные слоты. Если остаются неудобные варианты, люди договариваются между собой.

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

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

Как мы улучшили мини-процессы

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

Встречи 1:1 перестали держаться на личных заметках

Раньше встречи 1:1 во многом существовали в формате «контекст у каждого в голове». Темы обсуждений не всегда были понятны заранее, договоренности и задачи фиксировались у всех по-разному, а часть информации со временем просто терялась.

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

В результате процесс стал заметно прозрачнее:

• к встречам стало проще готовиться;

• важные темы перестали теряться;

• договоренности фиксируются сразу;

• к прошлым обсуждениям можно спокойно вернуться спустя время.

Распределение задач перестало быть ручным управлением

Похожая ситуация была и с распределением задач из листа ожидания, которые команда должна взять в работу в рамках итерации. Значительная часть информации о нагрузке команды существовала в ручном режиме — кто сколько задач может взять, у кого остается время, кому лучше взять новую задачу. Основная часть контекста держалась на руководителе.

Постепенно этот процесс тоже стал прозрачнее:

• тимлиды заранее фиксируют нагрузку команды;

• сотрудники сами отмечают, какие задачи готовы взять;

• важные ограничения и комментарии видны всем участникам;

• остаток времени считается автоматически.

В результате распределение задач стало быстрее и понятнее, а принятие решений перестало зависеть от одного человека.

Почему передача процессов не отменяет роль руководителя

Важно понимать, что передача процессов команде не означает, что руководитель больше не нужен.

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

Но разница в том, что кризис перестает быть повседневностью.

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

Для меня это был очень важный момент: команда перестала ждать указаний сверху и начала воспринимать процессы как свою общую ответственность.

Что изменилось в итоге

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

Но система стала намного устойчивее:

• процессы больше не зависят от одного человека;

• сотрудники быстрее принимают решения;

• команда стала самостоятельнее;

• снизилась операционная нагрузка на руководителя;

• новым тимлидам проще входить в роль.

И, пожалуй, главный вывод, к которому я пришла за это время: прозрачность намного важнее ощущения контроля.

---

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