×Закрыть

Как мы масштабировали команду и выжили

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

Такая мечта нашей управленческой команды сбылась. За последний год мы агрессивно выросли (почти в 10 раз), о чем и хочется рассказать, поделиться накопившимися уроками и опытом. Приведенный ниже кейс описывает инструменты и практики масштабирования, примененные в команде при росте с 10 до 60 разработчиков за полгода, которые помогли всему аккаунту «прыгнуть» с 30 до 250 человек.

Онбординг

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

Быстро стало понятно, что просто докупить столов и компьютеров — недостаточно. Напутственным словом тоже не отделаешься, как в случае с добавлением одного человека в устоявшуюся команду небольшого проекта. Нужно оперативно и системно адаптировать людей, дать необходимую информацию и определить контактных лиц, назначить ментора. Постоянная поддержка специалиста — даже после того, как он влился в коллектив, — очень важна. Особенно — со стороны ментора (его мы также стараемся поддерживать, например — организовываем курсы и воркшопы)!

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

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

Как выглядит онбординг:

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

Что мы получили после внедрения этой структуры:

  • Мы экономим время как опытных членов команды, так и новичков. Люди не отвлекаются на то, чтобы проверить, утвердить, помочь, найти. Есть заранее обозначенные активности и ответственные лица.
  • Вовлеченные специалисты распоряжаются своим временем рационально: каждая активность заранее планируется, является частью ежедневной нагрузки и не мешает основным задачам.
  • Новичок не ощущает себя брошенным — он всегда знает, что ему делать и у кого попросить помощи.
  • Эта система легко масштабируется.

Переосмыслить проект в целом

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

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

Выделить новые роли

В определенный момент роста команды получилось так, что нагрузка тимлидов (а их было на тот момент двое) оказалась распределена неравномерно: слишком много времени уходило на менторство и онбординг, слишком мало — на другие задачи.

Сухая теория гласит, что каждый mentee требует порядка 10% времени ментора. Эмпирически мы пришли к тому, что для нас комфортно разделить организационную и техническую нагрузку примерно поровну, то есть каждый лид может курировать до пяти подопечных. Чтобы разгрузить менеджеров и тимлидов, мы решили подробить проектные команды и делегировать функции.

Для этого создали роль Group Lead. Это разработчик не ниже Intermediate или Senior уровня, уже обладающий доменной экспертизой, с командой около пяти программистов: с таким количеством людей он/она могут валидировать задачи, уделяя внимание каждому. Также мы переосмыслили роль тимлида: для команды из 60 человек у нас их стало трое, каждый в своей экспертной области:

  • Тимлид по техническим вопросам, ответственный за R&D и фундаментальные технические вопросы.
  • Тимлид по бизнес-интересам и технологическому развитию — отвечает за взаимодействие «бизнес — команда разработки», валидирует требования.
  • Тимлид, отвечающий за процессы разработки — их имплементацию и контроль.

Тот же маневр проделали и с командой менеджмента. Выделили Project Managers, которые непосредственно работают с командой, Project Coordinators и Resource Coordinators, которые всегда готовы прийти на помощь. Это позволило разграничить зоны ответственности внутри аккаунта, обозначить сферы влияния от ежедневного распределения ресурсов до стратегического планирования.

Новый взгляд на сам процесс разработки

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

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

Давайте углубимся в детали и приведем несколько точечных примеров.

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

Поднажали на усовершенствование CI/CD практик, инвестировали в тестирование и инфраструктуру:

  • Пересмотрели подход и фреймворк для unit-тестирования.
  • Прокачали инфраструктуру, стали выполнять пакет тестирования не на каждый билд, а на каждый пулл-реквест, с автоматическим запретом мержа в случае ошибок. Конечно, стоило ввести это с самого начала, чего мы не сделали, но вынесли урок, который будем применять на других проектах.
  • Внедрили SSA (system stability assurance) процесс, который по своей сути содержит набор интеграционных тестов и событий, регулирующих их запуск. Этот подход призван сместить фокус автоматического тестирования с отдельных юнитов в сторону бизнес-сценариев, что позволит ускорить поставки и быть уверенным в их качестве. Говорят, когда Титаник тонул, у него из трубы все еще шел дым и в рубке горел свет — вот такие false-positive результаты тестирования мы и устраняем.

Пересмотрели подход к ревью кода. Перешли от модели «Пулл-реквесты проверяют лиды» на «Пулл-реквесты проверяют носители компетенции в целевом компоненте». Это означает, что большее количество специалистов взяли на себя ответственность за процесс. Мы выявили техэкспертов по компонентам и разгрузили лидов — децентрализовали принятие решения. В перспективе движемся к формированию SME (subject matter experts) по каждому из компонентов системы и специализации отдельных команд.

