Хватит начинать, начни заканчивать: как лечить завалы в команде

Давайте продолжим тему управления процессами в команде и поговорим о конкретных инструментах.

Я на своём опыте не раз успел убедиться, что в управлении процессами комбинации простых решений срабатывают чаще, чем одиночные сложные «выстрелы». Теперь я хочу рассказать об инструментах, которые применяю сам и оцениваю как высокоэффективные.

Начнём с метода, который звучит очень просто, но бывает довольно труден в исполнении. Этот инструмент — принцип «Хватит начинать, начни заканчивать».

⭐️ Два слова о вытягивающих системах

Для осознания этого принципа важно понимать, как устроены вытягивающие системы. В них новая задача берется в работу только тогда, когда предыдущая выполнена — то есть когда для этого есть реальная потребность и свободные ресурсы.

Проще говоря, мы не «нагребаем» задачи просто потому, что нам нечем заняться. Мы учитываем пропускную способность нашей системы и берем только то, что реально можем «переварить». В условиях IT-команды это может привести к простою некоторых ресурсов (например, если у них большой запас мощности по сравнению с другими этапами).

Более подробно о вытягивающих системах можно почитать в книгах «Цель» Элияху Голдратта и «Дао Toyota» Джеффри Лайкера.

⭐️ Вытягивающая система в команде

Если мы попытаемся построить вытягивающую систему в обычной команде разработки, то столкнемся с интересным эффектом: какие-то части системы окажутся бездействующими, так как производительность других этапов не позволяет освоить весь поток.

Несколько месяцев назад я писал цикл постов о том, как мы с командой решали подобную проблему: тестирование не справлялось с темпом разработки. В итоге нескольких оптимизаций мы добились нужного результата, но именно тогда я прочувствовал, что общая эффективность системы зависит от «бутылочного горлышка».

⭐️ Реализация принципа на практике

Вернёмся к принципу «Хватит начинать, начни заканчивать». В контексте вытягивающей системы он обретает глубокий смысл: если производительность системы определяется конечным результатом, то силы и время нужно вкладывать прежде всего в завершение уже начатой работы.

На практике это может выглядеть так: ➡️ разработчик пишет автотесты вместо того, чтобы брать новую задачу; ➡️ разработчик видит, что его коллега застрял, и помогает ему закрыть задачу; ➡️ тимлид блокирует попытки «докинуть» команде срочные задачи сверх лимита.

Этот принцип направлен на то, чтобы команда постоянно фокусировалась на финализации процессов. Это позволяет доставлять ценность потребителю чаще и быстрее. Приятный бонус — стабильное ощущение прогресса у команды, которая видит, как фичи регулярно «катятся на прод».

А первой точкой появления этого принципа в команде является голова её руководителя.

// Моя вытягивающая система блога готова принимать ваши 💛 на пост

В этом посте были ссылки, но мы их удалили по правилам Сетки