Как мы разделили большую "плоскую" команду на 5 мелких и не пожалели об этом

Сегодня в IT-компаниях Украины (и не только) популярна многоуровневая структура, состоящая из небольших Agile-команд до 10 человек. Многие обходят стороной плоскую организационную структуру в компаниях, ведь она кажется непривычной, неудобной и непонятной. Предлагаем заглянуть за кулисы и увидеть все преимущества подхода на опыте компании XCDS. Перед нами стояла задача разделить один коллектив на несколько команд поменьше, поскольку отдел разработки будем расширять до 150+ человек.

Меня зовут Лена Баринова, я Project Manager в XCDS и хочу поделиться с вами опытом внедрения изменений в структуру компании. Также здесь вы найдете выводы и рекомендации для всех, кто задумывается о плоской организации команд.

Иллюстрация Алины Самолюк

Почему мы выбрали плоскую организационную структуру

Как любая компания, мы не начинали свой путь с множества отделов по разным направлениям. Изначально в 2013 году нас было около 25 человек — специалистов и руководства, а менеджеров среднего звена не было вообще.

Шло время, компания росла. Спустя три года мы с коллегами поняли, что «плоская» команда из 60 человек — уже довольно много. Управление больше не казалось органичной вещью, приходилось прилагать больше усилий, чтобы поддерживать прежний темп работы и продуктивность. Но все же мы не отказывались от привычной структуры и решили продолжить работу уже с несколькими подобными командами. До максимума — 80 человек — мы доросли за год и в конце 2019-го начали переход к более многослойной иерархии. За 2020 год мы выросли до 124 человек. В будущем же перед нами стоит задача расширить команду разработки до 150 человек. В идеале новые маленькие команды будут расти до своей собственной границы, которую можно определить лишь индивидуально в каждом отдельном кейсе, а затем будут разделяться.

Как же мы смогли оставаться гибкими и разрабатывать продукт «плоской» командой до 80 человек? Мы использовали модель Spotify и их матричный подход к организации работы, что позволило масштабироваться без потери продуктивности. Практически всегда все члены команды принимали участие в планированиях, ретроспективах, предлагали идеи, открыто коммуницировали. Не было общения «через лидов» — каждый мог напрямую обратиться к нужному человеку. Любой сотрудник был на одном уровне с руководителем и даже директором по разработке.

Почему мы не делились на более мелкие команды с самого начала

Мы не делали этого, поскольку строим единый продукт, в котором есть различные модули. И каждый сотрудник принимал активное участие в разработке.

Что я имею в виду под «единым продуктом»? Это ядро, которое работает на 7+ платформах и состоит из трех редакторов (текст, таблицы и презентации). Любое изменение может влиять на работу всех компонентов на всех платформах. Именно поэтому постоянное взаимодействие членов команды помогло нам работать как единый организм.

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

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

Многие поправки и улучшения в рамках каждого релиза затрагивали все компоненты продукта. К примеру, на одну фичу требовалось 100% UI-дизайнера, на другую — 25%. Мы экономили время за счет переключения специалистов в нужный момент разработки и быстро продвигали задачи к релизу — подключали разработчиков именно в момент, когда это необходимо, а не после окончания их текущих заданий.

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

Как мы выстраивали работу большой «плоской» команды до 80 человек

Планирования, как и ретроспективы, проводились одновременно и занимали в среднем час.

Например, ретроспективы проводились в формате World Cafe , где у каждого есть возможность обсудить интересующие вопросы с коллегами. Всегда находятся более сложные области, которые сотрудники хотели бы обговорить. Это процесс разработки или тестирования, обучение новых сотрудников, проблемы инфраструктуры и прочее.

Ребята выбирают три самые актуальные темы и присоединяются к обсуждению за тремя столами. Ротация между кругами обсуждения происходит три раза соответственно. На каждом этапе ведущий подводит краткий итог предыдущей дискуссии и озвучивает, какие были договоренности или action items. Так мы продуктивно помещали (и до сих пор это делаем) до трех сессий общения в одну. Это дает прекрасную возможность решить все важные вопросы вовремя, сводя тем самым уровень рабочего хаоса к нулю.

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

Ежедневные стендапы в среднем занимают 15 минут, реже — до 25–30 минут. Если есть проблема, ее озвучивают для всех, после встречи желающие могут принять участие в решении.

Преимущества такой организации

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

Быстрое реагирование. Если возникает техническая ошибка, о ней говорят на стендапе и сразу же назначается митинг по решению проблемы. Работа над срочными задачами начинается сразу же после встречи.

Много людей на встречах — это не просто, но у каждого есть право голоса. Здесь нет ограничений, но бывают вопросы, которые необходимо обсудить отдельно. Если обсуждение заняло больше 5 минут, останавливаемся и встречаемся всеми заинтересованными отдельно. Коллеги останавливают друг друга, если кто-то выходит за рамки тайминга. Стоит отметить, что в маленьких командах стендапы иногда затягиваются минут на 40 и даже больше, и это связано с тем, что люди не привыкли друг друга останавливать. Кстати, такой подход помогает сотрудникам улучшить и навыки самопрезентации.