Для старта мы сделали матрицу компетенций, где на пересечении специалистов и компонентов есть возможность выбрать оценку от 0 до 3, где 3 — знание компонента на глубоком уровне. Само собой, те же компоненты были продублированы и в Jira, что помогает собирать статистику по каждому из них, а также ориентироваться по контактным лицам.

Knowledge sharing занял еще более значимую роль. Вместе с клиентом мы начали формировать базу знаний. Разработчики записывают демо реализованного функционала, мы каталогизируем эти записи, формируя единый удобный справочник. У нас появилась возможность «пощупать» продукт, даже не запуская его и не читая спецификаций.

Это, пожалуй, основные направления. Каждое под собой содержит еще десятки мелких доработок и изменений, которые необходимо было сделать во время миграции (или, быть может, правильнее сказать — эволюции) процессов аккаунта.

Вывод

Описанные шаги позволили нам хоть и не безболезненно, но успешно масштабироваться в условиях агрессивного роста — основное увеличение команды произошло менее чем за шесть месяцев.

Также к заслугам отнесем и то, что все процессы, которые мы внедряли для команды из 60 человек, успешно работают для 250 человек на стороне Dev-Pro и для 400 специалистов на стороне клиента. Более того, наша команда позитивно влияет и на работу других вендоров заказчика.

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

LinkedIn

24 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Андрей, спасибо за статью!
Пара вопросов:
— За какой период удалось вырасти с 30 до 250?
— Если не секрет, что за клиент (или хотя бы индустрия-домен)?

Спасибо, Богдан.
1 — около года, чуть больше
2 — ресторанный бизнес

+220 чуть более чем за год — круто!

стали выполнять пакет тестирования не на каждый билд, а на каждый пулл-реквест, с автоматическим запретом мержа в случае ошибок.

Мне вообще странно, что кто-то мог делать иначе в наше время. Но, видимо, остатки подходов сохраняются ещё с 1980-х, если не раньше (это когда считались нормой все эти безумные «build 1.2.497503»).
И есть инструментальные средства, которые этому способствуют. Тут нельзя ли раскрыть уголок тайны и назвать, на чём раньше работало?

Перешли от модели «Пулл-реквесты проверяют лиды» на «Пулл-реквесты проверяют носители компетенции в целевом компоненте». Это означает, что большее количество специалистов взяли на себя ответственность за процесс.

Где-то аналогично. Peer review для таких вещей — в моих краях скорее норма, и если отказываются где-то, то вместе со всем CI (были и такие места). Один друг до сих пор плюётся и ругается чёрными словами на все схемы такого ревью, рассказывая, что ему по полгода тормозили ревью, а за это время майнстрим уходил заметно вперёд, и всю работу по приспособлению и отладке приходилось повторять по новой, и так 3-4 раза.
Думаю, у вас есть обеспечение оперативности таких ревью, иначе это быстро загнётся — коллеги обычно меньше чувствуют ответственность за чужие задачи.

Внедрили SSA (system stability assurance) процесс, который по своей сути содержит набор интеграционных тестов и событий, регулирующих их запуск. Этот подход призван сместить фокус автоматического тестирования с отдельных юнитов в сторону бизнес-сценариев, что позволит ускорить поставки и быть уверенным в их качестве.

А мы с этого, наоборот, начали, и только затем стали спускаться к юнитам.

Для старта мы сделали матрицу компетенций, где на пересечении специалистов и компонентов есть возможность выбрать оценку от 0 до 3, где 3 — знание компонента на глубоком уровне.

Аналогичное следовало бы сделать ещё и для технологий в общем.

У нас появилась возможность «пощупать» продукт, даже не запуская его и не читая спецификаций.

Вот это непонятно, прошу расшифровать.

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

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

Приведенный ниже кейс описывает инструменты и практики масштабирования, примененные в команде при росте с 10 до 60 разработчиков за полгода, которые помогли всему аккаунту «прыгнуть» с 30 до 250 человек.

А сколько времени заняла подготовка этого процесса? Или всё отлаживали на ходу?

Вот это непонятно, прошу расшифровать.

новички смотрят записи демо, которые, при нормальной подаче, дают обзор гораздо быстрее, чем (слишком) детализированные текстовые спеки

На подготовку времени отдельно практически не было.

Из статьи неясно, какую методологию разработки использовали на этом проекте? Речь только о разработчиках идёт, сложно понять. Что-то аджайловое? Тогда вопрос такой: сейчас SAFe набирает оборотов, в его сторону не смотрели?

Инна,

