Как стать автором
Обновить
32.16
Рейтинг
Kolesa Group
Строим классифайды в Центральной Азии

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

Блог компании Kolesa GroupУправление разработкойУправление персоналом
Из песочницы

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

Мы в 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. Является гарантом того, что команда создаст решения соответствующего уровня качества.

Теги:структура компанииэффективность работыуправление командой
Хабы: Блог компании Kolesa Group Управление разработкой Управление персоналом
Всего голосов 16: ↑15 и ↓1+14
Просмотры4.2K

Похожие публикации

Лучшие публикации за сутки

Информация

Дата основания
Местоположение
Казахстан
Сайт
job.kolesa.kz
Численность
201–500 человек
Дата регистрации
Представитель
Anel Kerimbekova

Блог на Хабре