WIP: почему команда делает много, а заканчивает мало
WIP: почему команда делает много, а заканчивает малоЕсть одна метрика, которую я люблю за простоту.
WIP — Work in Progress.
То есть сколько задач одновременно находится в работе.
Звучит скучно, но на практике это один из самых быстрых способов понять, почему команда вроде бы занята, а результата мало.
Типичная картина:
— один разработчик делает фичу
— параллельно чинит баг
— параллельно ждёт ревью
— параллельно отвечает на вопросы аналитика
— параллельно “быстро смотрит” срочную задачу
— параллельно у него ещё висит почти готовая доработка
В календаре человек занят.
В Jira всё двигается.
В чатах активность есть.
Но завершённых задач мало.
Проблема в том, что мозг не работает как процессор с бесконечным количеством потоков. Каждое переключение съедает контекст. Чем больше задач одновременно в работе, тем больше времени уходит не на работу, а на возвращение в неё.
Для тимлида WIP полезен как простой индикатор перегруза системы.
Если у команды одновременно открыто слишком много задач, почти всегда появляются симптомы:
— ревью копятся
— задачи долго висят в “почти готово”
— люди чаще забывают детали
— растёт количество мелких ошибок
— сроки становятся менее предсказуемыми
— все заняты, но мало что доезжает до done
Самое неприятное: высокий WIP часто выглядит как продуктивность.
Много карточек в работе.
Много обсуждений.
Много коммитов.
Много движения.
Но ценность появляется не когда задача “в работе”.
Ценность появляется, когда задача завершена и дошла до пользователя.
Что можно попробовать без сложных процессов:
1. Посмотреть, сколько задач сейчас реально в работе.
2. Отдельно посчитать задачи, которые “почти готовы”, но чего-то ждут.
3. На неделю договориться: не начинать новую задачу, пока не помогли закрыть старую.
4. Посмотреть, стало ли быстрее доходить до done.
Иногда лучший способ ускорить команду — не начать ещё одну задачу, а наконец закончить три старые.
А у вас чаще проблема в том, что задач мало в работе или наоборот слишком много?