Привет, я Дмитрий Шестернин, техдиректор Flowwow. Знакомая ситуация, когда за полгода ваша команда прирастает почти на треть сильными крутыми спецами, а легче никому не становится? Если да — обнимемся. И я расскажу, как мы адаптировали и использовали на практике Spotify-модель управления командой и в результате распутали структуру нашей быстрорастущей разработки.
Признаки надвигающейся катастрофы
Кризис команды не приходит вдруг: как правило, его приближение становится заметно за месяц-два. Вот типичные знаки, что команде разработки стало тесно в своей привычной структуре:
Слишком долгие митинги. Как следствие — слабая вовлеченность всех участников. Как только вы с командой на дейли перестаете укладываться в 20 минут — это тревожный симптом.
Непрозрачная экспертиза. Непонятно, к кому идти с конкретной проблемой, отсюда — вопросы в канале, адресованные всем и никому, и треды на 30-40 комментариев, состоящие из гипотез.
Слишком много коммуникации. Если треды в рабочем мессенджере вырастают больше чем до 10 комментариев, а участников в каждом треде больше 5 — задачи решаются медленно, диалоги поглощают рабочее время.
Расстановка задач по принципу «кто менее загружен». Мы отсылаем продакт-менеджера не к тому, кто лучше справится с его задачей, а к тому, кто чуть меньше других зашивается. Мы все знаем, что это неправильно, но ситуация заставляет действовать именно так.
Малая эффективность от прихода новых людей в команду. Мы усилились отличными ребятами, но не можем качественно их загрузить, потому что все время уходило на коммуникации.
Корень проблемы
Я провел опрос внутри команды: попросил каждого написать, с кем из разработки он взаимодействует по рабочим вопросам 2 раза в неделю и чаще. Получилось вот что:
Такой вот “разум улья”: все вынуждены связываться со всеми, чтобы решать очень широкий круг задач. Когда в команде разработки 5 человек, это оптимальная схема, но когда нас стало 35 — это уже катастрофа. Результат: размазанность экспертизы, незаменяемые ключевые специалисты, невозможность грамотно нанимать и подключать новых людей, так как каждый новый сильный специалист только прибавляет связей в этот клубок.
Как раз в это время – весной – мы начали активно нанимать новых людей. Тогда на рынке было самое благоприятное время для усиления команды: часть иностранных компаний ушла из России, большие компании урезали бюджеты на разработку и даже зарплаты немного снизились. Но найм в нашу запутанную структуру — сложное решение: положительного эффекта в скорости разработки придется долго ждать, если вообще дождемся.
Spotify-модель для команды разработки
Нам была нужна модель отдела разработки, способная создать из имеющейся хаотической структуры более управляемую конструкцию. На одной из весенних IT-конференций мы задались целью — изучить опыт других компаний со схожими проблемами и численностью отдела разработки примерно как у нас и чуть больше (на самом деле брали в расчет компании даже с отделом разработки в 10 раз больше, чем у нас). Спрашивали подряд коллег о том, как у них все устроено, как они преодолели боли роста и какие проблемы им уже удалось заметить после принятия той или иной модели.
По совокупности, наиболее релевантной показалась Spotify-модель. Краткий экскурс: с 2010 по 2012 годы команда разработки Spotify выросла в 8 раз — с 30 до 250 инженеров. Чтобы такой стремительный рост не был болезненным, компания провела длительный эксперимент, разрабатывая модель управления продуктовой разработкой четко под свой рост.
В чем суть «чистой» Spotify-модели?
Команда в данной модели управления раскладывается в матрицу, где по одной оси оказываются отряды (squad), по другой — гильдии (chapter).
Отряды объединяют разных специалистов, решающих общую воронку задач, под предводительством лидера (продакт-менеджера или продукт-овнера), причем данная команда может решить почти все задачи воронки совсем или почти без привлечения дополнительной экспертизы со стороны.
Людей, работающих в рамках одинаковой технологии, объединяют в горизонтальные команды — гильдии. Цель объединения — следить за тем, чтобы все представители его цеха были взаимозаменяемы, развивались и работали в едином стиле, а технологическая горизонталь развивалась и не накапливала критическое количество технического долга.
Что общего у нас и Spotify?
Мы продуктовая компания, в своей разработке задействующая множество стэков и направлений, быстрорастущая, привыкшая к горизонтальным отношениям внутри команды разработки. И, как в свое время Spotify, мы осознаем, что естественно складывающиеся практики при таком штате нуждаются в корректировке.
Мы примерили эту модель к своей текущей команде, определили вертикали и горизонтали. Но, как это часто бывает, модель пришлось слегка доработать напильником под себя.
Что мы взяли из модели?
Прежде всего — матричную структуру. Только squad назвали кроссфункциональной командой (или вертикальной командой), а chapter — горизонтальной командой. Определили оптимальную численность команд: для вертикальных команд — до 9 человек, при условии что эта команда справляется с задачами. Для горизонтальной ограничений нет; сейчас самая многочисленная наша технологическая горизонталь — php-бэкендеры, их 15 человек (а тестировщиков всего 5, например).
Вместе с этим — сформулировали принципы формирования нашей вертикальной команды:
Автономность. Команда должна сама на 90% решать все входящие задачи. Если внешней экспертизы систематически требуется больше — значит, что-то нужно менять, усиливать команду или менять воронку задач.
Оперативность. Для этого команда не должна быть больше 9 человек.
Гибкость. Команда должна иметь возможность подстроиться под текущие задачи. Для этого лидер команды вправе инициировать найм или усиление команды за счет внутреннего перехода.
Трансформация разработки
На внедрение выбранной модели нам потребовалось примерно полгода. Старт — в июне 2022 года, сейчас процесс можно считать практически законченным.
1 этап: сформировали будущую структуру, примерно определили команды, быстро отделили те команды, которые были и так готовы начать работать автономно. На это ушло около месяца.
2 этап: сформулировали цели и задачи каждой лидерской роли, согласовали их с текущими лидами или кандидатами.
3 этап: дали возможность будущим лидам команд, тогда еще не готовых к отделению, определить сферы ответственности, донанять нужных людей в свои будущие команды и полноценно отделиться.
О лидах
Чтобы направлять команды (и было с кого спрашивать результат), мы ввели роли лидов и сформулировали кодекс, за что отвечают лиды.
Очень важно понимать, что в рамках нашей разработки лид — это не должность, а роль. Мы все — играющие лидеры, представители технологических горизонталей. Миссия любого лида — направлять и устранять препятствия, которые встают у команды на пути.
Продуктовый лид — ставит актуальные задачи и убирает неактуальные, расставляет продуктовые приоритеты, контролирует общие дедлайны.
Тимлид — организовывает людей, синхронизирует разработку, контролирует процесс выполнения задач и обеспечивает решение задач, намеченных продуктовым лидом.
Техлид — отвечает за техническое единство и развитие в своей горизонтали. Это глава гильдии: его задача — обеспечивать единообразие и надлежащий уровень качества разработки внутри своей гильдии и не допустить критический рост технического долга в погоне за продуктовыми задачами.
Тестлид — отвечает за обеспеченность продукта количеством и качеством тестирования.
Подводные камни
Мы ожидали, что не все будет просто. При делении разработки мы столкнулись со следующими проблемами:
Не все команды выделяются одинаково легко
Первой от нас отделилась команда 1С. Она и раньше в силу специфики продукта была максимально автономной. Буквально спустя неделю после старта ребята переехали в свой канал в slack, организовали свои митинги и стали работать в тесной связи с бухгалтерией (то есть, своими продуктовыми лидами, по сути).
С командой курьерского направления тоже было несложно: мы вместе решили, какой должна быть команда, чтобы закрывать задачи по курьерскому продукту, и усилили команду новым Android-разработчиком (искали его уже четко под курьерское направление).
Дальше процесс застопорился. Оставшиеся команды были недостаточно целостными и слишком связаны друг с другом, отделение нативным способом не шло. Мы приняли решение не торопить лидов и дать им время на самоопределение. Взяли паузу на три месяца и предложили лидам подумать, за что конкретно будет отвечать их команда, какую экспертизу и ответственность нужно передать из команды в команду, сколько и каких спецов надо нанять, чтобы выполнять свои входящие задачи. Спустя два месяца команды потихоньку «дозрели» до самоотделения, но мы решили не спешить: в итоге, когда командам предложили автономию, они ждали этого с нетерпением.
Крутые универсальные спецы в процессе отделения могут стать проблемой
Некоторые наши сотрудники за время работы вне жесткой структуры отрастили себе такую глубокую и всестороннюю экспертизу, что теперь им было сложно отнести себя к конкретной команде. Но так или иначе, это необходимо сделать, потому что незаменимость и владение уникальным знанием для нас в условиях роста — слабое место.
Если вы планируете наладить у себя Spotify-модель, осознайте: если спец умеет выполнять хорошо 50 разных задач, и его между ними разрывает, он обязан иметь возможность передать половину задач другому.
Некоторые команды могут поначалу быть неочевидными
На начальном этапе невозможно сразу определить все будущие вертикали. Так, последними в нашей матрице появились команда инфраструктуры и финансов. Мы смогли выделить их, только опираясь на воронку входящих задач. По факту команда инфраструктуры у нас и не существовала: специалисты просто занимались каждый своими задачами. Но после того, как остальные команды были выделены, стало ясно, что у нас наметились еще подразделения. Чтобы превратить направление в команду, мы назначили мотивированных ребят тимлидами и предложили им самим решить, что нужно для формирования полноценной кроссфункциональной команды, согласно нашим принципам.
Выделенные команды должны адаптироваться
В первые дни, когда новому лиду придется самому проводить дейли и курировать команду, будет много хаоса. Единственно верное решение здесь — не вмешиваться и дать время на адаптацию. Мы ограничились только сбором обратной связи у тимлидов, и в течение двух недель команды стали работать адекватно.
Выделенным командам нужна сквозная связь
По итогам мониторинга все тимлиды вертикальных команд отметили, что их в новой системе настораживает только одно: теперь никто не знает, что происходит в соседних командах. Для этого мы решили раз в неделю проводить короткий общий митинг тимлидов, где каждый рассказывает, что происходит в его подразделении. Это позволяет синхронизироваться и не утратить целостность команды. Любой член любой команды (и вертикальной, и горизонтальной) может подключиться и послушать лидов, задать вопросы, почувствовать пульс всей разработки.
Результаты
Заметно снизился уровень энтропии. Частные задачи решаются частными командами, гораздо меньше стало появляться обращений «на весь канал».
Все митинги и созвоны укладываются в 20 минут (кроме тех самых общих еженедельных: их норматив это час).
На основании принятой модели мы сформулировали новую программу найма: теперь ищем людей более прицельно, в конкретную команду и на конкретные задачи. Поэтому и находим все больше тех, кто сразу закрывает актуальные проблемы и повышает общую эффективность.
Вот что говорят ключевые лиды компании
Андрей Боярчук, тимлид команды курьеров:
С точки зрения команды, сепарация несколько улучшила мотивацию разработчиков, потому что мы смогли полноценно привлекать всех к обсуждению задач. Вовлеченности на ежедневных планерках стало больше, а времени на митинг уходит значительно меньше, как следствие — лучший фокус на задачах и большая очевидность в описании пула работ на день/два.
Павел Сирота, продуктовый дизайнер:
Стало легче планировать работу, в том числе на недели вперед (раньше наш горизонт планирования сводился к 2-3 дням). Мы можем набрать задачек на неделю и погрузится в работу, не отвлекая разработчиков на входящие запросы. Ребята стали меньше перепрыгивать с задачи на задачу, и мне стало проще, потому что я заранее знаю, кто чем будет заниматься и какой прогресс в конце недели мы получим.
Ольга Цивикова, тимлид команды клиентских приложений
Прежде всего, наши ежедневные утренние созвоны (дейли) мы проводим теперь по функциональным группам, поэтому утреннее планирование проходит значительно быстрее и эффективнее. Стало понятнее, кто в команде за что отвечает: ПО, тимлиды, техлиды. Разработчикам тоже понятнее, по каким вопросам к кому обращаться. Бывают еще моменты пересечения задач между командами, но в целом всем уже понятно, на какой созвон и к какой команде надо обращаться. Есть уже кросскомандые совещания.
Затем, я заметила, что каждая функциональная команда развивает свои процессы немного по-разному, а в какой-то момент мы делимся опытом и выбираем оптимальные для всех подходы. То есть, можно параллельно проводить разные эксперименты по управлению в разных командах и находить наиболее удобные варианты.
