В современных продуктовых компаниях самое главное — это продукт и его пользователи. Чтобы повысить фокус разработки на продукте, стандартом де-факто в отрасли являются кросс-функциональные команды.
Мы в Kolesa Group прошли путь от иерархической структуры управления в матричную. Хапнули багов и пропатчили ее до оптимального, в нашем профиле, состояния.
В статье разберем:
Как достичь автономности команд разработки.
Как эта автономность помогает нам расти в 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. Их основные задачи:
Создание, сплочение, лидерство и менторство
Найм и увольнение людей в команду
Фидбек
Ответственность за техдолг и и стратегию команды
Сотрудничество с другими инженерами и менеджерами по продуктам для решения интересных и сложных проблем на платформе.
Развитие здоровой культуры совместной инженерии, в соответствии с ценностями компании
Быть активной частью команды лидеров и сотрудничать с другими лидерами в компании
Растить техническую экспертизу команды
Engineering Manager в Badoo:
Работает с командой над внедрением новых фич, обучает и развивает команду в направлении гибких методологий.
Возглавляет междисциплинарную команду, работающую с клиентом, серверной частью и отделом контроля качества, помогая всем членам команды развивать свою карьеру в компании.
Работает с менеджером по разработке и менеджером по продукту, влияя на план развития его продукта.
Является гарантом того, что команда создаст решения соответствующего уровня качества.
