Как мы масштабировали команду и выжили
Кто из уже более-менее опытных менеджеров не мечтал, чтобы его проект вот так взял и вырос? Рано или поздно каждого, ну или большинство, посещают мысли о том, что процессы отлажены, все идет своим чередом, и остается только присматривать за происходящим, изредка внося те или иные коррективы. Скучно. Хочется новых вызовов и выхода на следующий уровень.
Такая мечта нашей управленческой команды сбылась. За последний год мы агрессивно выросли (почти в 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 специалистов на стороне клиента. Более того, наша команда позитивно влияет и на работу других вендоров заказчика.
Мы все еще не в конце пути: некоторые из описанных выше изменений были реализованы только частично, мы продолжаем внедрять определенные аспекты по сей день. Как ни крути, чем больше проект становится — тем большую инерцию он приобретает. Но это уже совсем другая история.
