Поделимся

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

Точно надо? Может не

Деление — непростой процесс для команды и вызов для её менеджера. Хочется быть уверенным, что точно уже пора.

Какие признаки помогут определиться:

• в команде больше 12 человек;
• планирование отнимает больше времени, чем несколько месяцев назад;
• задачи скапливаются или, наоборот, кто-то из ребят недозагружен;
• командные встречи утомительные, большая часть ребят не вовлечена в обсуждение;
• менеджер редко может ответить на вопрос «чо там с задачей N»;
• нет возможности проводить регулярные one-to-one.

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

Узнать как это бывает

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

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

Наверное, и в других компаниях можно так сделать 😊 И не обязательно это должны быть команды разработки. Маркетологи, редакторы и другие команды тоже могут поделиться опытом организации работы.

Деление приведет к ещё большему росту команды

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

Инфраструктуру нужно выделять в отдельную команду

Мы так не сделали на первом этапе и ребятам приходилось разрываться между крупными бизнесовыми и техническими задачами. Спустя год мы сделали ещё одну подкоманды — инфраструктурную.

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

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

Может остаться какая-то зона, не распределенная ни в одну из команд

Нормально оставить какой-то кусочек кода ничьим пока он не требует поддержки и доработок.

Не забыть про людей

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

Можно расспросить такое:

• расскажи как ты видишь свой личный вклад в продукт?
• бывает ли, что чувствуешь себя одиноко?
• какие задачи тебе хотелось бы выполнять чаще?

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

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

Что дальше

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

В любом случае, для менеджера это непростая задачка. Предстоит много дел, понадобится всё ваше терпение и любовь к команде 💙