Kolesa Group, Kaspi Магазин и маркетплейсы. Когда команды растут быстрее процессов

Kolesa Group, Kaspi Магазин, Chocofamily, площадки Wildberries и Ozon у нас. Продуктовые команды здесь привыкли к скорости: ежедневные релизы, A/B-тесты, continuous deployment. Со стороны это выглядит как зрелый agile.

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

Когда масштаб ломает привычное

Пока команд было пять, product-директор мог держать общую картину в голове. Кто над чем работает, какие фичи планируются, где могут быть пересечения. Коммуникация шла через общий чат и регулярные обеды. Этого хватало.

Одна из компаний выросла до пятнадцати продуктовых команд за два года. И столкнулась с ситуацией, которая при пяти командах просто не могла бы произойти. Две команды одновременно и независимо друг от друга внесли изменения в поисковую выдачу. Первая изменила алгоритм ранжирования. Вторая в то же время запустила A/B-тест на отображение результатов. Ни одна из них не знала, что другая тоже работает с поиском.

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

Почему «мы и так быстрые» перестаёт работать при росте

Когда компания маленькая, неформальной координации хватает. Все примерно представляют, кто что делает, потому что сидят рядом или общаются каждый день. При росте эта модель ломается тихо, без очевидного момента перелома. Просто однажды оказывается, что две команды делают пересекающуюся работу, а третья третий месяц ждёт API, о котором другая команда говорит «на следующей неделе, наверное».

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

Что помогает при масштабировании

Еженедельный sync между product owner-ами. Полчаса раз в неделю, где каждый PO коротко рассказывает, что их команда планирует и что может затронуть смежников. Простой ритуал, который предотвращает ситуации вроде «двух команд в поиске».

Общая карта фича-флагов с владельцами. Когда у каждого флага есть явный владелец и срок жизни, пересечения становятся видимыми заранее. Особенно это важно для A/B-тестов, которые могут конфликтовать друг с другом, как в истории выше.

Ретроспективы на уровне группы команд. Раз в месяц 3-4 связанных команды собираются и обсуждают, что работает и что ломается в их взаимодействии. Это занимает час, но предотвращает проблемы, которые потом стоят неделю.

WIP limits на уровне продукта. Когда ограничение «одновременно максимум 3 стратегических инициативы» действует на уровне всего продукта, появляется необходимость договариваться о приоритетах между командами. Это сложнее, чем работать автономно, но результат становится предсказуемее.

Где развивать навыки

Product owner и продакт-менеджерам полезна программа Advanced Product Ownership. Приоритизация при масштабировании, управление беклогом, координация между командами. Сертификат ICP-APO от ICAgile подтверждает продуктовые компетенции и работает у нас и за рубежом.

Тимлидам и скрам-мастерам подойдёт программа Advanced Scrum Master & Agile Coach. Как фасилитировать обсуждение между командами, как помочь группе договориться о WIP limits и зонах ответственности.

Базовая программа Certified Agile Professional полезна всем в команде: разработчикам, менеджерам, аналитикам, дизайнерам. Общий язык и понимание agile-подходов особенно важны в растущей компании, где новые люди приходят каждый месяц.