Антон Бевзюк, mindbox: «Я делаю людей счастливыми за счет своих знаний, умений и инженерных практик»

Антон Бевзюк – Head of Engineering в mindbox, одной из немногих «бирюзовых» компаний в России. В интервью на YouTube Антон рассказал о том, как работает самоорганизация в бизнесе, какие инженерные практики подойдут нетехническим командам и как управлять отделом разработки из 250 человек.

— Как давно ты в mindbox?

— Три дня назад исполнилось два года, как я работаю в mindbox. Моя позиция называется Head of Engineering. Обычно это мало о чем говорит, но суть позиции в том, чтобы научить разработку mindbox достигать бизнес-целей, не жертвуя качеством и людьми. То есть найти баланс между гонкой за целями и прибылью, счастьем людей в компании и качеством продукта. Это сложная работа, приходится постоянно балансировать за счет культуры, процессов и роста других менеджеров, но нам удается достигать результатов.

— Сколько сейчас человек в разработке?

— Сейчас примерно 250 человек.

— Они как-то делятся по продуктам?

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

Также есть базовые модули, без которых mindbox невозможен. Это CDP-модуль – ядро нашей системы, в котором хранятся данные, фильтры, сегменты. Есть несколько горизонтальных команд: команда платформы, отвечающая за надежность и масштабирование всей инфраструктуры, и команда фреймворка, которая улучшает developer experience для всех команд.

— А эти продуктовые трайбы полностью закрывают всю вертикаль – бэкенд, фронтенд, тестирование?

— Да, трайбы автономны, они создают продукты end-to-end. Они же его тестируют, деплоят и реагируют на поддержку.

Мы никому не передаем эти функции. И еще у нас нет отдельных тестировщиков. Мы полностью полагаемся на автотестирование. Разработчик отвечает за функционал, который он создал, и покрывает его быстрыми, надежными тестами. Это заменяет QA.

— Расскажи о структуре управления в Mindbox. У вас есть CEO?

— Сейчас у нас нет CEO. В ноябре 2020 года Саша Горник объявил, что снимает с себя обязанности CEO и передает их борду. Это круг управления компанией, состоящий из нескольких человек. Там есть представители из разработки, маркетинга, продаж, клиентского сервиса, администрации, бухгалтерии, юридического отдела. Всего девять человек, в том числе три представителя от разработки. По сути, Саша распределил свои обязанности CEO между членами этого борда, и так мы работаем сейчас.

— А как принимаются решения?

— Решения принимаются консентом, как и везде в компании, не только в борде.

— На это уходит какое-то время?

— Да. Смотри, любое решение — это всегда эксперимент. То есть мы не добиваемся того, чтобы решение было идеальным, чтобы прямо все нюансы учесть. Мы добиваемся того, чтобы оно было достаточно безопасным, чтобы попробовать. И если что, его можно изменить или отменить в любой момент, если увидим, что едем в стену. Так все решения принимают.

Мы собираемся регулярно, у нас есть несколько проектов, над которыми мы работаем, обсуждаем проблемы, какие есть в компании. Кто-то предлагает какое-то решение, обычно предварительная работа делается. То есть ты приходишь с каким-то уже предложением, говоришь: "Вот вижу такую-то проблему. Предложение такое-то". Дальше собираем возражения. Если их нет, то прекрасно, решение принято. Если есть, значит, мы их интегрируем по одному и улучшаем это решение. Когда все возражения интегрированы, оно тоже считается принятым. Потом просто информируем всех, что теперь живем так.

— Круто. Такой вопрос: были ли случаи, когда ты ощущал, что такой способ принятия решения неэффективен? То есть когда один руководитель мог бы сработать эффективнее?

— Вопрос, что такое «эффективнее»? Быстрее принять решение? Да, точно могли бы. Часто мы буксуем, но это наш выбор. Если к иерархии возвращаться, она тем хороша, что ты можешь быстро принять решение и его просто спустить вниз, сделать обязательным. У нас так не сработает, потому что есть два ключевых правила: любой может принять любое решение и любой может заветировать любое решение.

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

Он не может находиться везде, не знает всех деталей. У него сформируется какая-то картина довольно общая, широкая, но не глубокая. А могут быть нюансы, которые сильно могут повлиять на это решение.

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

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

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

— А в какие-то экстренные ситуации, типа мобилизации или ковида, разве не нужно было как-то более быстро организовываться?

— Да, нужно было, и мы организовывались.

Смотри, вот есть правило, по которому мы живем, но любое правило — это костыль. То есть правило работает, когда все нормально. В 80-90% случаев правило обслуживает тебе нормальный поток работы. Но бывают ситуации, когда правило надо нарушать, и любой может нарушить правило. Точно так же.

Это тоже решение. Ты можешь нарушить любое правило, обосновав и аргументировав это. Поэтому в кризисной ситуации может прийти человек, даже в другую команду, и сказать: «Ребята, стоп. Я здесь теперь главный, давайте делать так-то». Точнее, не «давайте делать так-то», а «вот делайте так-то». И если другим людям покажется, что он делает что-то неправильное или неполезное, они просто возразят, заветируют или потом дадут обратную связь, в крайнем случае – уволят. Но обычно они понимают, что этот человек знает, что делает, и ему доверяют, поэтому делают то, что требуется.

