Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Как мы разделили большую «плоскую» команду на 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). По моему мнению, это позволило бы расти и развивать отдельные компоненты продукта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось12
До обраногоВ обраному0
LinkedIn

Схожі статті




6 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Сложно назвать 80 человек командой.
А интуиция подсказывает что в этой команде, было ещё по 5-8 подкоманд, если не больше. И вопрос тогда — в чём же переход?

У нас сложность была в том, что не было подкоманд вообще. Я не считаю командой людей одной специализации, то есть команда ПО из 3-х человек, команда разработчиков и команда тестировщиков.
Специфика нашей разработки такова, что каждый релиз набор задач на разработку разный, следовательно, инженерная квалификация нужна разная. Поэтому есть люди, которые загружены на 100% задачами релиза, а есть те, кто могут уделить внимание инженерному долгу.
Делать кросс-функциональную команду в нашей реальности невозможно. Ведь чтобы поддержать возможность разработки даже определенной области задач, нам необходимо 15+ разработчиков, плюр тестировщики и ПО. Поэтому мы и решили использовать подход Spotify. Наличие компонентов и команд помогло разделить одну плоскую команду на подкоманды, набить других шишек, сделать выводы и двигаться в сторону LeSS.

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

По всему похоже, что пытались переизобрести LeSS. Вопрос — почему просто не попробовали его из коробки?

Спасибо за комментарий, возможно если добавить диаграмму, то будут понятны этапы через которые мы проходили при разделении на команды.
Отвечу на ваш вопрос, мы не пытались переизобрести LeSS. Мы придерживались мнения, что процесс не ради процесса, а процесс для людей, поэтому процессы и разные практики применяли для того, чтобы достигать бизнес целей, при этом максимально вовлекая команду. Таким образом мы делаем больше чем изначально планируем, ведь каждый сотрудник остается вовлеченным, берет на себя ответственность и меняет свой рабочий процесс так, чтобы быть эффективным для команды.
Сейчас это похоже на LeSS, на старте проекта был Scrum, по дороге примеряли много других подходов, но что будет завтра Huge LeSS или что-то другое, ответа нет. Главное мы ориентируемся на результат.

Честно говоря, ваш ответ можно сократить до

мы не пытались переизобрести LeSS.

вода

Сейчас это похоже на LeSS

Т.е. любой опытный менеджер сократил бы вам цикл обучения в разы.
Я прекрасно понимаю концепцию инструментов в контексте, но описанная в статье проблема имеет как минимум решение в.1.0. И ваш ответ в комментарии только подтвердил мое предположение.

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

Підписатись на коментарі