Частое явление когда, после выпуска продукта в свет, команда разработки остается на поддержке и продолжает разрабатывать новый функционал. Как организовать эффективную работу в такой ситуации?
Наиболее эффективно инженеры работают в условиях, где они могут сосредоточиться и погрузиться в работу. Однако в случае поддержки часто возникают отвлекающие факторы и конкурирующие задачи. При этом сложно балансировать между временем на сосредоточенную работу и оперативным реагированием. Разработка новых функций требует сосредоточенности, а реагирование на проблемы клиентов и поддержка работающего сервиса — оперативности и осведомленности.
Из популярных решений прибегают к следующим:
- Выделенная (под-)команда для поддержки
- Дежурный который принимает входящие запросы и перенаправляет в исполнителей, следит за выполнением
- Ротация команды поддержки
Microsoftпрактикует третий вариант, как это выглядит на практике.
Команда делиться на два экипажа:
- Экипаж разработки (feature crew) — занимается новыми функциями.
- Экипаж поддержки (customer crew) — отвечает за работоспособность сервиса.
Для его успешной реализации важно:
- Четко определить роли экипажей.
- Установить прозрачный процесс ротации.
- Регулярно корректировать размеры экипажей.
Экипаж разработки (F-crew)
F-crew сосредоточен на создании и выпуске новыго функционала. Они защищены от ежедневного хаоса поддержки, чтобы иметь время на проектирование, разработку и тестирование.
Члены F-crew минимизируют отвлечения: редко проверяют почту и избегают несрочных задач. Если возникает критическая проблема, ее делегируют экипажу поддержки.
Это позволяет глубже погружаться в контекст, находить сложные баги, проектировать новый функционал. Рекомендуемый work-in-progress (WIP) лимит для команды из 4-6 человек, обычно ограничен 2-мя фичами. Такой формат работы называют «спокойным и сосредоточенным» , он зарактеризуется предсказуемой пропускной способностью (throughput rate) и временем выполнения.
Экипаж поддержки (C-crew)
C-crew фокусируется на оперативных задачах: поддержка клиентов, исправление багов, мониторинг и телеметрия. Их главный приоритет — стабильность сервиса. Они быстро реагируют на проблемы, общаются с клиентами (через почту, Twitter и другие каналы).
C-crew называют «щитом», так как они защищают команду от отвлечений. Их работа динамична: в загруженные недели они разбирают поток запросов, а в спокойные периоды улучшают мониторинг. Однако такой темп может быть утомительным, поэтому важна регулярная ротация.
Ротация экипажей
Чтобы система работала, нужен четкий процесс ротации. Оптимальный вариант — еженедельные перестановки. В конце недели команда решает, кто переходит в другой экипаж.
Правила ротации:
- Самые опытные участники обычно меняются местами.
- Если кто-то хочет завершить текущую задачу, возможны исключения.
- Долгое пребывание в одном экипаже увеличивает вероятность ротации.
Частая ротация улучшает обмен информации, понимание системы и улучшает взаимопонимание в команде. Новые участники F-crew часто приносят улучшения в систему, а C-crew учится решать проблемы самостоятельно.
Размер экипажей
Размеры экипажей меняются в зависимости от нагрузки:
- Если много инцидентов или технического долга — C-crew расширяется.
- В некоторых случаях вся команда может временно перейти в C-crew (например, после крупного релиза).
Гибкое распределение ресурсов делает работу команды более предсказуемой.
Преимущества системы
- Продуктивность: F-crew обеспечивает стабильный выпуск функций, C-crew — оперативную поддержку.
- Предсказуемость: Четкое разделение задач помогает планировать сроки.
- Моральный дух: Инженеры понимают свои роли и работают ответственно.
Этот подход также применим и в других ситуациях с конкурирующими приоритетами, когда необходимо защитить крупную и сложную разработку от ежедневных отвлечений.
