Как понять, что команда занята, но не движется
Есть неприятная ситуация, знакомая многим тимлидам.
Команда вроде бы постоянно что-то делает. Задачи в Jira двигаются. Созвоны идут. В чатах активность. На дейли все рассказывают, чем заняты.
Но если посмотреть на результат, возникает странное ощущение: движения много, а прогресса мало.
Это один из самых опасных режимов для команды — высокая занятость без нормального потока результата.
Снаружи всё выглядит живым. Внутри система может быть забита ожиданиями, переключениями и незавершённой работой.
На что я бы смотрел в первую очередь.
1. Много задач “в работе”
Если у каждого разработчика по 3–5 активных задач, это не многозадачность. Это очередь из незавершёнки.
Человек переключается между контекстами, что-то ждёт, что-то чинит, что-то “почти доделал”. В итоге задач много, завершённых мало.
2. Задачи долго ждут ревью
Очень частый затык.
Код написан, но не принят. Разработчик уже ушёл в новую задачу. Потом прилетают комментарии, нужно снова вспомнить старый контекст. Потом ещё один круг.
Формально работа идёт. Фактически задача стоит в очереди.
3. Слишком много статусов и мало смысла
Если процесс выглядит красиво, но никто не может быстро объяснить, где именно тормозит задача, статусы не помогают.
“В работе”, “на проверке”, “на тестировании”, “ожидает релиза” — это полезно только если команда понимает, что с этим делать.
4. Регулярно появляются срочные задачи
Когда каждый день прилетает “вот это надо срочно”, план перестаёт быть планом.
Команда вроде бы занята, но не тем, что собиралась делать. А потом на ретро все удивляются, почему спринт опять не сошёлся.
5. Много обсуждений, но мало решений
Созвон был. Поговорили хорошо. Разошлись.
А кто принимает решение? Что делаем дальше? Кто владелец? Когда вернёмся к вопросу?
Если после встречи нет следующего действия, встреча легко превращается в имитацию движения.
Мне кажется, здесь важно перестать спрашивать только:
“Все ли заняты?”
И начать спрашивать:
“Что мешает задачам завершаться?”
Потому что эффективность команды — это не количество параллельной активности. Это способность стабильно доводить важные изменения до результата.
Что можно сделать практически:
1. Посмотреть, сколько задач сейчас одновременно в работе. 2. Найти задачи, которые дольше всего висят без движения. 3. Отдельно посмотреть очередь на code review. 4. Выписать все внеплановые задачи за последние 2 недели. 5. На ретро обсуждать не “кто не успел”, а “где поток ломается”.
Иногда команда не медленная. Иногда она просто забита работой, которая мешает другой работе завершаться.
А у вас где чаще всего застревают задачи: разработка, ревью, тестирование, согласования или релиз?
