Знакомство с командой операционной эффективности

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

Расскажи о твоём пути в IT до текущей роли?

Это был интересный переход. Я работала в издательстве «МИФ» руководителем одного из направлений корпоративных продаж. Так как это преимущественно бизнесовое издательство, мы очень любили экспериментировать и пробовать на себе интересные практики из выпускаемых книг. Когда мы издали книжку про скрам, подход показался нам очень интересным и было принято решение попробовать его в нашем отделе. Казалось бы, где корпоративные продажи и скрам, но у нас получилось. Мы сформировали команду, где люди помогали друг другу вместо того, чтобы воевать за клиентов, как это часто бывает в продажах, и в итоге наш отдел показал отличные результаты. Тогда было решено ввести новую роль, я стала ещё и скрам-мастером в команде. Со временем заметила, что после того, как мы изменили подход к работы, люди стали более замотивированными и самостоятельными, сформировалась классная атмосфера и драйв. У меня же как у руководителя появилось больше времени на стратегические задачи.

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

Ты проработала на позиции Agile Coach достаточно долго, расскажи, как такая роль помогает бизнесу?

Есть распространенное заблуждение, что скрам-мастера и эджайл-коучи просто проводят ретро и двигают тикеты по доске. Смысл моей работы, был ранее и есть сейчас, в том, чтобы смотреть на бизнес с разных сторон, анализировать процессы и оптимизировать их. Команды должны быть производительными — их темп работы должен соответствовать потребностям бизнеса. Они должны быть прогнозируемыми, потому что бизнес строится на планах, и мы должны их выполнять. Бизнес растёт, появляются новые проекты, под них собираются новые команды, и уже на этом этапе крайне важно поддержать ребят с точки зрения процессов и их синхронизации с другими платформами и продуктами, чтобы они жили в единой системе. Ещё у меня на контроле вопросы развития и операционки: есть ли документация, настроен ли шаринг знаний, отсутствует ли бас-фактор в команде, формируется ли лид-резерв, может ли команда быстро масштабироваться, нанять и заонбордить любое необходимое ей сейчас количество сотрудников, коррелируют ли цели команды с целями компании и с какой точностью команда умеет в них добегать.

Приведи примеры, какие задачи решает Agile Coach.

Зона ответственности часто очень зависит от компании. По моему мнению, эджайл-коуч должен быть таким же гибким, как и методологии, которые он внедряет, так что и задачи очень разнообразные. Например, в команде, где раньше никогда не было аналитика, ввели новую роль, и мне потребовалось помочь определить зону ответственности этого аналитика, выстроить понятные правила коммуникации между ним и аналитиками платформы, а также разработать процесс плавного погружения и сопровождать нового специалиста на протяжении его онбординга. Также, вместо того чтобы постоянно модерировать ретроспективы самой, я разработала и внедрила серию обучений, чётких памяток и живых документов, где подробно описала, как проводить ретро в разных форматах, как к нему готовиться и какие именно действия выполняет ведущий, и как через такие встречи системно снимать напряжение через командную рефлексию. Иногда нужно разработать новые инструменты, например, мы с командой сделали в Jira специальный плагин Jira-Gant, теперь сотрудники могут оперативно построить диаграмму Ганта на основании своих эпиков и задач, это облегчает восприятие и добавляет прозрачности. Задачи очень разнообразные, но от этого и интереснее.

Расскажи про отдел, который ты теперь возглавляешь?

Было принято решение сформировать отдел операционной эффективности и выйти за рамки методологий. И это совсем не про то, что теперь в каждый отдел нам нужен скрам. Это про то, что работа каждой команды должна быть автоматизирована, максимально комфортна и интересна ей самой и при этом эффективна для бизнеса. Я скептически отношусь к внедрению «скрама ради скрама». Нас интересуют не ритуалы, а то, как бизнесу и командам станет проще работать. Если для этого достаточно одной регулярной встречи и пары договоренностей — мы сделаем именно это, а не будем тащить полный набор церемоний. Ведь конечная цель — это оптимизация процессов работы компании. 

Мы будем заниматься несколькими направлениями:

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

2. Автоматизация — боты, интеграции и доработки 

3. Стандарты и документация — это все про документы и про то, что если есть рабочий процесс, он должен быть понятно расписан 

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

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

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