— В штатном режиме все работает так, что любой может принять любое решение, даже не советуясь?

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

Если есть, ты их интегрируешь, и после этого уведомляешь о том, что новое правило такое-то.

— Это все тоже через чат?

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

— И все, что связано с финансами, тоже через мессенджер? Даже несмотря на то, что какая-то часть команды в офисе, они тоже все постят в чат?

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

— Были ли случаи, когда ты внедрял гибкие практики в команды, не связанные с разработкой?

— Да, в Райффайзен-банке у нас был проект под названием «Agile в отделениях». Мы начали применять некий аналог скрама в отделениях банка. По сути, это было самоуправление с элементами кросс-функциональности.

Типичная ситуация в банковском отделении: есть кассир, премиум-менеджер, операционисты в зале. Клиентский поток неравномерный – обычные менеджеры могут быть перегружены, а премиум-менеджер сидит без дела. За счет кросс-функциональности они начали более гибко распределять этот поток между собой.

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

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

— Как вы оценивали результат?

— Мы ставили определенные цели. Знаете, какую проблему мы решали?

Они не готовы быть просто винтиком в этой машине. Они хотят на что-то влиять, принимать решения, чего-то добиваться.

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

— То есть это более игровая форма с большей ответственностью?

— Да, именно так. И эту проблему удержания молодых кадров мы решили.

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

— Если говорить о двух популярных методологиях, Scrum и Kanban, для чего они могут помочь командам, которые с ними не знакомы? В каких ситуациях?

— Это принципиально разные вещи. Scrum – это фреймворк, который позволяет тебе создавать продукт в сложной среде. Если ты попадаешь под эти условия, то есть тебе нужно создавать продукт короткими итерациями в условиях неопределенности, маленькой командой – супер, бери Scrum. Это минимальный фреймворк, который доказано работает.

Kanban – это метод улучшения любого процесса. У тебя есть какой-то процесс, он тебя не устраивает, и ты хочешь его улучшить – отлично, попробуй Kanban. Kanban'ом можно улучшать даже Scrum. Понимаешь, это вещи, которые независимы друг от друга. У них разные цели, но они отлично сочетаются. Можно использовать их и по отдельности.

Scrum многим на самом деле неприятен. У него сложная история. Почему? В какой-то момент он стал слишком популярным, я бы сказал. По сути, у Scrum очень хорошо поставлен маркетинг.

Они начали курсы, обучение, сертификацию, и просто про него знает больше людей. Это как цикл с позитивной обратной связью: больше людей знают про Scrum, они приходят учиться, про него узнают еще больше людей, они тоже приходят учиться, и у тебя 90% рынка думает, что Agile равно Scrum. Хотя это далеко не так.

При этом возникает очень много кривых реализаций. Поверхностное обучение приводит к тому, что люди думают, будто они все поняли, идут, что-то делают, какие-то элементы выкидывают или применяют неправильно. В итоге ничего не получается, процесс разваливается, и они говорят: «Да, этот ваш Scrum нифига не работает».

Не факт, что это был Scrum, это было что-то, какая-то их интерпретация. Но в итоге оно ожидаемо разваливается. Обвиняют не себя. Зачем? Кто будет себя обвинять? Виноват тот, другой, Scrum. И в итоге у него сформировался такой образ, что это, типа, сомнительный фреймворк, который не везде применим, или еще как-то. На самом деле, да, там есть ряд ограничений.

Например, про роль Scrum-мастера пресловутую, которая обязательна. Это не значит, что отдельный человек должен быть. Это просто значит, что кто-то в команде у тебя должен понимать, как эта штука работает, и следить за правилами. Обучать другую команду, обучать всю команду работать по небольшому набору, по сути дела, правил, которые диктует Scrum. Кто-то должен знать, как эта штука работает, и все.

При этом мы, например, в mindbox Scrum в чистом виде не применяем. Был период, когда пробовали, был период, когда пробовали LeSS, это масштабируемый вариант Scrum, в котором над одним продуктом работают несколько команд с одним бэклогом, с одним продуктом, такие кросс-функциональные команды, взаимозаменяемые. Тоже попробовали, но в общем не вышло, потому что продукт слишком большой и сложный, чтобы одна команда могла полностью разбираться во всех деталях его разных доменов. Поэтому разделили на домены, и собственно сейчас как будто бы неплохо работает в такой конфигурации.

Но Kanban применяем. То есть Kanban, мне кажется, это очень универсальный инструмент, метод улучшения, и мы им с удовольствием пользуемся. Какие-то элементы Scrum тоже применяем: короткие итерации, дейли, планирование, ретро. Все это с удовольствием используем тогда, когда это нужно.

У нас в трайбах есть два режима работы: миссия и лончпад. В миссии больше элементов Scrum применяется, а в лончпаде почти ничего не используем – там потоковая работа, постоянные мелкие тикеты, какие-то запросы других команд или просто небольшие улучшения в продукте. Там Kanban отлично подходит.

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

Смотрите полную версию интервью c Антоном на YouTube.

Другие интервью с моего канала:

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