Мы рассматривали ряд практик: SAFe, Nexus Framework, отчасти даже Spotify Tribe approach. Выбирали подходящее, но так и не выбрали. Поскольку мы аутсорс компания, возможности имплементации тех или иных процессов ограничены спецификой устоявшихся бизнес-процессов заказчика. Не то чтобы их нельзя изменить — скорее вопрос целесообразности и затрат на имплементацию против ожидаемого эффекта.

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

Если кратко, то наш изначальный фреймворк набрал «„жирка“» в виде дополнительных процедур и артефактов, но ни одним из популярных scaled фреймворков не стал, на данный момент в этом нет нужды.

Спасибо за разъяснения!

Спасибо за статью.
По сути вы разработали документацию для адаптации и пофиксили процессы.
Уверен, что все прошло не так гладко как написано в статье, но спасибо за указанные инструменты и опыт.

Хотелось бы узнать подробнее о взаимодействии менеджерского состава на проекте. Вы упомянули

Выделили Project Managers, которые непосредственно работают с командой, Project Coordinators и Resource Coordinators, которые всегда готовы прийти на помощь.

Если будет возможность, напишите пожалуйста как перестроили процессы управления.

Роман,
Тут двумя словами не обойтись и комментарий может получиться больше самой статьи :)

Учитывая нашу ко-локацию, Харьков, предлагаю обсудить на кофе-брейке какой-нибудь из следующих локальных конференций. На PMCon я часто Вас видел, так что, как вариант — на следующем.

Вы не против?

я бы тоже послушала :)

Да я тут намекал на серию статей)
Встретиться только за, если получится раньше весны, то было бы здорово, но это мы уже отдельно обсудим.
Спасибо за ответ.

Написано красиво, но в реальности, при 10 джунах просто замахаешься отвечать на усные вопросы, разве, что каждому рот заклеить.

раз наняли 10 джунов значит так надо, только нужно определить приоритеты менторство или девелопмент, а если так же продолжать девелопмент и добавилось менторство в фоне, то это, конечно, дичь и все будет плохо

Андрей,
Не могу не согласиться.

Именно поэтому, мы стараемся выдерживать баланс seniority как 50% Intermediate, и по 25% Junior и Senior — как среди разработчиков, так и среди не-деливери специалистов.

Практика показывает, что при такой композиции команд объем коммуникации позволяет поддерживать ее же качество на стабильном и приемлемом уровне.

позволяет поддерживать ее же качество на стабильном и приемлемом уровне

должна быть деградация проекта при таком раскладе, потому что здесь не 0-50-100% идеальности, а например 10-30-60% и среднее не 50%, а 30%, при которых появляется «снежный ком», который позволяет добиться экспоненциальной деградации и через пару лет «у нас сложный проект, с легаси»

Расшифруй, plz :) что мерялось и в каких попугаях?

это ж не научный труд с формулами и контрольными группами, просто наблюдение, что синьоры делают что-то лучше среднего в очень редких случаях, обычно просто решение в лоб, отсюда и 60% «идеальности», где 50% среднее решение компромисс между качеством и скоростью разработки, а дальше уже и не важно, проект пойдет деградировать, чтобы этого не было нужно в среднем выжать больше,чем 50%, т.е. основная масса должна быть синьорами, еще и на улучшения надо выделять время, потому что те условные 60% далеко не всегда достигаются, потому что далеко не все синьоры любят программирование, не везде адекватный менеджмент, не везде сроки не горят

Так если 10% на одного ученика, то при 10 как раз получается всё время отведено на них ;)
Но я бы при таком количестве сделал обязательным ознакомление каждого из них с тем, с чем сталкивается другой. Разве что у них совершенно разные направления...

по поводу system stability testing вы немного неточно описали, по сути это специфичное нефункционально тестирование, направленное на проверку интеграции системы в критичных условиях. такое делают не только на крупных проектах, можно и без интеграционных кейсов тоже проворачивать. допустим, эмулировать плохое интернет-соединение и так далее

больше почитать допустим тут
www.softwaretestingclass.com/...​ity-testing-what-why-how

в остульном большое спасибо за материал, интересно узнать чужой опыт :)

Анна,
Вы правы касательно сути system stability testing.

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

В качестве примера, могу привести вектор SSA для обеспечения стабильности приложения, а именно — его бесперебойной работы в течение N бизнес-дней.
С точки зрения «testing» — мы внедрили авто-тест, который симулировал работу продукта в максимально-приближенных к regular business operation условиях. То есть, фактически констатировал, может ли приложение покрыть то самое значение N.

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

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

Спасибо, очень интересно!

В качестве примера, могу привести вектор SSA для обеспечения стабильности приложения, а именно — его бесперебойной работы в течение N бизнес-дней.
С точки зрения «testing» — мы внедрили авто-тест, который симулировал работу продукта в максимально-приближенных к regular business operation условиях. То есть, фактически констатировал, может ли приложение покрыть то самое значение N.

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