Например, последние полгода мы с моей командой очень плотно работали с техподдержкой офиса. Все мы люди и гораздо легче и быстрее написать конкретному человеку, чем идти заполнять заявку. Поэтому сотрудники шли в личные сообщения к конкретным инженерам, к которым привыкли или с кем общались чаще. Это привело к тому, что часть сотрудников саппорта были в вечной запаре, а оценить реальную нагрузку на отдел было почти нереально. Мы прописали наши цели, учли паттерны поведения сотрудников и сделали очень крутую автоматизацию. Теперь можно просто написать сообщение в общий чатик технической поддержки в корпоративном мессенджере, а бот сам создаст заявку. Более того, пользователь может продолжить общение и внутри задачки в таск-трекера, и в комментариях под своим запросом в мессенджере, все синхронизировано, информация не потеряется. Инженер поддержки может закрыть тикет как внутри тикет-системы, так и если поставит на сообщение из чата реакцию «зеленая галочка». Также мы добавили к этому процессу ещё двух ботов. Первый подсвечивает сотрудникам поддержки, если запрос висит в статусе «Новый» дольше двух часов. Это позволяет им не пропустить ни одного обращения. Второй бот после закрытия тикета пишет пользователю и запрашивает оценку качества. Если кто-то ставит три звезды или ниже, мы приходим к человеку, уточняем, что было не так, и корректируем процессы, чтобы в следующий раз такой проблемы не было. В итоге оценка удовлетворенности сотрудниками службой технической поддержки стала 4,8 из 5, медианное время закрытия обращения —  20 минут. Это очень хорошие показатели. Кроме того, появилась статистика среднего количества обращений с разбивкой по категориям. Это помогает команде видеть свои зоны развития, боли пользователей и позволяет направить усилия на системное, а не локальное, решение проблемы. 

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

С какими вызовами ты сталкиваешься чаще всего?

Сейчас, когда мы стали работать с разными командами, видим сложности в том, что они не могут договориться друг с другом. Возникает синдром «это наша зона ответственности, и мы лучше знаем, как правильно». Есть задачи, которые находятся на стыке двух команд, и каждая тянет их на себя: «это наше, мы сами разберёмся, не лезьте». Казалось бы, самостоятельные ребята, берут ответственность за процесс, что тут плохого? Но на практике это приводит к путанице и дублированию, потому что каждая команда начинает делать одно и то же, но по-своему, не согласовывая с соседями.

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

Была ли ситуация, когда твои советы шли вразрез с желанием руководителя или заказчика?

Я не прихожу к командам просто так с советами и рекомендациями. Либо мы видим проблему уже на своем уровне, либо её подсвечивают, но это всегда про факты. Бывает, что заказчик — это руководитель департамента, который видит проблемы сверху и просит помочь. А руководитель команды при этом хочет оставить всё как есть. И здесь главное — не давить и не доказывать чью-либо правоту, а глубоко погрузиться в позицию каждого. Почему руководитель департамента хочет изменений, а руководитель команды — упирается? Какие у него страхи или ограничения? Что они видят такого, чего не вижу я?

Я убеждена: договориться можно о чём угодно. Но для качественных изменений недостаточно просто сказать «надо сделать так». Руководителю и его людям работать дальше, поэтому изменения не имеют смысла без их искреннего участия. Нужно сесть, объяснить на фактах и цифрах, почему предлагаемые изменения работают. Если мне в ответ тоже на фактах объясняют, что решение, с которым я пришла не будет работать — не беда. Мы берём и брейнштормим альтернативы. У меня за плечами большой опыт, и я могу увидеть сразу пятьсот шагов к идеалу. Но если вывалить их все на человека, он просто взорвётся и скажет «нет». Поэтому я всегда спрашиваю себя: а насколько он готов к изменениям? Какова его картинка мира? Что для него сейчас важно? Исходя из этого, мы внедряем не всё и сразу, а маленькими шагами: первый, второй, третий. Идеальная картинка из учебников никому не нужна. Нужна та, которая сложится из потребностей бизнеса, самого руководителя и его команды. Главное — договориться. А для этого достаточно одного: глубоко погрузиться в реальность другого человека и подсвечивать проблемы не эмоциями, а фактами. Тогда любой, даже самый сложный разговор, заканчивается согласием.

Что в Иви позволяет тебе работать эффективнее?

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

Какие качества должны быть у компании, чтобы отдел, подобный твоему, мог действительно приносить пользу, а не существовать «для галочки»?