Как мы за год повысили эффективность в командах разработки в 2 раза

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

Мы в Kolesa Group прошли путь от иерархической структуры управления в матричную. Хапнули багов и пропатчили ее до оптимального, в нашем профиле, состояния. 

В статье разберем:

1. Как достичь автономности команд разработки.

2. Как эта автономность помогает нам расти в 2 раза по всем показателям.

Немного контекста

Kolesa Group — это классифайды. 4 продукта в 2-х странах (Казахстан и Узбекистан) на 4-х платформах (iOS, Android, десктопный и мобильный web). Начинает свою историю компания с печатного издания. В 20хх году печатное направление было закрыто, и компания целиком сосредоточилась на онлайн-направлениях. 

Вся разработка ведет свою историю с веб-направления. Изначально это были fullstack-разработчики в отделе под названием «Веб-редакция». По мере роста в компании появлялись сначала админы, потом тестировщики, мобильные разработчики. Разделились на frontend и backend веб-разработчики, и наконец разделились QA на web и mobile.

Немного внутренней кухни

У каждого из направлений есть руководитель, который отвечает за: 

• операционные вопросы (отпуск, больничный, найм, увольнение), 

• развитие и обучение, 

• формирование требований к позиции, 

• оценку и грейдирование специалистов, 

• техническую стратегию по направлению. 

Специалисты разделены на команды по продуктам. А микрокоманды по микропродуктам. В каждой команде есть тимлид: отдельно веб, отдельно мобильный. Также есть менеджер продукта, подчиняющийся руководителю продукта, который в свою очередь подчиняется директору по продуктам.

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

О проблемах и их решениях

Проблема 1.  У специалиста появилось несколько начальников. 

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

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

Проблема 2. Организационные вопросы.

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

Решение. Сформулировали матрицу ответственности. 

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

Проблема 3. Появилась некоторая разобщенность внутри команд.

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

Решение. Ввели роль SEM-а или Software Engineering Manager.

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

Немного о SEM-ах: какие задачи они выполняют

Помимо оптимизации всего процесса разработки, SEM решает другую важную проблему — не допускает микроменеджмент со стороны руководителей отделов.  Теперь руководители могут решать возникающие проблемы системно. На уровне процессов и культуры, а не локально с помощью микроменеджмента. 

Изменение в воркфлоу команды происходит по цепочке:

Руководитель департамента -> SEM ->  Тимлид от департамента -> Юниты

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

Новая роль: тимлиды мобильной разработки

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

Итог

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

Аналоги

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

Так, например, в компании Spotify существуют Engineering Managers. Их основные задачи:

1. Создание, сплочение, лидерство и менторство

2. Найм и увольнение людей в команду

3. Фидбек

4. Ответственность за техдолг и и стратегию команды

5. Сотрудничество с другими инженерами и менеджерами по продуктам для решения интересных и сложных проблем на платформе.

6. Развитие здоровой культуры совместной инженерии, в соответствии с ценностями компании 

7. Быть активной частью команды лидеров и сотрудничать с другими лидерами в компании

8. Растить техническую экспертизу команды

Engineering Manager в Badoo:

1. Работает с командой над внедрением новых фич, обучает и развивает команду в направлении гибких методологий.

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

3. Работает с менеджером по разработке и менеджером по продукту, влияя на план развития его продукта.

4. Является гарантом того, что команда создаст решения соответствующего уровня качества.