Создание эффективных команд разработчиков, способных стабильно выпускать продукты в условиях динамичного рынка, — нескончаемый вызов для технических руководителей. Постоянные обновления зрелых продуктов требуют стабильной поставки новых функций без ущерба для качества и эффективности повседневной работы.
Мои выводы основаны на опыте управления мобильной игровой разработкой с аудиторией 500 000 активных пользователей в день и 16 функциональными областями, включая активную разработку новых фич. Так как контент игры обновляется ежедневно, от команд разработки ожидается высокая эффективность. Помимо выпуска новых фич в заявленные сроки, разработчики должны поддерживать бизнес-команды и оперативно реагировать на инциденты.
Высокое качество, понятные каналы поддержки, чувство ответственности и гибкость — эти задачи часто встречаются у технических лидеров в таких условиях. Тем не менее поиск баланса между стабильной поставкой продукта и поддержкой повседневных бизнес-процессов в конечном счёте повышает эффективность команды.
Сбалансированная ответственность за продуктовые функции
При управлении широкой и сложной системой чёткое распределение ответственности за функции продукта имеет решающее значение и должно быть доведено до всех сотрудников компании. Необходимо установить как технические, так и организационные границы и области взаимодействия.
Технические границы, такие как микросервисы, модули, API и отдельные репозитории, помогают разделить компоненты и разграничить зоны ответственности. Организационные границы включают правила взаимодействия и соглашения о сотрудничестве между командой и остальной частью компании, например: гайды по работе с функциями, процедуры эскалации или линии поддержки.
Важно обеспечить равномерное распределение ответственности за функции и сервисы продукта между всеми командами. Опытные команды, как правило, ведут больший объём или более сложные сервисы. Это может перегружать их, создавать узкие места, изолировать знания и повышать риск выгорания, что представляет угрозу для всей организации.
Оценивая баланс ответственности между командами, учитывайте когнитивную нагрузку поддерживаемых элементов, включая частоту использования, сложность решений, уровень технического долга и бизнес-критичность. Периодически пересматривайте текущее распределение ответственности и планируйте его на будущее при запуске новых проектов.
Стимулирование обмена знаниями
Команды, сосредоточенные на определённых областях приложения, развивают глубокую экспертизу в своей работе, что, однако, может привести к ограниченному пониманию того, как работают другие команды. Возникают изолированные участки, ограничиваются возможности обучения и снижается гибкость при распределении задач. Руководители должны стремиться создать среду, в которой команды сочетают глубокую экспертизу в своей области с рабочим пониманием других доменов.
Достичь этого можно с помощью стратегической ротации сотрудников — практики, известной как «ретиминг» (“reteaming”, смена команд). Одна из распространённых стратегий ротации, направленная исключительно на обмен знаниями внутри команд, — это чередование. При этом отдельные участники команды регулярно переходят в другую. Чтобы сохранить производительность и функциональность команд, ротации касаются аналогичных ролей — например, тестировщик на тестировщика или фронтенд-разработчик на фронтенд-разработчика. Длительность ротации нужно подбирать тщательно: если она слишком короткая — это дестабилизирует команды, если слишком длинная — может навредить участнику, покинувшему свою первоначальную команду.
Трёхмесячный период может стать хорошей отправной точкой, после которого участник команды возвращается в свою исходную команду для обмена знаниями. Это позволяет инженерам поработать с разными аспектами приложения, узнавать новое и погружаться в другую среду, что стимулирует развитие креативного мышления. Кроме того, это ограничивает желание удерживать лучших сотрудников в одной команде, поскольку некоторые лидеры, собрав сильную команду, стараются защитить её от изменений. Хотя удержание сильнейших инженеров может быть удобно для руководителя, в долгосрочной перспективе это создаёт проблемы, связанные с изолированной работой команды. Стратегия чередования вынуждает менеджеров команд разорвать этот круг.
Следует учитывать атмосферу и динамику внутри команды. Например, для команды может оказаться трудным потерять участника с уникальными навыками. Помимо технических, стоит учитывать и социальные навыки, а также неформальные роли в команде. Некоторые участники, например, являются своеобразным «клеем», который помогает команде функционировать как единое целое. Потеря такого человека, даже временная, может оказаться непростой. Помните, что каждая подобная ротация по сути создаёт новую команду.
Эффективное реагирование на инциденты в проде
Проблемы, с которыми сталкиваются пользователи, должны решаться оперативно, чтобы избежать негативного влияния на транзакции и бизнес-процессы. Это особенно важно для бизнес-моделей, основанных на микротранзакциях и онлайн-играх, так как каждая техническая ошибка в масштабах напрямую влияет на доходы компании.
Хотя конечная цель инженерной работы — выпуск качественного продукта без сбоев в проде, реальность такова, что работа с инцидентами является неотъемлемой частью процесса. Для этого необходима чётко выстроенная и эффективная система дежурств, с надёжным мониторингом, понятными процедурами оповещений и эскалации. Обычно дежурство несёт команда, которая разработала ту или иную фичу. Однако такой подход может оказаться затратным, особенно когда разные функции продукта отличаются по частоте использования и уровню сложности. Например, постоянное дежурство команды по функции, которая используется редко, приведёт к постоянным дополнительным расходам. Даже если такие траты можно оправдать с точки зрения бизнеса при необходимости высокой доступности сервиса, на практике это часто оказывается необоснованным.
Альтернативой может стать единая команда для реагирования на инциденты, которая будет работать независимо от того, кому назначена конкретная функция. Это сложная организационная модель. Она требует квалифицированных специалистов, качественного кода и эффективного обмена знаниями, чтобы дежурной команде не нужно было знать каждую деталь продукта для эффективной работы.
Система реагирования на инциденты должна мониториться с помощью метрик, таких как количество инцидентов, время отклика и проблемные зоны (участки продукта, где сбои происходят чаще всего). В этом контексте полезны ретроспективы, поскольку они формируют культуру обучения на ошибках и снижают частоту инцидентов. Анализ первопричин (Root Cause Analysis, RCA) также эффективен для обмена знаниями между командами через документацию RCA.
Мониторинг и наблюдаемость продукта
Эффективный мониторинг и наблюдаемость приложений имеют решающее значение в распределённых системах, основанных на микросервисах, так как они обеспечивают быструю диагностику и помогают предотвращать проблемы. Мониторинг собирает данные из системы, чтобы понять, что происходит. Наблюдаемость использует те же данные, чтобы понять, почему это происходит. Сбор и обработка данных из разных источников — инфраструктуры, контейнеров, логов приложений, трейсов — позволяет инженерным командам эффективно следить за системой, выявлять причины сбоев и быстро реагировать или предотвращать инциденты.
На рынке представлено множество систем, которые помогают в мониторинге и наблюдаемости. Их внедрение может быть затратным, но выделение значительных средств на эти системы быстро оправдает себя. При ограниченном бюджете можно комбинировать более дорогие решения в критичных областях с бесплатными инструментами, поддерживаемыми сообществом, в менее важных сферах. Подготовка обоснования и расчёта возврата инвестиций (ROI) поможет получить нужный бюджет для этих инструментов.
Как применять инженерные метрики
Разработка программного обеспечения — это сложный интеллектуальный процесс, который сложно точно измерить. Следует избегать упрощённых решений вроде подсчёта количества коммитов или пулл-реквестов — они могут вводить в заблуждение или даже быть вредными. Использование проверенных метрик (DORA или SPACE) помогает лидерам и командам выявлять возможные узкие места. Это позволяет измерять влияние изменений в таких областях, как распределение ответственности, обмен знаниями и реагирование на инциденты. Тщательно подобранные метрики стимулируют нужное поведение и отслеживают влияние изменений на инженерные процессы, предоставляя ценные инсайты о зонах, требующих улучшения.
Важно понимать, что при внедрении метрик ключевую роль играет коммуникация — если метрики вводятся без согласования с командами, это может вызвать сопротивление. Необходимо чётко объяснять, зачем и что именно будет измеряться, а также вовлекать команды в процесс для формирования понимания и сотрудничества. Задавайте открытые вопросы и инициируйте обсуждения, которые позволят командам внедрять метрики самостоятельно. Команда Google, разработавшая DORA-метрики, собрала и опубликовала вопросы, которые лидеры могут использовать как основу для обсуждений в своих командах. Позвольте командам самим обсудить и выбрать те метрики, которые им действительно важно отслеживать.
После внедрения метрик избегайте установки целей, основанных на бенчмарках. Вместо этого обращайте внимание на контекст, стоящий за метриками. Например, если вы видите высокое время на ревью пулл-реквестов, это может указывать на слишком большие пулл-реквесты, плохие уведомления или перегрузку участников команды другими задачами. Работайте с командами над устранением этих проблем до того, как ставить конкретные цели.
Инструменты для отслеживания метрик
Кроме простых инженерных сред, внедрение метрик потребует использования отдельного инструмента, который поможет собирать и визуализировать данные. Эти инструменты взаимодействуют с репозиториями, анализируя ветки и пулл-реквесты. Надёжный инструмент особенно важен при работе с комплексными репозиториями, где часто встречаются аномалии, временные ветки, незавершённые задачи и различные стратегии ветвления. На практике вы можете захотеть исключить некоторые ветки из расчёта метрик. Чтобы избежать утомительной ручной работы по исключениям, выбирайте инструменты, которые могут автоматически исключать ветки на основе заданных правил. Изучение доступных решений и подбор подходящего инструмента для конкретной задачи — то, чем обязательно стоит заняться техническому руководителю.
Заключение
Эффективным командам разработки необходимо сбалансированное распределение ответственности за функции, обмен знаниями и эффективное реагирование на инциденты. Руководители также должны разумно использовать инженерные метрики, опираясь не только на количественные данные, но и интерпретируя их в более широком бизнес-контексте для достижения значимых улучшений. Это включает использование проверенных систем метрик, таких как DORA или SPACE, поддержание открытой коммуникации с командами по вопросам метрик и использование подходящих инструментов для работы со сложными репозиториями.
Следуя этим шагам, технические менеджеры могут развивать высокоэффективные команды, которые стабильно выпускают обновления и новые фичи, обеспечивая конкурентоспособность и привлекательность продукта для сотен тысяч пользователей.
Для поддержания эффективной работы тимлиду приходится овладеть многими навыками, включая управление ролями в команде. В апреле в Otus пройдут открытые уроки, на которых опытные управленцы поделятся своими знаниями и опытом на эту тему: