Как фокус на занятости может повлиять на качество и гибкость в командах

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

В статье некоторые концепции объясняются при помощи системных диаграмм (Causal Loop Diagrams).

В первой части статьи мы подробно обсуждали, почему узкие специалисты в команде, работающие над “своими” задачами в Спринте, снижают общую скорость (Cycle Time) команды. Все дело в том, что узкие специалисты создают островки очередей. Когда возникает новая работа, то она помещается в конец очереди. А это влечет за собой увеличение общего времени выполнения задачи, ведь Cycle Time = Queue Time (время простоя в очереди) + Service Time (время работы над задачей).

Представьте, что я программист на Java, который максимально утилизирует свою узкую специальность и пишет код только для Backend. Команда, состоящая из подобных специалистов, создает большие очереди на каждом шаге разработки. И тогда время получение обратной связи от других шагов процесса, скажем, тестирования увеличивается.

Представьте, что я делаю некое предположение о протоколе в коде и получаю обратную связь через час. И совсем другое дело, когда это происходит через 30 дней. Тогда количество “сюрпризов” возрастает, потому что я в течение всех 30 дней использовал в коде неверное предположение. Ну а больше “сюрпризов” означает, что нужно работать еще упорнее. Вернемся к системной диаграмме и добавим усиливающую петлю.

В первой части статьи мы уже говорили о том, что Cycle Time = Queue Time (время простоя в очереди) + Service Time (время работы над задачей). С возрастанием Cycle Time общее время выхода с новой функциональностью на рынок (Leadtime) тоже возрастает, а это значит задержку в получении обратной связи и сниженная способность в реагировании на изменения на рынке. Когда мы не можем быстро выводить продукты на рынок и реагировать на изменения, то возникает организационный стресс. Но ментальная модель “организация эффективна, когда каждый загружен” подсказывает только одно решение — нужно работать еще упорнее. Давайте посмотрим на финальную системную диаграмму.

Несколько лет тому назад меня попросили помочь группе из 20 человек. Эта большая команда, по словам менеджмента, работала невероятно медленно, на нее уже махнули рукой. Никто не верил в то, что они могут работать быстрее. Мне было очень интересно разобраться в этой ситуации. Первое, что бросилось в глаза — все были невероятно загружены. Второе — все были сфокусированы на индивидуальной продуктивности и выполняли задачи только по основной специализации (Java, QA, Front etc.). Несмотря на ударный труд, работа продвигалась крайне медленно, фичи бесконечно долго выводились на рынок, а заказчики были недовольны. Команда хронически не выполняла прогноз, взятый на Спринт, а менеджмент считал, что ребята работают недостаточно ударно. В команде царила атмосфера общей подавленности.

Для начала я предложил ребятам визуализировать Бэклог Спринта. Так на стене появилась бумажная доска, которую ребята стали обновлять несколько раз в день. К сожалению, потом я заболел и появился лишь в самом конце Спринта. То, что я увидел, поразило. Вся доска была заклеена начатой, но не завершенной работой. За Спринт ребята создали огромные очереди-завалы на каждом из шагов процесса разработки, которые тормозили всю систему. Java-разработчики вообще оказались большими молодцами и “убежали” на несколько недель вперед. Они просто набрали новую работу из Бэклога Продукта.

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

• Занятость вызывает нелинейный рост очередей.
• Очереди повышают Cycle Time и снижают скорость команды.
• Очереди негативно сказываются на качестве из-за задержки обратной связи от других шагов процесса.
• Очереди задерживают обратную связь с рынка и снижают организационную гибкость.
• Визуализируйте Бэклог Спринта, чтобы увидеть очереди.

В следующей статье (третья часть) мы обсудим контр-меры, которые может предпринять Команда Разработки и их Скрам-мастер для того, чтобы побороть очереди.