Как мы стали переходить на другой формат работы

С момента, когда нас стало больше 80, нужно было выстроить такие же «плоские» команды, но с меньшим количеством людей (от 3 до 20). По моему мнению, это позволило бы расти и развивать отдельные компоненты продукта.

Как меняли организационную структуру:

Первая попытка разделить всех сотрудников на кросс-функциональные команды не увенчалась успехом. Люди сопротивлялись, им было привычно и удобно действовать в связке с остальными, ведь так они работали уже несколько лет!
Решили двигаться постепенно:
- Выделить группу людей (от 5 до 15 человек), которой был нужен лидер. Мы определяли эту необходимость исходя из наблюдения за рабочим процессом. Чувство рассинхронизации и спад продуктивности служили для нас маркерами. Решили назначить тимлида из уже существующих сотрудников. Обычно люди сами проявляли желание что-то менять, брать на себя ответственность, развивать лидерские качества. Мы всего лишь помогали сотрудникам с их желанием расти.
- Выделить зону ответственности лида с основным ориентиром на техническую составляющую, без привязки к софт скилам и управлению командой, хотя и на последнее старались обращать внимание.
- Привлечь сотрудников для обучения новых членов команды, чтобы они передавали знания по продукту и менторили новеньких.
- Наладить процесс получения фидбэка по работе команды от управленцев, которые будут делиться опытом и помогать разрешать конфликтные ситуации.

Мы руководствовались принципом ненавязчивости, чтобы предвидеть возможное сопротивление со стороны коллег. Собирали фидбэк от команд посредством опросов и личного общения, прислушивались к их пожеланиям. Примерно за год мы вышли на 6 команд, одна из которых и сейчас довольно объемная и состоит из 30+ человек, но и на этом не останавливаемся. Добавляем команды по мере роста компании.

Главное — обращать внимание на естественные процессы в работе людей. Видеть рабочие привычки и зоны ответственности сотрудников. Если лидер вовлечен, ориентирован на результат, поддерживает и развивает каждого сотрудника и команду, обязательно найдутся специалисты, которые возьмут на себя ответственность за работу, межкомандную коммуникацию и техническое развитие продукта.

Какие методологии используем в работе

У нас итерационный процесс разработки. Берем чуть от Scrum, чуть от Kanban, смешиваем в зависимости от задач и используем микс для достижения результата. Например, от Kanban мы взяли быстрое реагирование. Когда приходит высокоприоритетная задача, немного сдвигаем другие, чтобы максимально быстро с ней справиться. От Scrum берем груминги, планирования, ретроспективы, демо, работаем по итерациям. У нас также есть бэклог, спринты и Scrum-доска для демонстрации статуса по разработке.

Чем мы усиливаем работу больших команд?

У нас появился статус-бот, чтобы быстро узнавать, чем заняты люди, на каком этапе находится продукт или его фичи. Бот информирует членов команды о статусе по работе каждого человека, что позволяет коллегам быть в курсе происходящего, даже если они работают в разных командах.

Организовали онлайн-ивент Weekly Huddle по пятницам. Собираемся с коллегами в Zoom и обсуждаем продуктовые истории и задачи в разработке. На мероприятии мы озвучиваем риски, говорим о проблемах и подбираем людей, которые могут помочь с их решением. Благодаря этим встречам можно не ждать нового планирования, а решать вопросы «здесь и сейчас».

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

Итак, какая структура лучше? Где искать золотую середину

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

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

И если вы решите менять структуру в компании, будьте готовы к сопротивлению сотрудников. Будет и откровенное непонимание, зачем все это нужно, и даже саботаж некоторых решений, но... Старайтесь позитивно смотреть на вещи и получать удовольствие от всего, что делаете!

В любом случае, если вы собираетесь масштабироваться и разделить одну большую команду на несколько таких же «плоских», но поменьше, можете смело использовать наш с коллегами опыт:

Выделяйте более мелкие команды и назначайте им опытного тимлида. Переход к новой структуре должен быть органичным, а не навязанным. Люди вряд ли захотят менять свое удобство на следование новым правилам просто потому, что «так нужно». В этом поможет постоянная открытая коммуникация.
Занимайтесь обучением новых членов коллектива. Здесь неоценимую поддержку изменениям окажет менторство, о котором говорили Оксана и Франклин в своих колонках.
Собирайте фидбэк любыми удобными для вас способами, а еще лучше — наладьте процесс коммуникации с лидами, а они уже будут руководить мелкими командами.
Держите сотрудников в курсе изменений и событий — используйте ботов для отслеживания статусов, организуйте онлайн-встречи и рассылки. Вовлеченные в процесс люди всегда будут стремиться добиться лучших результатов!
И, конечно же, узнавайте об опыте других компаний и делитесь своим. Как говорится, в беседе рождается истина.

Поэтому, если хотите что-то спросить или поделиться собственным опытом, комментируйте эту статью, буду рада обсудить!

Опубліковано: 12/03/21 @ 08:00
Розділ Різне

SEO Блог