
Как правильно масштабировать команду?
В «Тинькофф бизнес» за 3 месяца сделали MVP продукта для запуска на рынке. За 3 года прошли от первых 500 клиентов до 300 000. А команда разработки выросла с 5 до 200 человек, испытав немало проблем роста. Как боролись?
В начале была единая небольшая команда. Но с ростом продукта росла и она. Работать вместе стало неэффективно при количестве человек больше 7, так что команду пришлось делить. Так появились слои: «веб», «клиент», «бек» и тп.
А рост все продолжался. Вскоре всплыли проблемы:
🔀 синхронизации между слоями не хватало,
⤵️ процесс разработки превращается в waterfall: фронты не хотят делать пока не готов бекенд, а бекенд не хочет делать пока не видит итоговый дизайн),
❌ постоянно происходили конфликты релизов,
⚠️ появлялилсь узкие места в слоях: то в qa, то в аналитике,
🏃♀️ все задачи приходили от разных заказчиков, но все — наипервейшего приоритета,
💢 команду разрывали на части, появлялась аллокация людей в задачи в % (ты тратишь 10% времени на это, 5% на это, 20% на…)
Как следствие — утрачивается понимание целей командой. Time2Market все больше, а команда попросту выгорает.
Что делать? Решили делиться на команды опять, но по-другому. Их назвали «Продуктовые единицы», и в каждой из них поставили одного заказчика, с одним беклогом, одной фулл-стек командой, отвечающей за свой сервис, со своими процессами: планирование, спринты, релизы.
А что сложного? Да вот что:
🔸 как почти любой продукт, растущий из mvp, «Тинькофф бизнес» представляет из себя монолит кода. Микросервисы отпиливались поочередно и небыстро.
🔹 увлекшись распиливанием монолита, команда полностью забыла про разделение интерфейсной части. Это задержало трансформацию на еще какое-то время, неучтенное в начале.
🔸 некоторые люди и некоторые части кода так и не поделилились. Кто-то из-за уникальной экспертизы, нужной сразу всем, или каких-то еще внутренних причин. Они так и остались общей прослойкой, и к коммуникациям с ней каждая команда относится с должным вниманием.
🔹 кое-что выделялось в отдельную команду совершено зря. Когда запускали валютные платежи, отдельная команда делала продукт для них. Но автоматизация операций была преждевременной, и еще год пришлось переделывать все системы.
🔸 не обошлось и без борьбы с топ-менеджментом. Для них вполне проблемы разработки казались то некомпетентностью персонала, то вообще повседневными жалобами программистов. Получение поддержки, которая сделала возможной весь процесс масштабирования, было возможно только после глубокого погружения топов в текущие проблемы ИТ.
Но в итоге все получилось. Все мини-команды после реформации также объединялись в одну команду, но с полностью переделанной внутренней структурой. Все видят общую цель, но и четко понимают свой собственный фокус при достижении этой цели. Профит!
А главное, теперь команде знает принцип, по которому можно масштабироваться снова и снова, и даже в курсе большинства подводных камней.
А вам приходилось участвовать в масштабировании команды?
🧐- да, успешно
😣 - да, неуспешно
🤓 - пока нет
Видео, 22 минуты без вопросов: tgclick.click/glGyhP32