Как ответить
Я бы начал не с внедрения инструментов или процессов, а с диагностики. Без понимания корня проблемы любые изменения — это гадание. Первым делом я соберу три слоя данных: объективные метрики, субъективные ощущения команды и контекст бизнеса.
Шаг 1. Объективные метрики (2-3 дня):
- Проверю цикл-тайм (от взятия задачи до релиза) и лид-тайм (от появления идеи до поставки) — если они >2 недель для обычных фич, это красный флаг. Посмотрю на DORA-метрики: частоту деплоев, время восстановления после сбоев, процент неудачных изменений. Например, если деплои раз в месяц, проблема в CI/CD или ревью.
- Гляну на WIP (work in progress) — если у каждого разработчика по 3-4 задачи в статусе «в работе», это классический признак перегрузки и контекст-свичинга.
- Соберу данные с ретроспектив за последние 3 месяца — какие боли команда сама называла чаще всего.
Шаг 2. Качественная диагностика (1 неделя):
- Проведу одно-на-один с каждым разработчиком (30 минут, неформально). Вопросы: «Что отнимает больше всего времени?», «Что мешает сделать задачу быстрее?», «Есть ли задачи, которые вы считаете бесполезными?». Обычно вскрываются вещи, которых нет в трекере — например, бесконечные согласования с заказчиком или legacy-код, который требует тройного тестирования.
- Посмотрю код-ревью за последнюю неделю: среднее время ожидания ревью, количество комментариев, стиль обсуждений. Если ревью висит 3 дня — это бутылочное горлышко.
- Проверю процесс онбординга — если в команде есть новые люди, они могут тормозить из-за отсутствия документации.
Шаг 3. Бизнес-контекст:
- Узнаю у продакт-менеджера, как часто меняются приоритеты. Если задачи переключаются каждую неделю, команда тратит 30% времени на контекст-свичинг. В одном проекте мы замерили — после стабилизации бэклога скорость выросла на 40% без найма.
Что буду делать на основе данных:
- Если проблема в процессах (долгие ревью, хаотичный бэклог) — внедрю лимиты WIP (максимум 2 задачи на человека), настрою автоматизацию CI/CD (чтобы деплой занимал 10 минут вместо часа), введу ежедневные 15-минутные стендапы с фокусом на блокеры.
- Если проблема в техническом долге (тесты падают, кодовая база раздута) — выделю 20% времени на рефакторинг и покрытие тестами критических путей. В прошлом проекте мы за полгода подняли покрытие с 30% до 70%, и количество багов в продакшене упало втрое.
- Если проблема в мотивации (выгорание, отсутствие видения) — организую демо каждые 2 недели, где команда показывает результаты реальным пользователям. Это даёт смысл работе.
С чего начну буквально: с разговора с тимлидом и PM, чтобы понять, какие метрики уже собираются. Если их нет — настрою сбор Cycle Time и WIP в Jira за один день. Параллельно запишусь на 1-1 со всей командой. Первые изменения (например, лимиты WIP) внедрю через неделю, чтобы не тянуть.