[] Как мы за год повысили эффективность в командах разработки в 2 раза
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
В современных продуктовых компаниях самое главное — это продукт и его пользователи. Чтобы повысить фокус разработки на продукте, стандартом де-факто в отрасли являются кросс-функциональные команды. Мы в 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. Их основные задачи:
- Создание, сплочение, лидерство и менторство
- Найм и увольнение людей в команду
- Фидбек
- Ответственность за техдолг и и стратегию команды
- Сотрудничество с другими инженерами и менеджерами по продуктам для решения интересных и сложных проблем на платформе.
- Развитие здоровой культуры совместной инженерии, в соответствии с ценностями компании
- Быть активной частью команды лидеров и сотрудничать с другими лидерами в компании
- Растить техническую экспертизу команды
Engineering Manager в Badoo:
- Работает с командой над внедрением новых фич, обучает и развивает команду в направлении гибких методологий.
- Возглавляет междисциплинарную команду, работающую с клиентом, серверной частью и отделом контроля качества, помогая всем членам команды развивать свою карьеру в компании.
- Работает с менеджером по разработке и менеджером по продукту, влияя на план развития его продукта.
- Является гарантом того, что команда создаст решения соответствующего уровня качества.
===========
Источник:
habr.com
===========
Похожие новости:
- [Управление проектами, Лайфхаки для гиков] Групповые чаты не работают: как мы сделали форум внутри таск-трекера
- [Карьера в IT-индустрии] Как хороший разработчик становится плохим менеджером
- [Учебный процесс в IT, Карьера в IT-индустрии] Яндекс.Практикум запускает курс для руководителей «Как управлять командой»
- [Управление проектами, Управление персоналом] 3 пути к возрождению организации
- [Управление продуктом, Управление персоналом, IT-компании, Удалённая работа] Один год удалённой работы в Figma (перевод)
- [Управление персоналом, Конференции, Интервью] Две крайности руководителя
- [Agile, Управление продуктом, Конференции] Scrum Community Meetup 13/04
- [Управление разработкой, Управление проектами, Управление продуктом] Нет Jira — нет проблемы (перевод)
- [Управление разработкой, Управление персоналом] Завал в IT-компании и как с ним бороться
- [Управление персоналом, Карьера в IT-индустрии, Конференции] Круглый стол «Как компании трансформируются в режиме «удаленки»: найм, адаптация, корпоративная культура
Теги для поиска: #_struktura_kompanii (структура компании), #_effektivnost_raboty (эффективность работы), #_upravlenie_komandoj (управление командой), #_blog_kompanii_kolesa_group (
Блог компании Kolesa Group
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:06
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 В современных продуктовых компаниях самое главное — это продукт и его пользователи. Чтобы повысить фокус разработки на продукте, стандартом де-факто в отрасли являются кросс-функциональные команды. Мы в 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. Их основные задачи:
=========== Источник: habr.com =========== Похожие новости:
Блог компании Kolesa Group ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:06
Часовой пояс: UTC + 5