Попытка организовать кросс-функциональные команды (перевод)
Our first take on cross-functional teams
Оригинал: https://tech.kartenmacherei.de/our-first-take-on-cross-functional-teams-b0af5476d802
Наша первая попытка организовать кросс-функциональные команды
Когда мы только начали переводить разработку в команду внутри компании в 2012 у нас было все просто, за исключением, естественно, усилий по поиску и убеждению талантливых людей присоединиться к нашей тогда еще маленькой компании. Кристоф и Штеффен решали что разрабатывать и в какой очередности. Они также постоянно напрямую общались с командой из трех разработчиков. Когда команда начала расти, мы начали использовать скрам с его типичными недостатками и достоинствами для начинающих команд.
В следующие 24 месяца команда выросла до 20 разработчиков, тестировщиков и технических менеджеров продукта и тогда у нас появились новые проблемы. Ожидаемый прирост продуктивности был заживо съеден все более неэффективными совещаниями и растущими затратами в коммуникации. В результате мы получили демотивированных разработчиков и неудовлетворенных заказчиков. Нашими главными проблемами были:
- Все более неэффективные совещания
Если у вас всего два человека на совещании, посвященному планированию, то все сказанное на совещании будет касаться обоих. Когда людей становится больше — растет количество ненужной для некоторых участников информации. В результате люди говорят меньше про те вещи, которые стоит обсудить более подробно. Это касается планирования, стендапов, ретроспектив и других встреч и совещаний.
- Одна большая задача блокирует все остальное
Поскольку у нас одна команда разработки, мы стараемся фокусироваться полностью только на одной задаче, поэтому большие задачи блокируют команду разработки на долгое время и задерживают все остальные задачи, это не оставляет места для маленьких задач
- Все остальное задерживает одну большую задачу
Несмотря на то, что мы старались фокусировать команду разработки только на одном наборе задач, объединенных одной темой, всегда появлялись срочные задачи (проблемы на продуктовом сервере, ошибки в коде продукта, проблемы порядка) которые нам приходилось решать с наибольшим приоритетом. Поскольку эти проблемы невозможно предсказать заранее, это делает планирование по приоритизированному списку достаточно сложным.
- Проблема хранения знаний
У нас было несколько человек, которые знали очень много о наших системах и они часто становились узким местом для команды разработки, которая полагалась на них, чтобы получить от них ответы на вопросы по реализации фич и исправлении ошибок
Как мы боролись с этим?
1. Параллельная работа!
Первым делом мы изменили размер команды. Мы решили стремиться к кросс-функциональным командам размера около 6 человек, состоящим из фронтенд и бекенд разработчиков, тестировщика и технического менеджера продукта, что является, по сути, традиционной командой при работе по Scrum.
Путь перехода от большой команды к многим маленьким позволил нам найти множество решений для тех проблем, с которыми мы столкнулись. С одной стороны, достаточно очевидно, что такие совещания, как стендапы, планерки, грумминги и прочие стали проходить быстрее и и на них обсуждались более релевантные для участников вещи. К тому же у нас появились многочисленные команды, которым мы можем назначать разные задачи и которые могут работать над ними параллельно
Чтобы стать еще более гибкими, когда дело касается распределения задач и проектов на команды, мы сознательно решили не ставить для команд чисто технических задач. Это значит, что каждая команда должна быть способна работать над любым функционалом, позволяя нам назначать задачу с наивысшим на данный момент приоритетом на первую же свободную команду. Это было для нас очень важно из-за проблем, которые у нас были с концентрацией важных знаний только у нескольких людей.
2. Создание задач на день путем разделения крупных задач из нашей дорожной карты проекта
На втором шаге мы позаботились об управлении входящими потоками. Как я уже говорил ранее, мы начали со своеобразной приоритизации “сверху вниз” нового функционала и задач. Кроме этого, нам надо было позаботиться и о мелких запросах с разной степенью срочности, как, например, новый формат карточек, проблемы порядка и ошибки в коде, которые мы не хотели ставить в очередь за большими и длительными задачами.
Мы ввели “двухпоточную” дорожную карту, где мы разделяли большие задачи дорожной карты (новый функционал, полная замена частей системы и другие вещи, исследование и реализация которых занимает очень много времени) и мелкие задачи, реализация которых не требует много времени, но которые имеют высокий приоритет.
Затем мы дали командам работу на спринт по запланированным по дорожной карте задачам без отрыва на мелкие “ежедневные” задачи. Дополнительно, мы запланировали день-два между спринтами, когда все команды работали исключительно над мелкими задачами. Эти мелкие задачи приоритезировались продуктовым менеджментом. Для прозрачности и наглядности для всех, приоритизация дорожной карты производилась вместе со всеми заинтересованными лицами проекта
Таким образом мы можем с одной стороны гарантировать быстрый релиз небольших задач, а с другой команды могут сосредоточиться на задачах из дорожной карты, запланированных на спринт
Как все это сработало в итоге?
Мы работали таким образом в течении уже 6 месяцев и можем подвести первые итоги результата и того, что мы успели узнать:
1. Преимущества маленьких команд!
Очевидные преимущества маленьких команд сработали как ожидалось. У нас теперь более эффективные и результативные стендапы, ретроспективы, грумминги и планирования, что, в свою очередь, привело к тому, что мы тратим меньше времени и команда остается более мотивированной (потому что никто не любит совещания). Кроме того, что мы теперь можем работать над задачами параллельно, мы определенно делаем больше просто благодаря двум вещам:
- Маленькие команды могут работать более слаженно и фокусироваться на их собственном спринте, не отвлекаясь на другие, ежедневные мелкие важные задачи, а также без потерь на коммуникацию и обсуждение задач с большим количеством людей, когда “у семи нянек дитя без глазу”
- Мы можем легко посадить команду в одной комнате, чтоб приводит к улучшению взаимодействия между членами команды, к повышению командного духа и мотивации
2 .Согласованность между командами!
Мы думали что после разделения на мелкие команды будет сложно сохранить согласованность между командами и единое понимание информации. У нас нет системности в назначении команды и команды у нас работают над одними и тем же репозиториями, но нам все равно необходимо информировать всех про новый функционал и новые технические решения. Единственным ограничением у нас было что код ревью должен проводится между командами и полагались на то, что фронтенд, бекенд и технические продуктовые менеджеры информируют всех внутри команд. Что мы можем сказать? — это сработало достаточно хорошо.
3. Масштабируемость!
Когда мы разделились на команды, у нас получилось 3 команды. Пока мы не достигли того размера команд, который бы нам хотелось, но мы все равно постоянно проверяем наш подход на возможность масштабируемости на большее количество команд. В прошлом месяце мы сформировали четвертую команду, которая подключилась к нашему процессу легко и без проблем.
4. Согласованность должна распространяться и вне команд разработки
Согласование приоритетов с другими заинтересованными лицами — сложная задача. Несмотря на то что мы разработали понятную и четкую дорожную карту (в большинстве случаев) и думали, что можем работать над задачами одну за одной, у нас все равно возникли проблемы. Поскольку команда разработки начинает свою работу только после фазы сбора требований, возникает ситуация, когда заинтересованные лица проекта уже работают над функционалом Б, а команда разработки задает вопросы про функционал А. Здесь возникает неэффективность, особенно когда команда разработки отделена от всей остальной компании. Умножьте это на два, потому что у заинтересованных лиц проекта такая же проблема. Во время работы над функционалом Б необходимо мнение разработчиков, несмотря на то, что они заняты внедрением функционала А.
По мере роста всей компании, количество команд, которых надо вовлекать в обсуждение также растет, делая очень сложной возможность включить всех необходимых людей в этот процесс.
Факт того, что мы работаем над продуктами, у которых есть сезонность, когда приоритеты меняются в зависимости от времени года, делает эту проблему еще более острой.
5. Компромисс между гибкостью и сфокусированностью
Как описывалось выше, мы решили не выделять отдельную специализацию у команд, чтобы иметь больше гибкости и разнообразия, когда дело доходит до распределения задач. Поскольку нет специализации (клиент, продукт, система), мы увидели “недостаточное понимания видения проекта”, что привело к снижению мотивации к достижению целей спринта, над которым работает команда и нежеланию брать на себя ответственность и принимать обоснованные решения. Невозможно разработать такое видение для вашего продукта/системы/клиента если вы работаете над новым функционалом для вашего конфигуратора и уже знаете, что в следующем спринте вы будете работать над чем то совершенно другим
Мы смогли решить проблему концентрации знаний о проекте только у нескольких людей, хотя возможно мы все же немного перестарались.
В итоге мы можем сказать что мы стали лучше в решении наших проблем, которые мы планировали решить таким образом и видим существенный прогресс в увеличении производительности и качества результата. Конечно у нас еще много работы впереди, но у нас уже есть идеи, как нам браться за следующую задачу.